EHR Integration Services: Patient-Facing and Provider-Facing

Table of Contents

Heading

EXCLUSIVE LAUNCH

AI Implementation in Healthcare Masterclass

Start the course

Key Takeaways

EHR integration is two distinct technical problems: patient-facing (the patient authorizes access to their own record) and provider-facing (the system exchanges clinical data with EHR workflows on behalf of clinicians or care teams).
Momentum integrates with any EHR system. The integration approach is determined by what the EHR exposes and your use case, not by a short list of pre-approved vendors.
Patient-facing integrations run on SMART on FHIR with patient-context authorization. Provider-facing integrations use HL7 v2, system-to-system FHIR, or Bulk FHIR depending on the EHR and clinical workflow.
A typical engagement runs 8 to 13 weeks. Every project includes a compliance report, HIPAA audit logging, BAA verification, a full test suite, and 90 days of post-launch support.

Is Your HealthTech Product Built for Success in Digital Health?

Download the Playbook

EHR integration is not one problem. It is two distinct problems that share some infrastructure but diverge significantly in authorization model, data flow, and compliance scope.

The first is patient-facing integration: the patient is the user of your application, and they authorize it to access their own health record. The second is provider-facing integration: the application exchanges clinical data with EHR workflows on behalf of clinicians, care teams, or the health system itself. Conflating these two at the architecture stage is one of the most common causes of EHR integration rewrites.

Momentum has built EHR integrations across more than 30 digital health projects covering both patterns. We work with any EHR system. The integration approach is determined by what the system exposes and what your application needs to do.

Patient-Facing EHR Integrations

Patient-facing integrations are used when your application serves patients directly: telehealth platforms, remote patient monitoring apps, patient engagement tools, chronic disease management applications, and consumer health apps that pull clinical context from a provider's EHR.

The authorization model is patient-context SMART on FHIR. The patient logs in, grants the application access to their record, and the application retrieves data through FHIR R4 resources: Patient, Observation, MedicationRequest, Condition, Appointment, CarePlan, and related resources depending on the clinical domain.

Key technical considerations:

Token management per patient. Each patient's access is governed by their own OAuth token. At scale, this means managing token refresh across a large number of individual authorization grants, not a single system-level credential.
Patient portal API surfaces. Epic's MyChart FHIR API and Cerner's patient-facing APIs have specific sandbox approval processes and profile extensions. AthenaHealth's patient-facing API moves faster through third-party approval. These differences affect timeline more than technical complexity.
Scope negotiation. SMART on FHIR scopes determine which FHIR resource types the application can request. Getting scope configuration right in the initial approval submission avoids delays when you need access to additional resource types later.
Data availability varies by instance. A health system running Epic may have specific FHIR profiles disabled or resource types unavailable on a given instance. We surface those gaps in discovery before they become scope changes mid-project.

Common patient-facing use cases:

Application type	Primary FHIR resources	Notes
Telehealth platform	Patient, Appointment, Condition, MedicationRequest	Often requires bidirectional write (encounter notes back to EHR)
Remote monitoring	Patient, Observation (vitals), DeviceMetric	High-frequency observation writes if monitoring data flows back
Chronic disease management	Condition, MedicationRequest, CarePlan, Goal	Care plan read/write requires specific SMART scopes
Consumer health app	Patient, Observation, Immunization, AllergyIntolerance	Read-only in most cases; simpler authorization scope

Provider-Facing EHR Integrations

Provider-facing integrations are used when the application is part of a clinical workflow. The users are clinicians, care coordinators, administrators, or the EHR system itself. Authorization is system-to-system: a server credential or backend service, not a patient login.

Use cases include clinical decision support tools, care management platforms, referral management systems, EHR-to-EHR data exchange, population health platforms, prior authorization automation, and any application that needs to respond to clinical events such as admissions, discharges, or lab results rather than patient-initiated actions.

Key technical considerations:

