EHR integration guide

How to Connect a Medical Device to an EHR

Send device data to Epic, Oracle Health and other EHRs over FHIR R4 or HL7, through your device cloud. This guide covers the architecture, authentication, the FHIR resources involved, the errors teams hit most often, and what actually sets the timeline.

Short answer

Do not connect the device to the EHR directly. Route the data through your device cloud. The cloud matches the patient, maps each measurement to a FHIR resource, authenticates server to server and records every exchange. The integration build can be short. Hospital security review and EHR-side activation usually set the timeline.

Why the device should not talk to the EHR directly

Credentials. EHR server-to-server credentials belong in a controlled backend. They should never sit on devices in the field.
Patient context. The device knows a serial number. The EHR knows a patient and, for most writes, an encounter. Matching the two is a cloud job.
One device, many health systems. Each health system has its own FHIR base URL, token endpoint, client ID and approved scopes. The cloud holds one connection per site.
Audit. Every write to a patient chart needs a record of what was sent, when and how the EHR answered.

Data stored once in the device cloud then serves the EHR, your clinician and patient portals, and your analytics.

Reference architecture: how a write reaches the chart

On BioT, the EHR connection runs as a managed EHR integration module next to your tenant. Each health system is configured as its own endpoint, with its own base URL, authentication type, token URL, client ID and environment. One deployment can serve several health systems at once.

An application, a rule or a schedule creates an EHR command, for example send vitals or upload document.
The platform hands the command to the EHR integration module and marks it in progress.
The module reads the endpoint configuration for the target health system.
It fills the request template for that command with patient, encounter and measurement values.
It resolves the EHR patient ID stored on the BioT patient record, and the encounter where the EHR requires one.
It obtains a short-lived OAuth 2.0 access token, server to server.
It sends the request to the EHR.
It records the request and the EHR response on the command.
It marks the command completed, or failed with a structured error that names the operation, the EHR response code and a readable message.

What flows in each direction

Capability	Direction	FHIR R4 resources
Send vital signs	Device cloud to EHR	Observation
Upload clinical documents: device reports, session summaries, ECG strips	Device cloud to EHR	DocumentReference
Get patient information: demographics, conditions, medications, allergies, lab results	EHR to device cloud	Patient, Condition, MedicationRequest, AllergyIntolerance, DiagnosticReport

Each read command can request any subset of those resources. Two initiation patterns are common. In the event-driven pattern, a measurement arrives and a rule pushes it to the chart. In the on-demand pattern, a clinician or an external system asks for the exchange, either through your application or through the BioT REST API.

Mapping measurements to FHIR

The FHIR R4 vital signs profile requires a status, the category vital-signs, a LOINC code, a patient reference, a time and a numeric value with a UCUM unit, or a reason the value is absent. These are the default mappings:

Measurement	LOINC	UCUM unit
Heart rate	8867-4	/min
Respiratory rate	9279-1	/min
Oxygen saturation (SpO2)	2708-6	%
Body temperature	8310-5	Cel or [degF]
Blood pressure panel	85354-9, with components systolic 8480-6 and diastolic 8462-4	mm[Hg] on each component

The blood pressure panel carries no top-level value. The systolic and diastolic components carry the values. The measurement timestamp maps to effectiveDateTime. Additional measurements and codes are added in configuration.

Agree the mapping with each site early. Many Epic sites file incoming Observations to flowsheet rows. The site's EHR analyst decides which codes land where, so the clinical mapping is a joint decision between your team and the hospital.

Authentication: server to server, with no user in the loop

EHRs authenticate backend integrations with OAuth 2.0 client credentials. The common standard is SMART Backend Services: you register a backend app with the EHR vendor and register a public key, and the integration signs a short-lived JWT assertion each time it requests an access token. No user logs in, and no password is stored on a device.

Register once per EHR vendor. Request only the scopes for the resource types your integration needs.
Activate once per health system. Each health system activates your app and client ID in its own production environment and supplies its production URLs.
Discover, do not hard-code. Read token and FHIR endpoints from the site's SMART configuration document.
Keep tokens short-lived. On BioT, access tokens are kept in memory only, and scopes are set per EHR and limited to the resources the integration uses.

Sending documents to the chart

Your application generates the report, uploads it through the BioT file API and starts an upload command. The EHR integration module builds a DocumentReference, sends it and returns the EHR's document ID.

