← All projects

health-interop-lab / ENGINEERING CASE

Interoperability is demonstrated end to end.

A public laboratory connecting one clinical workflow across five languages and different contracts.

MY ROLEArchitecture and development
DOCUMENTED STATUSPublic laboratory · synthetic data

The real problem.

Knowing the names of standards does not demonstrate that a message survives a distributed workflow. Interoperability requires agreed semantics, durability acknowledgements, retry handling and observation of the data path.

The architecture decision.

Implement one workflow with idiomatic services: HL7 v2 ingestion in Java, FHIR mapping in Kotlin, a Go gRPC gateway, EDI claims in C# and an Angular console. Contracts between services matter as much as each implementation.

  1. 01HL7 v2 / Java
  2. 02Kafka → FHIR / Kotlin
  3. 03gRPC / Go
  4. 04EDI X12 / C#
Simplified conceptual view of the workflow described in the CV.

The controls that support it.

  • Message acknowledgement after durable event publication.
  • Partial dates preserved without inventing clinical data.
  • Claim deduplication and explicit resource limits.
  • OpenTelemetry observability and privacy controls on trace attributes.

Evidence with context.

5clinical workflow languages
6documented CI workflows
71controls expressed as tests

The repository provides technical evidence of the approach: contracts, implementation, infrastructure and executable controls. The CV describes 34,226 lines of code and six continuous-integration workflows; these are not presented here as live CI status.

Source for figures and scope: the author’s 2026 CV. This is not live telemetry.

The limits matter too.

Example data is synthetic. Controls expressed as code do not replace a SOC 2 report, certification or validation of a hospital deployment. A public laboratory is not the same as a production clinical installation.

BRING THIS APPROACH TO YOUR CONTEXT

Does your system face
a similar problem?