Medplum and the Rise of FHIR-Native Health App Development

They may create a personalized clinical backend and spend months building data models, permissions, audit trails, and connectors. Alternatively, they might develop around a typical EHR while accepting tighter workflow limits, vendor dependence, and restricted product control.

Medplum provides a third alternative: an open-source healthcare development platform based on HL7 FHIR R4. It includes an FHIR datastore and API, as well as authentication, access controls, workflow automation, developer tools, and reusable application components.

That can remove a large amount of undifferentiated infrastructure work. But it does not remove the hard parts of healthcare product engineering.

The real opportunity is not simply to “use FHIR.” It is to make FHIR the operating model of the application while deliberately solving clinical semantics, security, legacy integration, performance, and governance.

What Is Medplum?

Medplum is a developer platform for building clinical applications, headless EHR products, patient and provider experiences, and healthcare workflow systems.

Its distinguishing architectural feature is that clinical data is stored in the original FHIR R4 format rather than being converted only when another system requires it. FHIR resources include patients, observations, encounters, questionnaires, appointments, treatment plans, and clinical records.

The platform includes an FHIR datastore and API, TypeScript SDK, authentication, access controls, GraphQL, React components, Subscriptions, Bots, and managed or self-hosted deployment.

This makes Medplum more than a standalone FHIR server. It is a healthcare application platform whose backend contract, identity model, and workflow primitives are designed around FHIR.

What Does FHIR-Native Health App Development Mean?

A FHIR-enabled application may exchange data through FHIR while keeping its internal database and business objects in a proprietary format. A FHIR-native application goes further.

FHIR becomes the primary clinical data model and API contract. Product features are designed around resources, references, profiles, terminology bindings, search parameters, and FHIR-aware authorization.

When FHIR exists only at the integration boundary, every external connection may require translation between the internal schema and its FHIR representation. 

Those mappings become another layer of technical debt. With a FHIR-native model, the product can use a shared representation across storage, APIs, integrations, and application logic.

But that does not guarantee an identical interpretation. US Core profiles, implementation guides, extensions, terminology, and local rules still determine what a resource means in a particular workflow.

FHIR-native development reduces avoidable translation. It does not eliminate healthcare data modeling.

Why FHIR-Native Development Is Accelerating in the US

The shift is being driven by more than developer preference.

On January 1, 2026, USCDI Version 3 became the standard for the ONC Health IT Certification Program. CMS-0057-F also requires affected payers to implement or expand FHIR-based Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs, with major API compliance dates beginning in 2027.

SMART App Launch, US Core, Bulk Data Access, and Da Vinci implementation guides are also making standardized application and exchange patterns part of mainstream US healthcare infrastructure.

This changes the product calculation.

A proprietary model may work inside one application. When the product needs to interface with EHRs, payers, labs, pharmacies, patient apps, analytics platforms, or AI services, the cost increases.

FHIR-native design provides a consistent starting point as well as structured, traceable data for automation and AI.

FHIR is evolving from an interoperability feature to a fundamental product engineering decision.

How Medplum Changes Healthcare Product Engineering

Provides a clinical data foundation from day one

Teams are not required to create a new schema for patients, practitioners, encounters, observations, prescriptions, appointments, or care plans. The engineering question changes from:

What database tables should we create?

To: Which FHIR resources and profiles accurately represent this clinical workflow?

However, it still requires clinical and interoperability expertise. A poorly designed FHIR model can be just as difficult to maintain as a poorly designed proprietary schema.

Reduces backend scaffolding

Authentication, resource versioning, access policies, auditability, search, and user identities are foundational healthcare application requirements. 

Building them independently can consume a significant part of an early product roadmap. Medplum provides reusable primitives, allowing teams to focus more on differentiated workflows and user experience.

Enables event-driven clinical workflows

Medplum Subscriptions can respond to changes in FHIR resources. Bots can then run server-side TypeScript logic when events occur or when an API invokes them.

For example, a newly submitted QuestionnaireResponse could trigger a workflow that:

• Validates the submitted answers
• Creates structured clinical resources
• Assigns a task to a care manager
• Sends an alert for a high-risk response
• Updates another connected system

This pattern supports intake, remote monitoring, referrals, care coordination, and integration orchestration.

Supports custom application experiences

