Stream: australia
Topic: Problem with au-receivingfacility extension
John Carter (Aug 28 2018 at 22:51):
On the AUPD working group call last week, I raised a problem related to our use of the au-rec-fac extension and was asked to write that up for further discussion... here's that writeup. May I have your thoughts please @Brett Esler , @Brian Postlethwaite , and others interested.
In the AUPD SecureMessagingEndpoint profile, there's an extension called au-receivingfacility that points to an AU base structure here: http://hl7.org.au/fhir/pd2018Mar/StructureDefinition-au-receivingfacility.html. in the Endpoint, the au-recfac has a cardinality of 0..1.
The description of that thing says : "Values for routing HLV2 message payloads associated with an endpoint. Suitable for MSH-6." It takes three chunks of data, corresponding to the three parts of the MSH-6 segment. All well and good.
In our initial implementation, we populated that structure with our vendor-specific addressing info. However, for federation with other messaging vendors as part of the Secure Message Delivery interoperability pilot we're participating in, we are expected to populate that block with the HPI-O addressing information.
I think both are valid use cases... we transmit tens of millions of messages using our internal ID scheme, so that's an important thing to cover off. And of course, HPI-O addressing for interoperation is a useful thing as well.
As a straw man proposal to solve this problem, I'd like your feedback on a 2-part change to the AUPD Endpoint profile. First, change the au-receivingfacility cardinality to 0..*. Second, add some sort of "type" to the au-receivingfacility structure, which might be as simple as a coded value bound to http://hl7.org.au/fhir/base2018Mar/ValueSet-au-hl7v2-0203.html or might have to be more complex similar to an instance of Identifier.
Jared Davison (Aug 29 2018 at 00:18):
Hi John, the cardinality of 0..1 was intentional, it was intended that if more ids are required then additional Endpoint resources be allocated.
Jared Davison (Aug 29 2018 at 00:28):
The problem with introducing multiple cardinality is that it would result in ambiguity, because as a user how would you know which one to use. The design was that you identify search either the HealthcareService or PractitionerRole resource of interest, and that indicates the Endpoint resource which explicitly tells you what to put into the HL7 message MSH-6 fields because there is only 1 possibility. Also if you have a HL7 message with a correct MSH-6 value you can query the Endpoint resource which tells you how to route/encrypt it etc using the MSH-6 field values. This works, it was done at the connectathon last year.
Jared Davison (Aug 29 2018 at 00:30):
I believe this is not a matter requiring change of the specifications, but just a matter of understanding how to use them.
John Carter (Aug 29 2018 at 05:48):
Hi @Jared Davison , Thanks for sharing your thoughts on this. In my original posting I did try to tackle the ambiguity that would result from having multiple au-recfac blocks by introducing a "type" to each one. In the approach you outlined, it seems that the same ambiguity could now reside in the multiple Endpoint resources... how does a sender know which one to pick? I do see the connectionType attribute, which binds (required) to a value set here: http://hl7.org.au/fhir/pd2018Mar/ValueSet-valueset-au-serviceinterface.html. I can see the right value to indicate SMD messaging in that list, and in the AUPD example resources. What value would I use to indicate that (the other) endpoint is intended to be used only for HealthLink-to-HealthLink messaging? I'd suggest adding a new value to that value set, but probably one of the existing codes was used at the Connectathon to solve the problem?
Jared Davison (Aug 29 2018 at 07:23):
The value set is defined to support interoperability. If you you want to define endpoint resources that are not going to be interoperable I do not see an issue with defining your own healthlink connectionType uri and putting it in connectionType. It won't be compliant, but that's exactly what you want as I understand it? Consumers should only be looking for things that work for them, ie Endpoints containing known values others such as your uri will be invalid. Really I don't think you should be publishing such records for viewing externally on a compliant interface, but for internal use within your system I see no problem.
Brett Esler (Aug 29 2018 at 13:34):
I agree with Jared in the main part - different connectionType is different Endpoint instance - I would suggest we make AU PD Endpoint.connectionType and Endpoint.payloadType extensible rather than required bindings to the valuesets; that would mean could extend the valueset for domain restricted use in another profile derived from AU PD spec
Brett Esler (Aug 29 2018 at 13:38):
is Healthlink to Health link HL7 on MLLP that is direct HL7 V2 over TCP/IP? there is code for that in connection type valueset hl7v2-mllp
John Carter (Aug 29 2018 at 21:16):
Separating out the endpoints and making those value sets extensible solves the problem I currently have to solve. We'll move ahead on the hope/assumption that is how things proceed.
John Carter (Aug 29 2018 at 21:21):
Regarding the use of MLLP or not, that code would probably achieve the goal, but it's not semantically great... I'm not trying to describe a wire protocol... rather, I'm trying to say "this endpoint conforms (or doesn't) to the current agreement/limitations in place on the SMD network (allowable certificates, allowable addresses, federation contracts, ...)".
Last updated: Apr 12 2022 at 19:14 UTC
