INTEROPX / ARCHITECTURE
What actually happens between the EHR and the record you can trust.
The feature list is on the previous page. This one is for the engineers who have to answer for it in a design review — how messages move, how integrations get onboarded, how events propagate, and where it runs.
API Gateway
Auth · rate-limiting · routing
Translation Engines
HL7 · FHIR · Mapper · Terminology
Event Engine
Subscriptions · webhooks · retries
Data Store
PostgreSQL · RLS · audit tables
Govern & Operate
Audit · Consent · Monitoring · Dashboard
Seven views of one platform
From the architecture diagram to cloud deployment — each section answers a different question an engineering or compliance team will ask before signing off.
Architecture Diagram
Five layers, top to bottom — source systems feed into the gateway, translation engines normalize the data, the event engine routes it, and the data store persists it. Governance runs across all layers.
Layer 1 — External Systems
EHR
Epic, Cerner, others
Lab / LIS
Result feeds
Payer
Eligibility, claims
Pharmacy
e-Rx, dispense
Downstream Apps
Analytics, portals
Layer 2 — API Gateway
API Gateway
Auth · rate-limiting · routing — the single authenticated entry point for every integration
Layer 3 — Translation Engines
HL7 Engine
v2.3–2.8 parse / generate
FHIR Server
R4 / R5 resources
Data Mapper
Canonical model mapping
Terminology Service
ICD-10 · SNOMED · LOINC
Layer 4 — Event Engine
Event Engine
Subscriptions · webhooks · retries — publishes real-time events to all registered downstream subscribers
Layer 5 — Data Store
Multi-Tenant Data Store
PostgreSQL · row-level security — every record isolated per tenant, append-only audit tables
Cross-Cutting — Governance & Operations
Audit Logs
Consent Mgmt
Monitoring
Dashboard
Fig. 1 — every request from an external system passes through all five layers; governance is enforced at each one, not only at the perimeter.
Data Flow
What happens to one message, start to finish — from the moment it leaves a source system to the moment it's a governed record someone can query.
Message Emitted
Source system sends HL7 or FHIR payload to the InteropX endpoint
Gateway Auth
OAuth2 / SMART token validated — unauthenticated requests rejected here
Format Detected
Inbound format identified: HL7 v2, FHIR R4/R5, or X12 EDI
Parsed & Mapped
Segments or resources mapped to the canonical internal model
Terminology Normalized
ICD-10, LOINC, SNOMED CT codes cross-mapped and validated
Persisted (RLS-scoped)
Record written with row-level security — tenant isolation enforced at the DB
Event Emitted
Clinical event published — all registered subscribers notified in real time
Fig. 2 — a consent check is evaluated at step 6 on every subsequent read, not only at ingest.
Integration Flow
How a new source system gets connected — the process an integration engineer actually runs, from first credential to production traffic.
Define Connector
Set the source endpoint, protocol (HL7, FHIR, X12), and credentials in the connector registry.
Configure Auth
Assign an OAuth2 client, API key, or mTLS certificate. Scopes are set per resource type.
Build Mapping
Use the visual canvas to align source fields to the canonical model, field by field.
Validate Test Messages
Run a dry-run against sample data. Every unmapped field and code mismatch is surfaced before go-live.
Go Live
Flip the connector to production. Traffic routes through the same pipeline as every other integration.
Monitor
Dashboard shows throughput, latency, error rate, and message volume from the first request onward.
Fig. 3 — mapping templates are reusable, so the second client of the same vendor onboards in a fraction of the time.
Event Flow
What happens after a clinical event is detected — including the retry path when a subscriber is temporarily unreachable.
Clinical event
e.g. ADT-A01 admit
Event Engine
detects & classifies
Match subscribers
by event type
Delivered
webhook 200 OK
Retry queue
exponential backoff
Logged
to audit
↳ unresolved after max attempts → dead-letter, surfaced in Monitoring
Fig. 4 — delivery outcome (success, retry, or dead-letter) is always logged, so an event is never silently lost.
Components
The building blocks behind the diagrams above — the same capabilities covered on the Interoperability overview, plus the infrastructure components underneath them.
EDGE
API Gateway
Auth, rate limiting, and routing for all inbound and outbound traffic.
ENGINE
HL7 Engine
Segment-level parsing and generation for HL7 v2.3–2.8.
ENGINE
FHIR Server
Native FHIR R4/R5 resource storage and REST API.
ENGINE
Data Mapper
Field-level transformation between source schemas and the canonical model.
ENGINE
Terminology Service
Cross-mapping across ICD-10, SNOMED CT, LOINC, RxNorm, CPT.
ORCHESTRATION
Event Engine
Subscriptions, webhook dispatch, and retry handling.
INFRASTRUCTURE
Message Queue
Durable, ordered queuing between ingest and processing stages.
INFRASTRUCTURE
Multi-Tenant Data Store
PostgreSQL with row-level security, per-tenant isolation, append-only audit tables.
INFRASTRUCTURE
Cache Layer
Reduces repeated terminology lookups and mapping resolution overhead.
GOVERNANCE
Audit Logs
Immutable, query-level logging of every read and write.
GOVERNANCE
Consent Management
Patient-level consent enforced at query time, not batch review.
OPERATIONS
Monitoring & Dashboard
Per-endpoint throughput, latency, error rate, and a unified operational view.
Deployment Options
Health systems don't all buy infrastructure the same way. InteropX is built to run in whichever model your security and compliance posture requires.
FASTEST TO LAUNCH
Multi-Tenant SaaS
Fully managed by Peerbits, shared infrastructure, tenant isolation enforced at the data layer.
- No infrastructure to operate
- Fastest onboarding path
- Best for single-facility and mid-size groups
DEDICATED RESOURCES
Private Cloud (Single-Tenant)
A dedicated VPC per customer, same managed operations, no shared compute or storage.
- Isolated infrastructure, still fully managed
- Meets stricter data-residency requirements
- Fits health systems with existing cloud contracts
MAXIMUM CONTROL
On-Premises
Deployed inside the hospital's own data center, behind existing network and identity controls.
- Data never leaves the facility network
- Fits systems with on-prem-only policy
- Peerbits supports install and upgrades
MIXED ENVIRONMENTS
Hybrid
Core engines on-prem near the EHR, governance and analytics layers in the cloud.
- Keeps latency-sensitive traffic local
- Centralizes reporting and monitoring
- Common for multi-facility health systems
Cloud Architecture
Containerized and cloud-agnostic by design — the same architecture runs on any major provider your organization has already standardized on.
Compute
Containerized services on Kubernetes, horizontally scaled per engine
Data layer
Managed PostgreSQL with row-level security, automated backups, point-in-time recovery
Messaging
Durable message queue between gateway, engines, and event dispatch
Availability
Multi-AZ deployment as standard; multi-region available for DR requirements
Networking
Private VPC, TLS in transit, encryption at rest for all persisted data
Observability
Centralized metrics and logs feeding the Monitoring and Dashboard components
Scaling
Auto-scaling per engine based on message throughput, independent of other components
Supported providers
HIPAA-eligible by default
- AES-256 encryption at rest on all PHI-bearing tables
- TLS 1.3 enforced for all in-transit data
- VPC-isolated compute with no public endpoint exposure
- BAA available for all supported cloud providers
- SOC 2 Type II audit trail ready out of the box
Bring your own EHR, lab feed, or payer connection — see how InteropX would map to it.
A technical walkthrough with our interoperability team, scoped to your actual message formats — not a generic demo environment.
Talk to engineeringSee capabilities →Frequently asked questions
InteropX is built on a five-layer architecture — external systems connect through an API Gateway, messages are parsed and translated by the HL7 and FHIR engines, routed via the Event Engine, persisted in a multi-tenant PostgreSQL data store, and governed by cross-cutting audit, consent, monitoring, and dashboard services.
InteropX supports four deployment models: Multi-Tenant SaaS (fully managed by Peerbits), Private Cloud (dedicated VPC per customer), On-Premises (deployed inside the hospital's own data center), and Hybrid (compute on-prem, governance and analytics in the cloud).
InteropX is cloud-agnostic by design. The same containerized architecture runs on AWS (HIPAA-eligible), Microsoft Azure (Azure Health Data Services), Google Cloud (Healthcare API), or any Kubernetes cluster — on-prem or managed.
A message is emitted by a source system, authenticated at the Gateway, format-detected (HL7/FHIR/X12), parsed and field-mapped by the translation engines, terminology-normalized, persisted with row-level security, and then a clinical event is published to all registered subscribers.
Integration onboarding follows six steps: define the connector (credentials, endpoint, protocol), configure the auth, build the mapping using the visual canvas, validate with a test message, go live with traffic, then monitor via the Dashboard. Mapping templates are reusable — the second client of the same EHR vendor onboards in a fraction of the time.
Have more questions?
Ask our experts
