Features​

Provider App: AI-Powered Spaces and Chat​

David Yanez

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

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

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

AWS Lambda Streaming for Bots​

David Yanez

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

WebSocket Subscriptions: Scale and Observability​

Derrick Farris

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

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

Scheduling Enhancements​

Noah Silas

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

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

Revenue Cycle: Claim Submission and Eligibility​

David Yanez

Advancing the Revenue Cycle & Billing roadmap initiative:

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

Pharmacy Components​

Oleg Rocklin

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

Multiple Redis Support​

Matt Long

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

Instance-Level Custom FHIR Operations​

Rahul Agarwal

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

Security and Authentication​

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

Developer Experience​

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

Documentation​

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

Operations and API

Darren Eam

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

Subscriptions

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

Provider and Clinical

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

Infrastructure and Security

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

Blog

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

Bug Fixes​

Clinical Data

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

Scheduling

• Fixed scheduling operations during UTC/local day boundary discrepancies

Server and Authentication

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

Infrastructure

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

Releases​

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

Looking Ahead​

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

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

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

The Basics: Authentication vs. Authorization​

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

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

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

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

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

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

Option A: Email Address​

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

Advantages:

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

Disadvantages:

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

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

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

Advantages:

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

Disadvantages:

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

Recommendation​

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

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

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

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

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

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

Decision 2: Identity Provider Strategy​

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

Option A: Medplum as IDP​

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

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

Option B: External IDP​

A third-party service (Okta, Azure AD, Auth0) manages credentials. Your platform trusts the external IDP to authenticate users.

Best for: Enterprise deployments with existing identity infrastructure. Enables centralized user management - when an employee leaves, disabling their Okta account immediately revokes access to all connected systems.

Option C: Domain-Level Routing​

This advanced approach routes users to different identity providers based on their email domain. When user@hospital-a.com logs in, they're sent to Hospital A's Okta instance. When user@hospital-b.com logs in, they're sent to Hospital B's Azure AD.

Best for: Multi-tenant platforms serving multiple healthcare organizations, each with their own identity infrastructure. Medplum supports domain-level identity providers for this use case.

Decision 3: Token Flow Architecture​

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

What's a Token?​

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

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

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

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

Before Building Custom Infrastructure​

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

Before adding intermediate infrastructure, consider:

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

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

Three-Legged OAuth (Recommended)​

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

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

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

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

Token Exchange (Multi-Service Access)​

Token exchange is useful for multi-service workflows:

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

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

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

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

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

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

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

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

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

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

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

Putting It Together: Recommended Architecture​

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

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

This architecture gives you:

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

Key Questions to Ask​

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

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

Conclusion​

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

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

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

Features​

Provider App: Spaces, Messaging, and Tasks​

David Yanez

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

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

Scheduling: $find and $book Operations​

Noah Silas

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

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

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

System-Level Custom FHIR Operations​

Gonzalo Bellver

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

FHIR Operations and Terminology​

Darren Eam

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

Matt Willer

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

Site Reliability and Infrastructure​

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

Matt Willer

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

Matt Long

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

Noah Silas

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

Security and Access Control​

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

SDK and Developer Experience​

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

AI and MCP​

Advancing our AI roadmap initiative:

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

Documentation​

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

Provider

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

Finn Bergquist

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

Self-Hosting and Operations

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

Medplum Agent

Derrick Farris

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

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

Additional Docs

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

Bug Fixes​

Forms and UI

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

Server and API

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

Agent

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

Infrastructure

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

Releases​

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

Looking Ahead​

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

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

As of December 2025:

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

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

Compliance (H1 2026)​

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

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

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

Enterprise Scale & Infrastructure​

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

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

Scheduling​

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

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

Provider Application​

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

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

Integrations & Plugins​

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

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

Revenue Cycle & Billing​

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

Related Reading: 💰 Billing Overview, 🏦 Payer and Coverage Context, ✅ Eligibility and Benefit Checks, 📄 Afiax Billing Settlement Exports

AI​

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

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

Key Themes for 2026​

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

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

Join the Movement​

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Coding Synonyms​

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

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

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

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

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

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

Scalable Concept Mapping​

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

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

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

$ curl -H "Authorization: Bearer $ACCESS_TOKEN" \
  'https://api.medplum.com/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.

Slideshow: View Presentation

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

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

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

The Core Problem: Coordination and Scarcity​

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

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

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

The Role of Data Standardization (FHIR)​

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

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

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

Architecture: Systems of Action​

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

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

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

The Future: The Distributed EHR​

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

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

Community Q&A Highlights​

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

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

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

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

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

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

Core Platform Modernization​

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

Runtime and Infrastructure​

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

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

New Capabilities​

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

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

Frontend and Developer Tooling​

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

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

Strategic Update: ESM by Default​

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

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

Planning Your Migration (Breaking Changes)​

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

API and SDK Changes​

Infrastructure Changes​

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

The Value of Upgrading​

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

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

Next Steps for Self-Hosted Customers​

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

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

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

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

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
Jan 12, 2026, 4:00 PM - 7:00 PM PT	New Year, New Regs - In Depth on HTI-4 and HTI-5 with Brendan Keeler and Medplum	Medplum, SF	Brendan Keeler, Medplum Team
Jan 15, 2025, 9:00 AM - 2:00 PM PT	Interactive Workshop FHIR+AI for Life Sciences	Medplum, SF	Kerry Weinberg, Reshma Khilnani

Past Events​

When	Topic	Location	Featuring
Dec 4, 2025, 10:00 AM PT	Visualizing Patient Flow: A Blueprint Reference App for Healthcare IT	Zoom
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	Blog Post	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.