HL7 v2 is still dominant in many environments. NextGen, Altera, Veradigm, and a significant portion of community hospital deployments surface clinical events through HL7 v2 feeds, not FHIR APIs. ADT (admission, discharge, transfer), ORU (lab results), and SIU (scheduling) message types cover the majority of provider workflow integration use cases.
Bulk FHIR for population-level access. When you need to pull cohort-level data, FHIR Bulk Data Access (Group/$export) is the right protocol. Not all EHRs support it equally. Epic and Cerner have solid Bulk FHIR implementations; smaller systems may require batch FHIR queries or HL7 v2 batch files instead.
System-to-system authorization. Backend service apps use the SMART Backend Services authorization profile (client credentials flow with asymmetric key authentication). This is simpler than patient-context authorization in terms of token management but requires separate registration and approval with each EHR vendor.
Webhook reliability. Event-driven integrations that subscribe to ADT notifications or FHIR Subscriptions need robust retry logic. EHR systems do not guarantee message delivery, and behavior around subscription management varies significantly between vendors.

Common provider-facing use cases:

Application type	Primary protocols	Notes
Clinical decision support	FHIR R4, CDS Hooks	CDS Hooks cards surface within the EHR clinical workflow
Care management platform	FHIR R4, HL7 v2 ADT	ADT notifications drive care transitions; FHIR for record access
Population health	Bulk FHIR, HL7 v2	Bulk FHIR where available; batch queries or file-based for others
Prior authorization	FHIR R4 (Da Vinci IGs)	Da Vinci implementation guides (PAS, CDex) specify the exchange patterns
EHR-to-EHR exchange	FHIR R4, CCDA	CCDA clinical documents for systems without native FHIR
Referral management	FHIR R4, HL7 v2 SIU	Scheduling messages for appointment coordination

Which EHR Systems We Work With

Momentum integrates with any EHR system. The six systems with the highest US market coverage are Epic, Cerner/Oracle Health, AthenaHealth, NextGen, Veradigm, and Altera Digital Health, but the list of systems we've worked with extends well beyond those. If your target health system or practice group runs an EHR, we can integrate with it.

The integration approach depends on what the system exposes:

What the EHR exposes	Integration approach
FHIR R4 APIs	Native FHIR with per-vendor profile adaptation
HL7 v2 feeds	Message parsing with ADT/ORU/SIU handlers
Proprietary REST API	Custom adapter mapped to your data model
CCDA/CCD documents	Clinical document parsing and normalization
File-based only	SFTP or HL7 batch file processing

Our unified data model abstracts this: your application layer sees a normalized structure regardless of what the underlying EHR exposes. Custom adapters per EHR handle field mapping, value set normalization, and protocol differences. Adding a new EHR system does not require changes to the core application.

For Caily, a caregiving platform, we architected EHR connectivity across seven systems, including Epic and Cerner, laying the groundwork for care recipients to securely access their health data, and shipped the platform on schedule. For InnGen, a medical testing platform, EHR integration work contributed to a 30% reduction in admin overhead and a 20% increase in adoption.

Engagement Process

A typical EHR integration project runs 8 to 13 weeks from discovery to go-live.

Phase	Duration	What happens
Discovery	2 weeks	Backend architecture review, integration surface mapping per EHR, patient-facing vs provider-facing scope confirmation, compliance requirements (HIPAA, BAA, audit logging)
Architecture	1 week	FHIR facade or HL7 adapter design, data normalization schema, per-vendor quirks and known API limitations documented
Implementation	4-8 weeks	OAuth flows, token management, sync logic, error handling, rate limits, HL7 v2 parsing where required
Compliance review	1 week	HIPAA audit logging verification, BAA status check, security scan
Go-live + hypercare	2-4 weeks	Production deployment, monitoring setup, 90-day post-launch support

Implementation time is driven by four variables: number of EHR systems, protocol mix (FHIR vs HL7 v2), integration pattern (patient-facing authorization is more complex than system-to-system), and data sync requirements (near-real-time vs scheduled batch).

Discovery is the phase that prevents the most timeline risk. "Supports FHIR" in vendor documentation does not guarantee that the specific resources and operations you need are available on a given customer's instance. We surface those gaps in week two, before they become scope changes in week six.

Momentum holds ISO 13485 certification. Compliance is scoped in discovery, not added at the end. Clients using our pre-built compliance modules have cut compliance-related development time by up to 60%.

Technical Scope

Authentication and authorization: SMART on FHIR patient-context authorization for patient-facing apps. SMART Backend Services (client credentials with asymmetric keys) for provider-facing system integrations. OAuth 2.0 with per-provider token refresh logic.

Protocol handling: FHIR R4 and STU3 resource operations. HL7 v2 message parsing for ADT, ORU, and SIU message types. CCDA/CCD clinical document processing. Bulk FHIR (Group/$export) for population-level data access.

