This is based on this tweet and replies: https://twitter.com/johnneeson100/status/1538051773948219395?s=21&t=UbIu0nGCAXKjcntNZ8rrwg around the EMIS being purchased being taken over.
My view on the interop side is primary care and secondary care interop in the UK is fundamentally different. The main reason I feed is primary care interop is often designed around data models and secondary is designed around business interactions.
You can put a different perspective on this and also say primary care is clinical focused and secondary care interop is often health administration based.
These are quite general statements and maybe 60–70% and we have overlaps which are visible on the technical side. For example the data model for Observations (body temp, weight, etc) are often very similar. You can say both primary and secondary care systems follow the same model and this has been occurring for a while e.g. Caristix HL7-Definition V2 represents the overlap. This is the old HL7 v2 representation and is not that readable … the HL7 FHIR version is much easier to read Observation - FHIR v4.3.0. The main difference here in the UK is primary care uses SNOMED CT and relatively standard units and secondary care (labs mostly) use local codes.
I believe the main reason for these differences is we are tackling interop with different combinations of
- people
- process
- technology
Often one or two of these will take precedence over others (normally a narrow focus on process), which can lead to failure. We also add in organisation requirements (so interop becomes focused on what the organisation wants rather than users).
We also see that in technical standards: openEHR + HL7 v3, HL7 v2 and HL7 FHIR tend to focus on different things:
- HL7 v2 has a event trigger/process focus (and a basic data model - it is not focused on the data model)
- HL7 v3 has a data model/data set focus (it often uses same data model in v2 but this is difficult to find)
- HL7 FHIR focuses on the basic data model and calls these resources (and overlaps with the v2 one)
- PRSB focuses on the clinical data model
- IHE (in the US) focuses on process
- openEHR has a archetype/data model focus, at a different level to FHIR. This doesn’t mean they are incompatible, they will have differences depending on how people view interop. It’s this that causes openEHR vrs FHIR debates, which are often apples and pears conversations as people are trying to solve different parts of the problem and have different perspectives.
We’re again back at people+process+technology
One of the big mistakes I feel we make in the UK is not focusing on the process side. In the US this is often part of IHE standards (not just XDS), for example community pharmacy standard https://www.ihe.net/uploadedFiles/Documents/Pharmacy/IHE_Pharmacy_Suppl_CMPD.pdf
Towards the start it has this diagram (the remainder does go down a very technical US focused solution)
It should be recognisable. E.g.
- EPS is present - the approved interaction feeding into the dispenser. (As is the HL7v2 pharmacy/treatment order)
- Having the prescription validated/checked is present on some EPMA.
- Repeat dispensing is done in EPS
Prescription refills (from NHS App and others) are not on the diagram but can see where it fits.
As a PCN/online consultation supplier. We believe we have the following use cases around medications:
- Pharmacist sends a prescription for validation and issuing via EPS to GP.
- a practitioner issues a drug via EPS (we also want to check the medication is safe, ideally with some decision support)
- A practitioner asks for a medication review following an incident
- patient asking for a prescription refill
- Get a full view of the patient meds for patient consultations.
- Ability to see dispensed medications or at least see the patient has collected the medications
- allow the patient to view current status of their prescriptions e.g. to know it is ready for collection, it has been dispatched, etc.
IHE often has a technical framework for solving process/user requirements.
The following goes into our technical ‘framework’ with a bit of HL7 FHIR Workflow:
We do have data models mentioned in the above e.g. prescription is in UK Core https://simplifier.net/guide/HL7FHIRUKCoreR4Release1/Home/ProfilesandExtensions/ProfileUKCore-MedicationRequest?version=current and the process interactions with EPS are defined.
A lot of the ‘ask’ or workflow bit isn’t covered in NHS standards. We don’t want to work with single GP supplier to request these as we expect the supplier to say no (or it will be too expensive). Roughly what we have at the moment is a request for a interface to do the following (based on FHIR Task workflow). This expects a series of exchanges between requester and owner of the task, e.g. Can you review patients 9876543210 medications and replies would be returned yes all ok, no it has problems, I’m too busy, etc
| Data Item | Notes |
|---|---|
| code | medication review, review and issue, refill prescription, issue, collect meds, etc |
| for | patient identification, probably NHS Number |
| requester | GMC, GPHC, GMP, etc of user and ODS Code or Patient NHS Number |
| owner | ODS Code plus GMC, GPHC, GMP, etc of user if applicable or patient NHS Number |
| status | request for the initial request, other status for replies see Task - FHIR v4.3.0 |
| focus | a reference/link to the prescription if applicable. Except some requests may need prescription sending with request |
| reasonCode | A code indicating reason for request. E.g. asthma attack |
| notes | narrative on the request, including if not coded |
codes probably SNOMED CT.
Obviously you can solve the user requirements in many different ways:
- We use a community version of the GP system
- We use part of the GP system for prescribing
- We give external users access to our system.
- We use the local ICS/STP/LHCRE (HIE) portal to view the patients record (or we access via an API)
- We degrade our data to text and send to supplier as text plus maybe some codes.
I would prefer to take the FHIR Task workflow route as it covers people+process plus it is quite generic (and extendable - easy to add new codes) and allows me to add in technical stuff like TIE/message middleware, pub/sub components, events, workflow engines, etc, without altering people+process part. (We often can’t do this because either the people, organisation or process focus makes the tech layer inflexible).