Document requirements vary by EHR and by site. Confirm these with each health system before go-live:

The content types the site accepts.
Whether an encounter reference is required.
The author reference and document status the site expects.
The document category the site files your reports under.

With Epic, enable both of Epic's DocumentReference APIs, Clinical Notes and Document Information, for your app.

The errors teams hit most often

Symptom	Usual cause	Fix
403 insufficient_scope	Scopes requested in the wrong format, or an API the operation needs is not enabled for the app	Request scopes in the format the EHR expects and enable every API the operation uses
400 Valid encounter required	The patient has no active encounter	File against an encounter. For remote monitoring, confirm the site's workflow, which may use a monitoring order or episode instead.
invalid_client or invalid_grant at the token endpoint	The JWT audience does not match the token URL, clock skew, or a key mismatch	Set the audience to the exact token URL, keep server clocks in sync and check the registered public key
unauthorized_client in production	The health system has not activated the app or approved its scopes	Complete activation with the site's EHR team
422 on a document	A field the site requires is missing, such as author, status or period, or the content type is not accepted	Add the required fields and send a content type the site accepts
401 at the FHIR server after a token was issued	The token was issued for a different tenant or environment than the FHIR base URL	Discover both from the site's SMART configuration document
Risk of filing to the wrong patient	A weak identifier match, a mistyped record number, merged or moved records	Store the EHR patient ID at enrollment, verify identity, and define a process for merges, transfers and withdrawn consent

Because every command stores the request, the response and the status, most of these are diagnosed from the command record without reproducing the call.

What actually sets the timeline

There are two clocks. The first is the build: configuring the endpoint, the templates and the code mapping, then testing against the EHR vendor's test environment. On BioT this is configuration of an existing module, and it is usually the short part.

The second clock is the health system. Expect these steps at each site:

The hospital qualifies your solution as an accepted store for patient data.
You answer its IT security and privacy questionnaire and share your certification evidence.
You agree the protocol, FHIR R4 or HL7, and how the connection is secured.
You agree the clinical mapping with the site's EHR analyst.
The site activates your app in its production environment and supplies production URLs.
You test with the site, then go live with a small pilot group.

IT security, privacy, clinical informatics, the EHR team and a clinical champion are usually involved. A practical sequence is a proof in the vendor's test environment first, then one pilot site, then each new site added as a new endpoint in configuration.

What BioT provides and what you own

BioT provides

The EHR integration module and FHIR request templates
One endpoint configuration per health system
Server-to-server OAuth 2.0 with short-lived tokens
A record of every request, response and status
Attribute-based access control over who can trigger EHR operations
PHI kept out of logs, and TLS 1.2 or higher in transit
App registration, credential and template setup during onboarding
Hosting in the US, EU and Asia, with a BAA and DPA
A platform layer certified and audited for HITRUST r2, SOC 2 Type II, ISO 27001 and ISO 27799

You own

The clinical use case and which data goes into the chart
The code mapping agreed with each site
The patient enrollment and identity verification workflow
The relationship and approvals with each health system
Assessing, with your regulatory advisors, whether writing data to the chart changes your device's regulatory scope

EHR interface: standards-based, FHIR R4, HL7 or open APIs. Epic and Oracle Health are documented named integrations. BioT customers have integrated with Athena Health and PointClickCare, among others. Other EHRs that support FHIR R4 or HL7 are added during onboarding.

Questions device makers ask

Do we need our own FHIR engineering team?

You need someone who owns the clinical mapping decisions with each hospital. The integration module, the templates and the setup come from BioT.

Can one deployment connect to several health systems?

Yes. Each health system is a separate endpoint with its own URLs, credentials and environment, and they can run on different EHRs.

Do we need a listing in Epic's app marketplace?

No. Epic does not require a marketplace listing for a health system to connect your product. Each health system activates your app and client ID in its own environment. A listing can still support your commercial strategy.

How do we avoid writing data to the wrong patient?

Store the EHR patient ID on the patient record at enrollment, verify identity during enrollment, and define what happens when records merge, a patient moves to another health system or consent is withdrawn.

Is every exchange recorded?

Yes. Each command keeps the request, the EHR response and the status, and PHI is kept out of the logs.

Where is the data hosted?

On AWS in the US, EU or Asia, either in your own AWS account or in a BioT-managed environment dedicated to your production, with a BAA and a DPA in both models.