Stream: implementers
Topic: STU3 pre-adoption of Reference in R4
Dave Barnet (Oct 22 2020 at 15:30):
I have a STU3 API that wants to be able to use HealthcareService as the recipient and sender of a Communication. This has been added for Communication in R4. What's the best way to achieve this (other than going to R4!). Is it to create an extension (but that might look a bit odd as you'd have a different concept name - "senderExtension" to the actual concept name "sender"). Is there a good pre-adoption route for adding references?
Michele Mottini (Oct 22 2020 at 15:39):
There is a standard way to create extensions to back-port elements: http://hl7.org/fhir/r4/versions.html#extensions
Dave Barnet (Oct 26 2020 at 10:09):
Michele - thanks for the link. My issue isn't about elements that missing from STU3, but additional choices on a Reference. Its a bit like the STU3 issue didn't have many references to PractitionerRole (which were put in for R4). So I guess I'll have to create an extension for a STU3 Communication to be able to have a HealthcareService reference for sender & recipient. Just seems a bit of a shame to complicate the profile in this way to add in extra choices in the References!
Michele Mottini (Oct 26 2020 at 13:43):
Ah I see, sorry I misread it
Rik Smithies (Oct 26 2020 at 16:19):
@Dave Barnet A pattern for this was mentioned lately on an FHIR-I call.
Instead of adding a new extension to replace the attribute ("e.g. mySender"), you can use the existing reference (sender) and just not have a value in it.
And then you put an extension for the new type in there. If I remember correctly, this "empty" reference is ok (that was the surprising part, for me), and it is closer to the original meaning.
Dave Barnet (Oct 26 2020 at 16:50):
On the page http://hl7.org/fhir/stu3/references.html it does say "At least one of reference, identifier and display SHALL be present (unless an extension is provided)." So Something like
<sender>
<extension url="https://fhir.nhs.uk/STU3/StructureDefinition/Extension-RefHealthcareService">
<valueReference>
<reference value="HealthcareServicePatient/ABC123" />
</valueReference
</extension>
</sender>
That works for me!
Kevin Mayfield (Oct 27 2020 at 07:07):
Not sure I agree with this. I'm not sure of the scenario here but I'm seeing this as MessageHeader.
In that case I have scenarios where HealthcareService is a legitimate Sender and Receiver, more so the Recipient
Should MessageHeader be similar to CommunicationRequest and HealthcareService (and CareTeam) is a valid receiver? (and maybe requester/sender)
Kevin Mayfield (Oct 27 2020 at 07:19):
On a side note. From a UK perspective and messaging.
I'm not sure it would be practical to send 'extranet' messages using PractitionerRole and HealthcareService, that expects internal organisation knowledge.
For intranet messages HealthcareService and PractitionerRole may be more practical.
For pragmatic reasons it may be desirable to send pairs of references, Organisation+HealthcareService or Practitioner+PractitionerRole. Messaging infrastructure can handle what it understands.
Lloyd McKenzie (Oct 27 2020 at 13:14):
Right. You shouldn't use Communication to serve the place of MessageHeader in messaging. If you must use messaging, then use messaging. (Though it's better still to use REST from an interoperability/less negotiation/better re-use perspective.)
Kevin Mayfield (Oct 28 2020 at 04:56):
@Lloyd McKenzie nobody is suggesting that. If we are messaging within an organisation, sending to/from services/clinics seems reasonable.
Lloyd McKenzie (Oct 28 2020 at 05:23):
I'm sorry, I misread the thread when responding. It's reasonable to ask that MessageHeader support HealthCareService.
Last updated: Apr 12 2022 at 19:14 UTC
