Reported issues for Last EHR — Medplum

Pod holds 14 of 14 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to Last EHR — Medplum.

Most discussed

Backend adapter: Oystehr — auth path and synthetic contract spike

Goal

Investigate and document the narrowest viable Oystehr FHIR adapter path for Last EHR, then validate it against the shared FHIR backend contracts using synthetic data only.

First verification target

• Identify the exact Oystehr FHIR endpoint, version, and supported development/sandbox workflow.
• Select the first supported auth story and document how a maintainer can obtain non-production credentials.
• Keep the work as a draft adapter until it has a repeatable contract-test path.

Read the thread · 2026-07-10 · open · 1 comment

Backend adapter: Firely Server — verification path and REST contract

Goal

Establish a reproducible Firely Server adapter spike for the FhirBackend contract, including the exact server version and authentication assumptions needed for reviewers to verify it.

First verification target

• Identify a supported Firely Server deployment path (local container or disposable sandbox) and version.
• Confirm whether the first useful path is no-auth local evaluation, bearer token, or another documented mode.
• Keep this target out of the runtime backend selector un

Read the thread · 2026-07-10 · closed · 1 comment

Backend adapter: Aidbox — auth spike and contract validation

Goal

Create a documented, synthetic-data-only Aidbox adapter spike for Last EHR’s FhirBackend contract. The outcome can be an implementation PR or a short no-go report if the target cannot meet the contract cleanly.

First verification target

• Confirm a concrete Aidbox version or sandbox/container path.
• Choose and document the first viable auth mode (for example, client credentials or a static development bearer token).
• Do not add FHIR_BACKEND=aidbox to the runtime factory until

Read the thread · 2026-07-10 · closed · 1 comment

Expose the agent tools over MCP

The four FHIR tools (search_patients, show_patient_info, add_note, record_observation) are plain functions over FHIR REST, so exposing them as an MCP server is a natural second surface: Claude Desktop, Claude Code, or any MCP client could work a chart against your Medplum project.

The open question is the approval gate, which is the point of the project. In the web app, needsApproval renders a card with the exact payload and nothing saves until you approve. Over MCP, the host's own tool-use app

Read the thread · 2026-07-02 · closed · 1 comment

Oystehr adapter

Second backend target, chosen on strategic fit: Oystehr is the platform behind the open-source Ottehr project, and that community is exactly the audience building on headless EHRs.

• FHIR-native (R4B recommended) with full CRUD/search/batch/history.
• M2M clients use standard OAuth2 client credentials (same shape as the quickstart).
• Users vs M2M actors map onto the signed-in-user model; Allow/Deny Access Policies are close to Medplum's.
• Caveat: no free tier today (paid sandbox), which is fr

Read the thread · 2026-07-02 · closed · 1 comment

Aidbox adapter

First non-Medplum backend target, chosen on technical fit:

• Full FHIR R4 REST for all resource types Last EHR uses, including Communication.
• Built-in OAuth2 with a client-credentials flow that maps 1:1 onto the existing quickstart (server-minted token into an HttpOnly cookie).
• Access control is literally a resource named AccessPolicy, so the "writes bounded by your AccessPolicy" story ports almost word for word.
• Free dev license means contributors can test without paying.

Depends on t

Read the thread · 2026-07-02 · closed · 1 comment

Harden the boundary against literal closing tags in chart free text

Found during adversarial review of #136 (pre-existing, applies to every wrapped field — notes as much as tasks).

asChartText wraps free-text chart content in <chart_text>…</chart_text> so the system prompt can declare it data-not-instructions. A chart value containing a literal </chart_text> closes the boundary early, letting the remainder of the value read as non-chart content to the model.

Mitigations to evaluate:

• Escape or strip literal </chart_text> sequences inside wrapped value

Read the thread · 2026-07-19 · closed · 0 comments

MCP write profile: elicitation-gated, proposal-shaped writes in @lastehr/mcp 0.2.0

ROADMAP §5 conditions any MCP write surface on "a reviewable confirmation protocol." That protocol now exists: MCP elicitation (spec rev 2025-06-18, kept in 2025-11-25) lets a server pause mid-tool-call, present a message + flat schema to the human via client-rendered UI, and receive an explicit accept / decline / cancel. Clients declare the elicitation capability at initialization, so the server can fail closed on hosts that cannot render approvals. This issue is the design gate befor

Read the thread · 2026-07-19 · closed · 0 comments

Most recent

Friendly preflight error when Docker is not running (demo:local, mcp:demo)

If the Docker daemon is not running, npm run demo:local and npm run mcp:demo fail with raw docker compose stderr. First-run evaluators should get a clear, actionable message instead.

What to do

• Add a small preflight to scripts/demo-local.ts and scripts/mcp-demo.ts (or a shared helper) that runs docker info (or equivalent) before docker compose up.
• On failure, print one clear line, e.g.: `Docker does not appear to be running. Start Docker Desktop (or your Docker daemon) and re-

Read the thread · 2026-07-12 · open · 0 comments

@lastehr/mcp: add a --version flag to the CLI

The MCP CLI (packages/mcp/src/cli.ts) supports init, doctor, and --help, but not --version/-v. Bug reports currently have no easy way to state which version is installed.

What to do

• Handle --version and -v in the argument parsing in packages/mcp/src/cli.ts: print the version from the package's package.json and exit 0.
• Read the version at build time or via a small import so it works from the published npm package (the compiled dist/cli.js), not just the repo checkout.
• Men

Read the thread · 2026-07-12 · closed · 0 comments

Docs: add a troubleshooting section for the local lab

docs/quickstart.md and docs/mcp.md walk through the local HAPI stack (npm run demo:local, npm run mcp:demo) but there is no troubleshooting section, and a repo-wide grep for "troubleshoot" comes up empty.

What to add

A short Troubleshooting section in docs/quickstart.md (and a pointer from docs/mcp.md) covering the failure modes a first-time evaluator actually hits:

• Docker Desktop / the Docker daemon is not running
• Port 8080 is already in use (another HAPI or app)
• HAPI is slo

Read the thread · 2026-07-12 · open · 0 comments

MCP server: FHIR_BACKEND support

mcp/server.ts still authenticates only against Medplum (token or client credentials). Now that FHIR_BACKEND=hapi exists for the app and seed, the MCP server should honor the same env pair (FHIR_BACKEND + FHIR_BASE_URL) so a fully local stack gets MCP too. Small change: the server already builds tools over a FhirBackend; only its auth bootstrap is Medplum-specific. The read-only default stays.

Read the thread · 2026-07-08 · closed · 0 comments

Operator-authored system prompts (Communication resources)

Medplum's Spaces loads its prompts from Communication resources, which proves the pattern first-party. A backend-portable variant fits this project: an optional, operator-authored system-prompt override loaded from a Communication with a well-known identifier, working on any FhirBackend (Communication is core FHIR, so it works on HAPI too).

Constraints from the start: excluded on the shared public demo (a visitor-writable resource must never steer the agent), never loaded from session-tagged re

Read the thread · 2026-07-08 · open · 0 comments

invoke_bot: approval-gated Medplum Bot invocation

Design (researched, adversarially challenged) for letting the agent trigger Medplum Bots behind the approval gate:

• Tool shape: list Bot resources the caller can read, propose an invocation (bot name + input payload rendered on the approval card), execute via $execute on approval.
• A backend capability interface (e.g. supportsBots) gates the tool so non-Medplum backends and deployments without the bots feature never expose it. Note: the demo's client-credentials session cannot rely on a per-u

Read the thread · 2026-07-08 · open · 0 comments

The remaining reports are on the project's issue tracker.