We are excited about it too. However, healthtech has been doing this for more than 40 years.

At Medplum, forward deployed engineering is not a trend we picked up. Healthtech companies have always built software in a "forward-deployed" manner, embedding engineers directly in the clinic to learn directly from interactions between healthcare providers and patients. This post is about what an FDE is, why healthcare got here early, how we think about the role at Medplum, and the values our team lives by. And, if any of this resonates, we would love to hear from you.

What is a Forward Deployed Engineer?​

Forward Deployed Engineers (FDEs) were first coined by Palantir, and initially, these engineers were literally deployed at military bases and other customers sites to build and deploy software. Sitting next to the people using the product meant engineers understood the real problem and could iterate in hours instead of quarters. For over a decade it stayed mostly a Palantir thing. Then it spread across enterprise software: Scale AI and C3 AI took the title directly, and Databricks and Snowflake built equivalents.

In the last two years, AI has made software itself easier and cheaper, shifting the bottleneck for growth to everything around the code itself: integrating with messy existing systems, mapping a product onto a customer's actual workflow, and getting them to adoption. That work is irreducibly human and contextual, and it is where FDEs live. OpenAI, Anthropic, Ramp, and ElevenLabs have all built FDE functions of their own. Leo Mehr's post on Ramp's FDE team is some of the best writing on this shift.

FDE is table stakes in healthcare​

While enterprise tech treats forward deployed as a new idea, healthcare buyers have expected white-glove, on-the-ground engineering for as long as the industry has existed.

Epic, the largest healthtech player in the United States, started with white-glove engineering. Judy Faulkner founded what became Epic Systems in 1979, building a custom solution to track patient data over time for a single group of physicians. For roughly the first decade, Faulkner and her team kept building one-off solutions for physician groups, using what they learned in the field to eventually ship EpicCare, their first EHR, in 1992. The philosophy of designing software from inside the doctor's office never left. To this day Epic sends all engineers on "immersion trips", where they sit in on patient visits and watch clinicians use the software in the room where the work actually happens.

Healthcare systems are complex and bureaucratic, the stakes are high, and the largest vendor in the market built its reputation and empire by putting engineers on-site. Buyers have come to expect exactly that. So for a company like Medplum, the FDE function is not optional.

What is different for us is the surface area. Medplum is an open-source, FHIR-native developer platform. At this stage, our customers are primarily not buying a finished clinical workflow off the shelf; they are building on top of us. So our version of an immersion trip is going deep on a customer's integration and interoperability problems — their data model, their existing systems, the standards they need to speak — and building alongside them.

How we run FDE​

In healthcare, the complexity and the revenue concentrate in the same place: large, sophisticated organizations, often running on legacy technology. Those are the customers with the largest operational challenges, who will likely not succeed on self-serve SaaS alone, and the customers worth winning. FDE is the engineering capability that lets us land them, get them to production, and keep them there. It is how Medplum moves upmarket. An FDE team is not a cost of doing enterprise business; it is the thing that makes Medplum's enterprise business possible.

To do that well, we map FDEs to the entire customer lifecycle rather than siloing it to a single function. The same person who scopes a pilot is there for our customers through implementation and rollout and into long-tail support. Context never gets lost in a handoff, relationships compound, and we stay accountable for whether a customer is actually getting value — not just whether we closed the deal or hit an implementation milestone.

Two structural facts about Medplum sharpen this. We have no product managers (as of this writing), and we are open source. At most companies, an FDE deploys the product as it is, and product managers decide what gets built next. We do neither. Our FDEs are the primary input to the roadmap: we triage every issue, feature request, and bug from customers and the community, set the priorities, and when it's the right call, ship the code ourselves. An FDE here owns both ends: not just getting a customer to value on today's product, but shaping what the product becomes.

Bedside manner, and the values of our FDE team​

There is a concept our FDE team borrows directly from our customers: bedside manner.

Bedside manner is a clinician's way of relating to a patient: communicating without jargon, respecting the patient's time and privacy, listening actively, and carrying warmth in the small nonverbal cues. It is what produces a good clinician-patient relationship: clearer communication, more trust and honesty, higher satisfaction with care.

The stakes of FDE bedside manner are lower, but the mechanism is identical: trust is built in how you show up, and trust is the whole job. Let me be clear about what this is not — it is not a substitute for engineering depth. A great clinician is both deeply knowledgeable and has excellent bedside manner; one without the other does not work. The same is true of an FDE. We hire strong engineers, many of them from pure software backgrounds, and then we explicitly train the relational skills, because both halves are the job.

Our six values make this concrete. They fall into three pairs.

Bedside manner: empathy and expertise​

Develop Customer Empathy. Always assume the best of a customer. Steel-man their position before you argue with it. Know exactly what you have committed to, and hold yourself absolutely accountable to it.

Present Expertise. An FDE is not a router or a recorder — you are the expert in the room. Be comfortable telling a customer what they need, and present it calmly and confidently. Confidence, delivered with empathy, is what instills trust.

These two are bedside manner in full: the warmth to assume good faith and the authority to lead. Empathy without expertise is a pleasant meeting that goes nowhere. Expertise without empathy is a correct answer nobody acts on.

Drive: keep moving, keep improving​

Keep the Ball in Our Court. There is always an action we can take to move a customer forward, and we follow through on our own ideas. Even when we are waiting on someone else, the wait is a deliberate move with a clear objective — never a stall.

Continually Improve. We do more with less by automating our own jobs. The FDE who automates a task out of existence has just bought time for the next customer.

Rigor: zero ambiguity, built to last​

Leave Zero Ambiguity. Internally, everything is written down — preferably in a public channel — so understanding is shared and nothing is lost when context changes hands. Externally, we relentlessly seek ground truth from the customer and validate every assumption rather than guessing.

Build Resilience. Assume chaos and plan for it. Cultivate more than one relationship inside each account. Write defensive, well-tested code. Build redundant team processes so that no single point of failure — a person, a relationship, a script — can take a customer down.

It is worth noting that this last pair is not in the standard FDE playbook. Most FDE writing stops at empathy and hustle. We hold ourselves to writing everything down and engineering for failure because healthcare is unforgiving in a way most software is not: the systems are chaotic, the data is sensitive, and the cost of an outage or a misunderstanding is measured in patient care, not just churn.

Who thrives here​

If you are reading this as a prospective FDE, here is what we actually screen for.

Drive comes first. It is the best predictor we have found of who will be great at this job. The combination of engineering depth, the industry we work in, and the communication skills we need for this job are rare, and thus we expect to do some level of training with everyone who joins. However, the drive to learn what needs to be learned cannot be replaced.

Engineering fundamentals are a bar to clear, not a number to maximize. You need to be a genuinely capable engineer; you do not need to be the strongest competitive programmer we have ever interviewed. Modern AI tooling has lowered the cost of writing and learning code, which means judgment, ownership, and the ability to learn a new domain fast matter more than raw algorithmic horsepower.

Customer empathy and communication are the bedside-manner half, and we weight them heavily. Can you defuse a tense call? Can you tell a customer "no" or "not like that" and have them thank you for it? Can you write something clear enough that a stranger understands it next week?

You do not need to come from healthcare. You do need an appetite for its complexity — the standards, the regulation, the clinical reality — and the patience to learn it properly. We hire strong engineers and teach the rest.

If that sounds like you, we are hiring. Come build with us! https://www.medplum.com/careers/forward-deployed-engineer

Scheduling saw a lot of activity. The Provider App gained a reusable inbox shell, and operation-based claim submission. SMART Health Cards and Links arrived with a QR code scanner, the Enterprise data warehouse export was released, and the AI workspace added configurable model routing. The platform also gained email-based multi-factor authentication, enforceable per project.

All of this continues to drive forward our 2026 roadmap priorities.

Features​

Scheduling​

Noah Silas

Building on May's operation suite, June moved scheduling to a Beta release and tightened the rules around how appointments are booked:

• Scheduling API Beta — The appointment operation suite is now a Beta release, and the older Slot-based alpha implementations have been removed in favor of the appointment-based flow
• $book alignment enforcement — Booking now enforces scheduling alignment, and $find supports nondivisible alignment times so slots respect configured intervals
• Planning horizon constraints — Scheduling operations are now constrained by Schedule.planningHorizon, and scheduling parameters can be inherited from the HealthcareService
• Availability defaults — Availability now defaults to "always" when unset, with the requested time slot included in availability error messages for clearer feedback (Rohith Vangalla)
• Provider scheduling flow — The Provider App streamlines encounter creation, links Appointment.slot, adds an Appointment confirm button, and moves to FullCalendar v7
• Cancelled-appointment slots — The schedule view now hides slots tied to cancelled appointments, so a cancellation frees the time back up instead of leaving a stale block

Provider App​

David Yanez

The Provider App gained reusable building blocks and revenue-cycle improvements:

• ResourceBoard inbox shell — A new React shell that encapsulates inbox logic, providing a reusable foundation for task and worklist views
• Performing practitioner in care teams — Care team fields now support a performing practitioner, improving attribution in clinical workflows
• Operation-based claim submission — Claim submission now uses a server-side FHIR operation, and the app creates or updates the Claim during export or submit, simplifying the billing integration
• Patient documents tab — A dedicated documents tab on the patient view, with inbound faxes now stored as DocumentReference resources so they land in the chart alongside other records
• Medications in the patient summary — MedicationStatement resources appear in the PatientSummary component, and both MedicationStatement and DocumentReference now resolve to readable display strings (Cody Ebberson)
• Self-service registration — A Register page for the Provider App lets new users sign up directly, with the reCAPTCHA widget hidden in the app shell (Cody Ebberson)
• Navigation polish — Navbar visual tweaks and a HeaderDropdown refactor (Kevin Shaw), plus fixes to the back button after fax loading and to autoscrolling (Noah Silas)

AI​

David Yanez and Maddy Li

AI work centered on the Spaces workspace — the in-app AI assistant in the Provider App — and real-time documentation:

• Configurable model routing — Spaces now supports a configurable base URL and a dynamic model list, so deployments can route AI requests through their own gateway to control cost and security
• AI real-time questionnaire form and real-time voice — A real-time questionnaire form plus voice input improvements that keep the socket active during a session
• Spaces UX — Prompt composer UI updates and grouping of each FHIR request with its corresponding response for clearer traceability

The Spaces documentation covers setup, the agent loop, and how to author the system prompts that drive its behavior. Here is a short walkthrough:

Identity, Sharing, and Documents​

Cody Ebberson

• Multi-factor authentication — A new email-based MFA method, plus a project-level mfaRequired setting that enforces MFA for every member, with documentation for enabling it (Derrick Farris)
• External token exchange across project memberships — Token exchange now works across project memberships, for users who span multiple projects
• Attachment handling — Inline attachments in Patient/$everything, base64 data support in <AttachmentDisplay>, and cursor pagination across patient-everything and multi-type searches
• Patient invite with RelatedPerson — The user invite endpoint accepts a Patient to support RelatedPerson, enabling caregiver and proxy access (Maddy Li)

Enterprise: Data Warehouse and Reliability​

Karl Pietrzak and Matt Long

Enterprise scale and infrastructure work made the analytics export production-ready and hardened the data layer:

• Data warehouse export controls — Configuration for which tables to sync, include/exclude filters, restored ORDER BY, and DuckDB lifecycle cleanup give data teams precise control over what reaches their lakehouse
• Transaction-scoped repositories — Repository connections are now transaction-scoped, with idle-in-transaction time tracked, improving reliability under load
• FHIRPath Patch — A FHIRPath Patch utility wired into the server for targeted resource updates (Matt Willer)
• Project-level SMTP — Projects can now configure their own SMTP settings for sending email (Darren Eam)

Agent and Connectivity​

Derrick Farris

The on-premise Agent — Medplum's connectivity service for legacy healthcare systems and HL7 interfaces — saw a concentrated round of reliability work this month:

• Durable HL7 message queue — The Agent now persists inbound HL7 messages to a durable queue, so messages survive restarts and transient outages instead of living only in memory
• Resilient Agent/$upgrade — A batch of fixes to the Agent upgrade flow: no more duplicated messages during an upgrade, a guard that checks for the upgrade artifact before unlinking it, and a documented upgrade bugfix, alongside a new Agent/$upgrade documentation page
• Reconnection hardening — The Agent now reconnects across a range of error states, records the acknowledgement before returning in acknowledgement-only mode, and triggers a clean shutdown before awaiting channel start
• Agent/$reload-config — A documented operation to reload a deployed Agent's configuration without a full restart
• WebSocket subscription reliability — A series of fixes recreate WebSocket subscriptions on reconnect, tear down the Redis listener cleanly on shutdown, bind the message listener before subscribing, and send a handshake on connection establishment

Compliance​

Cody Ebberson and Reshma Khilnani

Medplum achieved HITRUST certification this month — the headline of our compliance track. HITRUST is one of the most rigorous, prescriptive security frameworks in healthcare, and certification gives customers third-party assurance of Medplum's security and compliance program for their own vendor reviews. Several other pieces of the track also moved:

• HITRUST documentation — Published HITRUST documentation alongside the certification, and pointed compliance references at the Medplum Trust Center (with an updated Vanta Trust Center link)
• SMART Health Cards and Links — Support for SMART Health Cards and Links, including a QR code scanner and updates for the CMS "Keep the Card" (KTC) program, giving patients a verifiable, portable record

• Patient/$match with CMS criteria — The patient match operation now follows CMS matching criteria, aligning identity resolution with federal guidance
• Patient data access fixes — Corrected Patient/$everything pagination links and normalized C-CDA address handling, keeping patient-record exchange complete and standards-conformant (Joshua Kelly)
• Electronic prior authorization — Continued progress on electronic prior authorization toward the HTI-4 requirements ahead of the January 2027 enforcement date

Documentation​

Cody Ebberson

• Self-hosting fixes — Corrections across the Azure, GCP, and Kubernetes self-hosting guides, a Debian package fix that preserves local edits on upgrade and restores the DuckDB native dependency, and production Docker base images pinned to Node 24.18 (Karl Pietrzak)

Provider App and platform

• Shared Projects — New documentation on shared projects (Finn Bergquist)
• Multi-lingual FHIR support — Docs and a demo app for multi-lingual FHIR support (Ian Plunkett)
• Agentic engineering guide — A new agentic engineering guide and companion blog post (Everett Williams)
• AI real-time docs and Alpha/Beta feature expectations — Documentation for the AI real-time operation and a guide to what Alpha and Beta feature labels mean (Andy Stoneman, Noah Silas)

Integrations

• Electronic prescribing — Expanded e-prescribe documentation, including prescriber profile setup and staging NPI creation (Andy Stoneman, Maddy Li)
• Lab orders — Public docs for lab account number updates (Andy Stoneman)
• Clearinghouse claim submission — Claim submission documentation for clearinghouse connectivity (Finn Bergquist)

