Years building EHR/EMR platforms — first at HAKEEM, then at AFAQ as founder — taught me that the visible product (the UI, the buttons, the chart view) is maybe 15% of what makes the system actually work inside a hospital. The other 85% is paperwork you can’t see: regulation, audit, interop, and the exact wire format a pharmacy printer expects at 03:00. Every healthcare engineer I’ve ever trained has underestimated the 85% before they shipped, and understood it afterwards.

The iceberg

Picture a junior engineer’s first demo of a “vitals screen.” Heart rate, blood pressure, temperature, a nice graph. Looks great. Ships in a sprint.

Then reality arrives:

  • The vital has to come from six different makes of device over three different protocols (HL7 v2 over TCP, a vendor-specific binary, a FHIR REST API on the newer stuff). Half the devices pre-date FHIR and will never be upgraded.
  • The number the doctor enters manually has to coexist with the device number. Which one is canonical? Answer: it depends on whose shift, which hospital, which device model, and which ward’s protocol doc. You need a provenance field, not a value field.
  • The screen has to survive an audit six years from now. Not “show the same number” — prove who saw what, when, and whether they acknowledged it. That means immutable logs, not overwrites.
  • The same screen cannot leak across tenants. Clinic A’s vitals do not appear to Clinic B’s staff, even though Clinic A and Clinic B share some staff members who float between them. The permission model is a relationship graph, not a role enum.
  • Regulatory standards change. HL7 v2 was the thing in 2010; FHIR is the thing in 2025; whatever the thing is in 2035 has to slot in without rewriting the chart view.

Each of those bullets is a week of work nobody billed for. Most of them also can’t be deferred — they’re contractual, legal, or patient-safety-critical from day one.

The framing that helps

I’ve had better results with junior engineers when I explicitly draw the iceberg at the start of a healthcare project. The visible product is 15%. The visible scope is 15%. The sprint planning is about 15%. The other 85% has to be architected first, because retrofitting it costs double.

Concretely, I front-load these five things on any new healthcare build:

  1. Immutable audit log. Every write to anything patient-adjacent appends, never updates. I don’t care if this is a row-level ledger table, an event stream, or a flat file — but it needs to be there before feature one ships. Retrofitting this is the single most expensive thing I’ve ever had to do on a healthcare codebase.
  2. Provenance, not values. Every field has (value, source, observed_at, confidence). Pretending a field is just a scalar is fine in banking; it’s not fine in a system where two clinicians entered different numbers from two different monitors.
  3. Tenant isolation at the query level. Row-level security in Postgres, or equivalent. Not “the app filters on tenant_id” — because one day the app won’t, and that day is a breach.
  4. An interop layer, not direct integrations. A small service that speaks HL7 v2 + FHIR + whatever vendor binary, and exposes an internal clean shape to the rest of your app. You will add formats. You will never remove them.
  5. A regulatory-review cadence. Not a gate, a cadence. Every quarter, someone whose job it is to care about HIPAA / GDPR / local equivalent looks at what’s shipped and raises concerns. If you don’t have this, you’ll have one giant panic gate six months before launch.

What the CV line hides

On my CV, AFAQ is two lines: “Built EHR/EMR platform for hospitals.” HAKEEM is two lines: “National EHR for public hospitals.”

What those lines don’t say:

  • At AFAQ I wrote the first version of a drug-interaction check in MUMPS-adjacent code because that’s what the pharmacy system wanted as input. The week I shipped it, a clinician thanked me because the previous process was a printed PDF they had to keep at the desk.
  • At HAKEEM I watched a deployment stabilization across multiple hospitals where the blocker wasn’t the code — it was getting six different medical directors to agree on what “admitted” meant in the data model. We shipped the code in weeks. The agreement took months. The agreement was the real deliverable.
  • Both systems still run, somewhere. Code I wrote in 2012 is still routing vitals in a hospital in Jordan. That’s not a humblebrag — it’s a reminder that healthcare systems outlive their designers and their contracts. Plan for that from day one.

The 2026 plot twist

I’ll say the quiet part: AI-assisted engineering is an extraordinary accelerant for the 85%. The paperwork-you-can’t-see is mostly pattern work — audit wiring, provenance transforms, interop adapters, tenant filters. These are the things an LLM is good at generating if you frame them well. The visible-product 15% is where human judgment still matters most, because that’s where clinical workflow meets UI and the wrong choice kills people’s afternoons.

The mistake I see teams make in 2026 is the inverse: they use AI to generate the flashy dashboard and then handwave the audit layer. The correct order is the reverse. Use the AI to bolt in the 85% quickly and correctly; spend your human attention on the 15% that nurses actually touch.

The one thing every healthcare engineer should learn

If I were onboarding a new engineer to a healthcare project tomorrow, I would make them spend their first week reading incident reports from real hospital IT systems. Not HIPAA breach filings (those are lawyers). Actual post-mortems from the hospital IT community — the pharmacy system that printed the wrong dose, the interop adapter that dropped half a percent of lab results, the backup that restored a patient’s record from three years ago and no one noticed for a week.

That one week teaches you why the 85% exists. Every “we don’t need that” shortcut is someone else’s previous Tuesday. Read enough of them and you’ll stop asking to skip the audit log.