In Medplum, you can build your tenancy model around any FHIR resource type. Common examples include:

• Organization: Different clinics, practices, or healthcare organizations
• HealthcareService: Different departments or services (e.g., Cardiology Department, Oncology Department)
• CareTeam: Different care teams (e.g., Diabetes Care Team, Hypertension Care Team)

For a comprehensive guide on how to set up multi-tenancy in Medplum—including data modeling, compartments, propagation, and user enrollment—see our Multi-Tenant Access Control documentation.

This blog post focuses on a specific challenge: What happens when a user belongs to multiple tenants? And more importantly, how can you ensure your application restricts access to only one tenant at a time?

Understanding API-Level Security and Isolation​

Before diving into the solutions, it's important to understand what API-level security and isolation means, especially for non-technical readers.

When a user logs into your application, they receive an authentication token (think of it as a digital key). This token is used to make requests to the Medplum API server to read or modify patient data, medical records, and other healthcare information.

API-level isolation refers to security controls that are enforced by the Medplum server itself—not just by your application's user interface. When properly configured, the server checks every request against the user's permissions and only allows access to data the user is authorized to see.

Why This Matters: The Security Risk​

Here's the critical security concern: If a bad actor obtains a user's authentication token and knows how to construct FHIR API requests, they could potentially access data from all tenants that user has access to—even if your application's UI only shows one tenant at a time.

The risks include:

1. Unauthorized Data Access: An attacker with a stolen token could bypass your application's UI restrictions entirely and directly query the API to retrieve patient data from multiple tenants simultaneously.

2. Data Exfiltration: They could systematically extract sensitive health information (PHI) from all tenants the user belongs to, not just the one currently displayed in your application.

3. Compliance Violations: Accessing data across tenant boundaries could violate HIPAA, state privacy laws, or organizational policies that require strict data isolation between different clinics, departments, or care teams.

4. Cross-Tenant Data Leakage: Even if your UI correctly filters data, an attacker making direct API calls could discover relationships, patient overlaps, or other sensitive information that should remain isolated between tenants.

The key question: Does your security model rely solely on your application's UI to restrict access, or does the API server itself enforce single-tenant isolation?

This blog post explores different approaches to ensure that even if someone gets hold of an authentication token, the API server itself will restrict access to only one tenant's data at a time—providing true API-level security.

How to Ensure Your Application Can Be Contained to Just One Tenant at a Time When a User Belongs to Multiple Tenants​

The Challenge: Multiple Tenant Memberships​

When a Practitioner user belongs to multiple tenants, their ProjectMembership will have multiple entries in the access array, each with different tenant parameters:

In this scenario, the user's API-level access includes data from both clinics. But how do you ensure your application is contained to just one tenant at a time?

{
  "resourceType": "ProjectMembership",
  "access": [
    {
      "parameter": [
        {
          "name": "organization",
          "valueReference": {
            "reference": "Organization/clinic-a",
            "display": "Downtown Clinic"
          }
        }
      ],
      "policy": {
        "reference": "AccessPolicy/mso-policy"
      }
    },
    {
      "parameter": [
        {
          "name": "organization",
          "valueReference": {
            "reference": "Organization/clinic-b",
            "display": "Uptown Clinic"
          }
        }
      ],
      "policy": {
        "reference": "AccessPolicy/mso-policy"
      }
    }
  ]
}

{
  "resourceType": "ProjectMembership",
  "access": [
    {
      "parameter": [
        {
          "name": "healthcare_service",
          "valueReference": {
            "reference": "HealthcareService/cardiology-service",
            "display": "Cardiology Department"
          }
        }
      ],
      "policy": {
        "reference": "AccessPolicy/service-policy"
      }
    },
    {
      "parameter": [
        {
          "name": "healthcare_service",
          "valueReference": {
            "reference": "HealthcareService/oncology-service",
            "display": "Oncology Department"
          }
        }
      ],
      "policy": {
        "reference": "AccessPolicy/service-policy"
      }
    }
  ]
}

{
  "resourceType": "ProjectMembership",
  "access": [
    {
      "parameter": [
        {
          "name": "care_team",
          "valueReference": {
            "reference": "CareTeam/diabetes-care-team",
            "display": "Diabetes Care Team"
          }
        }
      ],
      "policy": {
        "reference": "AccessPolicy/careteam-policy"
      }
    },
    {
      "parameter": [
        {
          "name": "care_team",
          "valueReference": {
            "reference": "CareTeam/hypertension-care-team",
            "display": "Hypertension Care Team"
          }
        }
      ],
      "policy": {
        "reference": "AccessPolicy/careteam-policy"
      }
    }
  ]
}

Tenant Isolation Approaches: Comparison Table​

Column Descriptions:

• API-Level Isolation (All Enrolled Tenants): Whether the API restricts access to only the tenants the user is enrolled in via their ProjectMembership.

• API-Level Isolation (Per Tenant): Whether the API restricts a User's access to only one tenant at a time, even if the User is enrolled across multiple tenants.

• Application-Level Isolation: Whether the UI restricts what's displayed to a single tenant.

Choosing the Right Approach​

Choose Option 1 if cross-tenant visibility is acceptable and you want the simplest implementation.

Choose Option 2 if you need UI-level tenant isolation but want users to be able to switch between tenants without re-authenticating. This approach maintains API-level access to all tenants and is also able to restrict what's displayed in the UI to only a single tenant at a time. It is much easier to implement Option 2 than Option 3.

Choose Option 3 if you need strict API-level single tenant access for security or compliance reasons. This is the most secure approach but requires users to sign in separately for each tenant they need to access with a separate ProjectMembership.

Option 1: Allow Access to All Enrolled Tenants​

Description: The user can view Patients and resources from all enrolled tenants simultaneously.

Implementation: No additional restrictions needed. The AccessPolicy already grants access to all enrolled tenants, and your application can display data from all tenants.

Use Case: This approach works well when cross-tenant visibility is acceptable or desired. For example, a care coordinator who needs to see all patients across multiple clinics they manage.

Option 2: Frontend-Level Restriction with _compartment​

Description: Keep the ProjectMembership and AccessPolicy configuration the same, but add the _compartment search parameter to all frontend queries to scope results to a specific tenant. The _compartment search parameter may look familiar because it is used in the AccessPolicy critertia. We can also use _compartment on the query itself, in combination with the AccessPolicy criteria, to further restrict the data that is returned to the user to only the data for the currently selected tenant.

Implementation: At the application level, maintain state for the currently selected tenant, and append _compartment=<current_tenant_ref> to all search queries.

Example:

// User selects "Downtown Clinic" in the UI
const currentTenant = 'Organization/clinic-a';

// All queries include _compartment filter
const patients = await medplum.search('Patient', {
  _compartment: currentTenant
});

const observations = await medplum.search('Observation', {
  _compartment: currentTenant
});

Use Case: When you need UI-level tenant isolation but want to maintain API-level access to all tenants. This allows users to switch between tenants in the UI without re-authenticating, while ensuring the UI only displays data from the selected tenant.

Option 3: Multiple ProjectMemberships​

Description: Create a separate ProjectMembership for each tenant. Each membership has its own AccessPolicy with a single tenant parameter, enforcing isolation at the API level.

Multiple ProjectMemberships is an advanced Medplum feature. ProjectMemberships are a crucial part of access control to the Medplum data store and determine what resources a user can read, write, or modify. Misconfiguring ProjectMemberships or AccessPolicies can result in Users being locked out of necessary resources or gaining unauthorized access to data.

Before implementing multiple memberships:

• Thoroughly understand AccessPolicies and how they work
• Test extensively in a development environment
• Consider consulting with Medplum support or the community if you're unsure ::

Implementation: Use the /admin/projects/:projectId/invite endpoint with forceNewMembership: true to create additional memberships for the same user.

With multiple ProjectMemberships, each membership grants access to only one tenant, ensuring strict API-level isolation:

Example:

// First membership - Downtown Clinic
await medplum.post('admin/projects/:projectId/invite', {
  resourceType: 'Practitioner',
  firstName: 'Jane',
  lastName: 'Smith',
  email: 'dr.smith@example.com',
  password: 'secure-password',
  membership: {
    access: [
      {
        policy: { reference: 'AccessPolicy/mso-policy' },
        parameter: [
          {
            name: 'organization',
            valueReference: { reference: 'Organization/clinic-a' }
          }
        ]
      }
    ],
    identifier: [
      {
        system: 'https://medplum.com/identifier/label',
        value: 'Downtown Clinic'
      }
    ]
  }
});

// Second membership - Uptown Clinic
await medplum.post('admin/projects/:projectId/invite', {
  resourceType: 'Practitioner',
  firstName: 'Jane',
  lastName: 'Smith',
  email: 'dr.smith@example.com',
  forceNewMembership: true,  // Required for creating additional membership
  membership: {
    access: [
      {
        policy: { reference: 'AccessPolicy/mso-policy' },
        parameter: [
          {
            name: 'organization',
            valueReference: { reference: 'Organization/clinic-b' }
          }
        ]
      }
    ],
    identifier: [
      {
        system: 'https://medplum.com/identifier/label',
        value: 'Uptown Clinic'
      }
    ]
  }
});

// First membership - Cardiology Service
await medplum.post('admin/projects/:projectId/invite', {
  resourceType: 'Practitioner',
  firstName: 'Jane',
  lastName: 'Smith',
  email: 'dr.smith@example.com',
  password: 'secure-password',
  membership: {
    access: [
      {
        policy: { reference: 'AccessPolicy/service-policy' },
        parameter: [
          {
            name: 'healthcare_service',
            valueReference: { reference: 'HealthcareService/cardiology-service' }
          }
        ]
      }
    ],
    identifier: [
      {
        system: 'https://medplum.com/identifier/label',
        value: 'Cardiology Service'
      }
    ]
  }
});

// Second membership - Oncology Service
await medplum.post('admin/projects/:projectId/invite', {
  resourceType: 'Practitioner',
  firstName: 'Jane',
  lastName: 'Smith',
  email: 'dr.smith@example.com',
  forceNewMembership: true,  // Required for creating additional membership
  membership: {
    access: [
      {
        policy: { reference: 'AccessPolicy/service-policy' },
        parameter: [
          {
            name: 'healthcare_service',
            valueReference: { reference: 'HealthcareService/oncology-service' }
          }
        ]
      }
    ],
    identifier: [
      {
        system: 'https://medplum.com/identifier/label',
        value: 'Oncology Service'
      }
    ]
  }
});

