UK Messaging Principles Proposal

FHIR
1

This is unofficial.

I’m looking at putting forward a UK/NHS messaging proposal which is based on the principles below and interested in feedback:

Principle A - NHS Wide Message Standard

FHIR Messages are a NHS (UKCore?) wide interoperability standard, they are not programme or individual service/speciality focused.

Principle B - Atomicity (REST Compatibility)

It is expected endpoints will prefer to use FHIR RESTful, with transmission/exchange of these messages (between systems/applications and organisations) will continue to use traditional messaging. Conversion between different FHIR interaction styles should be as simple as possible.

Notification Events FHIR Messages are atomic and single resource focused (where possible). Workflow Events FHIR Messages are exempt from this rule due to the complex nature of the interactions.

Principle B1 - Documents are not to be used for Event Notifications or Workflow Requests

This is related to principle B. (policy?)

Clinical documentation and event notifications/workflow requests are to be decoupled and so atomic. Documents (CDA and FHIR Documents) should only be used to exchange letters and clinical summaries only. Workflow requests should be sent separately. E.g. a request for a GP to perform a Medication Review may be documented in a discharge letter but the request to perform a medication review is sent in a separate workflow request.

Principle B2 - Document Messages (structured data transfer) should not to be used

This is related to principle B. (policy?)

Document Messages are large structured exchanges often used to facilitate the population of central repositories. They are similar to clinical documents but lack the human readable element.

Document messages are highly discouraged (prohibited?), alternatives such as using FHIR Documents (clinical documents) or event notifications plus FHIR RESTful queries SHOULD be used instead.

Principle C - HL7 v2 Compatibility

Conversion to/from HL7 FHIR Messages to HL7 v2 should be simple. The initial version of the UK Core FHIR Message Types is based on HL7v2 Messages (this is likely to focus around HL7 v2.4 as used in HSCIC ITK 1 Specifications). FHIR Messages are not likely to be compatible with UK HL7v3 or HL7 FHIR STU3 FHIR Messages.

Principle D - FHIR Messages are decoupled from Middleware technologies

FHIR Message standard is a layer of specification independent from the middleware technologies being used. This is a breaking change from NHS (England) HL7 FHIR STU3 where FHIR Message types were linked to messaging infrastructure.

Principle E - Other Message Standards

(Is this a policy?)

If a compatible message definition exists (in HL7 FHIR (or V2)) then it SHOULD be used.

It will not be practical for all messages to be in HL7 v2 or FHIR Message format or a standard doesn’t exist. In those cases a best effort should be made especially around data model standards (FHIR Profile) defined in UKCore. E.g. a vaccination feed in CSV format sent over MESH, which contains both Patient and Immunisation data items SHOULD follow UKCore-Patient and UKCore-Immunization data models. (The COVID Vaccinations Data Capture API did follow these models and so was compatible with the COVID Vaccination History API as used by NHSApp)

2

Some good aspirations here Kevin, however:
Principle A: That’s great, but delaying the creation of a message for a given use case until every potential use case has been analysed is difficult when pieces of work are commissioned to deliver that one use case, and generally don’t have remit / resources / scope to consider the whole.
Principle B: Seems to be a mix-up between RESTful and ‘traditional messaging’ in the first sentence. Events are (or IMHO should be) a separate consideration, and further muddy the waters here.
Principle B2: There’s quite a few definitions of ‘Document’ competing here, not clear which are good and which are bad?
Princpile C: I think the work should be around making the messages suit / fit the business / clinical processes being handled. Given that HL7v2 has evolved on that basis over the years, alignment is likely to then follow, but I don’t see adherence to older standards as being a valid goal.
Principle D: I don’t know where message standards were previously coupled to messaging infrastructure?
Principle E: Is confusing.

3

I don’t see it that way.

Most of this is 80% behaviour already. Especially A.

E maybe should be don’t use another standard if FHIR Message R4 or HL7v2 standard exists.

4

Principle A:
@TCoates: “delaying the creation of a message for a given use case until every potential use case has been analysed is difficult when pieces of work are commissioned to deliver that one use case, and generally don’t have remit / resources / scope to consider the whole.”

If you don’t start until every potential use case has been analysed you will never start!

My suggestion would be that NHS Digital first establish mechanisms for general information exchange and then utilise these for specific types of information exchange. Where there is no standard for a specific type of exchange, the generic mechanism provides a fallback; it also provides metrics to focus efforts to support specific types of exchange. Only where we can show that a specific information exchange can’t utilise the generic mechanism do we create a complete new standard

(The present model would lead to a standard for Electricity Bill messages, a completely different standard for Birthday Card messages and never finish creating the standard for a Thank You Letter message. The concept of Royal Mail would be rejected as it didn’t meet current policy requirements)

Principles B1/B2:
@mayfield.g.kev: Our experience is that NHS orgs have very different levels of digital maturity and capacity for developing new interop capability. Document-centric approaches are shown to provide a low barrier to entry that encourages these orgs to participate in information sharing and can act as a waypoint to the more sophisticated information sharing that we would . Prohibiting this would create an insurmountable barrier to entry for many orgs that will ultimately stop information sharing that would benefit patients - it has to therefore be a Should Not rather than Must Not.

1 Like
5

My thoughts in B1 is documents would be supported

Workflow documents e.g. referrals, would become a
ServiceRequest message with an attached document (referral letter). Letter may be pdf, FHIR Document, etc

It wouldn’t be a Referral FHIR Document with attached ServiceRequest.

Discharge Letters would be two events. A quick ADT_A03 Encounter message to say the patient has been discharged which is followed by a Discharge Letter document.

B2 is a architecture style. It’s not really a principle more of an aim?

1 Like
6

We have to remember that the interoperability landscape still includes fax, email and (probably) carrier pigeon …

1 Like
7

I shouldn’t joke but intend to replace the pigeon with a phoenix and so FHIR compatible…

1 Like
8

Pigeon-on-FHIR does have a certain ring to it, though

1 Like