# Last EHR — Medplum [Health: Active]

**Category:** 🧬 Biology & Bioinformatics  
**Repository:** https://github.com/cbetz/last-ehr  
**GitHub Stars:** 4  
**npm Downloads (last month):** 16  
**Views:** 4  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/last-ehr-medplum

## Description
Read-only Medplum chart search and patient context for MCP clients.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "last-ehr-medplum": {
    "command": "npx",
    "args": ["-y","@lastehr/agent-write-conformance"]
  }
}
```

## Documentation

## What Last EHR — Medplum does

Last EHR — Medplum provides an MCP interface for reading patient records from a Medplum-backed FHIR EHR. It is an agent layer rather than an EHR or system of record: data remains in the connected FHIR backend, and the service does not store its own copy of protected health information.

The default MCP surface is read-only. Agents can search for patients, display patient information, inspect a bounded chart section with filters, and retrieve a document. The implementation is designed to report safety-relevant conditions instead of implying that a record is absent. For example, it can indicate when a read window was capped, a reference lookup was declined, or a code filter found no matches in a section that contains records.

The Last EHR — Medplum MCP server belongs in the Biology, Medicine and Bioinformatics category and is intended for patient-context workflows that need structured FHIR-backed reads.

## How it works

MCP tools call the connected FHIR API. For authenticated use, Medplum supplies the project context, authentication, tenancy, and access control. Last EHR does not replace Medplum’s Project, ProjectMembership, or AccessPolicy model; the connected token and Medplum policy determine what the agent can access.

The chart-reading surface covers 25 of the 27 readable US Core 9.0.0 resource types across 23 patient-scoped sections. References can be followed so related authors, encounters, and provenance are not left as unresolved identifiers. Unsupported filters are rejected with the permitted values rather than silently ignored.

Writes are not part of the default read flow. When enabled, the agent proposes an exact FHIR resource, a human makes an explicit decision, and only an approved proposal is committed. MCP write proposals use elicitation to obtain that decision. This approval boundary prevents an agent from directly saving a change, but it does not verify that the proposed clinical content is correct.

## Setup and configuration

Install and initialize the MCP package with `npx -y @lastehr/mcp init --client claude-code`, then configure a least-privilege Medplum token before connecting to a real project. The repository also provides a local MCP demo using a synthetic HAPI FHIR stack; that path is intended for fixture data and does not require FHIR or Medplum credentials.

The local lab is restricted to synthetic fixture patients. It is useful for inspecting the MCP read surface, but it is not generic HAPI support and is not a path for handling PHI. The project describes Last EHR as early and alpha, so APIs, structure, and scope may change.

## Tools and capabilities

- Search patients with `search_patients`.
- Display patient context with `show_patient_info`.
- Read a filtered chart section with `read_chart_section`.
- Retrieve a document with `read_document`.
- Enable elicitation-gated write proposals for approved changes.
- Preserve bounded-read signals such as capped windows and refused filters.

## Limitations and notes

Last EHR — Medplum is not a charting application, Medplum replacement, or system of record. It is a thin tool layer over a FHIR backend. Authenticated Medplum deployments are supported; the repository also identifies HAPI FHIR, Firely Server, Aidbox, and Oystehr adapters for synthetic evaluation, while other FHIR R4 backends require an adapter.

Use synthetic data while evaluating the project. The approval gate is a human review boundary, not a clinical, authorization, compliance, or safety certification. Models may still propose incorrect or fabricated facts, and the reviewer remains responsible for examining each proposed write before approval.

_Full upstream README: https://allmcps.com/mcp/last-ehr-medplum/readme_