// First membership - Diabetes Care Team
await medplum.post('admin/projects/:projectId/invite', {
  resourceType: 'Practitioner',
  firstName: 'Jane',
  lastName: 'Smith',
  email: 'dr.smith@example.com',
  password: 'secure-password',
  membership: {
    access: [
      {
        policy: { reference: 'AccessPolicy/careteam-policy' },
        parameter: [
          {
            name: 'care_team',
            valueReference: { reference: 'CareTeam/diabetes-care-team' }
          }
        ]
      }
    ],
    identifier: [
      {
        system: 'https://medplum.com/identifier/label',
        value: 'Diabetes Care Team'
      }
    ]
  }
});

// Second membership - Hypertension Care Team
await medplum.post('admin/projects/:projectId/invite', {
  resourceType: 'Practitioner',
  firstName: 'Jane',
  lastName: 'Smith',
  email: 'dr.smith@example.com',
  forceNewMembership: true,  // Required for creating additional membership
  membership: {
    access: [
      {
        policy: { reference: 'AccessPolicy/careteam-policy' },
        parameter: [
          {
            name: 'care_team',
            valueReference: { reference: 'CareTeam/hypertension-care-team' }
          }
        ]
      }
    ],
    identifier: [
      {
        system: 'https://medplum.com/identifier/label',
        value: 'Hypertension Care Team'
      }
    ]
  }
});