Medplum is not a fixed EHR interface.

Teams can build their own web or mobile experiences while using its backend services. Its React component library can accelerate common healthcare interface patterns, while the SDK can be used independently when teams need full design control.

This is particularly valuable for healthcare SaaS companies whose product experience is part of their competitive advantage.

Bridge modern and legacy systems

FHIR-native does not mean FHIR-only. Medplum documents support for FHIR APIs, SMART launches, CDS Hooks, C-CDA, webhooks, and HL7 v2 interfacing through Bots and connectivity tooling.

It can therefore serve as:

• The primary backend for a new healthcare product
• A headless EHR foundation
• An innovation layer beside an enterprise EHR
• A governed clinical data layer
• An interoperability and workflow orchestration platform

Where Medplum Fits Best

Medplum is a strong candidate when a product needs a longitudinal clinical record, custom workflows, standards-based APIs, and substantial control over the user experience. Typical use cases include:

• Virtual care and remote patient monitoring
• Care management and population health
• Patient intake and digital front door products
• Specialty clinical workflow software
• Provider and patient portals
• Headless or custom EHR products
• AI applications requiring structured clinical context
• Innovation platforms that extend existing EHR systems

It is less suitable for organizations expecting a no-code builder or a turnkey enterprise EHR with every clinical, financial, and administrative workflow preconfigured.

Medplum is developer-first.

Teams still require production operations, clinical workflow design, FHIR knowledge, engineering capability, and integration experience.

6 Hard Problems Medplum Does Not Automatically Solve

This is where many FHIR-native projects succeed or fail.

1. FHIR modeling and profile governance

The base FHIR specification is intentionally flexible. Teams must determine which resources, profiles, extensions, identifiers, status values, and code systems represent their workflows. 

Without governance, different engineering teams may model the same concept in incompatible ways. Create a FHIR modeling guide before development expands. It should define:

• Approved resources and profiles
• Identifier conventions
• Required terminology systems
• Extension policies
• Reference patterns
• Validation requirements
• Ownership of model changes

2. Legacy integration and patient identity

Most US healthcare environments continue to rely on HL7 v2, C-CDA, proprietary APIs, files, and vendor-specific procedures. Incoming data still necessitates mapping, validation, deduplication, error management, and reconciliation.

Patient matching remains a safety and governance issue, not just an API call. A FHIR Patient resource does not automatically resolve duplicate records, inconsistent demographics, or conflicting enterprise identifiers.

3. Authorization and multi-tenancy

Medplum Access Policies can restrict resources and individual fields.

The implementing organization must still design the authorization model.

A patient, clinician, care coordinator, billing user, support engineer, and external integration should not all have equal access. Multi-tenant healthcare SaaS packages must also minimize data leaks between customers while allowing for shared services and delegated administration.

Authorization should be tested as a product feature, rather than as a one-time setup exercise.

4. Search, analytics, and performance

FHIR resources are optimized for interoperability and clinical representation, not for every analytical query or application screen. Complex products may need:

• GraphQL for connected resource retrieval
• Denormalized read models
• Caching
• Search-parameter optimization
• Dedicated reporting stores
• Separate analytics pipelines

Reporting and AI workloads should not be allowed to degrade transactional clinical workflows.

5. Compliance and production operations

Medplum documents HIPAA compliance, SOC 2 Type II certification, and ONC certification for its Health IT module. Those credentials can support an implementation. They do not make every application built on Medplum compliant.

The product organization remains responsible for configuration, minimum-necessary access, risk analysis, monitoring, incident response, backups, updates, vendor management, and secure development.

Self-hosting adds further operational responsibility. Medplum’s AWS installation documentation describes production self-hosting as a complex process requiring strong cloud, Node.js, and command-line proficiency.

6. Standards and version alignment

Supporting FHIR does not mean supporting every profile, operation, or version required by a trading partner. Medplum’s documentation identifies FHIR R4 and SMART App Launch 2.0.0 support. 

The current published HL7 SMART App Launch implementation guide is version 2.2.0. That does not automatically create an incompatibility.

It means engineering teams must verify the exact:

• OAuth scopes
• Launch contexts
• Capability statements
• Implementation-guide versions
• Resource profiles
• Search requirements
• Certification test cases

Never assume interoperability from a shared standards label alone.

