How to Use Medplum as an Integration Layer for Healthcare Systems

In our new article, you’ll learn what it really means to use Medplum as an integration layer, how data flows step by step, and how authentication, authorization, audit logging, and PHI boundaries are enforced centrally.

You’ll also find out what standards are supported and how legacy systems fit into a modern architecture, as well as what risks and operational responsibilities you must plan for before making it your backbone.

Key takeaways

• Medplum for healthcare systems integrations helps reduce point-to-point interface sprawl by giving your ecosystem one governed exchange layer.
• Medplum and healthcare integrations work best when you treat FHIR as the shared contract for storing, validating, and delivering clinical data.
• Centralized authentication, role-based access control, and audit logging make security and compliance easier to enforce consistently.
• Normalizing data once (HL7 v2, FHIR, APIs, or files) lowers the risk of inconsistent mappings across downstream systems.
• This architecture improves long-term maintainability, but it still requires monitoring, clear ownership, and operational maturity.

What Is Medplum as an Integration Layer?

Medplum is an open-source healthcare developer platform built as an open-source, FHIR-native backend for medical applications. It provides the infrastructure to store, validate, and exchange clinical data using the HL7 FHIR standard, so teams can customize how data moves across systems with more transparency and fewer one-off integrations.

Medplum is designed for real-world scale: it facilitates care for over 20 million patients across hundreds of practices and powers over 120 million custom workflow actions. For security and compliance, it comes with HIPAA and SOC 2 compliance out of the box, follows OWASP security guidelines, and is verified by multiple penetration tests. The Medplum team also uses modern, event-driven web technologies (APIs, webhooks, and TypeScript Bots) so systems can exchange data in real time.

With built-in interoperability, it becomes especially useful when you need collaboration across external labs, imaging providers, pharmacies, or insurance systems, including cases where a combination of internal and third-party tools must stay in sync.

What does it mean to use it as an integration layer?

Using Medplum for healthcare systems integration means positioning it as the central data exchange layer between applications. Instead of building multiple point-to-point integrations, systems connect through a shared FHIR-based backend.

Incoming data from different sources is mapped to standardized FHIR resources such as Patient, Observation, or Encounter. Once normalized, that data becomes accessible through consistent APIs and governed access controls. This reduces data inconsistency and limits integration sprawl.

How does it technically connect healthcare systems?

As an integration layer, Medplum exposes RESTful FHIR APIs for structured data exchange. It validates incoming resources against FHIR specifications and maintains version history. It also supports authentication, role-based access control, and audit logging to manage secure access.

Event-driven capabilities, such as webhooks, allow workflows to be triggered when specific clinical or operational events occur. This enables coordination between EHRs, patient-facing healthcare applications, billing platforms, analytics tools, and other services without tightly coupling them.

Why does this matter for architecture and compliance?

• For engineering and architecture teams, this approach simplifies system design. It creates a controlled exchange point where standards enforcement and integration logic are centralized.
• For interoperability engineers, it ensures that data remains aligned with FHIR specifications at the infrastructure level.
• For security and compliance teams, it consolidates access control, logging, and traceability within one governed layer. This supports clearer oversight of how data moves across systems.

In this role, the integration layer becomes foundational infrastructure that supports standardized, secure, and auditable data exchange.

Medplum for the Back-end/Compliance Layer

You can position Medplum as your backend and compliance layer by letting it own core healthcare infrastructure (FHIR storage, identity, access control, audit logging, and integrations) while your application focuses on UI and domain logic.

As Medplum is FHIR-native (R4), clinical and operational data are stored as standard FHIR resources and accessed through a FHIR API. Your app communicates with this API, while non-PHI data can remain in your own database. This is a standard model that reduces custom PHI handling and simplifies governance.

Can it manage authentication and authorization?

Medplum works with OAuth2 and SMART-on-FHIR scopes. Users authenticate through this platform, receive tokens, and access FHIR endpoints based on defined permissions. AccessPolicies enforce fine-grained rules at the data layer, such as limiting patients to their own records or scoping clinicians to specific organizations.

How are audits and integrations handled?

AuditEvent resources support traceability of data access and actions. Event-driven workflows can be implemented using Subscriptions and Bots, making controlled and auditable integrations with external systems possible.

Medplum provides the infrastructure foundation. Your team remains responsible for application-level controls, operational processes, and internal compliance practices. Medplum development services are typically used to configure this backend layer to align with architectural and regulatory requirements.

Why Use an Integration Layer in Healthcare?

Healthcare systems rarely operate in isolation. EHRs, labs, billing platforms, patient apps, analytics tools, and third-party services all need to exchange data. For many healthcare organizations, that quickly creates a web of dependencies that is hard to manage. An integration layer adds structure and control.

Integration sprawl and maintenance complexity

Point-to-point integrations may look manageable at first. One system connects to another, and the work moves on. Over time, each new connection adds more dependencies, custom mappings, and environment-specific logic across different companies and tools.

