Scaling Healthcare Platforms: HIPAA and HL7 FHIR Without the Rewrite

Healthcare platform teams tend to hit the same wall at the same moment. The product works, the first hospital is live, and then the second hospital asks to exchange data with a lab system, a billing clearinghouse and a patient app — and it becomes clear that the data model was designed for one deployment, not for an ecosystem.

Retrofitting interoperability is one of the most expensive things you can do to a healthcare product. This piece covers what to get right first, and one claim to stop making.

Stop saying "HIPAA certified"

Worth clearing up early, because it appears on a great many vendor websites, including — until recently — parts of ours.

There is no such thing as HIPAA certification. The US Department of Health and Human Services does not accredit anyone, and no body issues a HIPAA certificate that HHS recognises. Organisations attest to compliance and are assessed against the Security Rule; vendors can be assessed against frameworks like HITRUST CSF or SOC 2, which are real and verifiable, but those are not HIPAA certification either.

Hospital CIOs know this. A vendor advertising HIPAA certification is telling an experienced buyer that it has not worked seriously in the space. Say what is true instead: which Security Rule safeguards you implement, whether you will sign a Business Associate Agreement, and what independent assessment you have actually undergone.

The Security Rule as an architecture spec

The HIPAA Security Rule organises safeguards into three families. Read as an engineer, it is a reasonably concrete specification.

Technical safeguards

Encryption in transit and at rest is the part everyone implements. The parts that fail audits are subtler: unique user identification that survives shared clinical workstations, automatic logoff calibrated so it does not get worked around, and — most commonly — audit controls.

Audit logging is where healthcare platforms most often fall short, because the requirement is not "log access." It is to record activity in information systems containing protected health information in a way that supports later review. In practice that means: who viewed which patient record, when, from where, under what access justification, in a store the viewer cannot alter. Application logs mixed into general telemetry with a 30-day retention will not satisfy this. A separate append-only PHI access log will.

Administrative and physical safeguards

These are usually treated as someone else's problem, but two have direct engineering consequences. Access management must be role-based and reviewable, which means your permission model needs to be expressible to a non-engineer during an audit — deeply nested per-user overrides are technically fine and audit-hostile. And workstation security in shared clinical environments drives real UI decisions: session behaviour on a ward terminal used by twelve people per shift is a product problem, not just an infrastructure setting.

Why HL7 FHIR changes the integration economics

Historically, clinical data exchange meant point-to-point integrations with bespoke message formats — HL7 v2 pipe-delimited messages with site-specific segment conventions, each pair of systems requiring its own adapter. Integration cost grew roughly with the square of the number of connected systems.

Fast Healthcare Interoperability Resources (FHIR), published by HL7 International, replaces that with a defined set of RESTful resources — Patient, Encounter, Observation, Condition, MedicationRequest, DiagnosticReport and the rest — exchanged over ordinary HTTP with JSON or XML payloads. The resources are versioned, extensible through a defined extension mechanism, and specified precisely enough that two independent implementations can interoperate without a bilateral agreement.

Native resources or a translation layer?

The decision that matters is whether FHIR resources are your data model or whether you map to them at the boundary.

Modelling natively gives you the cleanest interoperability story and eliminates a whole class of mapping bugs, but FHIR resources are shaped for exchange rather than for transactional workloads, and forcing your entire clinical workflow through them creates awkward queries and performance work.

A translation layer over a domain-appropriate internal model is usually the better trade for a platform with substantial clinical workflow. The cost is that mapping is real, ongoing work, and it is where subtle correctness bugs live — a code system silently dropped during mapping produces an observation that looks right and means something different. If you take this path, invest in mapping tests as first-class tests, not as an afterthought.

Terminology is the part that is genuinely hard

Teams consistently underestimate this. FHIR gives you the transport and the structure; it does not resolve the meaning. LOINC for laboratory observations, SNOMED CT for clinical findings, ICD for diagnoses, RxNorm for medications — if your source system uses local codes, someone has to map them, and that mapping is a clinical judgement, not a data-engineering task. Budget for clinical review time. A platform that exchanges structurally valid FHIR carrying unmapped local codes is interoperable in form and useless in substance.

What we would prioritise

If you are building now: get the PHI access log right from the first commit, because reconstructing it later is impossible. Decide the native-versus-translation question explicitly and write down why. Budget clinical time for terminology mapping. And be precise in how you describe your compliance posture — in this market, accuracy is a competitive advantage, because so many competitors are not accurate.