How to Build Healthcare Apps With Medplum

A reliable implementation starts with the workflow, not the platform.

Step 1: Define the workflow boundary

Document the users, decisions, data sources, workflow states, safety risks, external systems, and regulatory obligations. Do not begin by modeling every possible FHIR resource.

Model the scope required to support the product.

Step 2: Establish the canonical FHIR model

Select the resources, US Core profiles, extensions, terminology bindings, and identifier strategy. 

Create representative FHIR bundles for the most important workflows. Validate them before the frontend and integration teams build against them. This reduces expensive model changes later.

Step 3: Design identity, tenancy, and access together

Define how organizations, locations, practitioners, patients, memberships, and client applications relate. 

Then create an access matrix that states which role can create, read, update, search, or export each category of data. Include service accounts and integration clients in the same review.

Step 4: Create a controlled integration boundary

Data from any external system should be treated as untrustworthy unless confirmed.

Normalize HL7 v2, C-CDA files, webhooks, and vendor APIs within the canonical FHIR framework. Keep source IDs and provenance so that records may be tracked and resolved.

Do not place vendor-specific mapping logic throughout the core application.

Step 5: Govern workflow automation

Use Subscriptions and Bots for event-driven orchestration, but avoid scattering business rules across dozens of triggers. Automation should be:

• Version controlled
• Reviewed through CI/CD
• Idempotent
• Observable
• Retry-safe
• Tested against duplicate and out-of-order events

Clinical automation also needs clear escalation behavior when processing fails.

Step 6: Test conformance and production behavior

Validate resources against the required profiles. Test SMART launch flows, API scopes, access policies, and tenant isolation. Then test realistic search, transaction, integration, and reporting loads.

Conformance without operational reliability is not production readiness.

Medplum Vs Fully Custom Healthcare Backend

The decision is not platform versus flexibility. It is whether engineering capacity should be spent rebuilding healthcare infrastructure or creating the capabilities that differentiate the product.

Build Faster With CapMinds’ FHIR-Native Healthcare Development Services

Medplum gives healthcare organizations a strong FHIR-native foundation, but successful implementation still depends on the right architecture, clinical data model, security controls, integrations, and production strategy. 

CapMinds helps digital health companies, healthcare SaaS vendors, and provider organizations turn Medplum into a secure, scalable, workflow-ready healthcare application platform. Our services include:

• Medplum implementation, configuration, and self-hosted deployment
• FHIR-native healthcare application development
• Custom healthcare software development
• Healthcare API development and SMART on FHIR integration
• Custom EHR and headless EHR development
• HL7 v2, C-CDA, laboratory, pharmacy, payer, and EHR integrations
• FHIR profiling, terminology mapping, validation, and data governance
• Patient identity, multi-tenancy, access control, and audit design
• Workflow automation using Medplum Bots and Subscriptions
• Healthcare data migration, normalization, and reconciliation
• Cloud infrastructure, DevOps, monitoring, backup, and disaster recovery
• HIPAA-aligned security, compliance, testing, and production support
• AI-ready clinical data pipelines, analytics integration, and more

Whether you are launching a new digital health product, modernizing a legacy platform, or extending an enterprise EHR, CapMinds can support the full product lifecycle, from discovery and architecture through development, integration, deployment, optimization, and managed support.

Partner with CapMinds to build a FHIR-native healthcare solution that is clinically reliable, interoperable, scalable, and ready for real-world use across complex care environments.

Get Started With CapMinds

Frequently Asked Questions

Is Medplum an EHR or a FHIR server?

Medplum can function as a FHIR-native application platform and the backend for a headless or custom EHR. It provides data, API, identity, workflow, and development capabilities while product teams determine which clinical and administrative experiences to build.

Can Medplum replace an enterprise EHR?

It can support custom EHR products, but replacing an enterprise EHR requires more than storing FHIR resources. Organizations must evaluate documentation, orders, medication workflows, billing, integrations, migration, downtime, and support. In many enterprises, Medplum may fit better as an innovation or application layer.

Does Medplum make an application HIPAA compliant?

No platform can make an application compliant by itself. Medplum’s controls and compliance program can support a HIPAA-aligned architecture, but the implementing organization remains responsible for configuration, operation, monitoring, risk management, and appropriate use.