Written and maintained by CASRAI Editorial Board
Last updated
Redox Engine (Redox Healthcare) is a cloud-hosted healthcare Integration Platform-as-a-Service (iPaaS) and managed interoperability network that connects digital health applications, medical device platforms, clinical trial sponsors, and artificial intelligence tools to hospital Electronic Health Records (EHRs) through a single RESTful JSON or HL7 FHIR R4 API. Unlike self-hosted healthcare integration engines—such as the Rhapsody Integration Engine, Qvera Interface Engine (QIE), or Mirth Connect—where a health system’s internal interface analysts manage point-to-point VPNs and write custom channel mapping scripts, Redox operates as a managed cloud translation layer that absorbs site-to-site HL7 v2, C-CDA, and proprietary EHR API variations on behalf of connected applications.
Overview: How Does Redox Simplify Multi-EHR Integration?
When a digital health software vendor, remote patient monitoring (RPM) provider, or clinical research platform integrates across 50 hospital health systems running Epic, Oracle Health (Cerner), MEDITECH, eClinicalWorks, athenaOne, and NextGen, three architectural barriers emerge:
- Transport Heterogeneity: Hospital inpatient modules frequently rely on persistent TCP/IP sockets running Minimal Lower Layer Protocol (MLLP) inside site-to-site IPSec VPNs for real-time
ADT,ORM, andORUevents, while outpatient portals use SOAP/ebXML (IHE XDS.b/XCA) or OAuth 2.0 HL7 FHIR APIs. - Semantic Drift in HL7 v2 (“If You’ve Seen One HL7 Interface, You’ve Seen One HL7 Interface”): Hospital A may store a patient’s primary care provider in
PV1-7, Hospital B inPD1-4, and Hospital C inside a custom localZPDsegment, while using local facility laboratory mnemonic codes rather than standardized LOINC identifiers. - Multi-Network Connectivity Maintenance: Establishing and monitoring dozens of dedicated hardware or cloud VPN tunnels, TLS client certificates, and EHR sandbox registrations consumes months of engineering time per hospital go-live.
Redox (`redox ehr integration` / `redox api`) simplifies multi-EHR integration by decoupling the application developer’s code from each hospital’s wire protocol. Application developers build once against either the Redox Canonical JSON Data Model API or the Redox FHIR R4 API over standard HTTPS webhooks and OAuth 2.0 JWT authentication, while Redox’s cloud network maintains the underlying VPN/MLLP listeners, SOAP gateways, and site-specific mapping tables for thousands of connected healthcare organizations.
How Does Redox Translate Hospital HL7 v2 Feeds Into a Single API?
Under the hood, the Redox Engine executes a four-stage normalization pipeline whenever a hospital EHR broadcasts an HL7 v2 message or responds to a query:
- Edge Ingestion (VPN / MLLP, SFTP, SOAP, or FHIR Client):
- A hospital’s local interface engine (such as Epic Bridges, Cloverleaf, Rhapsody, or Qvera) transmits a pipe-delimited ER7 HL7 v2 message—for example, an
ADT^A01inpatient admission or anORU^R01laboratory result—over a dedicated VPN tunnel to a Redox MLLP listener, which validates message framing and returns an immediate HL7ACK(`MSA|AA`).
- A hospital’s local interface engine (such as Epic Bridges, Cloverleaf, Rhapsody, or Qvera) transmits a pipe-delimited ER7 HL7 v2 message—for example, an
- Parser & Site-Specific Configuration Normalization:
- Redox parses the ER7 segments (`MSH`, `PID`, `PV1`, `OBR`, `OBX`, `DG1`, `IN1`, and local `Z-segments`) and applies the hospital connection’s configuration profile—normalizing date/time formats (`YYYYMMDDHHMMSS` to ISO 8601 `YYYY-MM-DDTHH:mm:ss.sssZ`), mapping local MRN assigning authority codes (`PID-3`), and translating facility table codes into standardized values.
- Mapping to Redox Canonical Data Models or HL7 FHIR R4:
- Depending on the destination subscription, Redox transforms the normalized structure into either:
- Redox JSON Data Models: Event-driven JSON schemas organized by clinical workflow domain—such as
PatientAdmin.Arrival,Results.New,Orders.New,Scheduling.Booked,ClinicalSummary.PatientPush,Media.New, orFinancial.Transaction—with a uniformMetaheader (`DataModel`, `EventType`, `EventDateTime`, `Source`, `Destinations`), or - HL7 FHIR R4 Resources: Standard FHIR R4 JSON resources (`Patient`, `Encounter`, `Observation`, `DiagnosticReport`, `ServiceRequest`, `Appointment`) optionally persisted straight into Google Cloud Healthcare API FHIR stores via Redox’s cloud integration pipeline.
- Redox JSON Data Models: Event-driven JSON schemas organized by clinical workflow domain—such as
- Depending on the destination subscription, Redox transforms the normalized structure into either:
- HTTPS Webhook Delivery or Synchronous Query Routing:
- For event-driven pushes (`ADT`, `ORU`, `SIU`), Redox POSTs the JSON payload over TLS 1.2/1.3 to the subscribing application’s registered webhook URL with retry/queue management. For synchronous requests (e.g., querying a patient schedule or writing back a PDF clinical note via `Media.New` / `DocumentReference`), the application POSTs JSON to `https://api.redoxengine.com/endpoint` (or `/fhir/R4/…`), and Redox translates the request into the target hospital’s native HL7 v2 `MDM^T02`, SOAP, or FHIR write-back format.
Comparison: Redox Engine vs. Rhapsody, Qvera (QIE), Mirth Connect, and Direct FHIR
Health IT architects choose between managed iPaaS networks, traditional enterprise interface engines, and direct SMART on FHIR connections based on organizational role (hospital IT vs. external software vendor) and control requirements:
| Platform / Approach | Architectural Category | Hosting & Operations Model | Supported Standards & Data Models | Best For / Primary Trade-Off |
|---|---|---|---|---|
| Redox Engine (`Redox Healthcare`) | Managed Cloud iPaaS & Reusable EHR Network | Fully managed multi-tenant/cloud SaaS by Redox; customer manages only HTTPS JSON/FHIR endpoints | Canonical Redox JSON Data Models (30+ models) & HL7 FHIR R4 API; translates HL7 v2, C-CDA, X12, DICOM metadata | Best for: Digital health vendors, AI scribes, RPM platforms, and trial sponsors integrating across many hospitals. Limit: Recurring managed-platform subscription cost vs. self-hosted engines. |
| Rhapsody Integration Engine (Lyniate) | Enterprise Healthcare Interface Engine | Self-hosted on-premises or Rhapsody Cloud (AWS); customer or hospital analysts build and own routes | HL7 v2.x, HL7 v3, C-CDA, HL7 FHIR, X12 EDI, DICOM, NCPDP, custom JavaScript/Symposium mappers | Best for: Large hospital systems, HIEs, and public health agencies managing thousands of internal LAN interfaces. Limit: Requires dedicated HL7 interface engineers. |
| Qvera Interface Engine (`QIE`) | Graphical Enterprise Interface Engine | Self-hosted or cloud-deployed; visual 4-node channel designer (Source, Mapping, Routing, Destination) | HL7 v2, HL7 v3/C-CDA, HL7 FHIR R4, X12, XML/JSON, JDBC database connectors; ONC-certified | Best for: Ambulatory EHR vendors, mid-to-large hospitals, and labs wanting full ownership of visual JavaScript channels. Limit: Customer manages VPNs and hospital point-to-point onboarding. |
| Mirth Connect (NextGen Connect / Open Integration Engine) | Open-Source / Commercial Interface Engine | Self-hosted Java server (Docker / VM / Cloud) managed entirely by the engineering team | HL7 v2 (ER7), XML, JSON, DICOM, X12, FHIR (via extensions or custom Rhino JavaScript transformers) | Best for: Informatics labs and engineering teams wanting zero license fees and complete code-level control. Limit: All HIPAA infrastructure, VPNs, and site mappings are self-maintained. |
| Direct EHR FHIR R4 APIs (Epic on FHIR, Oracle, athenaOne) | Direct Standards-Based REST API | Application connects directly to each hospital’s FHIR R4 server via OAuth 2.0 / SMART on FHIR | HL7 FHIR R4 + US Core Implementation Guide (45 CFR § 170.315(g)(10)) | Best for: Read-only USCDI patient/clinician apps and native Epic Showroom apps. Limit: Write-back, scheduling (`SIU`), and real-time `ADT` push events often still require HL7 v2 or vendor-specific APIs. |
When Should Teams Use a Managed Integration Platform Like Redox Versus Direct FHIR Interfaces?
- Choose Direct HL7 FHIR R4 APIs When:
- Your application primarily reads standardized USCDI (United States Core Data for Interoperability) clinical data elements (`Patient`, `Condition`, `MedicationRequest`, `AllergyIntolerance`, `Observation`, `DiagnosticReport`) covered by ONC’s 21st Century Cures Act
45 CFR § 170.315(g)(10)API mandate. - You are deploying an embedded clinician-facing app launched via SMART on FHIR from inside Epic Hyperspace or Oracle Health PowerChart, where the EHR passes the `patient` and `encounter` context directly in the OAuth 2.0 token response.
- Your application primarily reads standardized USCDI (United States Core Data for Interoperability) clinical data elements (`Patient`, `Condition`, `MedicationRequest`, `AllergyIntolerance`, `Observation`, `DiagnosticReport`) covered by ONC’s 21st Century Cures Act
- Choose a Managed Integration Platform Like Redox When:
- Your workflow requires real-time event-driven push triggers—such as immediate notification when an inpatient is admitted (`ADT^A01`), discharged (`ADT^A03`), or has a critical lab result posted (`ORU^R01`)—where most hospitals still broadcast over HL7 v2 MLLP rather than FHIR R4 Subscriptions.
- Your application requires complex bidirectional write-back (such as placing discrete diagnostic orders via `ORM^O01`, modifying appointment schedules via `SIU^S12`/`S14`, or filing discrete flowsheet vitals and MDM notes) across a heterogeneous mix of inpatient and ambulatory EHRs that do not expose uniform FHIR write APIs.
Security, HIPAA Compliance, and Operational Maintenance
Because an integration platform sits directly in the path of electronic Protected Health Information (ePHI), teams evaluating Redox, Rhapsody, or Qvera must verify four governance controls: execution of a HIPAA Business Associate Agreement (BAA); HITRUST CSF and SOC 2 Type II certification of the cloud runtime; configurable payload retention policies (minimizing how long raw HL7 v2 and JSON payloads persist in message-replay queues); and automated alerting for VPN tunnel drops or hospital MLLP queue backlogs.
Frequently Asked Questions
How does Redox simplify multi-EHR integration?
Redox simplifies multi-EHR integration by providing a single cloud-based RESTful API (offering both canonical Redox JSON Data Models and native HL7 FHIR R4 endpoints) while managing the underlying hospital VPN connections, MLLP socket listeners, SOAP gateways, and site-specific HL7 v2 mapping tables on behalf of the connected software application.
How does Redox translate hospital HL7 v2 feeds into a single API?
When a hospital EHR sends a pipe-delimited HL7 v2 message (such as an ADT^A01 admission or ORU^R01 lab result) over MLLP, Redox ingests and acknowledges the message, parses the standard and custom Z-segments, applies site-specific normalization rules to standardize identifiers, timestamps, and code sets, and transforms the payload into a uniform Redox JSON Data Model or HL7 FHIR R4 resource delivered to the application via an HTTPS webhook.
When should teams use a managed integration platform like Redox versus building direct FHIR interfaces?
Teams should build direct HL7 FHIR R4 interfaces when their application primarily reads USCDI clinical data elements or launches inside the EHR via SMART on FHIR under ONC 45 CFR § 170.315(g)(10) rules. Teams should use a managed integration platform like Redox when they need real-time event-driven push feeds (such as HL7 v2 ADT admissions/discharges or ORU results) or bidirectional write-back (discrete orders, scheduling, and billing) across dozens of hospitals whose legacy modules still rely on HL7 v2 MLLP and C-CDA rather than FHIR write APIs.
Sources
- Redox, Inc. Redox Developer Documentation: Canonical Data Models, FHIR R4 API, and Engine Architecture. https://docs.redoxengine.com/
- Rhapsody Health (Lyniate) & Qvera. Enterprise Healthcare Integration Engine Technical Specifications. https://rhapsody.health/ and https://www.qvera.com/
- Health Level Seven International (HL7). HL7 Messaging Standard Version 2.5.1 / 2.8 & HL7 FHIR Release 4 Specification. https://hl7.org/fhir/R4/
