The BioT EHR Integration Module enables bi-directional data exchange between BioT and Electronic Health Record (EHR) systems. BioT supports EHR systems that implement the HL7 FHIR R4 standard, including Epic and Oracle Health (Cerner). Additional FHIR-compatible EHRs can be configured during onboarding.

The module translates data between BioT's data model and FHIR format, handling the mapping in both directions. The field mapping is configured for your environment. BioT sets it up as part of EHR integration onboarding, and new fields or resource types can be added at any time without code changes.

The module runs as a managed AWS Lambda plugin alongside your BioT tenant. It handles EHR authentication, FHIR request and response translation, patient and encounter resolution, and result reporting back to your application.

📘

Note

The EHR Integration Module is an optional add-on and requires setup by BioT. To get started, contact BioT Customer Support at [email protected].

---

Capabilities

The module currently provides the following capabilities.

Send Vital Signs (BioT → EHR)

Sends device-generated vital sign measurements to the patient's record in the EHR as FHIR Observation resources. Requires an active encounter in the EHR.

Default field mapping examples:

Additional vitals, device identifiers, or custom LOINC codes can be added during onboarding or later. The mapping is template-driven and does not require code changes.

Upload Clinical Documents (BioT → EHR)

Uploads clinical reports generated by the BioT-powered application (for example, a vital signs summary PDF or a device session report) to the patient's chart in the EHR as a FHIR DocumentReference resource.

Typical use cases: session summaries, ECG strips, titration reports, remote monitoring summaries, patient-reported outcome reports.

Get Patient Info (EHR → BioT)

Retrieves patient clinical context from the EHR into BioT. The following resource types are provided as examples:

• Patient — demographics (name, date of birth, gender, identifiers)
• Condition — active diagnoses
• MedicationRequest — active medication list
• AllergyIntolerance — documented allergies and intolerances
• DiagnosticReport — laboratory and diagnostic results

The retrieved data is mapped to your BioT data model as part of the integration configuration. You can request any subset of the above per command.

---

How It Works

The BioT-powered application triggers EHR operations through BioT. BioT handles authentication with the EHR, FHIR request and response translation using your configured mapping, patient and encounter resolution, and returning the result to the application. The application-level behavior described below.

Send Vital Signs

The BioT EHR module sends device-generated vital sign measurements to the patient record in the EHR as FHIR Observation resources. BioT handles authentication, FHIR translation using your configured field mapping, patient and encounter resolution, and result reporting.

Upload Clinical Documents

• The application generates a PDF report (for example, vital signs summary for a date range).
• The application uploads the PDF to BioT using the BioT File API.
• The application initiates an Upload Document operation, passing the file reference, patient, document title, and LOINC type.
• BioT converts the file to the EHR-specific format (text for Epic, XHTML for Cerner), resolves the encounter and author, and builds a FHIR DocumentReference.
• BioT writes the DocumentReference to the EHR. On success, the DocumentReference ID is returned to the application so it can display a "Sent to EHR" status.

Get Patient Info

• The application initiates a Get Patient Info operation, specifying which resource types to retrieve (one or more of Patient, Condition, MedicationRequest, AllergyIntolerance, DiagnosticReport).
• BioT resolves the patient's FHIR ID from the BioT patient record and queries the EHR for each requested resource type.
• The EHR returns the requested clinical data.
• BioT translates the FHIR responses to your BioT data model and returns them to the application.

---

Data Model and Field Mapping

The FHIR mapping is configured to match your device data model and EHR setup. Your patient's EHR FHIR Patient ID is stored as a subject_id attribute on the BioT patient record and is used to resolve the correct patient in the EHR.

• Your mapping is tailored to your specific needs and can differ from other deployments.
• New fields, LOINC codes, or resource types can be added without code changes.
• BioT works with you to define and manage the mapping, giving your team full visibility into how your device data is represented in the EHR.
• Request and response templates are stored on the EHR System device as attributes and can be updated at any time.

Multiple EHR Endpoints

A single BioT tenant can connect to multiple EHRs at the same time (for example, Epic for one customer health system and Cerner for another). Each EHR connection is a separate endpoint with its own base URL, authentication type, and credentials. Operations target the relevant endpoint, and BioT routes authentication automatically.

---

Configuration and Flexibility

• Application-driven: your application decides when and for which patient to exchange data.
• Template-driven: FHIR request and response structures are JSON templates with {{expression}} placeholders. No custom FHIR code is required for new fields or resource types.
• Access-based: BioT ABAC controls which users and applications can trigger EHR operations.
• Multi-tenant ready: different customers on the same BioT tenant can connect to different EHR endpoints.

---

Setup

BioT handles the initial integration setup, including EHR app registration, credential configuration, and FHIR request/response template setup. Once onboarded, field mapping configurations can be updated by your team or by BioT support as your requirements evolve.

---

Security

• All connections use TLS 1.2+.
• Authentication is OAuth 2.0 server-to-server. No passwords or API keys travel over the wire.
• Access tokens are short-lived and held in memory only.
• PHI is not written to logs.
• FHIR scopes are defined as part of the EHR configuration and limit access to the specific resource types required for your integration.
• BioT ABAC controls which users and applications can trigger EHR operations.
• All EHR requests and responses are logged for auditability.
• BioT is certified under SOC 2 Type II and HITRUST r2. HIPAA and GDPR compliance is maintained through self-declaration with supporting documentation. FDA 21 CFR Part 11 and MDR alignment is covered through BioT's existing certifications and data handling practices.

---

Observability and Audit

• Every EHR operation persists the FHIR request, response, and status for auditability.
• Operation state (pending, in progress, succeeded, failed) is available via the BioT REST API and admin console.
• Execution logs are available for operational troubleshooting (PHI scrubbed).
• Failed operations include a structured error with the FHIR operation, EHR response code, and human-readable message.

---

Prerequisites and Limits

• Each patient must have a resolvable FHIR Patient ID in the target EHR. This is stored on the BioT patient record as subject_id.
• Send Vital Signs and Upload Clinical Documents require an active encounter for the patient in the EHR. BioT auto-resolves it.
• For production, different EHRs might need different approval processes. For example, Epic requires App Orchard approval and Cerner requires Code Console promotion. BioT supports the customer through this process.

---

Getting Started

Contact your BioT solution engineer or [email protected] to learn more. Production deployment depends on the customer's EHR marketplace approval process, which BioT supports throughout.