Skip to main content

Interop Service — Service Overview

Status: populated Owner: TBD Last updated: 2026-04-18 Companion: Service Template · 03 platform-services · 02 DDD


1. Purpose

The interop-service is the platform's unified interoperability gateway. It consolidates two previously separate modules — fhir-gateway and hl7v2-interop — into a single deployable bounded context that owns all external integration channels: FHIR R4 REST API surface, HL7 v2 MLLP message processing, third-party EMR coexistence adapters, bulk data operations, and terminology gateway routing.

Every clinical service in the platform routes external-facing integrations through here. No other service exposes raw FHIR endpoints to external consumers directly.


2. Bounded Context

AttributeValue
DDD context nameinterop
Source modulesfhir-gateway, hl7v2-interop
Licensing categoryCore platform (always-on); individual add-on adapters may be gated
FHIR profile alignmentUS Core 6.1, IPS, Afghanistan FHIR profiles (AFG-Core)
HL7 v2 message setsADT A01/A03/A04/A08/A40, ORM O01, ORU R01, VXU V04

3. Responsibilities

ResponsibilityDetail
FHIR R4 gatewaySingle /fhir/R4/* entry point; route/proxy to owning service; consolidated CapabilityStatement
FHIR profile enforcementValidate resources against US Core 6.1, IPS, and AFG-Core profiles on write
Bulk data operations$export (Group/Patient/$export) and $import for large dataset exchange
HL7 v2 MLLP listenerAccept ADT/ORM/ORU/VXU messages; parse and persist immutable message log
HL7 v2 → FHIR mappingTranslate v2 messages to canonical FHIR resources; POST to owning service
HL7 v2 outboundSerialize FHIR-triggered domain events back to v2 for external LIS/RIS/ADT feeds
Third-party EMR adapterCoexistence pattern for external EMR platforms sharing patient populations
Connector managementPer-tenant/facility connector registry; auth config; activation/deactivation
OperationOutcome errorsConsistent FHIR error formatting for all FHIR endpoints
Tenant + ABAC enforcementApply tenantId isolation and resource-level ABAC at the FHIR boundary

4. Non-Responsibilities

  • Clinical data storage (stateless routing; no clinical persistence)
  • Clinical domain logic (owned by respective domain services)
  • Patient portal access policies (patient-portal-service)
  • AI orchestration (ai-gateway-service)
  • Terminology data storage (terminology-service)

5. Upstream Dependencies (Consumers of interop-service)

All clinical services use interop-service as the FHIR gateway proxy. Key consumers:

ServiceHow it uses interop-service
laboratory-servicePublishes FHIR Observation, DiagnosticReport, Specimen via /fhir/R4/*
radiology-servicePublishes FHIR ImagingStudy, DiagnosticReport
orders-servicePublishes FHIR ServiceRequest; receives ORM ack from HL7 v2
registration-servicePublishes FHIR Patient, Encounter; receives ADT from HL7 v2
patient-chart-serviceReads FHIR clinical facts (fan-out query)
patient-portal-servicePolicy-filtered FHIR reads
terminology-serviceExposes FHIR terminology operations ($lookup, $expand, $validate-code)

6. External Integrations

IntegrationProtocolDirection
External LIS platformsHL7 v2 ORM/ORU (MLLP)Bidirectional
External ADT sources (HIS, PAS)HL7 v2 ADT (MLLP)Inbound
Immunization registriesHL7 v2 VXU (MLLP)Outbound
National HMISFHIR bulk $exportOutbound
Third-party EMRFHIR R4 REST + AFG-Core profilesBidirectional
Payer / clearinghouseX12 EDI (adapter seam)Outbound

7. Architecture Diagram


8. Key Architectural Decisions

DecisionRationale
Merged fhir-gateway + hl7v2-interopFHIR mapping is inseparable from HL7 v2 translation; single deployment reduces latency
Stateless FHIR routingNo clinical persistence; pure proxy/router; simplifies compliance boundary
Per-service ownership routingEach resource type routes to its owning service; no shared clinical DB
ABAC at FHIR boundarySingle enforcement point for external FHIR access; internal service calls bypass
Immutable HL7 message logNon-repudiation; deduplication; compliance requirement
US Core 6.1 + IPS + AFG-CoreMulti-audience alignment: international interop (IPS) + US tooling (SMART) + local regulation (AFG)

9. Source Reconciliation

ModuleKey contributionsMerge decision
fhir-gatewayFHIR R4 routing, CapabilityStatement, OperationOutcome, ABAC enforcement, bulk opsFHIR gateway sub-domain retained
hl7v2-interopMLLP listener, message log, ADT/ORM/ORU/VXU mapping, connector registryHL7 v2 sub-domain co-located; shares connector config with FHIR gateway

Both sub-domains share a single PostgreSQL schema (interop_connectors, hl7_messages, fhir_routing_rules) and a single NestJS process.