Hey everyone, Alex here. Welcome back to another edition of Coding with Alex on sysseder.com.
If you've been scrolling through Hacker News lately, you probably saw the depressing headline making the rounds: "US healthcare still stupidly expensive, with pathetic outcomes, study finds." As engineers, our instinct when we see a massive, highly expensive system failing to produce quality outputs is simple: This is a broken pipeline. We need to refactor it.
While we can't rewrite national policy with a pull request, there is a massive domain where software engineers, DevOps specialists, and data architects have direct leverage: healthcare data interoperability. The US healthcare system is incredibly expensive largely because of administrative bloat, fragmented data silos, and archaic integration standards. If you've ever had to integrate an EHR (Electronic Health Record) system, you know the pain. It’s a mess of legacy HL7 v2 messages sent over raw TCP sockets, proprietary VPNs, and fax machines (yes, really).
Today, we are going to look at how modern developers can help bridge this gap. We’ll dive into the modern standard saving healthcare development—FHIR (Fast Healthcare Interoperability Resources)—and walk through how to build a modern, secure, and developer-friendly API layer on top of legacy healthcare data.
The Core Problem: HL7 v2 vs. FHIR
Historically, healthcare IT relied on the HL7 v2 standard, which was created in the late 1980s. To give you an idea of what we're dealing with, here is what a typical HL7 v2 message looks like. It is a pipe-delimited, non-self-describing flat file:
MSH|^~\&|EPIC|HOSPITAL|LAB|CLINIC|20231027103000||ORU^R01|MSG00001|P|2.3
PID|1||12345^^^MRN||DOE^JOHN^A||19800101|M|||123 MAIN ST^^ANYTOWN^NY^12345
OBR|1||54321^LIS|||20231027101500|||||||||||||||||F
OBX|1|NM|883-9^ABO Group||A|^|||||FIf you want to parse this, you can't just run JSON.parse(). You need specialized, expensive integration engines like Mirth Connect or Cloverleaf to route, map, and translate these messages. Worse, every hospital implements these segments slightly differently, meaning "standard" integration is a myth.
Enter FHIR (pronounced "fire"). Created by the HL7 organization, FHIR brings healthcare into the 21st century. It represents data as RESTful resources using standard JSON or XML, secured with OAuth 2.0, and queried via standard HTTP methods. Instead of parsing pipe-delimited strings, we can query resources like /Patient, /Observation, or /MedicationRequest.
A Clean FHIR JSON Representation
Here is that same patient and lab result represented as a standard, developer-friendly FHIR Observation resource:
{
"resourceType": "Observation",
"id": "blood-type-example",
"status": "final",
"category": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/observation-category",
"code": "laboratory",
"display": "Laboratory"
}
]
}
],
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "883-9",
"display": "ABO group [Type] in Blood"
}
]
},
"subject": {
"reference": "Patient/12345",
"display": "John A. Doe"
},
"effectiveDateTime": "2023-10-27T10:15:00Z",
"valueCodeableConcept": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "112144000",
"display": "Blood group A"
}
]
}
}As developers, we immediately know what to do with this. We can index it in Elasticsearch, query it via a React frontend, or pass it to a machine learning model for analysis.
Architecting a Modern Healthcare API Gateway
To make real-world healthcare systems interoperable, we often need to build a translation layer that consumes legacy HL7 v2 messages (usually delivered via MLLP - Minimal Lower Layer Protocol over TCP/IP) and exposes them as a modern FHIR API.
Here is a high-level architectural overview of how to build this pipeline in a cloud-native environment:
[Legacy EHR (Epic/Cerner)]
│ (HL7 v2 over MLLP)
▼
[MLLP Receiver (Go/Node.js Service)]
│
▼ (Publish Raw Message JSON)
[Message Queue (RabbitMQ / AWS SQS)]
│
▼ (Consume and Translate)
[Worker Service (Python/TypeScript Mapping Engine)]
│
▼ (Upsert via FHIR API)
[FHIR Server (HAPI FHIR / Azure API for FHIR)] <─── [React/Mobile App (OAuth2)]
Let's write a simple Node.js worker service that takes a raw, simplified incoming message and translates it into a valid FHIR Patient resource. We will use standard JavaScript to handle the parsing logic.
Step-by-Step Translation Example
Imagine we have parsed our incoming HL7 pipe segments into an array of fields. Let's build a clean function to construct our FHIR Patient payload.
/**
* Translates parsed legacy PID (Patient Identification) segment to FHIR Patient Resource
* @param {Object} legacyData - Parsed HL7 PID segment fields
* @returns {Object} FHIR Patient Resource
*/
function translatePidToFHIRPatient(legacyData) {
const { mrn, lastName, firstName, dob, gender, address } = legacyData;
// Map legacy gender codes to FHIR administrative gender codes
const genderMapping = {
'M': 'male',
'F': 'female',
'O': 'other',
'U': 'unknown'
};
const fhirPatient = {
resourceType: "Patient",
id: `pat-${mrn}`,
identifier: [
{
use: "official",
type: {
coding: [
{
system: "http://terminology.hl7.org/CodeSystem/v2-0203",
code: "MR",
display: "Medical Record Number"
}
]
},
system: "http://hospital.org/fhir/mrn",
value: mrn
}
],
name: [
{
use: "official",
family: lastName,
given: [firstName]
}
],
gender: genderMapping[gender] || "unknown",
birthDate: formatDateToFHIR(dob), // Helper to convert YYYYMMDD to YYYY-MM-DD
address: [
{
use: "home",
line: [address.street],
city: address.city,
state: address.state,
postalCode: address.zip
}
]
};
return fhirPatient;
}
function formatDateToFHIR(yyyymmdd) {
if (!yyyymmdd || yyyymmdd.length !== 8) return null;
return `${yyyymmdd.substring(0, 4)}-${yyyymmdd.substring(4, 6)}-${yyyymmdd.substring(6, 8)}`;
}
// Example usage:
const legacyPatientInput = {
mrn: "12345",
lastName: "Doe",
firstName: "John",
dob: "19800101",
gender: "M",
address: {
street: "123 Main St",
city: "Anytown",
state: "NY",
zip: "12345"
}
};
console.log(JSON.stringify(translatePidToFHIRPatient(legacyPatientInput), null, 2));
With this simple mapper, we have transformed a rigid, legacy data format into a standard REST resource that any modern developer on your team can instantly work with.
Key Engineering Challenges in Healthcare Development
Working with healthcare data isn't just about parsing JSON; it comes with unique, highly critical constraints that you don't encounter when building a typical CRUD web app.
1. HIPAA Compliance and Security at Rest/In Transit
If you're handling Protected Health Information (PHI) in the US, you are bound by HIPAA regulations. This means:
- Encryption Everywhere: Standard TLS is a bare minimum. Database volumes (e.g., EBS, RDS) must be encrypted using customer-managed keys (AWS KMS).
- Audit Logging: You must maintain an immutable audit trail of who accessed what record, when, and why. Technologies like AWS CloudTrail, database query logging, and FHIR's built-in
AuditEventresource are essential. - Access Controls: Fine-grained, attribute-based access control (ABAC). A doctor should only see records for active patients in their clinic, not the entire database.
2. Coding Systems and Ontologies
Unlike standard SaaS where you can define your own database schemas, healthcare requires strict adherence to standardized terminologies (ontologies) to ensure semantic interoperability:
- LOINC: Used for identifying laboratory observations (e.g., blood tests).
- SNOMED-CT: Used for clinical findings, diseases, and procedures.
- RxNorm: Used for normalized names for clinical drugs.
When designing your database schemas, always include fields to capture these coding systems alongside your internal database IDs. This ensures that when your data is shared with another hospital or insurance provider, they actually know what "Code 102" means.
How to Get Started (Open Source Resources)
If you're inspired to jump in and start hacking on healthcare problems, you don't need to sign a multi-million dollar contract with an EHR vendor to get sandbox access. The community has built phenomenal open-source tools:
- HAPI FHIR: The gold standard open-source Java library and server implementation of FHIR. Excellent for spinning up local sandbox environments.
- Medplum: A highly modern, developer-friendly headless EHR platform that is open-source and natively built on TypeScript and PostgreSQL. It feels like Stripe but for healthcare data.
- Synthea: An open-source synthetic patient generator. It lets you generate realistic, simulated patient records (including clinical histories, allergies, and prescriptions) in valid FHIR formats so you can test your apps without violating privacy laws.
Conclusion
US healthcare may be broken, expensive, and frustrating—but as developers, we are uniquely positioned to build the bridges that fix the underlying infrastructure. By abandoning legacy integrations and rallying around modern standards like FHIR, APIs, and cloud-native security pipelines, we can make healthcare data safer, faster, and cheaper to manage.
Are you currently working in healthtech or trying to integrate with legacy hospital systems? What are your biggest pain points? Let's discuss in the comments below!
Until next time, keep your systems modular and your APIs clean.