Bug Fixes​

FHIR and billing

• Render CMS-1500 Box 24E diagnosis pointers correctly (contributed by Andrew Wong)
• Prevent duplicate resources in convertToTransactionBundle (contributed by Steven Matthiesen)
• Normalize address part text nodes in C-CDA mapAddresses (contributed by Joshua Kelly)

Server and async

• Stop polling a cancelled AsyncJob by returning 200 from the status endpoint, and add Accept-Encoding: identity to token exchange (contributed by Raphael Malikian)
• Bound the 401 retry in MedplumClient to prevent infinite retry loops (contributed by Joshua Kelly)
• Paginate AWS Textract results via NextToken (contributed by Jake Diaz-Iglesias)
• Recreate WebSocket subscriptions on reconnect (contributed by Drew McDonald)
• Record the authenticating ClientApplication on AuditEvent.agent[] (contributed by Jesse Carter)

From the Blog​

Longer-form writing published this month:

• Medplum Achieves HITRUST e1 Certification by Reshma Khilnani — The certification announcement and what it means for customers
• Medplum Scheduling API: Beta Release by Noah Silas — A deeper look at the appointment operation suite now in Beta
• Large Patient Charts by Cody Ebberson — Handling patients with very large charts at scale
• Vibe Coding on Medplum by Everett Williams — Building on Medplum with AI coding assistants, the companion to the agentic engineering guide
• From BLE to FHIR: Streaming Clinical-Grade Biosignals with AnyBio + Medplum by Stephen Saine — Streaming device biosignals into FHIR

Releases​

• v5.1.14 — June 1
• v5.1.15 — June 3
• v5.1.16 — June 8
• v5.1.17 — June 9
• v5.1.18 — June 15
• v5.1.19 — June 20
• v5.1.20 — June 20
• v5.1.21 — June 20
• v5.1.22 — June 24

Looking Ahead​

June brought scheduling to Beta, made the Enterprise data warehouse export production-ready with selectable table sync, and added configurable model routing to the AI workspace. SMART Health Cards and Links, operation-based claim submission, and a reusable inbox shell round out a month focused on Provider App depth and platform reliability.

Join us on Discord to share feedback or follow along on GitHub.

Medplum's Scheduling API provides an interface for applications to atomically interact with Schedule, Slot, and Appointment resources to safely create and manage bookings without creating scheduling conflicts. Developing a feature like this required the ability to iterate as we learned, and our Alpha period provided exactly that.

What changed during Alpha​

We made some breaking changes over the course of the Alpha period to simplify the API surface and support multi-resource scheduling:

• Removed Schedule/:id/$find: This route has been replaced by Appointment/$find, which handles single-Schedule lookups as a basic case of its ability to query multiple Schedules at once.
• Removed slot-based Appointment/$book: The slot parameter input to $book has been removed. The operation now only accepts an appointment as input, which can act as a container for the potentially many Slot resources involved in a single atomic booking operation.
• HealthcareService as required service type: Our original specification considered using ActivityDefinition resources as an optional place to store shared service type definitions. After considering the impact it would have when booking appointments with several participants, we decided to require that service types be explicitly defined as HealthcareService resources, and a reference to such a healthcare service must be included to search for available appointments in $find.
• Changed availability format: We've chosen a storage format for customizing availability that mirrors the FHIR R5 Availability type. This will let us migrate these definitions easily when Medplum Server adds support for later FHIR releases.

The Beta API surface​

The Beta API consists of five operations:

What Beta means​

The core API contract is now stable. Breaking changes are still possible during Beta, but we will note them in release notes and provide a migration path where practical. The API is appropriate for production use in non-critical workflows. See our Alpha & Beta policy for the full details.

Get started​

Check out the Scheduling documentation for a full reference, including how to define availability, find open slots, and book appointments.

Thank you to all our partners who experimented with the API during the Alpha period and provided such valuable feedback!

There's a lot of plumbing in that gap: device integration, real-time ingest, signal processing, derived metrics, provenance, governance, FHIR projection, US Core conformance, and most of it is undifferentiated infrastructure that takes a year or more to build properly.

AnyBio handles the upstream half of that pipeline. Medplum handles the downstream half.

Together they give you a standards-based path from a BLE sensor on a patient's wrist to a US-Core-conformant Observation in a queryable FHIR record - and on the AnyBio side, wiring up that path is a configuration step, not an engineering project.

This post walks through what each side does and how the data is shaped, then gives you two ways in: a two-minute path that exports a synthetic demo run to your own Medplum instance with zero setup, and the full production wire-up. And - because "it works in the demo" is not the same as "I'd run this in production" - how the pipeline behaves when things go wrong.

The pipeline at a glance​

BLE device / wearable
  -> AnyBio SDK: Web Bluetooth (browser) or iOS (real-time stream, zero-data-loss buffer)
    -> AnyBio ingest (multi-device session handling: time-aligns and
        deduplicates concurrent streams from multiple sensors)
      -> Signal pipeline (DSP, partner algorithms via WASM)
        -> Composite + derived metrics (multi-modal correlation)
          -> Governance + audit (BAA, chain-of-custody)
            -> FHIR projection (US Core 6.1.0, multi-coded)
              -> Medplum (FHIR R4 transaction Bundle POST)

Two things worth saying up front:

1. FHIR is the delivery format, not the work. By the time data reaches Medplum it has been through a real-time pipeline that includes provenance stamping, algorithm execution, and US Core profile validation. The "FHIR-native" claim has teeth because the pipeline is engineered around producing valid resources - not because we serialize to JSON at the end.

2. Medplum is the right downstream for this. It's open-source, fully FHIR-native on R4 (4.0.1), runs a permissive but conformant validator, and - critically for development - auto-creates referenced Patient resources on first write, so you can stand up an end-to-end demo without wiring identity matching first. (More on why that's a dev-only convenience below.)

What AnyBio sends to Medplum​

The standard payload is a FHIR R4 transaction Bundle containing:

• Observation resources - one per measurement or derived metric: vital signs, HRV, derived classifications, multi-modal composites.
• DocumentReference + Attachment - for telemetry strips (ECG, EDA, PPG waveforms) rendered as PNG/PDF artifacts.
• Provenance - chain-of-custody from device through algorithm to derived artifact.
• Patient reference - a logical reference; Medplum resolves or auto-creates it.

Every Observation carries its lineage and its reproducibility metadata using standard FHIR elements - not custom fields:

• Multi-coded code - LOINC primary, AnyBio CodeSystem secondary. The AnyBio CodeSystem lives at a public, dereferenceable canonical URL (https://api.anybio.io/fhir/CodeSystem/biosignal) generated from our biosignal registry, so Coding.system resolves to a real CodeSystem resource.
• derivedFrom - derived metrics reference the source Observation(s) they were computed from, so any classification traces back to the raw signal it came from. This is FHIR's standard Observation.derivedFrom, a Reference(Observation).
• device - points to a Device resource representing the algorithm/sensor that produced the value, with the algorithm version in Device.version (e.g., anybio-hrv-v3.2). That's where reproducibility lives.
• Provenance - the emitted Provenance resource stamps the full device -> algorithm -> artifact chain with timestamps and version identifiers, so "which version produced this value" is answerable from the record itself.
• US Core meta.profile - asserted per resource type and validated in CI (details in the next section).

Here's a heart-rate Observation on the wire - a primary vital sign, with a device reference for reproducibility:

{
  "resourceType": "Observation",
  "status": "final",
  "meta": {
    "profile": ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-heart-rate"]
  },
  "category": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/observation-category",
      "code": "vital-signs"
    }]
  }],
  "code": {
    "coding": [
      { "system": "http://loinc.org", "code": "8867-4", "display": "Heart rate" },
      { "system": "https://api.anybio.io/fhir/CodeSystem/biosignal",
        "code": "heart-rate", "display": "Heart rate" }
    ]
  },
  "subject": { "reference": "Patient/<patient-id>" },
  "effectiveDateTime": "2026-06-15T14:32:11Z",
  "valueQuantity": {
    "value": 72,
    "unit": "beats/minute",
    "system": "http://unitsofmeasure.org",
    "code": "/min"
  },
  "device": { "reference": "Device/<algorithm-device-id>" }
}

A derived metric - say an HRV-based autonomic-state classification - links back to its sources via derivedFrom and names the producing pipeline via method and device:

{
  "resourceType": "Observation",
  "status": "final",
  "category": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/observation-category",
      "code": "procedure"
    }]
  }],
  "code": {
    "coding": [
      { "system": "https://api.anybio.io/fhir/CodeSystem/biosignal",
        "code": "hrv-autonomic-state", "display": "HRV-based autonomic state" }
    ]
  },
  "subject": { "reference": "Patient/<patient-id>" },
  "effectiveDateTime": "2026-06-15T14:32:11Z",
  "method": {
    "coding": [
      { "system": "https://api.anybio.io/fhir/CodeSystem/method",
        "code": "anybio-hrv-v3.2", "display": "AnyBio HRV pipeline v3.2" }
    ]
  },
  "device": { "reference": "Device/<algorithm-device-id>" },
  "derivedFrom": [
    { "reference": "Observation/<source-rr-interval-obs-id>" }
  ],
  "valueCodeableConcept": {
    "coding": [
      { "system": "https://api.anybio.io/fhir/CodeSystem/autonomic-state",
        "code": "balanced", "display": "Balanced" }
    ]
  }
}

Blood pressure is the case worth showing explicitly, because it's the classic conformance trap: there is no top-level value, only component entries. AnyBio ships it as a us-core-blood-pressure panel:

{
  "resourceType": "Observation",
  "status": "final",
  "meta": {
    "profile": ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-blood-pressure"]
  },
  "category": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/observation-category",
      "code": "vital-signs"
    }]
  }],
  "code": {
    "coding": [
      { "system": "http://loinc.org", "code": "85354-9", "display": "Blood pressure panel" }
    ]
  },
  "subject": { "reference": "Patient/<patient-id>" },
  "effectiveDateTime": "2026-06-15T14:32:11Z",
  "component": [
    {
      "code": { "coding": [
        { "system": "http://loinc.org", "code": "8480-6", "display": "Systolic blood pressure" }
      ]},
      "valueQuantity": {
        "value": 118, "unit": "mmHg",
        "system": "http://unitsofmeasure.org", "code": "mm[Hg]"
      }
    },
    {
      "code": { "coding": [
        { "system": "http://loinc.org", "code": "8462-4", "display": "Diastolic blood pressure" }
      ]},
      "valueQuantity": {
        "value": 76, "unit": "mmHg",
        "system": "http://unitsofmeasure.org", "code": "mm[Hg]"
      }
    }
  ]
}

Waveform artifacts ship as DocumentReference + Attachment, with the source signal coded in category. For dense numeric series (the raw samples behind those strips), FHIR's valueSampledData packs a regularly-sampled run into a single Observation — see Medplum's Using valueSampledData for Time Series.

Conformance and validation - the part you can check​

Conformance here is structural, not aspirational, and we've tried to make every claim verifiable rather than asking you to take our word for it:

• Registry-driven projection. Adding a new biosignal is a row in our registry, not a code change. The projection logic is identical for every signal type, which is what keeps conformance consistent across the board.
• Validated in CI against the real tool. Every resource type is validated against US Core 6.1.0 using the official HL7 FHIR Validator (validator_cli.jar), and the build fails on any validation error. We track warnings separately - US Core emits informational warnings even on fully conformant resources, so "zero errors" is the meaningful bar, and that's the one CI enforces.
• Published conformance. AnyBio exposes a CapabilityStatement describing the resources, profiles, and interactions it produces, so you can diff our asserted conformance against what actually lands in your server.

A note on the version pin. We target US Core 6.1.0 deliberately - not because it's the newest (it isn't; US Core is now published through 8.0.0, with 9.0.0 in ballot), but because 6.1.0 is the version aligned with ONC's (g)(10) certification criteria that production EHRs are held to. Medplum's own API is an open-source implementation of those same (g)(10) criteria, so the two line up by design. US Core remains FHIR R4-based - the move to R6 is under consideration but has no timeline - so R4 here is the standard, not a legacy choice. When the certification baseline moves, the registry-driven projection lets us re-target with a profile bump rather than a rewrite.

Try it in two minutes - no hardware, no code​

The fastest way to watch US-Core Observations land in your own Medplum is the Device Console demo export. It runs a synthetic biosignal scenario in your browser and ships the result to your sandbox Medplum, so you can see the conformant output end to end before wiring up a single device.