This creates tight coupling. A small change in one system can break several integrations. Troubleshooting gets harder because there is no single place to observe traffic or enforce standards. Scaling the environment means building and maintaining even more connections.

A centralized integration layer reduces this sprawl. Systems connect once to a common backend, which simplifies onboarding, versioning, and long-term maintenance.

Data normalization and interoperability challenges

Healthcare data often arrives in different formats and with different levels of structure. Even when standards are used, implementations still vary. Without a normalization layer, each downstream system has to interpret and transform incoming data on its own.

This increases the risk of inconsistent mappings and semantic drift. Over time, reporting, analytics, and clinical workflows may rely on slightly different interpretations of the same information.

An integration layer standardizes how medplum data or other clinical data is modeled and accessed. It applies consistent resource structures and validation rules before information reaches consuming systems. The FHIR model becomes a shared contract across applications, including a patient portal.

Security and audit consistency across systems

In point-to-point setups, authentication, authorization, and logging are often implemented differently in each connection. This makes it harder to prove who accessed what data and under which policy, or to trace activity tied to a specific account.

A centralized layer consolidates identity management, access control, and audit logging. Security policies are enforced in one place instead of being repeated across services. Audit trails follow a consistent format, which supports compliance reviews and incident analysis.

From a business perspective, this improves scalability and oversight. From a technical perspective, it creates clearer boundaries, better observability, and stronger long-term maintainability.

What Standards Does Medplum Support?

Healthcare integration depends on well-defined interoperability standards. In real-world projects, these standards must be implemented, validated, and enforced in live data flows. Medplum for integration healthcare systems is typically used to operationalize them in production environments.

FHIR-native APIs and canonical data modeling

As being said, Medplum is FHIR-native (R4). It stores and exposes data as standard FHIR resources such as Patient, Encounter, Observation, and DocumentReference.

FHIR becomes the canonical data model. External systems send data into the platform, where it is validated against FHIR definitions before being stored or shared. Downstream systems access the same standardized structure through RESTful FHIR APIs. This approach reduces custom schemas and ensures that data exchange follows a consistent contract across applications.

HL7 v2 ingestion and transformation

Many healthcare environments still rely on HL7 v2 messaging for labs, admissions, discharges, and transfers. These messages are often event-based and formatted differently from FHIR resources.

Medplum can ingest HL7 v2 messages and transform them into structured FHIR resources. For example, an ADT message can be mapped to Patient and Encounter records. This allows legacy systems to remain operational while newer applications consume normalized FHIR data. The transformation layer bridges older messaging standards with modern API-based architectures.

Event-driven workflows with subscriptions

FHIR includes a Subscription mechanism for event notifications. This headless EHR supports subscription-based workflows, allowing systems to react when specific resource changes occur.

For example, when a new Observation is created, a notification can trigger downstream processing or a webhook to another service. These event-driven patterns support near real-time integrations without polling or custom event frameworks. This keeps workflows aligned with standard resource changes and improves traceability.

Legacy and file-based integration patterns

Not all integrations use APIs or live messaging. Some partners rely on scheduled file exchanges, such as CSV or flat files, delivered over secure channels.

In these cases, files can be processed, validated, and mapped into FHIR resources within the platform. This ensures that even batch-based or legacy inputs are normalized into the same canonical structure used by API-driven systems.

The support of multiple standards and patterns within one backend allows teams to integrate modern and legacy systems without fragmenting their data architecture.

How Does Integration Work Step by Step with Medplum?

From our practice, this is the typical lifecycle of a single integration when Medplum sits between systems and acts as the routing and standardization layer.

1. External system sends data (HL7, FHIR, API call, or file)

An external system produces data, such as an HL7 v2 message from a lab, a FHIR resource from another app, an API payload from an internal service, or a scheduled file export. The payload usually reflects the source system’s structure, not what downstream systems expect.

2. Medplum receives the message via endpoint or bot

Medplum receives the inbound payload through a configured endpoint or an automation entry point. The goal at this stage is controlled ingestion: accept known formats, reject malformed traffic, and capture enough metadata to trace what happened later.

3. Data is parsed and mapped into FHIR resources

The inbound data is parsed and transformed into FHIR resources. For example, an HL7 v2 result message can be mapped into Observation resources linked to the correct Patient and Encounter. This step turns many input formats into one consistent representation.

4. Business logic or validation rules are executed

Validation rules run before data is used downstream. This may include required fields, code set checks, reference integrity, or project-specific rules such as “do not accept results without an ordering provider.” Any transformation or enrichment that must be consistent across systems also happens here.

5. Data is stored or routed to downstream systems

Once validated, the data is stored as FHIR resources so it can be retrieved through a standard API. If the integration requires forwarding, the data can also be routed to other systems in the format they need, using the normalized FHIR representation as the source of truth.

6. Subscriptions trigger real-time workflows or notifications

When key resources are created or updated, subscriptions can fire event-driven workflows. This enables near real-time delivery without polling. For example, a new Observation can trigger a notification to a care coordination app or a webhook to an analytics pipeline.