Reliability: Per-provider rate limit handling. Webhook delivery and retry logic. Sync scheduling with backoff and error recovery.

Data layer: Unified data model with provider-specific adapters for field mapping and value set normalization across ICD-10, SNOMED CT, LOINC, and RxNorm where required.

Compliance: HIPAA audit logging at the integration layer covering read and write events. BAA verification per EHR vendor. Security controls reviewed against HIPAA technical safeguard requirements.

What You Receive at Project Close

Integration documentation. Architecture covering each EHR system, data flows, authentication mechanisms, and provider-specific configuration.

Test suite. Unit tests for transformation logic and adapter behavior. Integration tests against sandbox environments for each connected EHR.

Compliance report. Audit log configuration, BAA status per vendor, and security scan results for your compliance team.

90 days post-launch support. Covers production issues, provider API changes, and performance monitoring. EHR vendors update APIs on their own release cycles. We track changes during hypercare and flag anything that requires action.

Momentum's EHR & FHIR integration service scopes and runs engagements like this.

Frequently Asked Questions

How long does EHR integration take?

A typical EHR integration project with Momentum runs 8 to 13 weeks from discovery to go-live. Discovery and architecture take 3 weeks. Implementation takes 4 to 8 weeks depending on the number of EHR systems, protocol mix (FHIR vs HL7 v2), and whether the integration is patient-facing or provider-facing. Compliance review and go-live add another 3 to 5 weeks. Single-system integrations sit at the shorter end of the range; multi-system deployments with mixed protocols sit at the longer end.

What is the difference between patient-facing and provider-facing EHR integration?

Patient-facing integration connects your app to a patient's health record with the patient's authorization. The patient logs in and grants access through SMART on FHIR. Provider-facing integration connects your app to EHR clinical workflows on behalf of clinicians or care teams, using system-to-system authorization. The two differ in authorization model, data flows, compliance scope, and technical complexity. Telehealth and consumer health apps are typically patient-facing. Clinical decision support, care management, and population health platforms are typically provider-facing.

Which EHR systems does Momentum support?

Momentum integrates with any EHR system. The most common systems we work with are Epic, Cerner/Oracle Health, AthenaHealth, NextGen, Veradigm, and Altera Digital Health, but we've worked with systems beyond those. The integration approach is determined by what the EHR exposes: FHIR R4 APIs, HL7 v2 feeds, proprietary REST APIs, CCDA documents, or file-based exchange. Our unified data model handles the abstraction so your application layer doesn't change when a new EHR system is added.

Do I need a BAA for EHR integration?

Yes. Any EHR integration that involves protected health information (PHI) requires a Business Associate Agreement with the EHR vendor before data exchange begins. Momentum verifies BAA status for each connected EHR as part of the compliance review phase and documents the outcome in the compliance report delivered at project close. If a BAA is not in place with a specific vendor, we identify that during discovery so it doesn't block the project timeline.

What is SMART on FHIR and why does it matter for health apps?

SMART on FHIR is an authorization framework that lets health apps request access to patient data stored in EHR systems in a standardized way. It combines OAuth 2.0 for authorization with FHIR for data exchange. For patient-facing apps, SMART on FHIR is the mechanism through which a patient grants your app access to their record. For provider-facing apps, SMART Backend Services handles system-to-system authorization without a patient login. Most major EHRs support SMART on FHIR, but each vendor has specific implementation details, sandbox approval requirements, and profile deviations that affect integration timelines.

Why does token management differ between patient-facing and provider-facing EHR integrations?

Patient-facing integrations use patient-context SMART on FHIR, where each patient's access is governed by their own OAuth token, so token refresh has to be managed across a large number of individual authorization grants. Provider-facing integrations typically operate under a system-level credential instead.

Do all EHR vendors approve patient-facing API access at the same speed?

No. Epic's MyChart FHIR API and Cerner's patient-facing APIs have specific sandbox approval processes and profile extensions, while AthenaHealth's patient-facing API tends to move faster through third-party approval. These differences affect project timeline more than technical complexity.

Written by Piotr Ratkowski

Head of Growth

Grows Momentum's client portfolio and advises HealthTech teams on product strategy, market positioning, and where AI actually makes a difference. Writes about the trends and decisions shaping digital health.