Standardised FHIR Pipelines and the Hospital IT Queue

A digital health product rarely loses a year because the clinical logic is unfinished. It loses the year in a queue it does not control: a hospital interface request, an EPR supplier change note, and a safety case that still cannot name the source system. A standardised pipeline does not abolish that queue. It takes the work that is actually yours (structure, acknowledgement, and a contract the device file can point at) off the trust’s internal backlog.

Who owns the calendar

Private vendors, pharma study teams, and contract research organisations all hit the same wall. The protocol or the product is ready. The hospital is not. Internal IT is staffed for outages and EPR upgrades, not for a third party’s extract. A custom API, when it is offered at all, arrives as a project with its own business case, its own test window, and its own place in a release train that was full before you called.

Waiting for that API is not a technical plan. It is a dependency on a department whose success metric is a stable EPR, not your launch date. Teams that treat the dependency as “they will build FHIR for us” discover, late, that the trust meant a flat file on a schedule, or a view that a supplier will not expose without a paid change.

What a pipeline is allowed to change

The useful split is between the medical device software and the pipe that feeds it. IMDRF’s SaMD definition is about software that performs a medical purpose on its own. A feed that normalises messages into a profiled exchange does not, by itself, become that device. It becomes part of the environment the device declares.

That distinction is what people mean by Software as a Medical Device (SaMD) data decoupling. The device keeps its intended purpose, its evidence, and its change control. The site-specific mess (local codes, extra segments, a PAS that predates the profile) lives in a configurable map. You still test the interface. You do not reopen the device’s clinical evaluation every time a trust spells a ward code differently.

MHRA’s note on crafting an intended purpose is blunt about this boundary. The statement has to say what the product is for, and the evidence sits behind it. If your intended purpose quietly includes “we will interpret whatever the local EPR emits,” every new trust is a new device. If the purpose assumes a stated input contract, the pipe’s job is to meet that contract or fail loudly.

UK Core is a contract, not a slogan

England’s direction of travel is FHIR Release 4 profiled as UK Core, with NHS England adding a further layer only where a national programme needs it. NHS England Digital’s UK Core API standards exist so information can move across organisations without a fresh private model each time. Vendors who build to that profile, plus the extensions a programme actually publishes, can reuse validation. Vendors who invent a cousin of Patient and Observation for each sales cycle cannot.

A drop-in pipeline earns its keep when it ingests the structured clinical data the trust can already emit (HL7 v2 from the EPR, a pathology feed, a scheduled extract) and presents resources that match the contract your product was evidenced against. Immediate ingestion here means days of mapping and fixture tests, not a multi-year wait for the trust to staff an API team. It does not mean the data are clean. It means you can see, on day one, which fields are missing.

Rule: If a new hospital forces a change inside the medical device software, the pipeline was never outside the device. Fix the boundary before you fix the map.

Where the months actually go

Pitch decks like a single percentage for “faster launch.” Ignore the number. Count the gates you still have to pass: information governance, a data-sharing or processing arrangement, clinical safety sign-off for the receiving system, and a test slot on a non-production EPR. Those gates do not shrink because your slides say FHIR. They shrink when the artefact is boring: a profile, a sample bundle, a reject report, and a named owner on both sides.

Dynamic HL7 mapping belongs in that artefact. Trusts do not speak one dialect. A map held as configuration, with golden messages per site, absorbs the dialect. A map buried in the device build absorbs the dialect into your release train, and the next trust waits behind your regression cycle.

What to put in the plan

Write the launch plan as two clocks. Clock one is yours: profiles, fixtures, acknowledgement behaviour, and the evidence that the device consumes a known contract. Clock two is the trust’s: access, sign-off, and a feed that will still exist after the next EPR patch. A pipeline attacks clock one. Pretending it attacks clock two is how programmes slip in month nine.

If you are placing a product into several hospitals, start from the contract, not from the logo on the EPR. The practical shape of that work sits in healthcare data integration and, where the product itself is the regulated software, in SaMD and AIaMD development. Bring a sample message from the ugliest site you already have. That file will tell you more about launch time than any roadmap slide.