Sign-In Flow: When a user with multiple ProjectMemberships signs in, Medplum automatically prompts them to choose which membership to use for their session. Each membership can have a custom label (via the https://medplum.com/identifier/label identifier system) to help users distinguish between them.

Use Case: When you need strict API-level tenant isolation. This ensures that once authenticated, the user's API access is limited to only the selected tenant's data. This is the most secure approach and is ideal for scenarios where regulatory requirements or organizational policies mandate strict data isolation.

• 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/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 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 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.

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.

This project is a perfect example of how the open-source community is tackling real-world problems. It was created by Jennifer Jiang-Kells, an honorary researcher at the University College London Hospitals (UCLH) NHS Foundation Trust, highlighting its roots in a premier healthcare institution.

Connecting Epic to Medplum​

One of HealthChain's most useful examples is a "Note Reader" service that integrates Epic NoteReader with Medplum. This demo shows how to process clinical notes, extract data like billing codes, and map them to the FHIR format. This addresses a key pain point for developers who need to modernize data workflows without replacing their existing Epic infrastructure.

By connecting Epic NoteReader to a modern FHIR server like Medplum, this project demonstrates a practical, open-source solution for developers. It's a powerful tool for bridging the gap between legacy CDA systems and modern healthcare platforms.

Get Started​

We encourage you to explore the project and see what's possible.

• HealthChain: https://dotimplement.github.io/HealthChain/
• Clinical Coding Demo: https://dotimplement.github.io/HealthChain/cookbook/clinical_coding/

Thank you so much for joining us today for our FHIR and AI for Life Sciences webinar. It was great to see many familiar and new faces from the broader healthcare community.

We wanted to share the recording for anyone who missed it or who would like to check it out again!

Below are a number of the resources which we shared during the webinar for you to peruse!

Medplum:

• docs, also book demo if you'd like a walk through
• mcp server
  • mcp backstory from Medplum CTO
  • mcp demo on YouTube
• github
• provider app docs
  • login to hosted provider app (you'll need a Medplum account)
  • provider app source code
  • bonus video - vibecoding EHRs based on provider app

phenoml:

• docs
  • Construe is the med RAG API we discussed!
• agent demos (patient support program, illustrative agents in apps + notebook)
• phenoml integrated medplum provider app

If you'll be in San Francisco for JPM in January 2026 please stay tuned for in-person workshops we'll be holding!

Thank you so much!

Reshma & Kerry

When	Topic	Location	Featuring
Dec 4, 2025, 10:00 AM PT	Visualizing Patient Flow: A Blueprint Reference App for Healthcare IT	Zoom
Jan 15, 2025, 9:00 AM - 2:00 PM PT	Interactive Workshop FHIR+AI for Life Sciences	San Francisco	Kerry Weinberg, Reshma Khilnani

Past Events​

When	Topic	Location	Featuring
Nov 18, 2025, 8:00 AM PT	FHIR Made Fast: Delivering Production-Ready Healthcare Apps in 12 Weeks with Medplum	YouTube	Medplum, TechMagic
Oct 30, 2025, 10:00 AM PT	Scheduling Agents for Healthcare Operations	Zoom	Cody Hall from Unity AI, Medplum Team
Oct 22, 2025, 5:00 PM PT	AI x Open source : Community evening with Hatchet, Medplum and SigNoz	San Francisco
Oct 8, 2025, 4:30 PM PT	Healthcare Devs Open Source Happy Hour - #SFTechWeek	San Francisco	Medplum, Awell, Villi Itchev
October 2025	Healthcare Devs Open Source Happy Hour - #SFTechWeek	San Francisco	Medplum, Awell, Villi Itchev
September 2025	FHIR + AI for Life Sciences	Zoom	Reshma Khilnani, Kerry Weinberg
September 2025	Infrastructure Tools for the Care Economy	San Francisco	Reshma Khilnani, Pivotal Ventures
August 2025	PlumCon 2025	San Francisco	Medplum Team
June 2025	San Francisco Health Tech Meetup	San Francisco	Medplum Team, Health Tech Nerds
July 2025	San Francisco Health Tech Meetup	San Francisco	Medplum Team, Health Tech Nerds
January 2025	Medplum & Flexpa: Devtools for research, commercialization and more in life sciences	San Francisco	Medplum Team, Flexpa

That's why a few months ago, we decided to ramp up our participation in the Open Source Security Foundation (OpenSSF). We're excited to share the progress we've made in two of their key programs: the Best Practices Badge and the Scorecard.

OpenSSF Best Practices​

The OpenSSF Best Practices Badge program provides a framework for open source projects to demonstrate that they follow security-related best practices. It's a comprehensive and detailed self-assessment that covers a wide range of topics, from secure development processes to vulnerability reporting.

We're incredibly proud to announce that the Medplum repository has achieved full "gold" status, the highest level a project can receive. This wasn't a simple task; it involved meticulously reviewing our processes and code to ensure we met every single requirement. You can view our full report here. This achievement validates our foundational commitment to building secure and reliable software.

OpenSSF Scorecard​

While the Best Practices Badge is a self-assessment, the OpenSSF Scorecard is where the rubber truly meets the road. This automated tool analyzes your repository and verifies that your project actually adheres to critical security practices. When we first ran the Scorecard on our repository, the results were humbling. The tests are rigorous, and they don't hold back.

Over the past few months, we've worked tirelessly to improve our Scorecard results. We are proud to say that Medplum is now consistently scoring 9.5+ out of 10. We see this not as an endpoint, but as a continuous journey to push for a higher and higher score, ensuring our users can trust the security of our platform. You can see our current Scorecard results here.

Bigger Picture: Why This Matters​

Our journey with the OpenSSF programs is not just about our project; it's about the state of open source security as a whole. A recent paper, “An Analysis of Supply Chain Security in Research Software,” highlights just how challenging this space is. The paper examines the Scorecard scores of 3,248 research software repositories, and the findings are eye opening.

The study found that the mean aggregate Scorecard score was 3.5, indicating a massive potential for improvement across the majority of scanned repositories.

While these stats are a bit sobering, they underscore why our achievements with the Best Practices Badge and the high Scorecard rating are so important. They are a clear signal to our users and the community that we take supply chain security seriously and have gone above and beyond to build a platform that you can trust.

We will continue to be active participants in the OpenSSF community and programs, constantly striving to improve our security posture and contribute to a more secure open source ecosystem for everyone.

Below you'll find slideshows and videos from each presentation, organized by talk. Most sections includes the speakers presentation and slides. We also have a YouTube Playlist available.

We also want to thank everyone who donated demos and demo videos to this event - we are thankful for our community.

Presentation Materials​

Keynote: Medplum Past, Present and Future​

Speaker: Cody Ebberson

Slides: Download Presentation

How to be a Healthtech Hero and Ship Apps 10x Faster​

Speaker: Rahul Agarwal

Slides: How to be a Healthtech Hero and Ship Apps 10x Faster
Video: Watch Recording

Fireside Chat: AI in Production in Healthcare​

Speakers: Matthew Woo, Reshma Khilnani

Fireside chat was not recorded, but see more info and case study below.

Scaling to Millions of Patients​

Speakers: Matt Long, Matt Willer

Slides: Scaling to Millions of Patients
Video: Watch Recording

Realtime Applications: FHIRcast, Websockets and HL7v2​

Speakers: Derrick Farris, Maddy Li

Slides: Real-time Medical Applications for Developers
Video: Watch Recording

Vibecoding EHRs​

Speakers: Kevin Shaw, David Yanez

Slides: Vibe Coding EHRs
Video: Watch Recording

Healthcare Integrations​

Speakers: Ian Plunkett, Rahul Agarwal

Slides: What We Worry About So You Don't Have To
Video: Watch Recording

Demo Showcase​

The following demos were provided by the community. Thank you so much to all teams who contributed videos.

Seen Health​

PACE specific EHR with realtime collaboration features and multi-player chart editing and workflow.

Summer Health​

24/7 Pediatric care via SMS, built their CareOS on Medplum. Read the case study. A live demo was showcased in the Fireside Chat.

Rad AI Omni Reporting​

Realtime application shown in the Realtime Apps presentation. More details here.

Progress Notes​

This psychotherapy EHR and scribe was created by one person, Dr. Wong - who is a clinician! Large portions were vibecoded, and this video was showcased in the Vibecoding EHRs session.

Payer Data Exchange​

This app was created by Flexpa and showcases payer FHIR API network. It was featured during the Happy Hour.

Clinical Trials AI Charting App​

A very cool Clinical Trials charting app created by the team at PhenoML was showcased at the Happy Hour.

Develo Pediatric EHR​

A comprehensive pediatric EHR system built with Medplum, showcasing specialized workflows for pediatric care was showcased at the Happy Hour.

Awell Clinical Ops Automation​

Clinical operations automation platform built with Medplum, streamlining healthcare workflows and improving operational efficiency.

Vibrant AI Enabled EHR​

AI-powered EHR system built with Medplum, featuring intelligent automation and enhanced clinical decision support.

PlumCon 2025 Photos​

Some photos from the conference.

The IRA profile, published in October 2023 by Integrating the Healthcare Enterprise (IHE), represents a transformative approach to radiology interoperability. Built on FHIRcast 3.0.0 and FHIR R5 standards, IRA enables different applications—from PACS systems to AI tools—to share context and content seamlessly during diagnostic reporting. For Medplum, certification as a FHIRcast Hub means our platform can now coordinate complex radiology workflows where multiple applications must work together in harmony.

The Radiology Workflow Challenge IRA Solves​

Today's radiologists navigate disconnected systems during their daily work. A typical workflow involves juggling between three to five applications simultaneously: PACS for image viewing, RIS for patient scheduling, dictation systems for reporting, and increasingly, AI tools for analysis/reporting. Each system operates in isolation, requiring manual synchronization that costs radiologists 1-2 minutes per patient—time that adds up to significant productivity losses across thousands of daily studies.

Manual data entry between systems introduces errors, while the cognitive burden of constant context switching contributes to radiologist burnout.

IRA addresses these challenges through intelligent application synchronization. When a radiologist opens a chest CT in their PACS system, IRA automatically synchronizes the reporting application, AI tools, and any other connected systems to the same patient and study. This seemingly simple capability eliminates thousands of manual clicks daily while dramatically reducing the risk of context-related errors.

Understanding IRA's Technical Architecture​

At its core, IRA leverages FHIRcast, a modern publish-subscribe protocol designed for real-time healthcare application communication. As the certified Hub, Medplum serves as the central nervous system for radiology workflows, managing multiple concurrent sessions and ensuring all connected applications stay synchronized.

The profile defines five key actors in the radiology ecosystem. Image Display applications present studies for diagnostic review. Report Creators handle dictation and structured reporting. Content Creators generate clinical evidence like measurements and annotations. Evidence Creators perform advanced visualization and AI analysis. The Hub—Medplum's certified role—orchestrates communication between all these actors through standardized events.

Four primary events drive the synchronization workflow. DiagnosticReport-open fires when a radiologist selects a study, establishing the anchor context for all connected applications. DiagnosticReport-update shares clinical content like measurements or AI findings across the ecosystem. DiagnosticReport-select indicates when specific content needs attention, enabling features like synchronized highlighting. DiagnosticReport-close cleanly terminates the session when reporting completes.

How FHIRcast Powers Real-Time Synchronization​

FHIRcast provides the underlying communication infrastructure that makes IRA possible. Using WebSocket connections for real-time notifications and OAuth 2.0 for secure authentication, FHIRcast enables applications to subscribe to relevant workflow events and respond instantly to context changes.

The protocol distinguishes between driving applications that initiate context changes and subscribing applications that follow along. In a typical scenario, a PACS system acts as the driving application when a radiologist opens a study. The reporting system, AI tools, and advanced visualization applications subscribe to these events, automatically updating their context to match. This publish-subscribe model ensures all applications remain synchronized without requiring point-to-point integrations between each system.

Version control mechanisms using context.versionId and context.priorVersionId ensure events process in the correct sequence, even in distributed environments where network delays might otherwise cause synchronization issues. When synchronization errors occur, the protocol includes sophisticated error handling and recovery mechanisms, allowing applications to query the Hub for the latest context and self-correct.

Real-World Scenarios Enabled by IRA​

The true power of IRA emerges in everyday radiology workflows. Consider a radiologist reviewing a complex oncology case requiring measurements across multiple imaging series. With IRA, measurements created in the PACS automatically appear in the reporting system as structured FHIR Observation resources. The radiologist can reference these measurements in their report without manual transcription, while the measurements remain linked to their precise anatomical locations for future reference.

AI integration represents another transformative use case. When an AI algorithm detects a pulmonary nodule, it creates an ImagingSelection resource highlighting the specific region of concern. Through IRA's DiagnosticReport-update event, this finding immediately appears in both the PACS and reporting system. The radiologist sees the AI annotation overlaid on the image while simultaneously having access to quantitative measurements and confidence scores in their report template.

For interrupted workflows—a constant reality in busy radiology departments—IRA enables seamless suspend and resume capabilities. A radiologist called away for an urgent case can return later to find all applications automatically restored to the exact context where they left off. This session persistence eliminates the frustrating and error-prone process of manually reopening studies and relocating specific findings across multiple systems.

Medplum's Unique Position in Healthcare Interoperability​

Medplum's achievement of IRA Hub certification represents a natural evolution of our FHIR-native platform strategy. As an open-source platform released under Apache 2.0 license, through open source Medplum makes integrations possible that weren't before. The Medplum architecture combines the flexibility developers need with the compliance healthcare requires, including HIPAA compliance, SOC 2 Type 2 certification, and ONC certification for patient API services.

The Hub certification adds a critical capability to Medplum's platform: the ability to orchestrate complex, multi-vendor radiology workflows. Unlike traditional integration approaches requiring custom interfaces between each application pair, Medplum's IRA Hub provides a standards-based switchboard that any compliant application can connect to. This dramatically reduces integration complexity while enabling true plug-and-play interoperability between best-of-breed radiology solutions.

The Big Picture​

IRA represents more than incremental improvement—it's a fundamental reimagining of how radiology applications interact. As the profile matures from experimental status to production readiness over the next 2-3 years, we can expect transformative changes in radiology workflows.

Radiology has always been a bellwether in healthcare IT, early to adopt digital systems, scribing technologies, and AI use cases. This type of real-time event context synchronization is emblematic of what scribes will need in the future as healthcare workflows become more complex and AI-driven.

Near-term developments will focus on stabilizing the underlying FHIRcast 3.0.0 specification and incorporating feedback from early implementations. As more vendors achieve certification, the network effects will accelerate adoption—each new IRA-compliant application increases the value proposition for all participants in the ecosystem.

The convergence of IRA with related IHE profiles promises even greater capabilities. The AI Workflow for Imaging (AIW-I) profile standardizes how AI algorithms integrate into diagnostic workflows. The AI Results (AIR) profile defines how AI findings are stored and communicated. Together with IRA, these profiles create a comprehensive framework for intelligent, AI-augmented radiology workflows where human expertise and machine analysis seamlessly combine.

Looking further ahead, IRA lays the groundwork for autonomous reporting systems where AI generates preliminary reports that save radiologists time and busy work. Real-time quality assurance could flag potential errors before reports are finalized. Predictive analytics might optimize workflow routing based on case complexity and radiologist expertise. These advances all depend on the real-time, standards-based interoperability that IRA enables.

For radiology departments struggling with fragmented workflows and disconnected systems, IRA offers a standards-based path forward. For vendors building next-generation radiology applications, Medplum's certified Hub provides the interoperability infrastructure needed to participate in modern, integrated workflows. For radiologists themselves, IRA promises workflows where technology enhances rather than hinders their ability to provide excellent patient care.

As healthcare continues its digital transformation, standards like IRA and platforms like Medplum that embrace them will prove essential. The future of radiology lies not in monolithic, single-vendor solutions, but in ecosystems of specialized, interoperable applications working in concert. With IRA Hub certification, Medplum has positioned itself at the center of this transformation, ready to enable the next generation of radiology workflows.

Related Reading​

• Medplum IRA Seal as PDF
• IHE Integrated Reporting Applications (IRA) Profile
• FHIRcast Specification
• AGFA HealthCare IHE 2024 Connectathon Results
• Rad AI Evolution of Radiology Reporting
• RSNA AI Integration in Radiology Workflows
• IHE North America Connectathon 2025
• Radiology Information Systems Market Analysis
• GE Healthcare IHE Interoperability

Morning Session​

9:00 AM	Breakfast
9:30 AM	Keynote: Medplum Past, Present and Future	Cody Ebberson
10:15 AM	Implementation Speedrun: 5 Pro Tips to Ship Healthcare Apps 10x Faster	Rahul Agarwal
10:30 AM	Coffee Break
10:45 AM	Fireside Chat: AI in Production in Healthcare	Matthew Woo, Reshma Khilnani
11:30 AM	Scaling to Millions of Patients	Matt Long, Matt Willer
12:00 PM	Lunch Break

Afternoon Session​

1:00 PM	Realtime Applications: FHIRcast, Websockets and HL7v2	Derrick Farris, Maddy Li
1:40 PM	Vibecoding EHRs	Kevin Shaw, David Yanez
2:00 PM	Stretch Break
2:20 PM	Orders, Medications and Transactions	Ian Plunkett, Rahul Agarwal
3:30 PM	Happy Hour and Demos

What Are FHIR Operations?​

FHIR operations are the "dollar sign things" – endpoints like $validate, $expand, or $match that perform specialized functions beyond standard CRUD operations. These are technically called "operations" in FHIR terminology, distinct from the basic "interactions" used for everyday data management.

Until now, Medplum supported built-in FHIR operations like $validate and custom logic through our Bot framework using $execute. But there was a gap: customers wanted more natural, domain-specific endpoints that felt like proper FHIR operations.

Why Custom Operations Matter​

Consider these scenarios:

• A pharmacy system that needs a MedicationRequest/$submit operation
• A quality assurance workflow requiring Patient/$quality-check
• Custom patient matching logic via Patient/$match
• Integration workflows that transform data before processing

Previously, these would all use the generic Bot/{id}/$execute syntax. Custom operations provide a more elegant, FHIR-native approach with endpoints that clearly communicate their purpose.

How It Works​

Custom FHIR operations build on Medplum's existing Bot infrastructure, providing three key benefits:

1. Natural API Design: Instead of Bot/dose-calculator/$execute, you can now use MedicationRequest/$calculate-dose
2. FHIR Standards Compliance: Operations are defined using standard FHIR OperationDefinition resources
3. Existing Security Model: Custom operations inherit all the access controls and permissions from the underlying Bot framework

Getting Started​

Setting up a custom operation involves three steps:

1. Create and deploy your Bot with the custom logic
2. Create an OperationDefinition resource that defines the operation's interface
3. Link them together using the operation-definition-implementation extension

The OperationDefinition specifies the operation code (like "quality-check"), input/output parameters, and includes a reference to your Bot implementation.

Once configured, you can call your custom operation using standard FHIR syntax:

POST /fhir/R4/Patient/$quality-check

Security and Access Control​

Custom operations follow Medplum's principle of "syntactic sugar on the existing Bot execute framework." They inherit all existing security controls:

• Bots must have appropriate project membership
• Standard FHIR access control applies
• Access policies are recommended for all Bot implementations
• The same permission model that governs $execute applies to custom operations

Implementation Philosophy​

We've designed custom operations following Postel's Law: "be liberal in what you accept and conservative in what you send." The system is flexible with inputs (your Bot receives the raw POST body) but strict with outputs (responses are properly formatted according to the OperationDefinition).

This approach prioritizes developer experience while maintaining FHIR compliance for API consumers.

Looking Forward​

This initial implementation focuses on Bot-backed operations, but the framework is extensible. Future versions could support external web service implementations or other execution models.

We're also considering whether customers should be able to override built-in operations – a powerful capability that opens interesting possibilities while requiring careful consideration of the implications.

Ready to Try It?​

Custom FHIR operations are available now in Medplum. Check out our documentation for detailed setup instructions, examples, and best practices.

This feature represents our commitment to providing healthcare developers with powerful, standards-compliant tools that adapt to real-world workflows. We can't wait to see what custom operations you build.

We know that technical leaders feel the pressure to define and execute on an AI strategy, and to demonstrate tangible progress to teams and stakeholders, that's expected in times of rapid technical advances.

That's why we're thrilled to announce our beta support for Anthropic's Model Context Protocol (MCP), marking a significant leap forward in how large language models (LLMs) can securely and intelligently interact with healthcare infrastructure and systems of record.

What is the Model Context Protocol (MCP)?​

Think of the Model Context Protocol (MCP) as the universal adapter for AI applications. Developed by Anthropic, MCP is an open standard designed to standardize how AI models, particularly LLMs, connect with and utilize external tools, systems, and data sources.

MCP provides a structured way for LLMs to understand and interact with the outside world, moving beyond simple text generation to actual, actionable engagement with your existing infrastructure.

For healthcare, this is a game-changer due to the rigors of the workflow. Imagine LLMs not just summarizing information, but intelligently querying patient data (securely and appropriately), managing workflows, or even orchestrating integrations with medical devices. That's the promise of MCP.

Medplum's Next Step: Empowering Intelligent Healthcare Applications with MCP​

Our initial support for MCP leverages the official TypeScript SDK, with a focus on cloud-native interactions via SSE (Server-Sent Events) and Streamable HTTP. While the MCP team is pushing for Streamable HTTP, we're currently supporting both to ensure compatibility with major LLM vendors.

The real power we're unlocking comes from our custom fhir-request tool, exposed through our MCP API. This tool allows an LLM to invoke almost any function within the Medplum API, because nearly everything in Medplum is exposed as FHIR resources and operations.

Here's a glimpse of what you can do:

Intelligent Data Retrieval: Imagine an LLM securely searching for synthetic patient data, reading specific observations, or getting conditions lists.
Automated Workflows: LLMs can initiate and manage healthcare processes, like creating a new task, scheduling an appointment, or marking a task as completed.
Complex Operations: Beyond standard FHIR resources, our fhir-request tool enables LLMs to trigger Medplum's powerful integrations and FHIR operations, such as submitting a Claim via $submit.

We're particularly optimistic about this pattern because LLMs already have a strong understanding of FHIR, allowing them to adapt to our API naturally and with surprising accuracy.

This capability is enhanced when combined with Medplum Bots. These are JavaScript/TypeScript snippets that run in response to triggers – imagine an LLM orchestrating a workflow that a Medplum Bot then executes, like deploying another Bot or executing a complex operation (/Bot/{id}/$deploy, /Bot/{id}/$execute).

And for those deeply embedded in existing healthcare infrastructure, our Medplum Agent takes this even further. The Agent provides on-premise connectivity to EHRs, LIS, RIS, PACS, and other devices. With MCP, an LLM could intelligently construct an HL7 v2 message and push it directly to an on-premise destination via /Agent/{id}/$push – that's truly sending data from the LLM chat to the front lines of healthcare delivery!

Why This Matters: Staying Ahead in AI​

For healthcare technical leaders, the message is clear: AI is no longer a distant future; it requires action today. The pressure to innovate and integrate AI into your healthcare strategy is real. Medplum's support for MCP offers a unique opportunity to:

Experiment Safely and Intelligently: Get hands-on with cutting-edge AI integration without starting from scratch.
Demonstrate Rapid Progress: Show your teams and leadership how AI can tangibly interact with healthcare data and workflows, even with experimental, de-identified data.
Build Future-Proof Architectures: By embracing open standards like MCP, you're positioning your organization to seamlessly adopt the next generation of AI capabilities.
Attract Top Talent: Signal that your organization is at the bleeding edge, embracing new technologies and solving complex problems.

We know you're looking for ways to leverage AI now to drive innovation and efficiency. Medplum, with MCP, provides a powerful pathway to explore these possibilities.

Responsible Innovation: Experimental Technology Ahead​

We are a healthcare company first and foremost, and that means prioritizing patient safety and data security above all else. Most major LLM vendors do not yet support HIPAA Business Associate Agreements (BAAs), and the landscape around production-grade, HIPAA-compliant AI integrations is still evolving rapidly.

Therefore, it is absolutely critical to understand that Medplum's current MCP implementation is a preview release and is experimental technology.

• Do not use this for protected health information (PHI).
• Use only with synthetic, de-identified, or test data.
• No guarantees are made about uptime or suitability for production workloads.
• Proceed with caution and exercise your best judgment.

Our commitment is to be a forward-leaning "high tech" player in healthcare. This means we make investments to get out in front of new technology trends, enabling you to explore future possibilities today. We're excited to offer this capability, but always with emphasis on responsible and ethical use.

Join Medplum's MCP Beta Today​

The current MCP implementation is available to all Medplum users. We encourage you to dive in and experiment!

Existing Medplum users: Jump into your Medplum project and start exploring our MCP capabilities. Look for the "beta" label and the associated disclaimers.

New to Medplum? The first step is to sign up for an account and go through our standard "Getting Started" flow. Once you're up and running, you'll have access to our MCP features.

We believe this initial support for MCP will spark incredible innovation. We can't wait to see what you build!

How to Set it Up​

• Open Claude and log in, you'll need to be on a paid plan to add integrations
• Navigate to the settings page in the bottom left and then click on "Add Integration" on the Organization Integrations page.
• In the diaglog that opens input "Medplum" for the Integration Name, and "https://api.medplum.com/mcp/stream" for the Integration URL and click Add
• Back on the Organization integrations page, you'll see a button to Connect, click on it and it will redirect you to Medplum where you should authenticate
• You'll be redirected to the Integrations page where
• Create a New Chat in Claude and paste the following

can you please confirm you have access to the "fhir-request" MCP tool?

LLMs can cometimes cache sessions, so if you find yourself unable to connect you can disconnect and reconnect in a new chat in order to get back to a good state.

Feedback welcome at support@medplum.com or join our Discord

Thanks to a strong security posture, including regular third-party pen tests, genuine vulnerability reports are rare. However, like any online business, we see a steady stream of security inquiries. These tend to fall into two distinct camps: the valuable, good-faith reports from legitimate researchers... and the noise.

The "noise" is what security expert Troy Hunt perfectly named "Beg Bounties." These are the low-effort, templated emails fishing for a payout for a non-issue.

We decided early on to be direct, transparent, and respectful of everyone's time—ours and the researcher's. So, when someone emails us about a potential vulnerability, here's the kind of response they can expect from us:

Subject: Re: Inquiry Regarding Security Issue

Thanks for your interest in the security of the Medplum platform. We take all potential vulnerabilities seriously.

Our process is to first receive the full details of the potential issue, including steps to reproduce it. Once received, our team will validate the report.

To set clear expectations, we absolutely offer fair compensation for novel, verifiable vulnerabilities with a demonstrable security impact.

We do not, however, provide compensation for common out-of-scope reports, including:

• Suboptimal HTTP security header configurations
• Missing best practices on DNS records (SPF/DKIM/DMARC)
• Scanner output without a proven, practical exploit

This approach allows us to focus on genuine, impactful security research. We look forward to receiving the details of your finding.

Best regards,

The Medplum Team

That's it. It's a simple, firm, and fair template. Here's why it works for us:

1. It puts process first. The conversation about money is on hold until we see a real vulnerability.
2. It filters out the noise. It clearly states what we don't pay for, saving everyone a lot of back-and-forth.
3. It encourages real research. It confirms we do pay for legitimate findings with a real-world impact.

This email is our day-to-day tactic, but it's based on our official strategy, which is documented for anyone to see in our Responsible Disclosure Policy on GitHub. It goes into more detail and includes a Safe Harbor clause to assure good-faith researchers they're protected.

The bottom line is simple: We take security seriously, and we take real security researchers seriously. If you have a legitimate, high-impact vulnerability, we genuinely want to hear from you and will be happy to compensate you for your work.

EHRs: The Foundation and Its Boundaries​

EHRs were pivotal in digitizing patient records and streamlining billing. While foundational, many traditional EHRs present limitations in flexible data sharing, adaptability to varied workflows, and support for modern, rapid development cycles. These boundaries are less a critique of their original design and more an acknowledgment of today's expanded healthcare needs.

UDHPs: Expanding the Horizon​

Unified Digital Health Platforms (UDHPs) represent a move to address these limitations. Unlike monolithic EHRs, a UDHP is envisioned as an ecosystem platform fostering interoperability (often via FHIR®), enabling seamless data flow, and providing robust APIs to spur innovation. The interest in UDHPs centers on their potential to create more connected and responsive healthcare experiences by extending capabilities rather than solely storing records.

Realizing the UDHP Vision: Implementation Matters​

The UDHP concept is promising, but its practical realization depends heavily on the implementation approach. Healthcare's inherent diversity—unique organizational workflows, existing tech stacks, and specific patient needs—means a one-size-fits-all UDHP solution often falls short. The "last-mile" challenge of tailoring the platform to these specific needs is critical.

Medplum's Approach: A Developer-First UDHP Foundation​

At Medplum, we believe a developer-first strategy is essential to effectively harness the UDHP model. Our open-source, FHIR-native platform functions as a "headless EHR," providing the core, secure, and compliant infrastructure. This empowers healthcare organizations and innovators to:

• Build with Precision: Develop applications and workflows tailored to their exact requirements.
• Ensure Data Interoperability: Leverage a FHIR-native data store for standardized and accessible information.
• Automate Effectively: Utilize an extensible framework to create custom automation for clinical and administrative processes.

This approach allows organizations to construct their own UDHP-powered solutions on a flexible foundation, ensuring the platform meets their unique needs and addresses integration challenges effectively.

Building a Connected Future​

The shift towards a UDHP model signifies a positive evolution, emphasizing greater connectivity and flexibility. Medplum is committed to supporting this evolution by providing robust, open tools for the builders who are shaping the future of healthcare technology.

TL;DR Forking feels like freedom; more often it is technical debt in disguise. Before you spin up a divergent codebase, walk through the checklist below and consider proven collaboration patterns that deliver 90 % of the control with 10 % of the cost.

The Temptation to Fork​

Every open‑source maintainer eventually receives the same message: “We love your project, but we need feature X immediately—so we’re considering a fork.” The allure is clear:

• Unblocked roadmap No need to wait for upstream review cycles.
• Rapid experimentation Freedom to rewrite modules, tweak schemas, or cut corners.
• Perceived leverage A fork can feel like an insurance policy against future licence or direction changes.

Yet the freedom is rarely free.

What a Fork Really Means​

At Medplum, we have seen partners launch forks with convinced leadership support—only to merge back within months after realising the hidden cost curve.

When a Fork Is Justified​

There are legitimate scenarios:

1. Project abandonment No active maintainers, unmerged PRs, stale security issues.
2. License retreat Upstream changes from permissive to restrictive terms.
3. Irreconcilable governance clash The core team rejects a domain‑specific regulatory requirement that your business legally must meet.

If none of the above apply, pause before you type git clone.

Alternatives That Usually Win​

Contribute Upstream​

Large features land faster than you think when paired with a well‑structured proposal, passing tests, and open communication. For context, Medplum has merged >1 000 community PRs, including entire modules such as the upcoming Kafka subscription channel.

Maintain a Thin Extension Layer​

Build your business logic in a backend‑for‑frontend (BFF) or dedicated microservice, leaving the core FHIR server untouched. You keep velocity while upstream remains a drop‑in upgrade.

Sponsor Roadmap Work​

If a feature is strategic but non‑differentiating—think sharding, compliance, or new spec versions—directly funding upstream development is often faster and cheaper than hiring a fork team.

Case Study: Four Years of Medplum Evolution​

• 250+ releases Semantic‑versioned, backwards‑compatible upgrades every two weeks.
• New capabilities Subscriptions, bots, Azure/GCP execution targets, sharding, DoseSpot integration.
• Regulatory alignment HIPAA, US Core, USCDI updates shipped continuously.

A downstream fork would have needed to replicate every one of these changes—or risk falling behind on performance and compliance.

A 30‑Minute Fork Decision Checklist​

1. List blockers Write down the features or constraints driving the fork discussion.
2. Search the tracker Is someone already working on your need? Comment and collaborate.
3. Draft a proposal PR Even a work‑in‑progress branch sparks upstream feedback.
4. Estimate ownership cost How many engineer‑months per year will merges, CI, and CVE triage consume? Multiply by three.
5. Schedule an architecture chat Most maintainers (Medplum included) are happy to roadmap with partners—often unlocking an upstream path.

Conclusion & Next Steps​

Forking should be the exception, not the default. The open‑source ecosystem thrives when contributors pull in the same direction, sharing maintenance and innovation. Before you commit to life on a fork:

• Open an issue outlining your blockers.
• Gauge maintainer responsiveness on a small PR.
• Consider a thin extension or sponsored roadmap work.

Our door is always open. If you’re weighing a fork—or just need architectural advice—reach out in the Medplum Slack, book office hours, or send us a pull request.

Move fast—but merge faster.

Modern Runtime Dependencies​

Medplum v5 makes several important dependency upgrades to provide the best performance, security, and developer experience:

Node.js​

• Dropping support for Node 20 (which reaches end-of-life in April 2026)
• Supporting Node 22 and 24 - taking advantage of the latest JavaScript runtime features and performance improvements
• Node 22 brings significant performance improvements with its Maglev compiler, enhanced WebSocket support, and better error handling for async middleware

PostgreSQL​

• Dropping support for Postgres 13 (which reaches end-of-life in November 2025)
• Adding support for Postgres 18 (releasing September 2025)
• Postgres 18 introduces major performance improvements with its new asynchronous I/O subsystem, enabling up to 2-3x faster operations for sequential scans and other common operations

Redis​

• Dropping support for Redis 6 (reaching end-of-life)
• Continuing support for all active Redis 7 versions
• Redis 7 includes Redis Functions, ACLv2, command introspection, and Sharded Pub/Sub, significantly enhancing flexibility and performance

Frontend Modernization​

React and UI Components​

• Dropping support for React 18
• Requiring React 19 only - we've already migrated internally and are prepared to support one React version moving forward
• Upgrading from Mantine 7 to Mantine 8 for our front-end components
  • Mantine 8 features improved date handling, new CSS-based organization, and enhanced typescript support

Web Framework and Code Quality​

• Upgrading Express from v4 to v5
  • Express 5 brings stronger Node 18+ compatibility, automatic error handling for async/await functions, and improved security
• Replacing ESLint and Prettier with Biome
  • This unified toolchain offers faster performance, simpler configuration, and reduced dependency overhead
  • Note: Our @medplum/eslint-config package will be deprecated as part of this transition

Planning Your Migration​

We recommend self-hosted customers begin preparation for these changes, particularly:

1. Database planning: Schedule Postgres upgrades and Redis updates with your DevOps team. These infrastructure components require careful migration planning.

2. Application codebase: Review any custom apps built on Medplum to ensure compatibility with newer React, Node, and Express versions.

3. Development environment: Consider upgrading local development environments to test with newer versions ahead of the v5 release.

The Benefits of Upgrading​

While upgrades may require some adjustment, Medplum v5 delivers significant advantages:

• Performance: Benefit from substantial performance improvements across the entire stack
• Security: Access the latest security features and mitigations in all dependencies
• Developer experience: Enjoy better tooling, faster build times, and modern language features
• Future-proofing: Set your healthcare solutions on a stable foundation for years to come

Timeline​

• May 2025: Blog post and initial announcements
• September 2025: Medplum v5 beta release
• October 2025: General availability release

We're committed to making this transition as smooth as possible. Our team will provide detailed migration guides, support resources, and early access testing opportunities as we approach the release date.

Stay Connected​

For questions, concerns, or feedback about the upcoming v5 release, please join the conversation on Discord or submit issues on GitHub.

By embracing these modern technologies, Medplum continues its mission to accelerate healthcare innovation through powerful, interoperable, and developer-friendly tools.

In this post, we'll focus on some key features of an MSO application using Medplum: multi-tenancy, access control, patient consent management, and project-scoped users. The application also supports FHIR, C-CDA and HL7v2 interfacing making it well suited to interface with record-keeping solutions across multiple practices.

If you haven't checked out the MSO Demo App yet, you can view the code here or watch our demo video below. The demo app is an example implementation for how to build the enrollment workflows and user management console for clinicians and patients across different clinics of an MSO provider network.

Understanding the MSO Architectural Needs​

At its core, an MSO usually needs to handle the following requirements:

• Multiple clinics (tenants) sharing the same platform
• Enrollment workflows that allow Practitioners and Patients to be added and removed from one or more clinics
• Customizable access control which Users have access to which resources. This can built with varying levels of sophistication depending on how restrictive the MSO wants to be.
• Provider directory to group and display clinicians from across the MSO.

Core Implementation​

Tenant Management with Organizations​

To achieve multi-tenancy with Medplum while allowing for some level of coordination between tenants, the recommended pattern is to represent each healthcare clinic as an Organization resource, all within a single Medplum Project.

const clinic = await medplum.createResource<Organization>({
  resourceType: 'Organization',
  name: 'Kings Landing Health Center',
  active: true,
});

Access Control​

Organizationally Contained Access Restrictions​

The most basic MSO access control model is to restrict access to resources that share a common Organization assignment.

Imposing these restrictions on Practitioner users is done via Medplum's AccessPolicies, which are applied to each Practitioner user's ProjectMembership.

Enrollment of a Practitioner into an Organization is done by adding a Organization reference to the Practitioner ProjectMembership's access field. Here is an example for a Practitioner enrolled in one Organization:

{
 "resourceType": "ProjectMembership",
 //...
 "access": [
   {
     "parameter": [
       {
         "name": "organization",
         "valueReference": {
           "reference": "Organization/0195b4a4-0ed7-71ed-80cf-c6fff1e31152",
           "display": "Kings Landing Health Center"
         }
       }
     ],
     "policy": {
       "reference": "AccessPolicy/0195b4a3-374e-75cf-a6f0-0bcee7c754c5"
     }
   }
 ]
}

Enrollment of a Patient into an Organization uses Compartments, which provide a way to tag Patient resources with the Organization references that it belongs to. So for example, a Patient enrolled in two Organizations might look like this:

{
 "resourceType": "Patient",
 //...
 "meta": {
   "project": "019571c0-035b-72fe-a5fa-75d13a09589c",
   "compartment": [
     {
       "reference": "Organization/019571c0-035b-72fe-a5fa-75d13a09589c",
       "display": "King's Landing Center for Medicine"
     },
     {
       "reference": "Organization/0195b4a3-e637-77e2-ab0c-7ec36b68932d",
       "display": "Winterfell Pediatrics Center"
     },
   ]
 }
}

Because of the Patient's compartment definition, which is essentially a way to link related resource types to the Patient resource, we can set the compartment array on the Patient resource and have that same compartment propogate to all the other resources related to the Patient. These are resources like Appointments, Observations, and DiagnosticReports that should all inherit the same access restrictions. This is done using the Patient $set-accounts FHIR operation.

For example, say you want to enroll Patient/123 into two Organizations, Organization/789 and Organization/456. You can do this by making the following request:

const response = await medplum.post('/fhir/R4/Patient/123/$set-accounts', {
  resourceType: 'Parameters',
  parameter: [
    {
      name: 'accounts',
      valueReference: {
        reference: 'Organization/789',
      },
    },
    {
      name: 'accounts',
      valueReference: {
        reference: 'Organization/456',
      },
    },
    {
      name: 'propagate',
      valueBoolean: true,
    },
  ],
});

Then, the AccessPolicy can be configured to restrict access to all of the resources based on the Organization references in each resource's compartment. Here is what the Practitioner AccessPolicy might look like:

{
 "resourceType": "AccessPolicy",
 "name": "Managed Service Organization Access Policy",
 "compartment": {
   "reference": "%organization"
 },
 "resource": [
   {
     "resourceType": "Patient",
     "criteria": "Patient?_compartment=%organization"
   },
   {
     "resourceType": "Observation",
     "criteria": "Observation?_compartment=%organization"
   },
   {
     "resourceType": "DiagnosticReport",
     "criteria": "DiagnosticReport?_compartment=%organization"
   },
   {
     "resourceType": "Encounter",
     "criteria": "Encounter?_compartment=%organization"
   },
   {
     "resourceType": "Communication",
     "criteria": "Communication?_compartment=%organization"
   },
   //...
 ]
}

Additional Access Control: Patient Consent​

What if we want to do everything discussed above but also restrict any access until the Patient has given consent?

To do this, we can create a universal Consent resource with its status set to active that can also be added to the Patient's compartment and extended to all resources related to the Patient using the $set-accounts operation. Then to revoke Patient consent, you can simply remove the Consent resource from the Patient's compartment.

Then, your access policy will look like this:

{
  "resourceType": "AccessPolicy",
  "name": "Managed Service Organization Access Policy with Patient Consent",
  "compartment": {
    "reference": "%organization"
  },
  "resource": [
    {
      "resourceType": "Patient",
      "criteria": "Patient?_compartment=%organization&_compartment=Consent/<your-universal-consent-id>"
    },
    {
      "resourceType": "Observation",
      "criteria": "Observation?_compartment=%organization&_compartment=Consent/<your-universal-consent-id>"
    },
    {
      "resourceType": "DiagnosticReport",
      "criteria": "DiagnosticReport?_compartment=%organization&_compartment=Consent/<your-universal-consent-id>"
    },
    {
      "resourceType": "Encounter",
      "criteria": "Encounter?_compartment=%organization&_compartment=Consent/<your-universal-consent-id>"
    },
    {
      "resourceType": "Communication",
      "criteria": "Communication?_compartment=%organization&_compartment=Consent/<your-universal-consent-id>"
    },
    //...
  ]
}

Additional Access Control: Assigning Practitioner Access to Specific Patients​

If allowing Practitioners to access all Patients enrolled in a shared Organization is not restrictive enough, you can also configure the AccessPolicy to only allow access to specifically assigned Patients. This can be done using a similar pattern to the Organizational access by not just adding Organization references to the Patient's compartment, but also adding Practitioner references to the Patient's compartment that represent the Practitioners that are allowed to access the Patient. Again, this is done using the $set-accounts FHIR operation.

For example, say you want to give Practitioner/456 in Organization/789 access to Patient/123. You can do this by making the following request:

const response = await medplum.post('/fhir/R4/Patient/123/$set-accounts', {
  resourceType: 'Parameters',
  parameter: [
    {
      name: 'accounts',
      valueReference: {
        reference: 'Organization/456',
      },
    },
    {
      name: 'accounts',
      valueReference: {
        reference: 'Practitioner/789',
      },
    },
    {
      name: 'propagate',
      valueBoolean: true,
    },
  ],
});

along with this AccessPolicy:

{
 "resourceType": "AccessPolicy",
 "name": "Managed Service Organization Access Policy with Patient Consent",
 "compartment": {
   "reference": "%organization"
 },
 "resource": [
   {
     "resourceType": "Patient",
     "criteria": "Patient?_compartment=%organization&_compartment=%profile"
   },
   {
     "resourceType": "Observation",
     "criteria": "Observation?_compartment=%organization&_compartment=%profile"
   },
   {
     "resourceType": "DiagnosticReport",
     "criteria": "DiagnosticReport?_compartment=%organization&_compartment=%profile"
   },
   {
     "resourceType": "Encounter",
     "criteria": "Encounter?_compartment=%organization&_compartment=%profile"
   },
   {
     "resourceType": "Communication",
     "criteria": "Communication?_compartment=%organization&_compartment=%profile"
   },
   //...
 ]
}

User Management Strategy​

Project vs Server Scoped Users​

When building an MSO, it is recommended to follow the best practices for project-scoped and server-scoped users:

• Project-scoped users: Ideal for clinicians and patients who primarily interact with a single production project
• Server-scoped users: Best for administrators and developers who need access across multiple projects

As you can see in the MSO Demo App, we use project-scoped users for clinicians that are actually enrolled across different Organizations and server-scoped users for the administrators and developers who are provisioning clinician and patient access with the different enrollment operations.

For reference, here is the code that the MSO Demo App uses to invite clinicians as project-scoped users.

MSO Demo Links​

• MSO Demo App Video
• MSO Demo App Code

Andrei Zudin is a healthcare interoperability expert and advisor to the Medplum community. He is the former CTO and co-founder of Health Gorilla.

A Technical Guide to TEFCA Integration for Software Developers and Health IT Professionals (Download as PDF)

Purpose​

This white paper aims to provide a technical guide for software developers and healthcare IT professionals seeking to integrate their systems with the Trusted Exchange Framework and Common Agreement (TEFCA). It delves into the technical aspects of TEFCA, including the various participation models, QHIN connectivity, data exchange methods, and security considerations. It also explores the incentives for TEFCA participation and how Medplum can help organizations achieve TEFCA compliance and leverage its benefits.

Background​

The healthcare industry has long struggled with fragmented data, leading to inefficiencies, errors, and suboptimal patient care. TEFCA represents a step towards addressing these challenges by establishing a nationwide framework for secure and interoperable health information exchange¹. By participating in TEFCA, healthcare organizations can improve care coordination, reduce costs, and enhance patient outcomes².

Understanding the TEFCA Framework​

TEFCA, enacted through the 21st Century Cures Act, aims to establish a universal policy and technical floor for nationwide interoperability³. It seeks to simplify connectivity for organizations to securely exchange information to improve patient care, enhance the welfare of populations, and generate healthcare value³. TEFCA operates as a "network of networks," connecting various Health Information Networks (HINs) across the country¹. These HINs, upon meeting specific criteria and undergoing a vetting process, are designated as Qualified Health Information Networks (QHINs)⁴.

TEFCA Goals​

TEFCA has three primary goals:

1. Establish a universal policy and technical framework for nationwide interoperability.
2. Simplify connectivity for organizations to securely exchange information.
3. Empower individuals (patients) to gather their own health information³.

Trusted Exchange Framework (TEF) Principles​

The Trusted Exchange Framework (TEF) outlines seven foundational principles for trust policies and practices to facilitate data sharing among HINs:

1. Standardization: Prioritize the use of federally recognized and industry-acknowledged technical standards, policies, best practices, and procedures for a cohesive and efficient exchange ecosystem⁵.
2. Openness and Transparency: QHINs should operate transparently, promoting stakeholder trust and fostering a collaborative environment⁵.
3. Cooperation and Non-discrimination: QHINs should cooperate with each other and not discriminate against other HINs or participants⁵.
4. Privacy: QHINs should prioritize the privacy of individuals' health information and comply with applicable privacy laws and regulations⁵.
5. Security and Safety: QHINs should ensure the security and safety of health information exchange, protecting it from unauthorized access and disclosure⁵.
6. Access: QHINs should facilitate and promote a clear understanding of how information has been used or disclosed while adhering to civil rights obligations on accessibility⁵.
7. Equity: QHINs should consider the diverse impacts of interoperability on different populations and throughout the entire lifecycle of the activity, ensuring an inclusive approach⁵.

These principles guide the development and implementation of TEFCA, fostering a trustworthy and reliable health information exchange ecosystem.

TEFCA Architecture​

TEFCA operates as a "network of networks," connecting various Health Information Networks (HINs) across the country¹. These HINs, upon meeting specific criteria and undergoing a rigorous vetting process, are designated as Qualified Health Information Networks (QHINs)⁴. QHINs serve as facilitators of nationwide interoperability within the TEFCA framework, adhering to a common set of rules and technical specifications¹.

Participants, such as healthcare providers, health systems, payers, connect to a QHIN to engage in TEFCA exchange⁶. Subparticipants, often members of a Participant's organization, can also connect to a QHIN through a Participant⁶. This layered structure creates an interconnected network where data can flow seamlessly between different organizations and systems.

The following table illustrates the different ways an organization can participate in TEFCA:

Qualified Health Information Networks (QHINs)​

QHINs are the foundation of the TEFCA framework, responsible for ensuring secure and reliable health information exchange across the network¹. They play a crucial role in upholding the principles of TEFCA and ensuring compliance with the Common Agreement.

To become a QHIN, an organization must meet stringent requirements, including:

• Ownership Requirements: Being a U.S. entity with no foreign control that could pose a national security risk⁷.
• Exchange Requirements: Demonstrating the capability to exchange Electronic Health Information (EHI) with multiple unaffiliated organizations, supporting all required exchange purposes, and adhering to non-discrimination policies⁷.
• Designated Network Services Requirements: Maintaining a robust and secure network infrastructure, establishing data governance policies, and ensuring compliance with privacy and security standards⁸.

QHIN Onboarding

The QHIN onboarding process involves several steps to ensure the organization's readiness for participation in TEFCA exchange. This includes:

• Application and Review: Submitting a comprehensive application with supporting documentation and undergoing a thorough review by the Recognized Coordinating Entity (RCE)⁷.
• Testing: Conducting tests to ensure the QHIN's network can connect to those of other QHINs⁷.
• Production Environment Integration: Successfully integrating the QHIN's network into the TEFCA production environment and demonstrating the ability to exchange data with other QHINs⁷.

This rigorous onboarding process ensures that QHINs meet the technical and operational requirements for secure and reliable health information exchange within the TEFCA framework.

As of March 2025, eight organizations have been designated as QHINs:

Data Exchange Methods​

TEFCA supports both document-based (CDA) and FHIR-based exchange methods to accommodate the diverse needs of healthcare organizations.

Document-Based Exchange

The initial iteration of TEFCA focuses on document-based exchange, leveraging existing standards and infrastructure⁹. This involves the exchange of HL7 CDA documents, which are widely used in healthcare for sharing clinical information⁹. TEFCA leverages Integrating the Healthcare Enterprise (IHE) profiles, such as Cross-Community Patient Discovery (XCPD) and Cross-Community Access (XCA), to facilitate the secure retrieval of these documents⁵.

FHIR-Based Exchange

While the first iteration of TEFCA focuses on document-based exchange and supports facilitated FHIR exchange, FHIR is not mandatory at this time. Nevertheless a large number of Participants and Sub-participants voluntarily use FHIR as it addresses their needs best. Examples of such use cases included but not limited to Individual Access Services using SMART-on-FHIR and Electronic Case Reporting. More use cases and exchange purposes are on the roadmap for future development⁹. The TEFCA FHIR roadmap outlines a phased approach for incorporating FHIR into TEFCA, with the goal of enabling more granular and standardized data exchange⁵. This will allow developers to leverage FHIR APIs for accessing and exchanging data, promoting interoperability and innovation in healthcare applications.

Patient Matching in TEFCA​

Patient matching is a critical aspect of TEFCA, ensuring that the correct patient data is accessed and exchanged⁵. Accurate patient matching is essential for preventing errors, improving care coordination, and ensuring the integrity of health information exchange.

TEFCA acknowledges the challenges of patient matching and plans to work with QHINs to create future patient-matching guidelines⁵. This collaborative approach will help improve patient matching accuracy and consistency across the TEFCA network.

Key Considerations for QHIN Connectivity​

Connecting to a QHIN is a crucial step for organizations seeking to participate in TEFCA exchange. Here are some key considerations:

• Technical Requirements: Organizations must ensure their systems meet the technical specifications specific to the QHIN of their choice. Organizations can join several QHINs if necessary. Depending on the selected QHIN connectivity specifications may include supporting IHE profiles, FHIR IGs, security standards, patient matching methods, and provenance tracking⁶.
• Data Governance and Compliance: Organizations must establish data governance policies and procedures that align with TEFCA requirements and flow down agreements. This includes addressing data quality control, data storage, and legal considerations related to privacy and security¹⁰.
• Operational Considerations: Organizations should consider operational factors such as network traffic, potential data quality issues, and the dispute resolution process when connecting to a QHIN⁷.
• Choosing a QHIN: Organizations should carefully evaluate different QHINs based on their technical capabilities, network reach, governance model, and participation costs⁶.

Medplum & TEFCA​

Becoming a TEFCA compatible FHIR responding node is part of the Medplum roadmap and we hope to connect with organizations that are interested in this functionality.

Today, Medplum is a healthcare platform that can help organizations achieve TEFCA compliance and leverage its benefits¹¹. It offers a range of capabilities that align with TEFCA requirements, including:

• Integration Engine: Medplum's integration engine supports various healthcare data exchange standards, including FHIR, HL7, and CCD-A¹². This allows organizations to connect their existing systems to QHINs and participate in TEFCA exchange.
• FHIR Support: Medplum is FHIR-native, providing a FHIR datastore and API for storing and accessing healthcare data¹³. This ensures compliance with TEFCA's future direction towards FHIR-based exchange.
• Security Features: Medplum prioritizes security and compliance, offering HIPAA compliance, SOC2 certification, and robust security controls¹⁴. This helps organizations meet TEFCA's security requirements and protect patient data.

The following are specific features that relate to TEFCA that are on the Medplum roadmap.

Addressing the Gaps​

Medplum is committed to supporting TEFCA and has a roadmap for addressing any potential gaps in its capabilities¹⁵. This includes plans for enhancing FHIR-based exchange functionalities, expanding its integration engine to support emerging TEFCA use cases, and continuously improving its security and compliance posture.

Medplum's Value Proposition​

Medplum offers a compelling value proposition for organizations looking to participate in TEFCA:

• Open-Source: Medplum's core technology is open source, providing flexibility, transparency, and community-driven innovation¹⁶.
• Comprehensive Feature Set: Medplum offers a wide range of features, including questionnaires, scheduling, communications, care plans, and analytics, enabling organizations to build comprehensive healthcare solutions¹⁶.
• Simplified Compliance: Medplum simplifies compliance with HIPAA and other healthcare regulations, providing built-in audit capabilities and secure authentication¹⁶.

Incentives for TEFCA Participation​

Participating in TEFCA offers several incentives for healthcare organizations:

• Regulatory Requirements: TEFCA aligns with federal regulations and may be required for participation in certain government programs⁶.
• Value-Based Care: TEFCA facilitates data exchange necessary for value-based care models, enabling care coordination and improved patient outcomes⁶.
• Improved Patient Care: TEFCA enables access to a more complete patient record, leading to better clinical decision-making and improved care coordination⁶.
• Enhanced Interoperability: TEFCA promotes interoperability across different healthcare systems, enabling seamless data exchange and reducing administrative burden⁶.
• Public Health Reporting: TEFCA facilitates public health reporting, enabling the electronic submission of case reports and other critical data⁶.
• Competitive Advantage: TEFCA participation can provide a competitive advantage by demonstrating a commitment to interoperability and data exchange⁶.

Data Governance and Compliance​

TEFCA emphasizes data governance and compliance to ensure the responsible and secure exchange of health information. Key considerations include:

• Data Quality Control: QHINs and their participants are responsible for implementing data quality control measures to ensure the accuracy and reliability of exchanged data¹⁷.
• Data Storage: QHINs generally act as pass-throughs for data and do not store it. Participants and Subparticipants become stewards of the data they consume and are responsible for its storage and use in compliance with HIPAA and other applicable laws¹⁷.
• Legal Considerations: Agreements between QHINs, Participants, and Subparticipants address how information will be exchanged and do not alter existing legal authority for accessing or sharing data¹⁷.

Operational Considerations​

When connecting to a QHIN, organizations should consider the following operational aspects:

• Network Traffic: QHINs are designed to handle high volumes of transactions, but organizations should monitor network traffic and potential bottlenecks¹⁷.
• Data Quality Issues: Organizations should have processes in place to address potential data quality issues and escalate concerns to the RCE if necessary¹⁷.
• Dispute Resolution: Organizations should be familiar with the TEFCA dispute resolution process for resolving any issues or disagreements that may arise¹⁷.

The Evolving Landscape and Future of TEFCA​

TEFCA is shaping the future of healthcare interoperability, and its landscape is constantly evolving.

The Role of Epic and Other EHR Vendors​

Epic, a leading EHR vendor, plays a significant role in TEFCA. Epic has developed its own QHIN, Epic Nexus, to facilitate TEFCA participation for its customers¹⁸. As of December 2024, Epic Nexus has connected 625 hospitals to the TEFCA network¹⁸. This demonstrates the commitment of EHR vendors to supporting TEFCA and promoting nationwide interoperability.

The Future of Carequality and CommonWell​

Carequality and CommonWell, two major health information exchange frameworks, are aligning their strategies with TEFCA¹⁹. Carequality is enhancing its framework to bolster trust and plans to converge with TEFCA in the future¹⁹. CommonWell, now a designated QHIN, is actively collaborating with TEFCA to improve data exchange and interoperability²⁰. This convergence of existing frameworks with TEFCA will further strengthen nationwide interoperability and streamline data exchange.

Emerging Use Cases​

TEFCA is enabling new and innovative use cases for health information exchange. Some examples include:

• Electronic Case Reporting: TEFCA facilitates electronic case reporting to public health agencies, enabling the automated transmission of case reports and supporting public health surveillance²¹.
• Public Health Data Exchange: TEFCA enables public health agencies to access and exchange data for various purposes, such as case investigations, syndromic surveillance, and immunization reporting²¹.
• HEDIS Reporting: TEFCA is being explored for HEDIS reporting, potentially streamlining data collection and reducing the burden associated with quality measurement²².

These emerging use cases demonstrate the potential of TEFCA to transform healthcare interoperability and improve various aspects of healthcare delivery and public health.

Benefits of TEFCA for Developers​

TEFCA offers several benefits for software developers:

• Facilitating Innovation: TEFCA provides a standardized framework for data exchange, removing barriers to innovation and enabling the development of new technologies and applications².
• Reducing Administrative Burden: TEFCA streamlines data exchange processes, reducing administrative burden and allowing developers to focus on building and improving healthcare solutions².
• Promoting the Development of New Technologies: TEFCA fosters a collaborative environment for developing new technologies and applications that leverage interoperable health data².

Challenges and Opportunities of TEFCA​

While TEFCA presents a significant opportunity for improving healthcare interoperability, there are also challenges to consider:

• Implementation Complexity: Implementing TEFCA requires careful planning and coordination to ensure compliance with technical specifications, governance policies, and security requirements¹⁰.
• Stakeholder Alignment: Achieving widespread adoption of TEFCA requires alignment and collaboration among various stakeholders, including healthcare providers, payers, health IT vendors, and government agencies¹⁰.

Despite these challenges, TEFCA offers a unique opportunity to create a more connected and interoperable healthcare system, leading to improved patient care, enhanced efficiency, and greater innovation.

Security Considerations​

TEFCA prioritizes security and privacy, requiring QHINs and their participants to implement robust security controls²³. These include:

• HIPAA Compliance: QHINs and participants subject to HIPAA must comply with its privacy and security rules²³.
• Data Encryption: All entities must encrypt individually identifiable information, both in transit and at rest²³.
• Cybersecurity Measures: QHINs must implement cybersecurity measures, including annual technical audits, penetration testing, and incident reporting²³.
• Identity Proofing and Authentication: TEFCA requires strong identity proofing and authentication mechanisms to ensure secure access to health information²³.

These security measures help protect patient data and maintain the integrity and trustworthiness of the TEFCA exchange ecosystem.

Conclusion​

TEFCA represents a significant advancement in healthcare interoperability, establishing a nationwide framework for secure and efficient data exchange. By connecting various health information networks and their participants, TEFCA enables seamless access to patient information, improves care coordination, and promotes innovation in healthcare.

Software developers and healthcare IT professionals play a crucial role in integrating systems with TEFCA. By understanding the technical specifications, governance policies, and security requirements of TEFCA, they can ensure their applications and organizations are TEFCA-compliant and leverage its benefits.

Medplum offers a valuable platform for organizations seeking to participate in TEFCA. Its integration engine, FHIR support, and security features facilitate QHIN connectivity and enable the development of interoperable healthcare solutions.

The evolving landscape of TEFCA, with the participation of major EHR vendors and the alignment of existing HIE frameworks, further strengthens the foundation for nationwide interoperability. Emerging use cases, such as electronic case reporting and public health data exchange, demonstrate the potential of TEFCA to transform healthcare and improve patient outcomes.

We encourage healthcare organizations and developers to embrace TEFCA and contribute to the development of a more connected and interoperable healthcare ecosystem.

Glossary of Terms​

Works cited​

1. TEFCA | HealthIT.gov, accessed February 16, 2025, https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca
2. Understanding TEFCA: Key Changes and Impacts on Healthcare in 2025 and Beyond, accessed February 16, 2025, https://www.productiveedge.com/blog/understanding-tefca-key-changes-and-impacts-on-healthcare-in-2025-and-beyond
3. TEFCA Overview and Perspectives From the Field - ASTHO, accessed February 16, 2025, https://www.astho.org/48f67a/globalassets/pdf/tefca-overview-and-perspectives-slides-april-2024.pdf
4. Qualified Health Information Network | QHIN - MedAllies, accessed February 16, 2025, https://www.medallies.com/qualified-health-information-network-qhin/
5. TEFCA in Healthcare: TEFCA QHIN and Components of TEFC - Kodjin, accessed February 16, 2025, https://kodjin.com/blog/trusted-exchange-framework-and-common-agreement/
6. Trusted Exchange Framework and Common Agreement (TEFCA) Overview - CDC Foundation, accessed February 16, 2025, https://www.cdcfoundation.org/TEFCADataSharingandImplementationCenters-JimJirjis.pdf?inline
7. HTI-2 Final Rule Fact Sheet: TEFCA and QHIN Designations, Governance and Appeal Rights | HIMSS, accessed February 16, 2025, https://gkc.himss.org/resources/hti-2-final-rule-fact-sheet-tefca-and-qhin-designations-governance-and-appeal-rights
8. Standard Operating Procedure (SOP): TEFCA Security Incident Reporting, accessed February 16, 2025, https://rce.sequoiaproject.org/wp-content/uploads/2024/07/SOP-TSI-Reporting-v1-508.pdf
9. Understanding TEFCA and its Role in National Interoperability - Harmony Healthcare IT, accessed February 16, 2025, https://www.harmonyhit.com/understanding-tefca-and-its-role-in-national-interoperability/
10. Decoding Interoperability: TEFCA and National Networks and Frameworks Explained, accessed February 16, 2025, https://gkc.himss.org/news/decoding-interoperability-tefca-and-national-networks-and-frameworks-explained
11. Medplum | Medplum, accessed February 16, 2025, https://www.medplum.com/
12. Integrations and Interoperability Engine - Medplum, accessed February 16, 2025, https://www.medplum.com/products/integration
13. Products | Medplum, accessed February 16, 2025, https://www.medplum.com/products
14. Security | Medplum, accessed February 16, 2025, https://www.medplum.com/security
15. Blog | Medplum, accessed February 16, 2025, https://www.medplum.com/blog
16. Stop building your own EHR - A CTO's introduction to Medplum, accessed February 16, 2025, https://www.vintasoftware.com/blog/building-ehr-introducing-medplum
17. TEFCA Frequently Asked Questions | ASTHO, accessed February 16, 2025, https://www.astho.org/globalassets/pdf/tefca-frequently-asked-questions.pdf
18. Health Systems Using Epic Have Connected 625 Hospitals to the ..., accessed February 16, 2025, https://www.epic.com/epic/post/health-systems-using-epic-have-connected-625-hospitals-to-the-tefca-interoperability-framework-in-one-year/
19. Carequality Announcement About Framework Enhancements, accessed February 16, 2025, https://carequality.org/carequality-announcement-about-framework-enhancements/
20. About CommonWell, accessed February 16, 2025, https://www.commonwellalliance.org/about/
21. www.cdcfoundation.org, accessed February 16, 2025, https://www.cdcfoundation.org/TEFCA-eCR-Query-Hartsell?inline
22. Updated TEFCA SOPs for Health Care Operations and NCQA - NCQA, accessed February 16, 2025, https://www.ncqa.org/blog/updated-tefca-sops-for-health-care-operations/
23. ASTP Final Rule Codifies Requirements for TEFCA-Qualified Health Information Networks, accessed February 16, 2025, https://www.mwe.com/insights/astp-final-rule-codifies-requirements-for-tefca-qualified-health-information-networks/
24. TEFCA Glossary, accessed February 16, 2025, https://rce.sequoiaproject.org/wp-content/uploads/2024/01/Draft-TEFCA-Glossary-508-Compliant.pdf
25. TEFCA Glossary, accessed February 16, 2025, https://rce.sequoiaproject.org/wp-content/uploads/2024/07/TEFCA-Glossary_508-1.pdf

Footnotes​

Modern Healthcare Integration in the Wake of NextGen's Announcement

This week, NextGen Healthcare announced that Mirth Connect, the healthcare integration engine that has been a cornerstone of interoperability for countless organizations, will no longer be available. As long-time healthcare integration engineers ourselves, we recognize this news creates significant uncertainty for the many organizations that rely on Mirth Connect for critical healthcare workflows.

Honoring Mirth's Legacy​

First, we want to acknowledge Mirth Connect's tremendous contribution to healthcare interoperability. For more than a decade, Mirth has enabled healthcare data exchange for organizations of all sizes, from small clinics to large hospital systems. It helped usher in an era of digital healthcare, and many of us at Medplum have deep experience with Mirth throughout our careers.

Moving Forward: Why Consider Medplum​

As healthcare organizations evaluate their options, we believe Medplum offers a modern, future-proof alternative for many Mirth use cases. While we're developing a comprehensive comparison guide (coming soon), we wanted to highlight some key differences that make Medplum worth considering:

Cloud-Native Architecture with Local Protocol Support​

Mirth's on-premise model required maintaining local servers with all business logic and integration channels running on-site. Medplum takes a different approach:

• Medplum Agent: Our lightweight local component converts legacy protocols (HL7, DICOM, ASTM - coming soon!) into secure websockets, eliminating the need for VPNs while maintaining compatibility with local systems.
• Cloud Processing: Complex transformation logic runs in the cloud using modern JavaScript/TypeScript through Medplum Bots, improving maintainability and scalability.

Modern Technology Stack​

One of Mirth's challenges has been its reliance on aging Java versions and custom Rhino JavaScript implementations. Medplum is built on a continuously maintained modern tech stack:

• TypeScript/JavaScript: Industry-standard languages that are widely understood and have robust tooling
• Regular Security Updates: Weekly dependency upgrades and proactive security maintenance
• Compliance Ready: SOC2 Type 2 certified with ONC certifications and HITRUST certification in progress

Open Source​

Like Mirth in its early days, Medplum is committed to open source. Our core platform is Apache 2 licensed, giving you the freedom to use, modify, and deploy as needed without vendor lock-in.

Designed for Today's Healthcare Integration Challenges​

Medplum was built by experienced healthcare engineers who have suffered through the limitations of previous-generation integration engines:

• FHIR-Native: Though we support HL7v2 and other formats, we embrace modern FHIR standards
• Developer Experience: Purpose-built for the way modern healthcare applications are developed
• Scalability: Designed from the ground up for horizontal scaling across cloud environments

Next Steps for Mirth Users​

We understand that migrating from a system as essential as Mirth requires careful planning. In the coming weeks, we'll publish a comprehensive guide for Mirth users considering Medplum, including:

• Detailed feature comparisons
• Migration strategies and patterns
• Technical implementation guidance
• Case studies from organizations who have made similar transitions

In the meantime, we invite you to:

• Join our Discord community where you can connect with our team and other healthcare developers
• Explore our documentation to understand Medplum's capabilities
• Try our sandbox environment to experiment with the platform

We're Here to Help​

As fellow healthcare interoperability enthusiasts, we understand the challenges you're facing. Whether you ultimately choose Medplum or another path forward, we're committed to supporting the healthcare integration community through this transition.

Look for our comprehensive Mirth to Medplum comparison guide in the coming days, and please reach out if we can assist with your evaluation process.

Medplum is an open-source healthcare development platform that provides infrastructure and tools for rapidly building compliant healthcare applications. Learn more at medplum.com.

However, we've identified an issue affecting some Medplum deployments that are configured to automatically pull the :latest Docker tag. With our recent release of Medplum 4.0.0, these deployments may be caught in a failing deployment loop. This post explains why this is happening and how to resolve it.

The Issue​

Medplum 4.0.0 introduces significant improvements that require a data migration step. This migration must be completed while running version 3.3.0 before upgrading to 4.0.0 if your deployment contains data from before version 2.2.0 (released in November 2023).

If your deployment is:

• Using the :latest Docker tag
• Configured to automatically upgrade
• Attempting to jump directly from a pre-3.3.0 version to 4.0.0

Then your deployment is likely failing and retrying in a loop.

How to Fix It​

If you're experiencing this issue, follow these steps to resolve it:

Important Caveat​

The data migration is only necessary for deployments that contain data from before version 2.2.0 (released in November 2023). If your deployment started on version 2.2.0 or later, you can skip the migration step using one of the methods described below.

1. Stop the auto-update process temporarily:

   • Modify your deployment configuration to use a specific version tag (3.3.0) instead of :latest
   • This will break the failing deployment cycle

2. Perform the required upgrade path:

   Pre-3.3.0 → 3.3.0 → Run Data Migration → 4.0.0
   

3. Deploy version 3.3.0 explicitly:

   • Update your infrastructure-as-code (AWS CDK, Terraform, Helm charts, etc.) to use the specific 3.3.0 tag
   • Apply your updated infrastructure configuration to deploy version 3.3.0

4. Run the data migration:

   • Log in to your Medplum admin interface
   • Navigate to the Admin panel
   • Click on the "Data Migration" button
   • Wait for the migration to complete successfully

5. Update to 4.0.0:

   • Once migration is complete, you can safely update to 4.0.0
   • You may resume using :latest if desired, or pin to 4.0.0 for stability

Skipping the Migration (For Deployments Started on 2.2.0 or Later)​

If your deployment started on version 2.2.0 or later (November 2023), you can skip the migration step using one of these methods:

Option 1: Direct Database Update

-- Run this SQL query on your Postgres database
UPDATE "DatabaseMigration" SET "dataVersion"=1;

Option 2: API Command

In version 3.3.0, we also added an API endpoint to set the data version. You can use this endpoint to set the data version to 1.

# Get an auth token
export AUTH_TOKEN=$(npx medplum token)

# Use curl to set the data version
curl -X POST \
  -H "Authorization: Bearer $AUTH_TOKEN" \
  -H "Content-Type: application/json" \
  https://api.medplum.com/admin/super/setdataversion \
  -d '{ "dataVersion": 1 }'

After using either option, you can proceed directly to upgrading to version 4.0.0.

Best Practices for Production Deployments​

This situation highlights some important deployment best practices:

1. Avoid :latest in production: Always pin to specific version tags in production environments
2. Read release notes: Always check release notes before upgrading, especially for major version changes
3. Test upgrades in staging: Validate upgrade procedures in a non-production environment first
4. Implement controlled rollouts: Consider using a controlled rollout strategy for updates

Looking Forward​

We understand this may have caused disruption for some users, and we're taking steps to improve our release process:

• We're exploring ways to make the upgrade path more robust
• We're enhancing our tooling to detect and prevent problematic upgrade paths
• We're improving our documentation around version dependencies

Need Additional Help?​

If you continue to experience issues with your upgrade:

• Join our Discord community for real-time support
• Check our comprehensive upgrade documentation
• Open an issue on our GitHub repository
• Contact us directly at support@medplum.com

We're committed to helping every Medplum user successfully upgrade to version 4.0.0 and benefit from the latest improvements to our platform.