I’ve been finding this an ongoing problem for a while now and why I came to this forum in the first place.
If I working on a problem in a NHS Trust or Region then I’m working in the environment on the right. If it’s central NHS/Government then it’s the one on the left (well, except for the COVID period when central NHS/Gov took the RHS approach).
My specialty is interoperability and my tools are IHE/HL7/FHIR, this is easy in the RHS environment but I’m questioning their value in the LHS as it’s a bit too bespoke at present … and if I’m being honest I’ve asked myself whether this ABC standard would have better off just being a PDF Report/Consultation Note/Discharge Letter/etc. (It probably needs to be something in between, a bit like goldilocks “This supplier specification is too weak” or “this central NHS spec is too much” → as developers we aren’t getting the requirements clinicians really want?)
E.g. for genomics I can get a PDF genomic report to a general consultant quite easily but getting a highly structured report would be very hard and way beyond what most consultants would use. What we probably need is the PDF for clinicians to read and much smaller list of codes (e.g. Patient is positive for BRCA2 gene)
if 1 is hard, then it is hard. No easy answer to that other than good luck and be sure to use the right tools etc. We can come back to specifics on that.
But for 2, if it is possible to, why not sent the “highly structured report”, then turn it into the “PDF” for the consultant to view?
The structured version can be stored for other uses than the direct human view, and the human view generated on demand (by whichever system is most appropriate).
I would not suggest sending only PDF just because that is what humans like to see.
If there is important rendering/layout information in the PDF (such as “red means high”), then that fact will need coding into the structured data also, so that a faithful “PDF” can be recreated, along with the red parts. Which is not always easy, but doable. And if on the receiving system the rule is “green means high” (for some strange reason) then the “PDF” can be re-generated with the locally appropriate formatting, if the full semantics were sent in the structure.
This all assumes that the PDF was generated from some sort of structure in the first place. If all you have is a PDF, or a PDF and a few scattered codes, then that is different - you are stuck. But I assume from the question that there is some sort of mix of structure and PDF and so a degree of choice about what is sent.
That is an example problem - we already have answers for that already which are following several HL7 (v2 and FHIR RESTful) and IHE (LTW) international standards, in addition to following clinical requirements and regional clinical process. If we go for a structured document, then we will follow HL7 Europe standards (FHIR Document).
However that has the potential of creating a different enterprise stack to central NHS/government, which is the other NHS tier/level.
p.s. this is a Patient Care Coordination problem and is being solved by a Health Information Exchange and Trust Integration Engine, we’re not an application so we have to keep this straight forward and aligned to enterprise integration techniques.
This may sound odd but I have to take a “German Engineering” approach and be process orientated rather than the more “English Engineering” approaches which can often be a little bespoke.
I’m not completely following the analogy here. Are you able to describe the differences you’re seeing between the two environments in slightly more concrete terms? Are you seeing the differences reflected in the technology approaches being championed by the central orgs? or in the way they approach problem solving?
I’ve documented a mix of common NHS Trust/ICS interactions on this page Laboratory Testing Workflow (LTW) - NHS North West Genomics v0.0.7
All are focused on existing clinical processes, i.e. it’s process orientated - we aren’t tech or system orientated which tends to be the case in central NHS.
Although this is for genomics, the process (and standards) for laboratory, imaging, pathology are similar. For a given condition (e.g. cancer testing), all of these diagnostics tests fit into one pathway.
Central NHS has no standards around this (except for one or two point to point messaging standards e.g. the series of NHS England Pathology standards), at most we have use NHS Number and SNOMED. (p.s. I do think the Welsh ORU_R01 standard is good and we’ve built on that in the North West)
It’s similar around sharing data or documents, most ICS/regions are sharing documents. The most common standard is IHE XDS SOAP API with one or two roughly like the more modern version of IHE XDS, MHDS (which has FHIR RESTful API’s)…. Central NHS has implemented a series of document sharing systems (which includes NRL, eRS, BARS, etc).
This is the main example of two tier NHS: providers/suppliers are going for (and asking NHS England to follow) international standards (inc IHE + HL7) and central NHS has a mix of systems with bespoke FHIR APIs.
p.s. Re Genomics. NHS England has done a gone data standard which we are following. We are differing in our approach as we have to take a more practical and pragmatic approach.
So at present we are mostly HL7 v2 Workflow (IHE LTW) and FHIR RESTful API (IHE QEDm) for data sharing. We hope we can move to NHS Englands recommendation using conversational FHIR Workflow in the near future.
To support the regional document sharing systems, we have adopted IHE Europe UK metadata and implementing this via HL7 v2 MDM_T02 (our document sharing system using using IHE MHD/FHIR RESTful)
We are finding it difficult to be pure SNOMED (as we are process orientated many codes don’t exist) and so bringing LOINC…. which actually makes it easier to get diagnostic reports into the main EPRs (as they are mostly US systems and so support a mix of LOINC + SNOMED)
Thanks @mayfield.g.kev - I do understand what you’re saying a bit more clearly now. It’s something I probably don’t fully appreciate given lack of direct experience working in Trust / Provider land.
On surface, it would seem that using profiled FHIR APIs does align with following international standards, but is the issue that it requires trusts / providers to implement multiple dedicated APIs to support different domain workflows vs using a more generic document exchange approach which allows some of the process logic to be handled within TIEs etc.? I guess the nugget I’m not fully understanding is why central NHS adopting things like FHIR is at odds with what Trusts need / want around standardisation (rather than building totally bespoke / proprietary APIs as seems to be happening with the FDP..)?
Central NHS is program-centric which results in multiple specialist APIs targeting the needs, desires, and foibles of the program. These are not coordinated and result in implementation of unnecessarily specialist APIs (consider FGMPractitioner … ). This is compounded by creation of a perverse incentive encouraging central NHS staff to invent long and complex programs (consider how many programs have been cancelled by the staff working on it realising that the problem has already been solved by someone else …).
Most (but not all) real-world interoperability problems could be solved using generalist APIs. We only need look at the plethora of solutions enhancing primary and community care that are built on generalist APIs offered onto EMIS Web and TPP SystmOne. Whilst these are proprietary offerings, much of the equivalent capability (“What do you know about this patient?“) can largely be provided using international standards (e.g. International Patient Summary and International Patient Access).
Similarly, general purpose messaging APIs (“Here is some information about a patient that you should be aware of“, “Here is something you should do for this patient“) can also help solve real-world interoperability problems.
There is an added benefit at the system level by creating an environment that encourages innovation. Generalist APIs provide consistent technical interoperability so that consumers and providers can quickly explore new workflows (i.e.business process interoperability) to determine whether they provide benefit. The result of this exploration may be that we reject the workflow (“fail fast“), keep the workflow as-is or recognise that the particular characteristics of this workflow mean that we should invest the additional time and effort to develop a specialist API.
Thanks - I think I understand the point you’re making now, and can see the perspective at least. I realise I probably shouldn’t / can’t form an opinion on it without taking some time to properly understand the real-world examples a bit more. I do completely recognise the issue of programme-driven interoperability design.
Re placement of process/business logic in TIE, we don’t do that. The TIE is really an event streaming system which routes and transforms data, it’s not like MESH which is more simple file transfer.
The TIE is working with event messaging where the producer says “I’ve done this” and the consumer “ok, so now I need to update my records to this and do that”. The business logic rests with the consumer (it’s really difficult to get producer or middleware to handle process logic).
I don’t really treat HL7 v2, FHIR, DICOM, XDS Document Entry, etc as being different models, it’s mostly formatting differences. This is another difference between English NHS and NHS England, we can’t do jumps between different modelling. E.g. if a v2 PV1 segment says PV1-19 visit number is mandatory and has this format, then IHE XDS and FHIR Encounter need to keep the same rules.
p.s. this isn’t new, NHS England use of V3 and CDA had these issues.
I understand that. When I was working within NHS England it was quite apparent we steered towards data standards and what clinicians were originally asking for was for the most part removed/reduced.
It was like the business analysts were being side lined/bypassed.
I haven’t thought deeply about this, but I wonder if this is partly due to the perceived levers that NHS England had / has. i.e. if you squint enough, you can sort of make out a route to enforcing / strongly encouraging compliance with documented data standards (whether it be through contractual levers, market pressure, or just strong collaboration with suppliers etc.). I could imagine it might be less obvious as to how the centre can play a role in more generic approaches.
Here are you saying that the approach you’re taking in Trusts doesn’t allow jumping between different models? Or the centralised data standards approach?
I’m working on a regional genomics project at the moment, and we’ve had to start aligning different standards as we have
NHS England using FHIR
LHCRE/ICS using HL7 v2 MDM and IHE XDS
EPR and LIMS using HL7 v2 ORU
It sounds worse than it is, for most part it’s me altering my language (standard) when talking to different developers. Most of the developers (and suppliers) are quite amenable to change …. if I talk in their language.
It’s same for project staff and we’ve adopted their more clinical focused language which does tend to be process focused (most developers were doing this already).
). This is compounded by creation of a perverse incentive encouraging central NHS staff to invent long and complex programs (consider how many programs have been cancelled by the staff working on it realising that the problem has already been solved by someone else …).