7. Logs and audit trails are generated

Every step should be traceable. Requests, transformations, and downstream deliveries produce logs that help with debugging and monitoring. Audit trails capture access and system actions to support governance and compliance reviews.

Taken together, Medplum features provide a repeatable integration flow: ingest, normalize to FHIR, validate, store, and deliver. All while keeping execution observable and auditable.

How Do You Secure Medplum Integrations?

When Medplum sits between clinical systems and external services, it becomes part of your security boundary. So, you must design authentication, authorization, PHI handling, and auditability as core architecture decisions.

OAuth/OIDC and SMART-on-FHIR flows

Access to FHIR APIs should be protected using OAuth2 or OIDC flows. Users or systems authenticate, receive scoped access tokens, and use those tokens when calling endpoints. This is invaluable for maintaining consistent access rules across healthcare workflows without slowing down day-to-day operations.

In healthcare ecosystems, SMART-on-FHIR scopes define what data can be accessed and under which context. Whether that’s medications, outcomes, or patient-facing forms, this improves efficiency by ensuring apps request only what they needand helps keep sensitive access aligned with real roles.

Role-based and least-privilege access control

Authentication alone is not sufficient. Authorization rules must restrict access at the resource and, where necessary, field level. That control is what keeps teams at the forefront of building safer healthcare software while still moving fast.

Role-based access control allows you to define who can read, write, or search specific resource types. Least-privilege design means each user or service receives only the minimum access required for its function. Enforcing this centrally at the integration layer reduces policy drift and improves traceability across apps, so teams can explore new features without re-auditing the same rules in five places.

Audit logs and traceability

Every access to protected data should be traceable. Audit logs must record who accessed which resource, what action occurred, and when it happened. This supports compliance reviews, incident response, and forensic analysis, and it also unlocks operational insights when you need to understand how data is being used across systems.

Centralizing audit generation at the integration layer avoids fragmented logging practices across multiple applications and makes investigations more predictable.

PHI protection and data boundaries

Protected health information should be clearly separated from non-PHI services. Encryption in transit and at rest is required, but architectural boundaries are equally important for reducing exposure risk.

The integration layer should define which systems are allowed to send or receive PHI, how data is validated before storage, and how outbound data is filtered based on authorization rules. In practice, these boundaries reduce the risk of inconsistent controls and uncontrolled data exposure across the environment. They support the real workflows that depend on accurate medications, measurable outcomes, and secure data exchange.

What Risks Should You Consider?

Medplum can simplify integration architecture, but it does not remove complexity. Healthcare organizations should assess the main risks early.

HL7 to FHIR mapping is complex

Converting HL7 v2 into clean FHIR resources often requires both technical and clinical context. Different systems use the same fields in different ways, which can create hard-to-catch data quality issues.

The integration layer adds operational burden

Once it becomes a central dependency, failures can affect multiple systems at once. Monitoring, alerting, log review, and ongoing support need to be in place from the start.

Scaling needs planning

As data volume grows, performance depends on decisions around processing models, retries, and bulk data flows. Testing with realistic workloads is important.

Governance stays your responsibility

Even if the platform supports access control and audit logs, teams still need clear policies for permissions, audits, retention, and incident response.

Medplum is a strong fit when you need a FHIR-native system, centralized control, and event-driven integrations. It may be less practical for companies with limited interoperability needs or low operational capacity. The right choice depends on your architecture, team readiness, and long-term ownership model.

Final Thoughts

Using Medplum as an integration layer is more about redefining how healthcare systems connect. Instead of managing a growing web of point-to-point interfaces, you centralize data exchange around a FHIR-native backbone. 

Clinical data is normalized once, secured once, audited once, and then shared through governed APIs and event-driven workflows. An integration layer simplifies structure, but it still requires engineering discipline and long-term accountability.

Looking ahead, several trends make this model increasingly relevant:

• FHIR as a default contract. More vendors are exposing FHIR APIs, and regulators continue to push for standardized access. Canonical FHIR backends will likely become common infrastructure rather than optional architecture.
• Event-driven healthcare systems. Real-time notifications and workflow triggers are replacing batch-heavy integrations.
• Subscription-based models align well with modern care coordination and analytics needs.
• Security centralization. As compliance scrutiny increases, organizations are moving toward centralized access control and audit enforcement instead of distributed policy logic.
• Composable healthcare platforms. Teams want to add or replace applications without rebuilding integration logic each time. A stable integration layer supports this modular approach.

At the same time, not every environment requires a full FHIR-native backbone. Smaller ecosystems with limited interoperability needs or established enterprise integration engines may choose a different path. The right decision depends on scale, regulatory exposure, internal expertise, and long-term ownership capacity.

In many modern architectures, however, treating integration as core infrastructure has become a practical necessity. When implemented with clear governance and operational maturity, Medplum can serve as that structured, standards-based foundation for secure and maintainable healthcare data exchange.