Created by Brett Esler, last modified on 02 Nov, 2017
Attendees
Agenda
“Secure Messaging Target Identifier” on the Endpoint Resource. This is taken from SMD/ELS and per the ELS V1.3 specification it identifies the “Target Service Owner” i.e. the Organization that sits behind the Endpoint. So this is effectively a Reference to the Organization by stealth. In the June workshop (http://confluence.hl7australia.com/display/PA/2017-06-08+Secure+Message+TWG+Workshop) it was expressly agreed to not add a reference from Endpoint back to anything. I was not particularly comfortable with that, but thought that if we needed it, it could be added later. However, if we are going to add a reference to Organization it should be a proper FHIR reference, rather than this “Target” identifier. To further muddy this, however, it is clear that in the real world, whilst Organisations own Endpoints, they are not the logical targets for the message. The logical target for a message is always a Practitioner Role or Healthcare Service. So, if the Target ID is re-cast as the logical target, then it becomes a reference to the Practitioner Role or Healthcare Service by stealth – again contrary to the agreement in June.
Network HPI-O on the Healthcare Service. The network HPI-O was promoted by NEHTA to be used as an identifier for Healthcare Services, and jurisdictions and the wider industry have clearly rejected this model. It was a flawed approach and people have been wise to reject it. This leaves us without a national identifier for Healthcare Services - but I am not aware of any need for a national identifier for these. If the receiving organisation advertises a Healthcare Services with a local identifier and endpoint(s), once the message is received with that local identifier, the organisation knows what to do with it. I believe we should consign the Network HPI-O as a Healthcare Service identifier to the dustbin of history
HPI-I@HPI-O on Practitioner Role. As for Healthcare Services, I also not aware of any need for national identifiers for Practitioner Roles. A local identifier is fine for these as the recipient organisation will know what it means. A practitioner role is a Practitioner at a Healthcare Service, so using a HPI-O here would only makes sense if we are identifying Healthcare Services with network HPI-O’s, which, I suggest, we shouldn’t.
The original TWG workshop agreed that Practitioner Roles would not reference Healthcare Services, but this reference has not been constrained out in the IG. However, I think that for large organisations (such as jurisdictions), this reference may be needed so that they can advertise Practitioner Roles at a particular clinic (service). Neither the location reference nor a sub-organisation reference would be good substitutes.
The original TWG workshop agreed that Locations would not reference endpoints. I support this, but this reference has not been constrained out in the IG.
The original TWG workshop agreed that Organisations would not reference endpoints. I support this, but this reference has not been constrained out in the IG
Review: Certificate IG points added
Note: 4 + 5 + 6 there are two perspectives to IG - definition as to 1. what is allowed + what must be supported vs 2. what will be produced by a server - Discuss.
This has been noted and discussed in FHIR community at large
Excluding usage of elements requires systems to strip other content even when it may be supported (custom profile application)
Client systems can ignore elements if they are not part of the profile they intend to comply with (unless FHIR modifier)
Makes difficult down the track with backwards compatible profiles derived from this one (i.e can re-introduce excluded elements)
Minutes
#1 SMD message - use Endpoint.identifer - SM target identifier in the MessageMetadataType.receiverOrganisation
#2 owned, contracted service provider, gateway; HealthcareService.identifier keeps HPI-O
encrypting to CSP cert needs to be assessed in terms of the privacy act + consenting
identity of intended recipient MUST be in the certificate
guidance from SMD standard or verifying identifier of recipient
signed by end user organisation not the system provider
CAs must also follow policies
#3 ok for now
Brian + Jared: examples next time.... tooling
Action items
Todo: Split ANZSCO; ANZSIC CodeSystem out from current role codes - separate
Todo: Provider roles mapping SNOMED, NHSD
Todo: Healthcare service roles mapping SNOMED, NHSD