1. Sign in. Go to secure.anybio.io and sign in with Apple, Google, or Microsoft. A sandbox environment is provisioned for you automatically.
2. Run the demo. Open the Device Console and click Try Demo. AnyBio streams a synthetic scenario (ECG, PPG, HR, SpO2) in the browser and shows a live summary with the derived metrics.
3. Export. On the summary, click Export to EHR / Medplum and paste your sandbox Medplum client ID, client secret, and FHIR base URL (prefilled with https://api.medplum.com/fhir/R4).
4. Watch it land. AnyBio builds a US-Core transaction Bundle from the demo's Observations using the same registry-driven projection production uses, exchanges a one-shot OAuth token, and POSTs it to your Medplum. The panel reports the created resource references, or the receiver's OperationOutcome if Medplum rejects the Bundle.

Because the demo data is synthetic, there is no PHI and no BAA required: it maps to Medplum's auto-create-Patient (medplum_demo) mode, which stands up the referenced Patient on first write. What lands is real and conformant, not a simplified mock - it goes through the same registry-driven projection and US Core 6.1.0 validation the production pipeline uses.

The demo exports the run's scalar Observations (heart rate, HRV, SpO2, …) with full Provenance and the synthetic Patient. Waveform artifacts (DocumentReference telemetry strips) and panel signals like blood pressure belong to the production episode pipeline - which renders strips from real signal data - not the synthetic demo, so they don't appear in the demo export (blood pressure comes back in the response's skipped list instead).

Behind the button is a single stateless call (POST /api/v1/demo/fhir-export) that takes the demo's features plus your pasted Medplum credentials, projects, and forwards. The credentials are used once for the token exchange and never stored, and the endpoint is locked to Medplum hosts.

Wire it for production​

The two-minute demo skips the upstream half (it uses synthetic data in the browser). For a real deployment, here is the full path. On the AnyBio side it is configuration, not an engineering project.

1. Create your AnyBio account​

secure.anybio.io -> social sign-in -> you land in the dashboard with a sandbox environment. Copy a developer key (sk_sandbox_*) from Settings -> API Keys. It is the bearer token for every AnyBio API call below.

2. Stand up Medplum​

If you don't already have a Medplum project, the fastest path is the hosted version at app.medplum.com — register a new project in a couple of minutes. Then create a ClientApplication from the Project Admin page; that gives you a client_id and client_secret for the OAuth 2.0 Client Credentials flow. Medplum's hosted FHIR base URL is https://api.medplum.com/fhir/R4 and its token endpoint is https://api.medplum.com/oauth2/token; tokens are issued with a one-hour lifetime (expires_in: 3600).

3. Get a biosignal flowing into AnyBio​

Connect a device and start streaming. The most accessible path needs no native app: Web Bluetooth via AnyBio's web SDK. Drop the CDN script (https://cdn.anybio.io/biosdk-web/v1/bioui.js), configure a <bio-provider> with your sandbox key, and pair a supported BLE device straight from the browser; frames stream to POST /ingest/raw-packet. For production real-device capture the iOS SDK is the native path; for no-hardware testing the synthetics generator simulates a device. Either way the signal attaches to an episode under a program/profile you enroll a patient into. That episode is what the export fires on.

4. Register the Medplum endpoint with AnyBio​

Create an OAuth provider holding your Medplum client_id / client_secret, then register the FHIR config (credentials are referenced by FK, not inlined):

POST /api/v1/fhir-medplum-configs
{
  "base_url": "https://api.medplum.com/fhir/R4",
  "oauth_provider_id": <id>,
  "binding_mode": "medplum_demo"
}

binding_mode is medplum_demo for development (Medplum auto-creates the Patient) and provider_logical for production, where a provider-issued logical identifier is used because patient identity is owned by an upstream EHR.

5. Create the export and attach a trigger​

POST /api/v1/data-exports
{
  "kind": "fhir_medplum",
  "target_ref": { "kind": "fhir_medplum", "fhir_medplum_config_id": "<config-id>" }
}

Then attach the export to your program by adding it to the profile's spec.exports[] with a trigger such as on_episode_end. The trigger lives on the profile binding, not on the data_export itself.

6. Close an episode and verify​

Stream some data, then close the episode (manually or via an end-condition). on_episode_end fires, AnyBio builds the transaction Bundle and POSTs it to Medplum under your cached OAuth token (Redis, 1h TTL, auto-refreshed). Confirm the round-trip:

curl -X GET "https://api.medplum.com/fhir/R4/Observation?subject=Patient/<id>" \
  -H "Authorization: Bearer <medplum-access-token>"

You should see the Observations AnyBio wrote, with US Core profile metadata, multi-coded code, the device and derivedFrom links, the Provenance resource, and any DocumentReferences for waveform artifacts.

What happens when it breaks​

A happy-path demo tells you the integration can work. Here's how it behaves when it doesn't - which is the part that decides whether you'd put it in front of patients.

Transaction Bundles are all-or-nothing. A transaction Bundle either fully applies or fully rejects; one invalid resource or one broken reference fails the entire episode's export, and the server returns an OperationOutcome describing why. AnyBio validates the Bundle against US Core in-pipeline before the POST, so most of this is caught early. If Medplum still rejects it, the Bundle is quarantined with the returned OperationOutcome attached - so you can see exactly which resource and which constraint failed instead of reverse-engineering it from logs.

Transient failures retry; persistent ones dead-letter. Network errors, 5xx responses, and expired tokens trigger exponential backoff with jitter and a capped retry count. A 401 refreshes the token and retries. Once retries are exhausted, the Bundle moves to a dead-letter queue and raises an alert rather than being silently dropped.

Re-fired triggers don't create duplicates. Idempotency is the failure mode people forget until they have three copies of every heart-rate reading. If a trigger fires twice - a retry after an ambiguous timeout, a replayed episode close - the write has to be a no-op, not a duplicate. AnyBio stamps a stable business identifier on every resource and writes with conditional semantics: ifNoneExist on that identifier (the server no-ops if a matching resource already exists), or a client-assigned ID via PUT (a replay upserts rather than duplicates). Either way, replaying a Bundle is safe.

Late and out-of-order data resolve cleanly. Biosignals don't always arrive in order - a buffer flush after a connectivity gap can backfill readings minutes late. Because every Observation carries its own effectiveDateTime and stable identifier, a late write is just an idempotent upsert keyed on time and identifier, and downstream queries order by effectiveDateTime, not by when the data happened to land.

Security and governance​

This is clinical data, so the controls matter as much as the pipeline:

• Authentication. Client secret is fine for development; for production, JWT client assertion (RFC 7523, asymmetric keys) is the stronger option - no shared secret crosses the wire, and you can rotate keys per instance. Medplum supports both and mandates JWT-based client auth for SMART Backend Services-style integrations.
• Transport and logging. PHI travels over TLS only, and identifiers go in the request body or headers - never in URLs or query strings, so PHI never lands in access logs.
• Audit. Every write Medplum performs generates an AuditEvent, and Medplum can strip human-readable detail (patient names, clinical descriptions) from those events while retaining the machine-readable identifiers - so the audit trail itself isn't a disclosure risk. On top of that, AnyBio's Provenance gives you clinical chain-of-custody from device to derived artifact: auditing any signal back to its origin is one query.
• BAA before PHI. A Business Associate Agreement is signed before any PHI flows. The medplum_demo auto-create mode is dev-only for exactly this reason - it's built for synthetic and test data, not real patients.

Why this composition works​

• Conformance is structural, not bolted on. The projection is registry-driven and validated against US Core 6.1.0 in CI at zero errors. Medplum's permissive-but-conformant validator accepts that output cleanly.
• Provenance survives the wire. The Provenance resource chains device -> algorithm -> artifact with timestamps and version identifiers. Auditing a clinical signal back to its origin is a single query, not a forensics exercise.
• The pipeline does the work; FHIR delivers it. What makes AnyBio + Medplum useful isn't that FHIR works - that's table stakes. It's that real-time biosignals become US-Core-conformant clinical artifacts before they ever hit FHIR. The wire format is the easy part.

The same conformant Bundle is also the starting point for stricter downstream EHRs: the projection is designed so that Epic and Cerner targets are a matter of adapter-specific profiling on top of the same US Core base, rather than a separate pipeline.

What's next​

We're using the Medplum integration as the reference implementation for AnyBio's broader EHR integration framework. The same ExportAdapter pattern that wires up Medplum is what we're building other connectors with and HL7v2-over-MLLP on. If you're building on AnyBio and want to write to a different FHIR destination, the lift is configuration, not engineering.

Get started​

Try it in two minutes — no hardware, no code:

1. Sign in at secure.anybio.io.
2. Open the Device Console and click Try Demo.
3. Click Export to EHR / Medplum and paste your sandbox Medplum credentials.

Related reading​

To go deeper on the Medplum side of the pipeline:

• Working with FHIR Data — how Medplum stores and serves FHIR R4.
• Chart Data Model — modeling Observations and vital signs, including valueSampledData for time series.
• Commonly Used Terminologies — LOINC, SNOMED CT, and UCUM, and how multi-coded code works.
• Batch & Transaction Requests and Conditional Batch Actions — atomic Bundles and idempotent (ifNoneExist) writes.
• FHIR Profiles & Validation and Understanding USCDI Data Classes — US Core conformance.
• Patient Deduplication — identity matching versus auto-create.
• External Files and Document References — storing waveform strips and other binary artifacts.
• Client Credentials and Client Assertion (JWT) — OAuth for backend integrations.
• ONC Certification — Medplum's (g)(10) implementation.

The skepticism isn't unreasonable. FHIR resources can be verbose, real charts are messy, and clinical workflows don't forgive much. A physician who opens a chart and watches a spinner for five seconds has already been let down by the architecture.

We've benchmarked Medplum's performance before, mostly around throughput — can a FHIR server handle millions of small requests at once. A customer recently pushed us on the inverse question, which turns out to be harder: can a FHIR-native system handle one enormous chart?

The test case​

We built the largest patient we could justify: a synthetic chart with roughly 131,000 FHIR resources. Tens of thousands of Observations, a multi-year longitudinal history, dozens of resource types all referencing each other. No real clinician will ever open a chart like this. That was the point — we wanted something pathological enough to surface whatever breaks.

Four ways to load a chart​

Most "FHIR is slow" complaints assume you have to pull the entire payload in one shot. You don't. We tested four approaches:

• Patient/$everything — the standard FHIR operation for retrieving a full chart.
• Resource-type queries — fetching Medications, Labs, and so on independently and in parallel.
• Recent-first loading — load the last 30 days of clinically relevant data first, then hydrate the older history in the background.
• Full browser download — a React demo that streams the entire chart into the app with a live progress bar.

The recent-first strategy is the one that matters in practice. A doctor shouldn't be blocked on ten years of history before they can start working. Load what's actionable now, fill in the rest behind it, and the UI is usable almost immediately.

Results​

The full, unmitigated 131,000-resource chart downloaded into the browser in about five seconds. That's not a backend microbenchmark — it's a React app pulling the whole thing over the wire, progress bar and all. With progressive loading, the critical data was on screen in a fraction of that time.

FHIR isn't the bottleneck​

131,000 resources. Five seconds. In a browser.

Speed isn't a property of the data standard — it comes from query strategy, indexing, pagination, streaming, and front-end design. Get those right and a FHIR-native architecture delivers the lightning-fast experience clinicians expect, on a fully open standard. You don't have to choose between interoperability and performance.

Want to see it for yourself? Try the demo or spin up a free Medplum project. The whole platform is open source at github.com/medplum/medplum — clone it, load your own monster chart, and time it.

The single biggest lever we have found is this: make your AI tools learn from Medplum's open-source code and docs rather than from solely generic FHIR training data. This dramatically improves the outputs you get from any request you make.

Give your tools access to Medplum​

Medplum is FHIR-native, so any LLM with baseline FHIR training has a head start. But FHIR is a standard, not an implementation - and the gap between knowing the spec and knowing how to build something real is where most AI-generated code falls apart. Medplum's open-source docs and codebase cover that gap directly: real patterns and working examples. Point the LLM there, and you get code that actually works instead of plausible-looking output that doesn't.

The simplest way to set this up, and the one we reach for first, is to clone the Medplum repo and symlink it into your project:

ln -s /absolute/path/to/medplum medplum-link

Then tell the model it can read medplum-link/. If you would rather not clone, you can give the agent docs and GitHub search instead, or connect Medplum's MCP server — the guide covers both.

Plan and prompt with Medplum as the source of truth​

The setup only pays off if your prompts push the model toward it. The pattern that has worked best, in our experience, is to plan before you build: ask the model to read the relevant docs and code (or have a rule file do this for you — more on that below), explain the common design patterns and their tradeoffs, and only then implement. It is far cheaper to catch a wrong architectural turn while it is still a paragraph than after it is a few hundred lines. Where you can, point the agent at the closest existing implementation to adapt rather than asking it to start from a blank file.

Keep conversations short​

One thing that is a real risk - long conversations decay. An agent that started with the right context drifts as the thread grows and earlier details get summarized away — strong answers early, subtle regressions later. We have had the best luck keeping a conversation scoped to a single task, starting fresh often, and re-pointing the model at the docs at checkpoints, for instance right after it generates a resource.

Verify the output​

An agent's confidence is not a measure of correctness, so build verification in. The cheapest check — and one the agent can run itself if it has terminal access — is to compile the generated code against Medplum's TypeScript types. The types are strict, so a hallucinated field on a typed FHIR resource is a compile error rather than a production surprise. Tests and linting catch more, and when you want the real thing, Medplum's server-side validation will check resources against the actual FHIR and profile definitions.

And the part we would never skip, because this is healthcare: review the output, especially the sensitive parts. LLMs make mistakes, and a wrong access policy does not throw an error — it quietly exposes data. Anything touching access control, auth scopes, or PHI deserves a careful human read before it ships.

Put it in a rule file​

Everything above works better when you write it down once instead of repeating it in every prompt. A rule file — CLAUDE.md, Cursor rules, or an AGENTS.md — gets read on every turn, so it keeps the model pointed at Medplum's docs without being told, and it survives the context decay from the last section. We offer a starter rule file you can drop in and adapt; grab it from the guide.

Advanced: direct data access​

Finally, an aspect that should be treated with care: giving your AI tool direct access to your Medplum data, through an API token or the MCP server. It can speed things up, but the caveats are real. If the tool can reach live PII or PHI, you must have a BAA with your LLM vendor; if you do not, scope an access policy so the token only ever reaches non-PII/PHI data.

None of this is that complicated, but together it changes how much you can trust what your agent hands back. The full write-up — setup options, prompting patterns, the validation tiers, and the data-access caveats — lives in Building on Medplum with AI Coding Assistants. Give your tools the source of truth, plan before you build, verify the output, and keep a human in the loop. Then go build something, and let us know what you make.

San Francisco, Calif., June 1, 2026 – Medplum, a leading provider of open-source healthcare developer infrastructure, today announced its Medplum Platform residing at Amazon Web Services (AWS) has earned certified status from HITRUST for cybersecurity and information protection.

The HITRUST e1 Certification demonstrates that Medplum has met requirements defined by a leading cybersecurity assurance leader, confirming that strong controls are in place to protect sensitive data and manage risk effectively.

Built on the HITRUST Assurance Program, this achievement reflects independent third-party testing, centralized quality assurance, and certification backed by HITRUST's Cyber Threat-Adaptive engine. These elements ensure continuous alignment with the latest threat intelligence and evolving standards across NIST, ISO, and OWASP.

"As cybersecurity expectations rise, our stakeholders expect credible, validated assurance," said Reshma Khilnani, CEO at Medplum. "Achieving HITRUST Certification reinforces our ongoing commitment to protecting data, managing risk, and maintaining the trust of those we serve."

"Earning HITRUST Certification demonstrates Medplum's commitment to managing information risk and protecting sensitive data through a rigorous, proven assurance process," said Gregory Webb, CEO at HITRUST. "This achievement reflects the organization's proactive approach to cybersecurity and trust."

HITRUST certification was a key commitment on the compliance theme of our 2026 roadmap. The HITRUST e1 Certification joins Medplum's existing compliance portfolio, including SOC 2 Type 2, HIPAA, and ONC certification — see the compliance overview for details. For organizations pursuing their own HITRUST certification using Medplum as a primary application backend, our HITRUST documentation describes how we can support your certification process.

To learn more about the HITRUST framework, assurance methodology, and its measurable results in reducing the risk of cyber breaches, see the HITRUST Trust Report.

About Medplum​

Medplum is an open-source healthcare developer platform built on FHIR standards. Medplum provides the API, data store, authentication, and developer tools that healthcare organizations use to build custom EHRs, patient portals, and clinical applications. Medplum is available as a managed service hosted on Amazon Web Services (AWS) and as self-hosted software under the Apache 2.0 license.

Features​

Scheduling​

Noah Silas

May completed the core scheduling operation suite that the scheduling roadmap has been building toward. Each step of the booking lifecycle now has a dedicated, spec-aligned FHIR operation:

• Appointment/$find multi-schedule search — Search for open slots across multiple schedules in a single request, the foundation for self-scheduling across providers and locations
• $hold operation — Temporarily reserve a slot while a patient completes booking, preventing double-booking during checkout
• $book for proposed appointments — $book now accepts a proposed appointment as input, with test coverage for the patient self-booking path
• $confirm operation — New Appointment/:id/$confirm operation to confirm a held or proposed appointment
• $cancel operation — New scheduling cancel operation with improved error-path handling throughout the booking flow
• Appointment-based Provider flow — The Provider scheduling calendar now uses the Appointment-based flow, reveals more slots in the schedule page, and is gated behind a scheduling feature flag for controlled rollout
• Self-scheduling reference flow — Foomedical, a sample patient-facing experience, now uses Appointment/$find + $hold to demonstrate the end-to-end patient booking pattern

Provider App: Medication Ordering and Prescribing​

Oleg Rocklin

Medication ordering moved into the Provider App this month:

• Meds ordering components — New React and Provider App components for ordering medications, bringing prescribing into the standard clinical workflow
• Batched pharmacy/org searches — Preferred pharmacies and organizations are now fetched with batched searches during prescribing for faster load times
• Resilient draft handling — Draft MedicationRequest resources are soft-deleted when an order-medication step fails, keeping the chart clean after errors

Provider App: Order Sets and Billing​

Andy Stoneman and David Yanez

• Order set import — An order set bundle and import button were added to the Provider App, with a sync bot trigger that runs automatically after an example order set is imported
• Operation-based claim submission — Claim submission now uses a server-side FHIR operation instead of a bot, simplifying the billing integration and reducing moving parts
• Self-pay coverage filtering — Self-pay coverage is now filtered out of the visit eligibility check and removed from the PatientSummary insurance display, so eligibility reflects only billable payers (Insurance Eligibility Checks)
• ClinicalImpression in the timeline — Clinical impressions now appear in the patient timeline (Maddy Li)
• Cancel Visit — A "Cancel Visit" button and a fixed "Details" link tab round out the encounter workflow (Noah Silas)
• Configurable onboarding — The Provider App "Get Started" screen can now be hidden via a project setting (Ian Plunkett)

AI: Real-Time Clinical Documentation​

David Yanez

AI work this month focused on real-time clinical documentation inside Spaces, the AI-powered chat workspace in the Provider App, as part of the AI roadmap:

• Real-time speech-to-text — Live speech-to-text in the Provider App for AI-assisted clinical documentation, backed by updates to the $ai-realtime operation
• Markdown responses in Spaces — Spaces now renders markdown in AI responses for clearer, better-formatted output
• Whisper hook in react-hooks — The Whisper transcription hook moved into the @medplum/react-hooks package so it can be reused across applications

Enterprise: Data Warehouse Export​

Karl Pietrzak

A major Enterprise Scale feature landed: Medplum can now export directly from PostgreSQL into Apache Parquet and Apache Iceberg tables on S3 Tables. This gives data teams an efficient, columnar path into modern lakehouse analytics without standing up a separate ETL pipeline. A new startDate parameter lets exports run incrementally. This is new functionality related to Medplum Enterprise.

Platform, Security, and Infrastructure​

Cody Ebberson

• Passwordless magic-link login — New OAuth2 pre-authorized code flow enables magic-link sign-in, with the pre-authorized code lifetime extended to 7 days for email-based flows
• Unified external authentication — Consolidated the external identity-provider paths into a single unified external auth flow, including Google Cloud Identity Platform userinfo support
• AWS GuardDuty Malware Protection — Added support for AWS GuardDuty Malware Protection on uploaded files, with graceful handling of images quarantined by the scanner
• HTTPS-only subscription URLs — Rest-hook Subscription URLs now require HTTPS by default, and a server option can require a verified email address before login
• OAuth2 spec-compliance fixes — A batch of OAuth2 token endpoint corrections including offline_access handling when refresh_token is in grant_types, www-authenticate: bearer responses, and enforcing login membership before scope
• log-streaming project feature — A new log-streaming project feature plus a Project.features search parameter for managing it

Derrick Farris

• Bot Lambda lifecycle management — Medplum now prunes old bot Lambda versions, deletes the Lambda when a bot is deleted, and removes stale versions, keeping cloud deployments tidy and within service limits
• Agent/$stats operation — New operation to retrieve statistics for a deployed Agent, Medplum's on-premise connectivity service for legacy healthcare systems
• User/$rescope operation — New operation to change a user's project scope without re-issuing credentials
• Rate-limit reliability — Optimized Redis key access for rate limiting, exposed the RateLimit header for CORS, and improved WebSocket subscription error messages

Maddy Li

• Rate-limit administration — A new project rate-limits operation, an admin API endpoint for rate-limit utilization status, an active-consumer index, and a Rate Limits tab on the admin page give operators full visibility into rate limiting
• NPI Lookup example bot — A new example bot for NPI lookups using the NPPES API

Matt Willer

• Range search — FHIR search now supports range queries with correct overlap and boundary handling
• Patient scope hardening — Patient-scoped tokens are now restricted to their context Patient compartment, and chained search and _include types are validated for safety
• Vendored JSON Patch — The JSON Patch library is now vendored, and FHIR quota-limit computation was unified into a single helper
• Larger payload handling — Oversized request bodies are transformed into a clean HTTP 413 response

Matt Long

• Transaction reliability — Serialized transaction state transitions and more consistent repository connection-state tracking improve site reliability under load
• Project.link search parameter — New search parameter for navigating linked projects

Documentation​

May's documentation work spanned self-hosting, compliance, integrations, and the Provider App.

Self-hosting and reliability

Cody Ebberson

• Install on DigitalOcean — New guide for self-hosting Medplum on DigitalOcean
• Uptime and reliability — New documentation covering Medplum's uptime and site reliability practices
• VM context bot security note — Added a security note for VM context bots in production

Compliance and scale

• Electronic prior authorization testing — Testing documentation for electronic prior authorization, part of the HTI-4 compliance initiative ahead of the January 2027 enforcement date (Cody Ebberson)
• Async batch processing — New documentation for asynchronous batch processing, with a note on how FHIR quotas apply (Finn Bergquist, Andy Stoneman)

Integrations

• Health Gorilla sync-back resources — Documentation for resources synced back from Health Gorilla (Maddy Li)
• Self-service prescriber enrollment bot — Documented the self-service prescriber enrollment bot (Ian Plunkett)

Provider App and platform

• Spaces feature documentation — Added Spaces feature documentation for the Provider App, including a walkthrough video (Everett Williams)
• Charting documentation restructure — Restructured the charting documentation with additional decision-guide content (Everett Williams)
• Project vs. server-scoped users and direct external auth — Clarified user scoping and external auth setup (Finn Bergquist)
• Rate limits operation — Documented the new rate-limits operation, plus a clarification on bots with ProjectMembership (Maddy Li)
• Trust center links — Updated compliance links to point to the Medplum Trust Center (Reshma Khilnani)

Testing infrastructure

Karl Pietrzak

A broad effort migrated many internal packages — including hl7, fhir-router, generator, create-medplum, cdk, ccda, mock, and definitions — from Jest to Vitest for faster, more consistent test runs across the monorepo.

Bug Fixes​

AWS and CDK

• Fixed handling of complex server configuration, and corrected CDK to send the prefix instead of the bucket name (contributed by Jim Fiorato)

Authentication

• Serialized cross-tab token refresh using the Web Locks API to prevent race conditions across browser tabs (contributed by Dillon Streator)
• Fixed the RECAPTCHA_SITE_KEY always reverting to the default value (contributed by Meade)
• Added defaultProjectFeatures to the config object keys set (contributed by Nate Watkins)

FHIR and Agent

• Fixed indexing of fragment CodeSystem resources in the coding table (contributed by Jeffry Looijestijn)
• The Agent now returns an explicit error when an upgrade artifact is missing (contributed by Agustin Bereciartua Castillo)
• Display of onBehalfOf was added to History, Timeline, and Blame views (contributed by Alex Lin)

Releases​

• v5.1.10 — May 1
• v5.1.11 — May 6
• v5.1.12 — May 17
• v5.1.13 — May 20

Looking Ahead​

May brought the scheduling operation suite to completion — $find, $hold, $book, $confirm, and $cancel now cover the full booking lifecycle — and moved the Provider App onto an Appointment-based flow with medication ordering and order set import. Passwordless magic-link login and GuardDuty malware protection strengthen the platform's security posture.

Join us on Discord to share feedback or follow along on GitHub.

This year's agenda brings together healthcare builders working across open source infrastructure, AI-enabled operations, Stanford Biodesign, and large-scale healthcare IT.

This agenda is preliminary and subject to change.

Morning Session​

9:00 AM	Breakfast
9:30 AM	Keynote: Medplum Past, Present and Future	Cody Ebberson
10:15 AM	Stanford Biodesign: Vibecoding Healthcare IT	Vishnu Ravi, Aydin Zahedivash
11:15 AM	Coffee Break
11:30 AM	Scaling to 100M Patients	Matt Long, Maddy Li
12:00 PM	Lunch Break

Afternoon Session​

TBD	Scheduling Agents for Healthcare Operations	Cody Hall, Unity AI
TBD	Open Source Impact on Healthcare	Stuart Parmenter
TBD	Community Demos	Medplum community
TBD	Happy Hour

For recordings, slides, demos, and photos from last year, see PlumCon 2025 Materials.

Features​

Provider App: Spaces and AI​

David Yanez

April brought three focused Spaces improvements touching the full AI interaction loop — input, reasoning, and execution — as part of the AI roadmap:

• Tool request/response visibility — Tool calls and responses now surface inside the Spaces chat experience for full transparency into AI agent actions
• Improved AI agent loop handling — More robust multi-step agent execution with a resizable preview panel for inspecting generated output
• $ai project API key — The $ai operation now uses the project-scoped API key for consistent model configuration across environments

Provider App: Billing and Coverage​

David Yanez

April's biggest Provider app push closed more of the end-to-end billing loop — from submitting a claim to understanding why it failed:

• Claim submission — Submit claims directly from the Provider app
• Submit claim confirm modal — Confirmation step before claim submission to prevent unintended submissions
• Coverage eligibility display — Coverage eligibility request and response panels in the Provider app, accessible from within encounters
• Coverage request component — Dedicated component for initiating coverage requests (Insurance Eligibility Checks)
• Error display on claim submission — Error messages surface clearly when a claim fails to submit

Provider App: Prescribing​

Oleg Rocklin

Two long-running prescribing threads landed this month:

• Drug/Allergy warning enhancement — Drug/Allergy Warning support brings prescribing safety checks into the Provider app workflow
• Provider enrollment React hooks — React hooks allow a prescriber self-enrollment bot to reduce the integration setup to a few hook calls

Scheduling​

Noah Silas

The scheduling overhaul reached an inflection point in April: HealthcareService is now the authoritative source for scheduling parameters, replacing looser conventions and enabling far more reusable slot configurations:

• HealthcareService scheduling parameters — Scheduling operations now use parameters defined directly on HealthcareService resources, enabling more expressive and reusable configurations
• Explicit HealthcareService references — Scheduling uses explicit HealthcareService references for unambiguous slot resolution
• R5/R6 Availability type alignment — The scheduling availability subextension is shaped to match the R5/R6 Availability type for forward compatibility, which will help with future-proofing
• HealthcareService.offeredIn backport — R5 offeredIn field backported to Medplum's R4 HealthcareService for richer service-location relationships
• Scheduling UI consistency — Provider scheduling UI fixups and month view corrections for a more consistent experience
• State-by-state medical licensure scheduling — Scheduling support for state-by-state practitioner licensure requirements (Finn Bergquist)
• Insurance eligibility FHIR operation — New custom FHIR operation $stedi-check-eligibility for insurance eligibility checks (Finn Bergquist)

Platform and Infrastructure​

Cody Ebberson and Matt Long

April's platform work covered security hardening, search correctness, and operational reliability — feeding into Enterprise Scale and the H1 compliance track:

• mTLS passthrough on ALB — Mutual TLS passthrough at the Application Load Balancer for certificate-based client authentication
• Tightened access controls for linked projects — Stricter permission enforcement and consolidated logic for determining permitted project IDs
• Auto-disable subscriptions on failure — Subscription resources automatically disable after repeated delivery failures, reducing noise and resource waste
• Patient.$match operation — Server-side FHIR $match operation for patient de-duplication and record linkage, which is part of a master patient index pattern
• Project-scoped presigned URLs — Project context is now included in presigned Binary URLs for more secure access
• Login rate limiting — Separate, stricter rate limit on login paths to improve brute-force resistance
• JWT jti claim — The JWT ID (jti) claim is now always set for replay-attack protection
• Skip post-deploy migrations in firstBoot — Operators can skip post-deploy migrations during initial boot for faster first-start deployments, which will benefit self-hosted Medplum users
• Transaction dead connection management — Improved handling of dead connections during database transactions
• SSE-C encryption for S3 Binary storage — Server-Side Encryption with Customer-Provided Keys (SSE-C) support for S3 Binary storage (Nicolas Weiß)

Matt Willer

• Range search — Range-based FHIR search correctly handles overlapping ranges and boundary conditions
• _filter modifier support — Modifiers in _filter search parameters now work consistently
• OTel delta aggregation — OpenTelemetry metrics use delta aggregation temporality with exponential histogram views for accurate reporting
• Rate-limit delay improvement — Rate-limited requests delay in async context rather than consuming rate-limit tokens for fairer enforcement

Derrick Farris

• Agent message tracking — Agent messages are tracked independently of connected clients for more reliable delivery and observability
• Load balancer algorithm config — CDK support for configuring the load balancer routing algorithm via loadBalancerAlgorithm
• WebSocket handler colocation — All WebSocket handlers consolidated into a single location for a cleaner server architecture

Developer Experience​

• ResourcesInput component — New React component to search and select multiple resources, simplifying multi-select UI patterns (David Yanez)
• MedplumClient streaming support — MedplumClient now accepts ReadableStream and Node.js Readable for efficient streaming uploads (Cody Ebberson)
• Streaming bulk export — Bulk export uses streaming to handle large datasets without buffering in memory (Cody Ebberson)
• valueSetElementToCoding / codingToValueSetElement — Utility functions now exported from @medplum/react for mapping between value set elements and codings (Darren Eam)
• PatientSummary modular architecture — Refactored into a config-driven, modular architecture for easier customization per deployment (Rahul Agarwal)
• Tenants tab on Patient page — Multi-tenancy visibility directly on the Patient detail page (Maddy Li)
• Admin MFA reset endpoint — New admin endpoint to reset a user's MFA enrollment (Ian Plunkett)
• externalAuthProviders via environment variable — External auth providers can now be configured via environment variable for simpler deployment (Ian Plunkett)
• Apply markdown rendering to Resource documentation fields — Resource documentation fields now render markdown for richer display (Noah Silas)
• Two new FHIR search parameters — Additional search parameters added to expand query capabilities (Matt Long)

Documentation​

April saw a concentrated documentation effort on two fronts: filling out the clinical workflow narrative from intake through care plans and diagnostics, and hardening the auth and integrations reference material that production deployments rely on.

Clinical workflows

Everett Williams

• Intake & Registration clinical workflow — End-to-end guide for patient intake and registration flows
• Longitudinal patient case tracking with care plans — How to model ongoing patient cases using CarePlan resources
• Diagnostic Orders: restructured IA and workflow content — Reorganized Diagnostic Orders section with deeper workflow guidance
• Visits page: video walkthrough and tutorials — Video walkthrough and tutorial notes added; sidebar reorganized to surface questionnaires more clearly
• Message editing and drafts — Guide for editing messages and managing drafts in the communications system
• Async encounters with SDK walkthrough — Expanded guide with full SDK code walkthrough for async clinical encounters
• Clinical sidebar reorganization — Care Coordination, Diagnostic Orders, and Clinical Configuration sections reorganized for clearer navigation

Authentication and security

• Client assertion authentication — How to authenticate using signed client assertion JWTs in support of CMS-0057 (Cody Ebberson)
• mTLS authentication — Setup and configuration guide for mutual TLS client certificate authentication (Cody Ebberson)
• Direct external auth — Added to the auth sidebar and overview for better discoverability (Ian Plunkett)
• MFA reset flow — Admin documentation for resetting user MFA enrollment (Ian Plunkett)

Platform and integrations

• Clinical Protocols execution guide — How to execute clinical protocols using Bots and automation (Rahul Agarwal)
• Health Gorilla: receiving flow and migration guide — Lab result receiving flow and migration guidance for Health Gorilla integrations (Rahul Agarwal)
• Patient $match documentation — Documentation for the new patient matching FHIR operation (Reshma Khilnani)
• CDS Hooks — Basic CDS Hooks integration documentation (Reshma Khilnani)
• HTI-4 / CMS-0057-F update — Compliance documentation updated to include CMS-0057 requirements (Reshma Khilnani)
• Self-hosting: enabling rollbacks — How to enable and execute server rollbacks in self-hosted deployments (Derrick Farris)
• Prescriber enrollment statuses — All registration statuses documented for the prescriber enrollment flow (Andy Stoneman)

Bug Fixes​

C-CDA

• Fixed nullFlavor allergy reactions and single translation element handling in C-CDA parsing, preventing import failures on common EHR exports (contributed by Amanda McGivern)

Agent

• Fixed agent channel reload when the endpoint protocol changes, preventing stale connections after a protocol switch (contributed by Adewoye Adegoke)

Releases​

• v5.1.7 — April 8
• v5.1.8 — April 14
• v5.1.9 — April 23

Looking Ahead​

April deepened the Provider app's billing story — from claim submission to live coverage eligibility display — while Spaces gained speech-to-text for AI-assisted clinical documentation. Scheduling's alignment with HealthcareService parameters makes multi-location and multi-service configurations significantly cleaner. Clinical documentation now spans intake through care plans, diagnostics, and async encounters, giving builders a fuller end-to-end picture of workflow implementation on Medplum.

Join us on Discord to share feedback or follow along on GitHub.

Features​

Provider App: Spaces and AI​

David Yanez

Spaces continues to advance our AI roadmap initiative and the Provider Application roadmap goal:

• System prompts on Communication resources — Spaces stores system prompts as Communication resources for clearer modeling and reuse
• Component preview, code, and FHIR resources — Previews and visibility into generated UI, code, and underlying resources in the Spaces chat experience
• Translator tool looping — The translator can iterate until the user's request is satisfied for more reliable multi-step workflows
• Updated default language model — Newer model defaults for improved quality and consistency
• Spaces demo bots — Demo bots for Spaces are easier to discover in development environments
• Tab navigation — Standardized tabs across high-traffic screens (Kevin Wadeshaw)

Provider App: Messaging, Scheduling, and Billing​

David Yanez

The Provider app gained messaging, calendar, and billing improvements:

• Communications payload and eFax — A dedicated payload tab on Communications, eFax integration, and ThreadChat updates (subject on communications, clearer file metadata for uploads and search)
• Calendar scheduling — Switch practitioner schedules from the calendar; more robust Find pane when service types omit a system; visit setup right after $book; schedule pickers resolve actors via Schedule:actor
• Candid billing — Claim status in the Provider app and use of external identifiers when a Candid encounter id is absent
• SMART App Launch — fhirContext support and respect for an existing login query parameter on launch
• Project-scoped Provider access — Project membership aligns with who can open the Provider experience (Cody Ebberson)
• Domain rules for external apps — DomainConfiguration can target apps hosted outside the core deployment (Cody Ebberson)
• Charting and sample data — Controlled-substance documentation updates (Maddy Li) and CPT handling fixes on sample data

Scheduling Operations​

Noah Silas

Server-side scheduling advances the Scheduling roadmap initiative:

• $find service type matching — More accurate matching when resolving available slots
• Wildcard availability removed — Clearer availability semantics and fewer ambiguous slot definitions
• FooMedical scheduling demo — Updated patient-facing scheduling showcase
• Demo schedules — Refreshed demo schedule content and calendar examples (Reshma Khilnani)

Platform and Infrastructure​

Cody Ebberson and Matt Long

This work advances Enterprise Scale & Infrastructure:

• Workers — Dispatch worker path, configurable background workers, CDK support for worker-only services, and conditional worker deployment
• auth/me project features — Clients read enabled project features from the authenticated session
• Marketplace definitions — Foundation resources for marketplace packages (package resource)
• Bot $init operation — Initializes Bot content for repeatable deployments (Bots overview)
• Auth UI extraction — Shared React components for sign-in and session flows

Matt Willer

• Presigned Binary uploads — Secure, efficient client-side uploads without routing through the server
• Rate-limit caching — In-memory tracking of heavily rate-limited IPs for faster enforcement
• Database tuning — PostgreSQL transaction idle timeouts and faster login flow
• Observability — Broader FHIR interaction metrics from the system repository; transaction consistency fixes in database reads

Derrick Farris

• WebSocket subscription hardening — Subscription token lifecycle, stale subscription detection against user limits, and FHIRcast topic key refresh
• HL7 client resilience — Clients now warn instead of error on unknown message control IDs

Developer Experience​

• ThreadInbox / ThreadChat — Optional allowPatientSelection for patient-facing apps; prop type exports; QuestionnaireForm fixes for repeated multiple-choice items; questionnaire signature stories (David Yanez, Noah Silas)
• useSearch typing — Results use WithId<T> for safer access to server-assigned ids (Noah Silas)
• SMART launch — Opens in a new tab by default; respects an existing login query parameter on launch (Maddy Li)
• Reference display fallback — UUID fallback when a reference has no display string (Maddy Li)
• ValueSetAutocomplete — Configurable count behavior (Aditya Suri)
• MedplumClient retry options — Configurable maximum retry time and default maxRetries (Cody Ebberson, Aditya Suri)
• CLI healthcheck validation — Custom base URLs are validated against the server healthcheck when configuring profiles (Medplum CLI, Rahul Agarwal)
• SMART on FHIR demo app — New example app for SMART launch and patient context (Alex Lin)
• Why Open Source — New page on Medplum's open-source philosophy

Documentation​

March's documentation push emphasizes communications, clinical and scheduling workflows, and platform operations — supporting builders who ship workflow-heavy provider experiences.

Communications and messaging

Everett Williams

• Thread lifecycle, participants, and access control — How threads behave over time, who can see them, and how access policies apply
• Messaging data model — Updated mental model for how conversations are represented and evolve
• Task-based message response tracking and routing — Patterns for tying tasks to message workflows
• Searching and querying threads — Practical search patterns for threaded communications
• Sending messages and attachments — Attachment flows for secure messaging
• Read receipts and message status — Delivery and read state for auditing and UX
• Messaging automations with Bots — Automations that react to messaging events
• Example code — New messaging snippets aligned with the guides
• Sidebar reorganization — Clearer navigation for communications and related topics

Additional communications documentation pages are in the works beyond what shipped in March, so expect the communications section to keep growing.

Clinical charting and scheduling

Darren Eam

• Visit Templates and the SOAP Approach — Visit templates tied to SOAP (structured S/O/P, narrative assessment) in clinical charting
• Time zones and timestamps — Scheduling with zones and instants in FHIR and the app (Cody Ebberson)
• Scheduling guides — Broader refresh of scheduling documentation (Finn Bergquist)
• Defining availability — Clarified alpha labeling (Aditya Suri)

Platform and operations

• External identity providers — Routing strategies for external IdP integrations (Rahul Agarwal)
• Multi-tenant access policies — Tenancy guidance in access documentation (Maddy Li)
• Server configuration: maxBatchSize — How maxBatchSize interacts with async batches and maxJsonSize (Rahul Agarwal)
• Medplum Events Calendar — Updated upcoming events (Reshma Khilnani)
• Lab account onboarding — Revised instructions for requesting a lab account (Reshma Khilnani)

Bug Fixes​

Server

• Return HTTP 400 when PostgreSQL rejects date/time values that overflow field bounds, instead of a generic database error (contributed by Léandre Chamberland-Dozois)
• Improved patch behavior when JSON patch operations implicitly create arrays
• Hardened ProjectMembership.invitedBy population for consistent invite attribution
• Additional edge cases for subscription token expiry and rebinding
• Fixed basic authentication handling for inactive project memberships

Clinical and UI

• Fixed mapReferenceRange so numeric reference ranges map cleanly into FHIR Range for observations (contributed by Amanda McGivern)

Releases​

• v5.1.2 — March 7
• v5.1.3 — March 7
• v5.1.4 — March 20

Looking Ahead​

March deepened the Provider app's Spaces, messaging, and scheduling story, while worker and subscription work strengthened the platform's operational backbone. Communications documentation now gives teams a clearer map from threads and tasks to automation — supporting the next wave of patient and clinician-facing workflows.

Join us on Discord to share feedback or follow along on GitHub.

Executive Summary​

Cluster Configuration​

The cluster used for this evaluation mirrors one of Medplum's most extensive managed production clusters, making these results grounded in real-world infrastructure rather than a synthetic benchmark environment.

Testing Methodology​

All tests were run using Grafana's hosted k6 testing framework, which is purpose-built for generating massive load through efficient script optimization. Key aspects of the methodology:

• Operating system configurations were adjusted to raise default network and user limits
• The load generator was monitored continuously to ensure optimal resource utilization
• Test scripts were crafted to account for k6 scripting nuances, options, and file handling
• A single k6 instance was configured to utilize all available CPU cores, enabling simulation of thousands of virtual users and hundreds of thousands of HTTP requests per second

Each scenario was configured to ramp up to 1,000 virtual users (VUs) over a 5 minute 30 second test window.

Scenario 1: Unauthenticated, Read-Only, No Database Access​

Endpoint: HTTP GET /

This scenario tests the raw serving capacity of the Medplum API tier with no database involvement - reflecting performance for cached or statically resolved responses.

A total of 5,767,860 requests were made with a peak throughput of 46,750.67 reqs/s. The p95 response time was 30 ms, and zero HTTP failures were recorded. At steady state, the system handled an average of 16,972 requests/second.

View full run on Grafana k6

Scenario 2: Unauthenticated, Read-Only, Database Access​

Endpoint: HTTP GET /healthcheck

This scenario introduces database reads into the picture without authentication overhead, testing the throughput of simple DB-backed responses.

A total of 2,916,547 requests were made with a peak throughput of 14,733.67 reqs/s. The p95 response time was 89 ms, and the average request rate was 9,408 requests/second.

View full run on Grafana k6

Scenario 3: Authenticated, Read-Only, Database Access​

Endpoint: HTTP GET /fhir/R4/Patient/{id}

This scenario adds JWT authentication to a FHIR read operation, reflecting the typical performance profile for reading a single FHIR resource in a production application.

A total of 3,641,640 requests were made with a peak throughput of 20,796.67 reqs/s. The p95 response time was 57 ms, and the average request rate was 11,747 requests/second.

View full run on Grafana k6

Scenario 4: Authenticated, Read, Write, and Search​

This is the most realistic scenario - simulating a real-world application workflow that creates, reads, and searches for FHIR Patient resources under load.

Endpoints (executed in sequence per VU):

1. HTTP POST /fhir/R4/Patient - CreatePatient
2. HTTP GET /fhir/R4/Patient/{id} - ReadPatient
3. HTTP GET /fhir/R4/Patient?name={name} - SearchPatient

A total of 743,313 requests were made with a peak throughput of 6,738.33 reqs/s. The p95 response time was 403 ms, and the average request rate was 2,398 requests/second.

Zero HTTP failures were recorded across all three endpoint types.

View full run on Grafana k6

Summary​

These results demonstrate that a properly configured self-hosted Medplum deployment can handle demanding production workloads with strong latency characteristics and zero error rates. The cluster configuration used here - 15 Fargate instances backed by a high-memory PostgreSQL node and a Redis cache - represents a realistic mid-to-large production setup.

For teams evaluating Medplum for high-throughput applications, these benchmarks provide a concrete baseline for capacity planning. Questions about sizing, configuration, or performance optimization? Join the conversation on Discord or reach out to the Medplum team.

Features​

Provider App: AI-Powered Spaces and Chat​

David Yanez

The Provider app's Spaces experience gained significant AI capabilities this month, advancing our AI roadmap initiative:

• LLM components and visualization preview in Spaces — AI-generated structured components and previews now render inside the chat interface, enabling richer, more interactive AI responses
• Attachment support in chat — Providers can now send and receive file attachments within the base chat component
• Updated AI models — The provider app is configured with the latest available language models
• ThreadInbox as a reusable React component — Moved to the @medplum/react package, making inbox functionality available to any Medplum-powered application
• Navbar alerts and counts — Provider app navigation links now support badge icons and resource counts for at-a-glance workflow status

The Foomedical demo — a sample patient-facing experience — was also updated to showcase the latest chat experience.

AWS Lambda Streaming for Bots​

David Yanez

Bots deployed on AWS Lambda can now stream responses back to callers in real time. This unlocks Server-Sent Events-style streaming from Lambda-hosted bots — a foundational capability for building AI scribes, copilots, and other latency-sensitive applications. This directly supports the AI roadmap initiative.

WebSocket Subscriptions: Scale and Observability​

Derrick Farris

February saw a major investment in WebSocket subscriptions, improving performance, reliability, and operational visibility at scale — directly advancing the Enterprise Scale & Infrastructure roadmap priority:

• Per-user WebSocket subscription limits — Prevents runaway connections from any single user from destabilizing the platform
• Super admin dashboard for subscription stats — Real-time visibility into active WebSocket subscriptions, connection counts, and resource utilization across the entire platform (super admin guide)
• Admin operation to clear all WebSocket subscriptions — Administrative control for operations teams managing large deployments
• Multiple performance improvements — Subscription criteria is now only evaluated when criteria match, access policy decisions are cached in the hot evaluation loop, active subscription lists are partitioned by resource type, Redis key deletion is non-blocking, and a new efficient event payload format reduces latency and CPU load at high subscription volumes

Scheduling Enhancements​

Noah Silas

Building on January's $find and $book foundation, scheduling received several refinements this month:

• Customizable appointment creation before $book — Developers can now inject custom fields and logic into the appointment object before the booking operation executes, enabling clinic-specific workflows
• _count parameter for $find — Limits the number of available slots returned, improving efficiency for high-volume scheduling queries
• Adding a visit now creates a busy slot — The Provider calendar correctly blocks time when a visit is added, ensuring accurate availability display
• Improved UTC/local day discrepancy handling — Scheduling operations behave correctly when the server's UTC time and the local calendar day differ

Revenue Cycle: Claim Submission and Eligibility​

David Yanez

Advancing the Revenue Cycle & Billing roadmap initiative:

• Claim submission to Candid — A proof-of-concept integration for submitting claims directly to Candid Health, enabling automated professional billing workflows from within the Provider app (billing overview)
• CoverageEligibilityRequest in $extract — The SDC $extract operation now uses the standard CoverageEligibilityRequest resource for insurance eligibility checks, aligning with the FHIR specification

Pharmacy Components​

Oleg Rocklin

New React components for patient preferred pharmacy selection are now available in @medplum/react. This supports e-prescribing workflows and the ePrescribe integration roadmap initiative.

Multiple Redis Support​

Matt Long

Medplum server now supports multiple Redis instances, enabling more flexible infrastructure topologies including Redis Cluster deployments and failover configurations. This is an important step for enterprise-scale deployments that require high availability for caching and pub/sub. (self-hosting guide)

Instance-Level Custom FHIR Operations​

Rahul Agarwal

Developers can now define custom FHIR operations at the instance level with resource input — enabling more granular, resource-specific API extensions. Combined with updated bot operation documentation, this gives builders more control over custom workflow APIs. For self-hosters, this is particularly valuable: you can expose clinic- or organization-specific operations directly on your FHIR server without forking Medplum, keeping your customizations cleanly separated from the core platform.

Security and Authentication​

• Public PGP key published — Medplum now has a published security PGP key for responsible disclosure, listed on the security page (Cody Ebberson)
• Sub claim fallback in external auth — Improved compatibility with external OIDC providers that use non-standard subject claim formats (Rahul Agarwal)
• In-memory rate limit tracking for high-volume abuse — Heavily rate-limited users are now tracked in memory for faster enforcement (Matt Willer)
• Access policy search permission explicitly checked — Tightened enforcement of access control on search operations (Matt Willer)

Developer Experience​

• Members tab in project admin — Users and Patients are now combined into a single Members tab on the project admin page for a cleaner project management experience (Maddy Li)
• SMART app launch with patient identifier — SMART app launch URLs now support patient identifiers, improving interoperability with EHR launch contexts (Maddy Li)
• Token :text modifier in SearchControl — The SearchControl component now supports the token text modifier for more flexible searches (Cody Ebberson)
• Hidden field support in forms — Form components now support hidden fields for passing context without user input (Maddy Li)
• Membership label filtering in profile chooser — The profile selection form can now filter memberships by label, contributed by jeffrey-peterson-vanna
• Operation to refresh reference display strings — A new operation allows refreshing cached display strings on resource references, keeping display data current after resource updates (Matt Willer)
• Native bcrypt for improved authentication performance — Switched from the pure-JavaScript bcryptjs library to native bcrypt bindings, significantly improving password hashing throughput (Cody Ebberson)
• Configurable CDS services URL — The Clinical Decision Support (CDS) Hooks service URL is now configurable, enabling integration with custom CDS endpoints. CDS Hooks support is part of Medplum's HTI-4/CMS-0057-F compliance initiative, which covers payer interoperability requirements ahead of the January 2027 enforcement date. (Cody Ebberson)

Documentation​

February's documentation work was substantial, with a major restoration of SDK docs and expanded coverage of operations, subscriptions, and integrations.

Operations and API

Darren Eam

• Reorganized FHIR operations sidebar and index — The FHIR operations docs are now organized with a cleaner sidebar and index page for faster navigation
• New documentation for custom and bot operations — Full coverage of custom FHIR operations, including instance-level and system-level patterns
• Project and system administration operations — New reference pages for admin operations
• Data export and import operations — Documented the Bulk Data Export, C-CDA Export, Claim Export, and CSV export API operations
• Clinical decision support operations — New reference for CDS Hooks operations, part of Medplum's HTI-4/CMS-0057-F compliance initiative

Subscriptions

• Subscription extension docs — Clarified the subscription extension format for interaction filters and retry policy (Ian Plunkett)
• useSubscription lifecycle hooks — Added documentation for lifecycle hook callbacks in the useSubscription React hook (Rahul Agarwal)

Provider and Clinical

• DoseSpot notifications — Updated documentation for DoseSpot notification handling (David Yanez)
• Patient login and launch URI clarification — Improved docs for patient-facing login flows and SMART launch URIs, contributed by Mallikharjuna Mulpuri
• Allergy representation — Clarified allergy status and AllergyIntolerance formatting in the chart data model, contributed by Aaron Hong
• CareTeam tenancy patterns — Clarified per-patient CareTeam cardinality and multi-tenancy patterns (Rahul Agarwal)

Infrastructure and Security

• Docker Hardened Images — Added Docker Hardened Images to the security page (Cody Ebberson)
• Medplum Agent solutions page — Created a dedicated Medplum Agent solutions page. The Medplum Agent is an application that runs inside your firewall and bridges on-premise devices (HL7/MLLP, ASTM, DICOM) to the cloud via secure WebSocket channels (Maddy Li)
• Branding guide — New branding documentation explaining how to customize the Medplum logo and application name (Aditya Suri)

Blog

• Identity Management: A Practical Guide — New blog post by Everett Williams on managing digital identities in healthcare applications (read the post)
• Medplum Secures Healthcare Platform on Docker Hardened Images — Published on the Docker blog, this post by Cody Ebberson and Docker's Ajeet Singh Raina covers how Medplum uses Docker Hardened Images to reduce CVE noise, meet HIPAA and SOC 2 requirements, and minimize container security configuration burden

Bug Fixes​

Clinical Data

• Fixed handling of nullFlavor values in CCDA-to-FHIR conversion, improving interoperability with C-CDA documents that contain null-flavored data elements (contributed by Amanda McGivern)
• Fixed handling of terminology designations without a language code

Scheduling

• Fixed scheduling operations during UTC/local day boundary discrepancies

Server and Authentication

• Fixed project-scoped users being properly removed when their project membership is deleted
• Fixed a string equality check error in the token endpoint

Infrastructure

• Fixed the CDK deployment option for retaining RDS instances on stack deletion
• Fixed basic auth behavior for inactive project memberships
• Reverted an overly strict date validation change that caused regressions

Releases​

• v5.0.14 — February 3
• v5.0.15 — February 20
• v5.1.0 — February 24
• v5.1.1 — February 27

Looking Ahead​

February's investments in WebSocket subscription performance and Lambda streaming set the stage for more capable real-time and AI-powered workflows in Q1. The scheduling enhancements continue to push toward a full self-scheduling experience, and the Candid claim submission proof-of-concept marks meaningful progress on revenue cycle automation.

Join us on Discord to share feedback or follow along on GitHub.

This guide breaks down the key decisions you'll face when integrating with a FHIR-based platform like Medplum, explains the tradeoffs, and recommends approaches that work well for most healthcare organizations.

The Basics: Authentication vs. Authorization​

Before diving into architectural decisions, let's clarify two terms that often get confused:

Authentication (AuthN) answers the question: "Who are you?" It's the process of verifying a user's identity — typically through a username/password combination, single sign-on, or biometric verification.

Authorization (AuthZ) answers the question: "What can you do?" Once we know who you are, authorization determines which resources you can access and what actions you can perform.

In healthcare, both are critical. You need to know that Dr. Smith is actually Dr. Smith (authentication), and you need to ensure Dr. Smith can only access records for patients in her practice (authorization).

Decision 1: Using Email Address Logins vs. External Identity Provider (IDP)​

The first fundamental decision is how to uniquely identify users in your system. You have two primary options:

Option A: Email Address​

Using email as the unique identifier is simple and intuitive. Users log in with their email, and the system matches them to their account.

Advantages:

• Familiar to users
• Works with multiple login methods (Google, Microsoft, Okta)
• No additional services needed

Disadvantages:

• Email addresses change (marriage, company rebranding, job changes)
• When an email changes, you need manual processes to update the account linkage
• Can create orphaned accounts if not managed carefully

Option B: External ID (e.g., Okta User ID)​

Instead of email, you can use a stable identifier from your identity provider — like an Okta User ID or Azure AD Object ID.

Advantages:

• The ID never changes, regardless of email updates
• More robust for long-term identity management
• More flexible for multi-provider scenarios

Disadvantages:

• Users are locked to a single identity provider
• Requires more upfront configuration by admins

Recommendation​

The right choice depends on your organization's size and existing infrastructure.

For smaller organizations without an existing identity provider, email-based identification is perfectly sufficient. It's simpler to set up, requires no additional infrastructure, and the occasional email change can be handled manually without significant overhead. Medplum supports multi-factor authentication (MFA), which is required for many regulated scenarios.

For enterprise customers with existing IDP infrastructure (Okta, Azure AD, etc.), a hybrid approach works best:

• Use external IDs for your organization's internal staff (the team building and operating the platform). These users have employer-managed identities through your corporate IDP, and stability matters more than flexibility. When an employee's email changes from jsmith@yourcompany.com to jane.smith@yourcompany.com, their account should continue working seamlessly with your existing SSO.

• Use email for patients and domain-level routing to IDPs for partners (clinicians or administrators at clinics using your EMR, etc.). This provides flexibility because different customer organizations may use different identity providers - or none at all. Email-based identification allows Medplum to dynamically route users to the appropriate IDP based on their email domain. For example, user@clinic-a.com routes to Clinic A's Okta instance, while user@clinic-b.com routes to Clinic B's Azure AD.

This hybrid approach lets you maintain tight SSO integration for your own team while giving customers the flexibility to use whatever identity infrastructure they have.

Decision 2: Identity Provider Strategy​

The next decision is where user credentials are managed. You have three options:

Option A: Medplum as IDP​

Medplum manages credentials directly. Users create accounts with Medplum, which handles password storage, reset flows, and authentication.

Best for: Smaller deployments, patient-facing applications where you don't have existing identity infrastructure.

Option B: External IDP (App-Based Routing)​

A third-party service (Okta, Azure AD, Auth0) manages credentials, and the routing is determined by the application. You configure a specific IDP for each application (Client ID).

Best for: Scenarios where all users of a specific app (e.g., "Patient Portal") use the same authentication method (e.g., "Sign in with Google"), regardless of who they are.

Option C: External IDP (Domain-Based Routing)​

A third-party service manages credentials, but routing is determined by the user's email domain. When user@hospital-a.com logs in, they're automatically routed to Hospital A's Okta instance. Medplum supports domain-level identity providers for this use case.

Best for: Multi-tenant platforms serving enterprise customers who want to bring their own identity provider (BYOIDP).

Decision 3: Token Flow Architecture​

This is where many teams make costly mistakes. Understanding token flows is essential for building a secure, maintainable system.

What's a Token?​

A token is a data packet that proves a user's identity for API requests. Think of it like a wristband at a concert - it proves you're allowed to be there without requiring you to show your ID at every interaction.

When integrating with external identity providers, you'll encounter multiple tokens:

• IDP Token (from Okta, Azure AD, etc.): Proves the user authenticated with the external IDP
• Platform Token (from Medplum): Required to access the FHIR API

The question is: how do you get from an IDP token to a platform token?

Before Building Custom Infrastructure​

When evaluating token flows, it's worth asking whether custom middleware or proxy layers are truly necessary. Modern FHIR platforms typically provide robust, standards-compliant authentication out of the box.

Before adding intermediate infrastructure, consider:

• What specific requirement does it solve? Make sure there's a documented need that the platform's native authentication can't address.
• What's the maintenance burden? Custom auth layers require ongoing security updates and auditing.
• Does it duplicate existing functionality? Often, the platform already handles what you're trying to build.

In most cases, the three-legged OAuth (redirect flow) described below will meet your needs without additional complexity.

Three-Legged OAuth (Recommended)​

Three legged OAuth is the recommended approach unless your application needs access to other services beyond Medplum:

1. User clicks "Login" in your app
2. Browser redirects to Okta
3. User authenticates with Okta
4. Okta redirects back to your app with a code
5. Your app exchanges the code with Medplum
6. Medplum validates with Okta and issues its own token
7. User's browser stores only the Medplum token

Result: User ends up with just a Medplum token. Clean, simple, secure.

Best for: Applications that only need to access Medplum APIs.

Token Exchange (Multi-Service Access)​

Token exchange is useful for multi-service workflows:

1. User authenticates with Okta
2. Okta issues a token stored in the user's browser
3. Your app sends the Okta token to Medplum's token exchange endpoint
4. Medplum validates the token and issues its own token
5. User's browser stores both tokens

Result: User has both an Okta token and a Medplum token.

Why this matters: If your application needs to access other services beyond Medplum (billing systems, other healthcare APIs, etc.), the user still has their Okta token to authenticate with those services. This is common in healthcare, where a single workflow might touch multiple systems.

// Using the Medplum SDK for token exchange
const medplum = new MedplumClient({
  baseUrl: MEDPLUM_BASE_URL,
  clientId: MEDPLUM_CLIENT_ID,
});

// Exchange your external IDP token for a Medplum token
await medplum.exchangeExternalAccessToken(OKTA_ACCESS_TOKEN);

// Now you can make FHIR API calls
const patient = await medplum.readResource('Patient', patientId);

On-Behalf-Of (Server-Side Pattern)​

For server-side applications that act as intermediaries, the On-Behalf-Of pattern allows a trusted backend to make requests on behalf of specific users:

1. Your backend authenticates as a ClientApplication
2. When making requests, include a header specifying which user you're acting for
3. Medplum applies that user's access policies to the request

curl 'https://api.medplum.com.ar/fhir/R4/Patient' \
  --user $CLIENT_ID:$CLIENT_SECRET \
  -H 'content-type: application/fhir+json' \
  -H 'x-medplum: extended' \
  -H 'x-medplum-on-behalf-of: ProjectMembership/abc123' \
  --data-raw '{"resourceType":"Patient","name":[{"given":["Homer"],"family":"Simpson"}]}'

Best for: Architectures where a custom backend mediates all interactions with Medplum. Useful for maintaining audit trails showing both which system made the request and which user it was acting for.

Putting It Together: Recommended Architecture​

For most healthcare organizations building on a FHIR platform, here's the recommended approach:

1. Choose your unique identifiers - external IDs for your internal staff, email for customers and their users
2. Use an external IDP (Okta, Azure AD) for enterprise users, with domain-level routing for multi-tenant scenarios
3. Implement Three-Legged OAuth unless your application needs access to other services outside of Medplum
4. Lean on native platform capabilities unless you have a specific, documented requirement for custom infrastructure

This architecture gives you:

• Centralized user management through your existing IDP
• Stable user accounts that survive email changes
• Simplicity of token flow
• Direct API access without unnecessary intermediaries

Key Questions to Ask​

Before finalizing your identity architecture, ensure you can answer these questions:

1. Who are your user types? (Staff, clinicians, patients, caregivers)
2. What identity providers do they use? (Corporate SSO, social login, self-registration)
3. What other systems need the IDP token? (Determines if you need Token Exchange)
4. How do you handle user offboarding? (Centralized IDP makes this easier)
5. What's your multi-tenancy model? (May require domain-level routing)

Conclusion​

Identity management doesn't have to be complicated. The key is understanding your requirements before jumping into implementation.

Start with the simplest approach that meets your needs. Three-legged OAuth with an external IDP is the recommended starting point for most healthcare applications. If you later need to access services beyond Medplum, you can adopt token exchange at that point.

For a complete overview of authentication options, see the Medplum Authentication Documentation.

Features​

Provider App: Spaces, Messaging, and Tasks​

David Yanez

The Provider app saw major improvements across messaging, task management, and the new Spaces experience. This work advances the Provider Application roadmap goal of expanding available workflows.

• Spaces streaming and buffered support — real-time communication with both streaming and buffered message delivery
• Server-Sent Events bot implementation — SSE support for bots, enabling real-time AI-powered interactions
• Messaging improvements — URL support in the inbox, participant filtering, and topic-based threading for Communications
• Task management — auto-selection when the task list is empty, priority display for better triage
• Navbar updates for both Medplum and Provider apps by Kevin Wadeshaw, plus a new Get Started page

Scheduling: $find and $book Operations​

Noah Silas

The most significant feature work this month was a ground-up buildout of FHIR-native scheduling operations. This directly supports the Scheduling initiative on our 2026 roadmap, where we committed to self-scheduling, advanced availability management, and resource scheduling.

• $find operation for querying available slots on a single Schedule resource, now with unique slot identifiers and timezone support (scheduling docs)
• $book operation for creating Appointments through a FHIR operation, with a first pass on the Provider UI booking flow
• Provider Calendar refactor to support the new scheduling operations
• Timezone support in SchedulingParams, enabling scheduling across time zones
• New search parameters for ActivityDefinition.code, Communication.priority, and ProjectMembership.active

These operations give developers a clean, standards-based API for building patient self-scheduling and staff scheduling workflows — a capability that has been one of our most requested features.

System-Level Custom FHIR Operations​

Gonzalo Bellver

Developers can now define custom FHIR operations at the system level, not just per-resource. This is a key building block for the Integrations & Plugins roadmap initiative, enabling more flexible bot-powered workflows and custom API endpoints.

FHIR Operations and Terminology​

Darren Eam

• Patient $summary operation with updated $everything documentation
• ConceptMap import and comprehensive terminology operations documentation
• New authentication and security operations and resource validation operations

Matt Willer

• X-FHIR-Query support in SDC $extract — enables dynamic queries in Structured Data Capture extraction, improving form-based data capture workflows
• Display language overrides in ValueSet/$expand and CodeSystem/$validate-code — supports multilingual terminology services, which is important for international deployments

Site Reliability and Infrastructure​

These changes support the Enterprise Scale & Infrastructure roadmap priority of handling growing platform traffic.

Matt Willer

• Reserved database connections for healthcheck — prevents health checks from being starved during high load
• Redis failover error handling in BullMQ workers — improves resilience during Redis cluster failovers
• Skip caching on write for AuditEvent resources — reduces memory pressure for high-volume audit logging
• Tracing extensions on OperationOutcome — better observability for debugging production issues

Matt Long

• ReindexJob configuration enhancements — more control over reindexing for large datasets
• Per-resourceType padding configuration — fine-grained tuning of array padding for storage optimization
• Array padding calculator — tooling to help determine optimal padding settings

Noah Silas

• Automatic pre/post deploy migration generation — streamlines the database migration workflow for self-hosted deployments

Security and Access Control​

• Inactive ProjectMembership disables access tokens — when a membership is set to inactive, associated tokens are immediately invalidated (access control docs) (Matt Willer)
• Subscription Bot execution respects ProjectMembership — ensures subscriptions run in the correct membership context (Matt Willer)
• On-behalf-of header support with proper cache disabling (Maddy Li, Cody Ebberson)

SDK and Developer Experience​

• client.post<T> generic type annotation for better TypeScript ergonomics (Noah Silas)
• Nested connections in GraphQL (Maddy Li)
• Configurable base64 caps in core (Sakshum Gadyal)
• Abort signal support for sleep to allow request cancellation (Mirza Kapetanovic)
• Subscription AuditEvent destination extension for routing audit events (Rahul Agarwal)

AI and MCP​

Advancing our AI roadmap initiative:

• MCP server updated to replace deprecated methods, keeping Medplum's Model Context Protocol support current (Noah Silas)
• AI operation documentation added (AI operation docs)

Documentation​

A significant documentation effort this month improved coverage across the Provider app, scheduling, self-hosting, the Medplum Agent, and compliance.

Provider

• Provider app docs updated (Provider app guide)
• Updated charting documentation

Finn Bergquist

• Revamped multi-tenancy documentation (multi-tenancy identity providers)
• Scheduling docs: availability time zones, $find beta status, SchedulingParameters duration param (scheduling docs)
• DoseSpot enrollment documentation: how to enroll users with the Enroll Prescriber Bot (medications docs)
• AccessPolicy requirements for Bulk Export API (API docs)
• Observation.valueSampledData documentation

Self-Hosting and Operations

• Self-hosting best practices docs (self-hosting guide)
• AWS Lambda bots on localhost guide (Bots docs)
• Node.js version requirement updated to 22+ (self-hosting guide)
• Docker Compose persistence and restart policies improved

Medplum Agent

Derrick Farris

The Medplum Agent is an application that runs inside your firewall and connects to devices over low-level protocols such as HL7/MLLP, ASTM, and DICOM, bridging them to the cloud via secure HTTPS WebSocket channels. This month the Agent docs received several updates:

• Minimal access policy for Agent documented
• Enhanced mode aaMode documented
• Section on deactivating memberships added

Additional Docs

• Integration tables organized into logical groups (integrations overview)
• Terminology services: translated display strings documentation (terminology services guide)
• Compliance documentation and CHPL listing updated for V5 (compliance overview)
• 2026 Roadmap published (2026 roadmap)

Bug Fixes​

Forms and UI

• Fixed repeatable items in QuestionnaireForm
• Fixed dark mode on the visit details page
• Fixed color inheritance issue (dark to inherit)
• Updated diagnoses binding URL in OrderLabsPage

Server and API

• Fixed SQL error in date array search parameters
• Fixed search by POST issue via body-parser update
• Fixed CCDA timezone offset conversion to FHIR format (Amanda McGivern)
• Fixed validateResource argument merging
• Fixed consistent storageBaseUrl generation with /binary/ path (Jim Fiorato)
• Fixed out-of-order query results in useSearch
• Fixed too-many-requests error re-wrapping in fetchTokens

Agent

• pushToAgent now returns on first ACK by default
• Added logging for enhanced mode acknowledgments

Infrastructure

• Fixed Docker Compose full-stack config after hardened images
• Added persistence to Docker Compose files (Matthew Raspberry)
• Fixed database connection release during seeding
• Fixed Spaces message persistence

Releases​

• v5.0.11 — January 21
• v5.0.12 — January 23
• v5.0.13 — January 28

Looking Ahead​

January's scheduling work sets the stage for the self-scheduling and resource scheduling features planned for 2026. The Provider app's Spaces and streaming capabilities are moving us closer to a production-ready provider experience. On the infrastructure side, the Redis failover handling and database connection improvements directly support enterprise-scale deployments.

Join us on Discord to share feedback or follow along on GitHub.

As of December 2025:

• 500,000+ Docker downloads (up 2x from 2024)
• 161 GitHub contributors (up 40% from 2024)
• 2,100 GitHub stars

As informed by our community and customers, we are focusing on the following initiatives in 2026.

Compliance (H1 2026)​

Medplum is pursuing HITRUST Certification for our hosted environment. We are also certifying changes related to HTI-4/CMS-0057-F to enable both providers and payers to comply with the mandate, with key milestones aligned to the January 2027 enforcement date.

These compliance primitives support hospital and health system connectivity and interoperability. The HTI-4 mandates are also important because they cover prior authorization for medications, professional billing, and facilities billing.

Related Reading: 📋 Compliance Overview, 🛡️ HITRUST, 🔒 SOC2, 🏥 HIPAA, ✅ ONC Certification, 🔗 TEFCA Overview

Enterprise Scale & Infrastructure​

Platform traffic on Medplum is growing quickly, and we are investing in several initiatives to achieve scale. We are implementing sharding and archiving capabilities to handle larger datasets efficiently. Data warehouse integration via Kafka will support high volume connections. We are also enhancing cross-cloud support for GCP, Azure, and AWS deployments.

Related Reading: 🏠 Self-Hosting Overview, 🗂️ Sharding Discussion, ☁️ Install on AWS, 🌐 Install on GCP, 🔷 Install on Azure, 📊 Analytics, 📈 AWS Athena Guide, 🎬 PlumCon Scaling to Millions of Patients

Scheduling​

Scheduling is key to healthcare workflows, and we are investing heavily in making it great for a wide variety of use cases. This includes self-scheduling, advanced availability management, facilities scheduling, and resource scheduling.

Related Reading: 📅 Scheduling Overview, ⏰ Defining Availability, 🗓️ Scheduling Product, 🤖 Scheduling Agents for Healthcare Operations

Provider Application​

Medplum has a provider experience that is ONC certified as a base EHR. We will make investments this year to expand the available workflows and integrations. We are also improving the onboarding experience for new practices to get up and running quickly.

Related Reading: 👨‍⚕️ Provider Overview, ⚙️ Provider Setup, 📝 Charting

Integrations & Plugins​

We are building a plugin ecosystem to give you access to a wide variety of tools that work with your workflow. We are also enhancing the prescribing experience with improved safety features and HTI-4 compliance.

Related Reading: 🤖 Bots Overview, 📚 Bot Basics, 💊 ePrescribe

Revenue Cycle & Billing​

We are enabling developers to build high fidelity revenue cycle management solutions. We are also streamlining prior authorization workflows to reduce administrative burden in accordance with the upcoming regulations in HTI-4.

Related Reading: 💰 Billing Overview, 🏦 Patient Insurance, ✅ Insurance Eligibility Checks, 📄 Creating CMS1500

AI​

Medplum continues to be a destination for builders who are making incredible AI applications. We will make continued investments to our AI infrastructure such as MCP, SSE, websockets, and composable model configurations that will power the next generation of models, copilots, scribes, and more.

Related Reading: 🧠 AI Overview, 🔌 MCP Support, 🩻 Rad AI Case Study, 👶 Summer Health Case Study, 📡 FHIRcast, ⚡ Async Bots and SSE

Key Themes for 2026​

To summarize, our 2026 priorities center around three key themes:

1. Regulatory Readiness - HITRUST certification and HTI-4 compliance to meet upcoming mandates
2. Scale & Performance - Infrastructure investments to support enterprise-grade deployments
3. Developer Experience - Enhanced scheduling, billing, AI tooling, and plugins to accelerate development

Join the Movement​

2026 will be a transformative year for healthcare technology, and Medplum is leading the charge. Whether you're a developer, healthcare provider, or innovator, there's never been a better time to join our growing community.

Stay tuned for more updates, and join us on Discord to be part of the conversation. We share quarterly progress updates and actively incorporate community feedback into our prioritization process. Your input directly shapes where we invest next.

An incredible year of growth, innovation, and community. From v5 release to expanding our developer ecosystem, 2025 marked several milestones for Medplum's open-source healthcare platform.

As we close out 2025, the Medplum team would love to thank our community and customers for joining us on this journey.

We wanted to highlight a few memorable moments and reflect on all that happened during the year. It was a lot of fun, and huge thank you to the team who pushed so hard to make all these things happen.

✅ Released Medplum v5, our most significant platform modernization to date, featuring full FHIR terminology validation, GraphQL Patch support, and comprehensive dependency upgrades to Node.js 22/24, PostgreSQL 14/18, and React 19

✅ Launched our new brand identity, reflecting our evolution as a leading open-source healthcare infrastructure platform. See the details here.

✅ Hosted our first annual developer conference PlumCon 2025 in San Francisco, bringing together healthcare innovators from around the world

✅ Delivered many new features and integrations, including enhanced AI capabilities with MCP server support, custom FHIR operations, IHE IRA radiology reporting certification, and expanded integrations with health information exchange, medications, and revenue cycle.

✅ A special thank you to those who contributed this year - we now have 157 talented contributors from around the world building the future of healthcare together

✅ Incredible ecosystem growth: 1,462 pull requests, 55 releases, 551 issues resolved, 2.1K GitHub stars, and 500K+ Docker downloads powering healthcare applications globally

✅ Added many wonderful customers, and several have made videos of their implementations. See case studies and PlumCon recap for videos.

✅ Organized several events throughout this year, including FHIR + AI for Life Sciences, Scheduling Agents for Healthcare Operations, and Visualizing Patient Flow, building our community of healthcare developers

Thank you, dear reader, for being part of our community. See you on Discord.

• Supporting synonyms in ValueSet/$expand, allowing users to find codes by a number of different search terms
• Scaling our implementation of the ConceptMap/$translate operation to handle maps with over a million entries
• Updating our library of UMLS code systems with their latest release, including several new code systems around medications and supplements and a mapping between related code systems and RxNorm
• A collection of performance enhancements that speed up ValueSet expansion and code validation by a significant margin
• (In beta) The option to validate all required terminology bindings in resources on write

Below we'll discuss each of these changes in more detail and give examples of the features available in Medplum's Terminology Services today.

Coding Synonyms​

Many codes are known by multiple different related names or terms, and users may use different search terms in different contexts when trying to find the right code for a clinical concept. For example, consider a provider populating information about a patient allergy, who wants to fill in the AllergyIntolerance.reaction.manifestation field with the SNOMED CT® code for hives using the Clinical Findings ValueSet. The relevant code in SNOMED is 247472004, but its display string is "Wheal (finding)" — not "hives"! If the user doesn't know the more technical term, finding the correct code would be difficult.

Fortunately, most code systems record multiple names (synonyms) for their codes. These are stored as metadata properties on the coding, which can be seen by looking up the code:

{
  "resourceType": "Parameters",
  "parameter": [
    { "name": "name", "valueString": "SNOMED CT (US Edition)" },
    { "name": "display", "valueString": "Wheal (finding)" },
    {
      "name": "property",
      "part": [
        { "name": "code", "valueCode": "SY" },
        { "name": "value", "valueString": "Hives" }
      ]
    },
    {
      "name": "property",
      "part": [
        { "name": "code", "valueCode": "SY" },
        { "name": "value", "valueString": "Urticarial rash" }
      ]
    },
    {
      "name": "property",
      "part": [
        { "name": "code", "valueCode": "SY" },
        { "name": "value", "valueString": "Welt" }
      ]
    },
    {
      "name": "property",
      "part": [
        { "name": "code", "valueCode": "SY" },
        { "name": "value", "valueString": "Weal" }
      ]
    },
    {
      "name": "property",
      "part": [
        { "name": "code", "valueCode": "SY" },
        { "name": "value", "valueString": "Nettle rash" }
      ]
    }
    // ...
  ]
}

Medplum now supports searching against these synonyms in addition to the primary display string when searching with the filter parameter of the ValueSet/$expand operation. Specifically, any coding properties with a special uri value of http://hl7.org/fhir/concept-properties#synonym will be indexed for search as a synonym for the given code. The SY property shown above is defined in the corresponding CodeSystem resource:

{
  "code": "SY",
  "type": "string",
  "description": "Designated synonym",
  // Properties with this `uri` will have their values included when searching for codes
  "uri": "http://hl7.org/fhir/concept-properties#synonym"
}

You can see the feature working as intended below, using Medplum's <CodeableConceptInput> React component:

Scalable Concept Mapping​

Some of the largest code systems in common clinical use contain hundreds of thousands of different codes, and mappings between them also operate on that scale. Our existing implementation of the ConceptMap/$translate operation relied on the data present inside the ConceptMap JSON, which limited the number of mappings that could be supported to the amount that would fit in a single resource.

To enable large mappings between complex code systems, we rebuilt our system for handling ConceptMap resources from the ground up. Existing mappings contained in the resource JSON were indexed into an optimized lookup table, and we added a new ConceptMap/$import endpoint similar to the one for CodeSystems to facilitate loading maps with a million entries or more into the system.

For example, we can query a large map of drugs from many different code systems to get their corresponding RxNorm code:

$ curl -H "Authorization: Bearer $ACCESS_TOKEN" \
  'https://api.medplum.com.ar/fhir/R4/ConceptMap/$translate?url=$RXNORM&system=http://snomed.info/sct&code=9500005'

{
  "resourceType": "Parameters",
  "parameter": [
    { "name": "result", "valueBoolean": true },
    {
      "name": "match",
      "part": [
        { "name": "equivalence", "valueCode": "equivalent" },
        {
          "name": "concept",
          "valueCoding": {
            "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
            "code": "8123"
          }
        }
      ]
    }
  ]
}

Our Postgres database is able to serve translations like this robustly, with a typical request executing in just 10 – 50 ms on our server! The ability to convert codes efficiently from one system to another is expected to be a foundational capability for supporting cross-coding and partner integrations at scale in the future.

This development paves the way for us to support complex mappings between large, commonly-used code systems. Next on our roadmap for this feature is to ingest the entire SNOMED to ICD-10 mapping and make it available to customers for testing. This map is both large (~250,000 entries) and complex, containing dependency requirements and descriptive notes that ensure codes are mapped correctly in context.

Updated UMLS Library with 2025AA Release​

Medplum maintains a library of full code systems imported from the semiannual UMLS releases, which includes several widely-used systems like SNOMED CT, ICD-10, and LOINC. We've created an updated version of the library from the latest release (2025AA), containing over 10,000 new codes and several new code systems:

• FDB MedKnowledge
• Gold Standard Drug Database
• FDA Structured Product Labels for drugs and active substances
• Manufacturers of Vaccines
• Medical Subject Headings (MeSH)

In tandem with the updates to scale ConceptMap/$translate described above, the mapping of several medication terminologies to RxNorm was extracted from the UMLS data set. This ConceptMap, containing about a quarter million mappings, was used as the foundation of our testing for the changes to ConceptMap. The following code systems are currently mapped in whole or part to RxNorm via this resource:

• CVX (vaccines)
• Gold Standard (drugs)
• MeSH (drugs and substances subset)
• FDA Structured Product Labels (drugs)
• FDB MedKnowledge (drugs)
• SNOMED CT (drugs subset)

Contact support@medplum.com.ar for access to the updated 2025AA release resources, in either our hosted cluster or your own self-hosted install.

ValueSet Performance Improvements​

Expanding a ValueSet to find matching codes is the most common terminology operation on Medplum: every time a user uses an autocomplete to fill in a coded value, the relevant ValueSet definition is being queried and filtered to provide them with a list of matching options. However, the database queries to power the autocomplete expansion can and often do contain complicated recursive joins in combination with text filters to find all the correct codes. While working on some of the other features listed here, we noticed a few ways to improve the relevant SQL queries. We were able to significantly boost performance across multiple terminology operations by combining a few different optimizations:

1. Improving index usage for text filters
2. Updating indexes on coding properties
3. Preloading property IDs to eliminate a JOIN

By replacing conditions of the form LOWER(display) LIKE '%filtertext%' with the equivalent display ILIKE '%filtertext%', we enabled better use of existing indexes in our lookup tables and made text search in ValueSet/$expand more efficient.

Since many terminology queries also involve property metadata (for example, to determine whether one code is a child of another), optimizing that part of our database queries had the potential to impact multiple different operations including code validation. With a combination of minor changes to our query structure, and updates to our lookup table indexes, we were able to make these queries up to 20x faster!

The effect these changes had was dramatic: the median latency for our ValueSet/$expand operation improved by 95%, as shown below (endpoint latency in milliseconds):

Before

After

Terminology Validation​

Last but not least, we've finally unlocked a long-requested feature: validating all terminology requirements for FHIR resources on write. Most resources contain some coded values, and the FHIR specification or a custom resource profile can require that those values are drawn from a specific allowed set. Medplum server now includes the option to check that any required terminology bindings are satisfied in resources being written to the server. Since this involves potentially tens of validation queries to the terminology service per resource, all the performance work we did over the past few months was instrumental in making it possible.

By enabling the validate-terminology feature for your Project, you can opt into the new validation process. It provides assurance that your data is fully compliant with the FHIR specification, and maximizes the interoperability of data stored in Medplum. This does come with a small performance cost to perform the validation, but we will be continuing to monitor and optimize this functionality in the coming months.

If you're interested in helping us test out terminology validation in your development or staging Project, contact support@medplum.com.ar to have the feature enabled. If you operate a self-hosted cluster, you will need to upgrade to Medplum v5 before the feature will be available.

Slideshow: View Presentation

This is a transcript summary of the October 2025 webinar with Medplum and Unity AI. Medplum CEO Reshma Khilnani interviews Unity AI CTO Cody Hall.

Reshma: We recently hosted a webinar exploring the intersection of AI, healthcare operations, and open-source infrastructure. I was joined by Cody Hall, CTO and Co-Founder of Unity AI, to discuss how his team is solving one of healthcare's most persistent bottlenecks: scheduling, using AI Agents.

Reshma: At Medplum, we often talk about the "terrible choice" healthcare developers face: invest heavily to build from scratch or fight with rigid, off-the-shelf software. Unity AI demonstrates a third path—building exceptional products on top of pre-built primitives. Here is a recap of how Unity AI is using Medplum and FHIR to coordinate scarce resources.

The Core Problem: Coordination and Scarcity​

Cody: Healthcare operations are fundamentally about the coordination of scarce resources—staff, equipment time, and physical space. While clinical algorithms for treatment are well-established, the logistics of getting the right patient to the right place at the right time remains a massive challenge.

Cody: Currently, this coordination is driven by human-to-human negotiation. A scheduler might make ten phone calls to confirm a single appointment. If a patient doesn't pick up, that scheduler rarely has the time to immediately find a backfill. The result is unused capacity, lost revenue for the clinic, and, most importantly, delayed care for patients.

Cody: Our thesis is that voice agents represent a solution to this communication constraint. Unlike humans, AI agents are infinitely scalable. They can react instantly to cancellations, reach more people simultaneously, and continuously work to fill schedule gaps.

The Role of Data Standardization (FHIR)​

Cody: Automation requires a high-fidelity representation of reality. Dr. Herbert Simon once said that decision-makers can "satisfice" by finding optimum solutions for a simplified world or satisfactory solutions for a more realistic world. FHIR allows us to find solutions for the realistic world because it lets us model complex relationships without oversimplifying.

Cody: A practical example of this is the RelatedPerson resource in FHIR. In a pediatric context, the patient is rarely the person coordinating the appointment. For example, if a parent is scheduling dental cleanings for two children, do you treat this as two separate tasks and call the parent twice? Or do you query the RelatedPerson resource, identify that one contact manages both appointments, and consolidate the communication?

Reshma: This is a really subtle but important point. At Medplum, we see this constantly with pediatrics and elder care on the platform. Noting down the RelatedPerson is critical for caregiver access. It is excellent to see an agent that actually respects this data model to reduce friction for the family.

Architecture: Systems of Action​

Cody: We use Medplum not just as a data store, but as a foundation for a "system of action." We model a confirmation request as a FHIR Bundle containing the Appointment, Patient, and Organization.

Cody: Once that bundle hits our API, a subscription in Medplum triggers our application. We use a durable workflow engine to spin up a voice agent. That agent calls the patient, verifies identity (like checking Date of Birth), and confirms the slot. The agent then updates the Task and Appointment status in Medplum in real-time.

Cody: Because Medplum handles the identity management and event-driven architecture, we can focus entirely on the logic of the scheduling agents rather than building boilerplate infrastructure.

The Future: The Distributed EHR​

Cody: Historically, EHRs were monolithic systems like Magic MUMPS. If you needed a specific feature, you hoped your vendor built it. Today, we are moving toward composability. I see a future of "Distributed EHRs," where Medplum acts as a headless backend allowing specialized vertical applications—like Unity AI for scheduling—to sit on top of a shared data layer.

Reshma: We agree completely. We believe customization is required to be successful, and monolithic systems often fail to yield to specific workflows like infusion or complex radiology. The composability of this architecture allows for "best-of-breed" solutions to work together seamlessly through standard APIs.

Community Q&A Highlights​

Cody: During the Q&A, we discussed how referrals are handled. In our system, referrals are modeled as a ServiceRequest. We pick up that request and generate the downstream communication workflows to ensure the patient is scheduled, closing the loop between providers.

Reshma: We also discussed the role of Bots. In Medplum, Bots effectively act as server-side functions. Whether verifying insurance with a partner like Stedi or triggering a custom workflow, Bots provide the logic layer that connects static data to active processes.

Cody: Finally, regarding data storage, the consensus is to keep data in FHIR whenever possible. While there is always a temptation to use a separate SQL database for app-specific config, keeping data in FHIR ensures interoperability and allows for powerful graph queries via GraphQL across the entire patient context.

To learn more about Unity AI, visit UnityAI.com.

As outlined in our preparatory post in May, Medplum v5 represents a comprehensive and necessary modernization of our core stack. This release ensures our platform maintains the highest standards of performance, security, and developer experience by aligning with the latest stable versions of our critical runtime and tooling dependencies.

As with all major releases, our goal is to provide a stable, predictable, and future-proof platform for building healthcare solutions.

Core Platform Modernization​

The bulk of the work in v5 involved essential dependency upgrades and technical debt reduction.

Runtime and Infrastructure​

Medplum v5 now requires and is rigorously tested against modern runtime environments:

• Node.js: We have deprecated Node 20 and now continuously test on Node 22 and 24. This upgrade enables access to the latest JavaScript features and performance improvements, including Node 22's Maglev compiler.
• PostgreSQL: We have ended support for Postgres 13 and now continuously test on Postgres 14 and 18. Users benefit from major database performance features, such as Postgres 18's asynchronous I/O subsystem.
• Redis: Support for Redis 6 has been dropped; we now continuously test on Redis 7.

New Capabilities​

We are excited to release several major new features in Medplum v5:

1. Full FHIR Terminology Validation. Medplum now includes comprehensive, built-in terminology support covering major code systems like SNOMED, ICD, CPT, and others. Crucially, this functionality also includes hierarchy support (e.g., "descendant of"). This advanced validation logic contributes directly to better data hygiene, improves data quality, and increases confidence in the integrity of the data managed by the Medplum platform.
2. FHIR GraphQL Patch support. The Medplum GraphQL API now supports FHIR Patch operations, enabling more efficient and flexible updates to FHIR resources via GraphQL mutations. This enhancement allows developers to perform partial updates, reducing payload sizes and improving performance for applications that require frequent resource modifications.

Frontend and Developer Tooling​

We have streamlined the frontend stack to improve build times, component quality, and overall developer experience:

• React: We've dropped support for React 18 and now require React 19, which simplifies our component maintenance moving forward.
• UI Components: Upgraded all usage from Mantine v7 to v8, which features improved date handling and enhanced TypeScript support.
• Core Frameworks: Successfully upgraded Express from v4 to v5 and Storybook from v8 to v9.

Strategic Update: ESM by Default​

A key architectural shift in v5 is the move to ES Modules (ESM) by default.

This aligns Medplum with the modern JavaScript module standard, offering benefits like improved tree-shaking and better future compatibility. For a smooth transition, we will dual-publish certain SDK packages as CJS+ESM. We strongly recommend that all custom applications migrate to ESM for optimal compatibility and performance moving forward.

Planning Your Migration (Breaking Changes)​

Medplum v5 includes a few minor breaking changes, primarily involving the deprecation of long-standing features and updates to API signatures for better consistency and modern patterns.

API and SDK Changes​

Infrastructure Changes​

• AWS Container Insights: Updated from v1 to Container Insights v2.
• CloudWatch Logs for Audit Events: Audit logging now utilizes AWS FireLens log routing for improved log management.

The Value of Upgrading​

While a major version upgrade requires planning, Medplum v5 delivers concrete benefits that justify the effort:

• Performance: Immediate and substantial performance gains across the stack, from the database and runtime to frontend tooling.
• Security: Access to the latest security features and patches across all dependencies.
• Future-Proofing: Setting your healthcare solutions on a stable, supported platform that is aligned with industry best practices.

Next Steps for Self-Hosted Customers​

We encourage self-hosted customers to begin planning their upgrade immediately.

• Consult our detailed migration guides on the documentation site.
• Schedule database and runtime environment upgrades with your DevOps team.
• Review your custom application codebase for compatibility with newer dependencies and the breaking changes listed above.

For technical questions or feedback, please join the conversation on Discord or submit issues on GitHub.

Medplum v5 is ready to power your next generation of healthcare applications.