Stream: uk
Topic: UK FHIR Messages - current practice
Kevin Mayfield (Sep 15 2020 at 06:07):
I'm currently researching FHIR Messaging and looking for some examples of how this has been approached in the UK (both STU3 and R4).
Examples I have at the moment include:
- Manchester LHCRE Pathology R4 - https://simplifier.net/guide/GreaterManchesterLHCRE/UnsolicitedObservations
- NHS Digital - Digital Medicine (Electronic Prescription Services) R4 - https://simplifier.net/guide/DigitalMedicines/MessageDefinition
- Nottingham Council Referrals STU3 - https://simplifier.net/guide/SocialCareDataService/Home (missing MessageDefinition but believe it is used)
- NHS Digital Transfer of Care STU3 - https://digital.nhs.uk/services/interoperability-toolkit/developer-resources/transfer-of-care-specification-versions
- NHS Digital Event Management System (mostly ADT) STU3 - https://developer.nhs.uk/apis/ems-beta/overview_supported_events.html
- NHS Digital - Digital Medicine (Med Dispense and Vaccinations to GP's) STU3 https://developer.nhs.uk/apis/digitalmedicines-1.2.3-private-beta/
Any more?
Kevin Mayfield (Sep 15 2020 at 06:29):
My initial thoughts is we have two differences of opinion of Message event coding.
For example this ValueSet has detailed encounter codes https://fhir.nhs.uk/STU3/ValueSet/EventType-1
Whereas in Hl7v2.4 these would have one trigger event ADT_A04 and Encounter.type sub divides the trigger. I prefer the Hl7v2 patten, thoughts?
René Spronk (Sep 15 2020 at 15:13):
Hl7 v2 trigger events are kind of the (lowest?) common denominator when it comes to 'business events', and the definition of the expectations when one receives such a trigger. On notifications, one could define tons of triggers, but if senders and receivers (jointly!) decide that to be useful, then why not?
Kevin Mayfield (Sep 16 2020 at 07:34):
That's what I want to explore. I not seeing any clear pattern either way.
Styles I've found so far: pathology or observation related:
- A unsolicited-observation focus DiagnosticReport
- B {specialty}-{reportType}-report focus Diagnostic Report
- C observations focus Encounter
For point to point I guess this doesn't matter, with a router and/or pub/sub I'd probably favour B & possibly C being a child of unsolicited-observation (code).
Wondering if that is a solution, have already discussed a hierarchy of MessageDefinition, parent being UK unsolicited-observation (focus DiagnosticReport plus optional Patient), a regional (English LHCRE) version (focus DiagnosticReport plus required Patient) and point to point or specialty version (say English secondary care to primary care) will further constrain on the LHCRE version.
Alternatively, we can have generic MessageDefinition's (e.g. unsolicited-observations), detailed routing is done via the DiagnosticResource. Including service/specialty or reportType in the event coding is duplication and complicates message handling.
Kevin Mayfield (Sep 16 2020 at 11:47):
Should notification messages be quite basic. So diagnosticReport has Crud lime codes, create, update and delete?
Kevin Mayfield (Sep 19 2020 at 06:44):
A proposal https://www.openhealthhub.org/t/event-notifications/2306
Last updated: Apr 12 2022 at 19:14 UTC
