Stream: fhir-messages
Topic: References - by identifier or resource
Kevin Mayfield (Feb 13 2021 at 06:12):
In UK / England standards we are seeing a trend towards identifier references which mirrors HL7v2 behaviour.
So we would refer to patient, practitioner and organisation by a national code. We would not include those resources in a bundle.
Kevin Mayfield (Feb 13 2021 at 06:18):
The resulting messages again mirror V2 but have less resources ('segments').
Anyone have experience of this in practice?
I can see issues around patient where you don't know the English patient identifier and in those cases a Patient resource must be in the message.
Jens Villadsen (Feb 13 2021 at 22:23):
I dont see the real issue here
Jens Villadsen (Feb 13 2021 at 22:24):
That is more or less the nature of message oriented arch
René Spronk (Feb 14 2021 at 07:45):
Messaging makes worst-case assumptions: none of the data may be known at the receiver end, so better include everything. However, if in your context some things can be stated to be always known, there's no real reason to send it. What you sketch seems like a natural evolution of the messaging paradigm, quite attractive actually. (I'll certainly add this concept to our FHIR training materials)
Kevin Mayfield (Feb 14 2021 at 08:12):
Thanks both. Was after a sanity check. I'm refactoring a number of HL7v3 and FHIR STU3 messages at the moment and leaning towards V2. It is resulting in a 50-97% reduction in message content.
However I think the real problem is getting this across to people who are still thinking in
- processes driven logical/complex models (V3/FHIR STU3 Messages and compositions/CDA)
- resource/profile only based FHIR (which results in large FHIR Bundles which end up mirroring V3)
Within a domain resource/RESTful is fine but inter domain/provider especially around events probably should be tackled differently (which is where identifiers kick in)
René Spronk (Feb 14 2021 at 12:03):
The more active discussion around event handling is probably related to Subscriptions right now (there's a fair amount of interest in that) - that same discussion applies directly to messaging. Currently one gets a notification of the event (EVN, MessageHeader) only, or event + focal resource. They've started the discussion of how to specify in a subscription what the scope should be of what should be in the notification. IMHO this directly relates to how FHIR might/should support messaging in a more modern way than perhaps in v2/v3.
(v2 is still the best solution for certain workflows, so you won't hear me commenting about that aspect of your comment)
IMHO those that have an interest in Subscriptions and those that have an interest in Messaging should be sitting at one table to hash out something that'll work for both exchange mechanisms - they're too close to ignore the overlap.
Last updated: Apr 12 2022 at 19:14 UTC
