Health IT spent two decades on a problem that sounded technical and was mostly political: getting one organisation's clinical data into another's system. That problem is substantially solved. There is a modern, resource-oriented, JSON-over-REST standard that vendors actually implement, and national exchange frameworks that give organisations a legal and technical basis for querying each other.
Having watched enterprise platform work in a regulated life-sciences environment, what interests me is what surfaced after the pipes connected. Because the remaining problems are the ones you find in any integration programme once transport stops being the excuse.
What FHIR actually gave us
FHIR's design choice was to model clinical concepts as resources — Patient, Observation, Encounter, MedicationRequest — with references between them, accessed over ordinary REST, with a real extension mechanism. That sounds obvious now. Compared to the document-and-segment formats it replaced, it meant a developer without healthcare-specific tooling could be productive in an afternoon.
Two things built on top made it usable in practice:
SMART on FHIR — an OAuth2 profile letting an application launch inside the clinician's existing workflow, with the patient context handed over. This is the important part commercially. An app that requires a clinician to leave their EHR, log into something else and re-find the patient will not be used, no matter how good it is.
CDS Hooks — a way for the EHR to call an external service at a defined moment in the workflow (opening a chart, signing an order) and receive suggestions back. It puts decision support where the decision happens rather than in a report someone reads later.
The combination is what makes third-party clinical software viable, and I would argue it did more for the sector than any individual data standard.
The semantics problem nobody can API their way out of
Here is the part that surprises engineers arriving from other domains.
Two hospitals both send you a Observation resource for a blood test. Both are valid FHIR. Both use a standard code system. And they still are not comparable, because:
- One reports in mg/dL, the other in mmol/L
- One measured on a different assay with a different reference range
- One recorded the specimen collection time, the other the result time
- One's code is more specific than the other's, and rolling up loses information
None of that is a standards failure. It is that clinical meaning depends on context that the record may not carry. Terminology work — the mappings between code systems, and the versioning of those mappings — is the actual substance of clinical data engineering, and it is skilled, ongoing, unglamorous work that budgets consistently underfund.
The lesson that transfers: a shared schema is not a shared model. I have made this mistake on non-clinical platforms too — agreed the message format, declared integration done, and discovered six months later that two teams meant different things by "active customer".
Ambient documentation is the first genuinely popular AI in the clinic
Most clinical AI has struggled with adoption for a consistent reason: it asks a clinician to trust a recommendation and take responsibility for it.
Ambient documentation — recording the visit and drafting the note — inverts that. It removes work rather than adding a decision, the clinician reviews and signs so the accountability boundary is unchanged, and the value is immediate and personal to the person using it. Documentation burden is one of the largest measured contributors to clinician burnout, so removing it is a real benefit rather than an efficiency abstraction.
The engineering constraints are real but tractable: ambient audio in a clinical setting is about as sensitive as data gets, so access controls, retention and de-identification are the design centre. A draft that a clinician signs is a legal record, which means provenance — what audio produced this text, which model version, what did the clinician change — has to be retained.
The pattern generalises. In regulated environments, AI that drafts for human approval has a dramatically shorter path to production than AI that decides. The same logic drives how I design agent pipelines: every phase produces an artefact a human approves, and the approval is recorded next to it.
Software as a medical device, and the pre-approved change
The regulatory question everyone building clinical AI runs into: if your model is a medical device, and you retrain it, have you shipped a new device?
Historically the answer was effectively yes, which meant clinical AI was frozen at approval — you could not improve it without re-clearing it. The mechanism that fixed this is a predetermined change control plan: you describe up front what kinds of modifications you intend to make, how you will validate them, and what performance boundaries you will stay within. Changes inside that envelope do not require new clearance.
This is a genuinely good piece of regulatory design and it maps cleanly onto engineering practice. It is a contract that says: here is my retraining pipeline, here are my acceptance criteria, here is my monitoring. Which is what a mature MLOps setup produces anyway — so the work is documenting and committing to it rather than inventing it.
Remote monitoring's real bottleneck
Remote patient monitoring has clear clinical value and a reimbursement pathway, and the technology is unremarkable — a device, a phone, an API. Having built IoT platforms, none of this is hard.
The bottleneck is who looks at the data. A continuous stream from a thousand patients generates alerts, and someone clinically qualified has to triage them. Programmes fail on staffing models, not telemetry.
Which makes alert precision the whole design problem, and it inverts the usual instinct. A false negative is a missed deterioration. A false positive is a nurse's time, and enough of them means every alert gets ignored — at which point the false negatives arrive anyway. The systems that work invest heavily in reducing noise, personalised baselines rather than population thresholds, and escalation tiers so that not every anomaly reaches a human immediately.
What I would tell a team entering healthcare
Budget for terminology. Not as a task. As a function, with an owner, indefinitely.
Integrate into the workflow or do not bother. Clinicians will not context-switch for you. If it does not launch in-context and write back to the record, it will be used enthusiastically for three weeks.
Treat provenance as a feature. Who generated this, from what, when, which version, who approved it. In regulated domains you will be asked, and retrofitting lineage is the most expensive kind of rework.
Assume the data is messier than the standard implies. Valid FHIR is a low bar. Plan validation, reconciliation and a human review path for the records that fail.
The pipes are connected now. What remains is the part that was always hard: agreeing what the data means, and fitting into the day of somebody who did not ask for new software.