It is not always feasible for sending systems to have access to the messaging system directory. Rather than being prescriptive about the values being "copied from" the directory, we should just say that they should match. See also my comment on HL7au:00045.7 re ensuring that they match. Resolved via comment about endpoint content matching - When using the Australian Profile for Provider Directory Services, the values from this field must be copied from match with the sending party's HealthcareService.Endpoint[x].au-receivingfacility as published in the directory of the messaging system being used for the transaction.
There may be multiple identifiers in the PractionerRole identifier list. It is important to map the routable identifers in the order specified in the directory entry. Note that HL7v2 systems often will consider only the first repeat of this field.
The current AU-FHIR-PD profile does not support ordering of identifiers, hence the order cannot be guaranteed.
HL7OO: Request extensions as drafted by Jared to HL7AU PA:
It is not always feasible for sending systems to have access to the messaging system directory. Rather than being prescriptive about the values being "copied from" the directory, we should just say that they should match. See also my comment on HL7au:00045.7 re ensuring that they match.
HL7OO: drafted fix in A10.1.3.1 MSH-3 Sending application (HD)
HealthcareService
The provider directory IG allows endpoints to be referenced from HealthcareServices, PractitionerRoles, and Locations. There are valid scenarios where the acknowledgement endpoint may not be referenced from the HealthcareService. We should just say the endpoint that the acknowledgements are to be sent to rather than specifying "HealthcareService".
HL7OO: drafted in A10.1.3.1 MSH-3 Sending application (HD)
au-receivingfacility
this link does not resolve - i think it should be -
Should this be PractitionerRole.location.address.line? Move done.
HealthcareService.location.address
Should this be HealthcareService.location.address.line? Move done.
Appendix 5 Conformance Statements (Normative)
HL7au:00044.5.6 CNE datatype conformance points andHL7au:00044.6.6 CWE datatype conformance points: <alternate text (ST)> component must be valued and this must be whit is intended for display to the user.
This implies that alternate text is mandatory; which is not true if no alternate text exists.
Appendix 10 Addressing messages using Australian Profile for Provider Directory Services (Normative)
HL7OO: resolve comment from A8.12.1.1.1 Australian Profile for Provider Directory Services. When using the Australian Profile for Provider Directory Services, the values from this field must be copied from sending match with the sending party's HealthcareService.Endpoint[x].au-receivingfacility as for receiving acknowledgements or responses to this message as published in the directory of the messaging system being used for the transaction
HL7OO: resolve comments from A8.12.3.1.1 Australian Profile for Provider Directory Services
... When using the Australian Profile for Provider Directory Services, the values from this field must be copied from sending match with the sending party's HealthcareService.Endpoint[x].au-receivingapplication as for receiving acknowledgements or responses to this message as published in the directory of the messaging system being used for the transaction. ...
HL7OO: fix links from A8.12.1.1.1 Australian Profile for Provider Directory Services ...
When using the Australian Profile for Provider Directory Services, the values from this field must match with the sending party's Endpoint[x].au-receivingfacility for receiving acknowledgements or responses to this message as published in the directory of the messaging system being used for the transaction.
Each component of the MSH-4 (HD) field must be valued with the FHIR valueString according to each of the extensions Endpoint resource's au-receivingfacility as per the following table. ...
HL7OO: resolve comment from Appendix 8 A8.12.2.5 PRD-5 Provider communication information (XTN)
XTN Component / sub-component
FhirResource element
Comment
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text]
if ContactPoint.use.code system is either phone, fax, pager, sms
HL7OO: resolve comment on A8.12.3.2.1 Australian Profile for Provider Directory Services. only when a-recevingapplication is populated
... When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving party's HealthcareService.Endpoint[x].au-receivingapplication as published in the directory of the messaging system being used for the transaction when the extension is present.
Each component of the MSH-5 (HD) field must be valued with the FHIR valueString according to each of the extensions Endpoint resource's au-receivingapplication as per the following table. ...
HL7OO: resolve issue with au-receivingfacility links
HL7OO: fix link as commented on A8.12.1.2.1 Australian Profile for Provider Directory Services
... When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving party's HealthcareService.Endpoint[x].au-receivingfacility as published in the directory of the messaging system being used for the transaction.
Each component of the MSH-6 (HD) field must be valued with the FHIR valueString according to each of the extensions Endpoint resource's au-receivingfacility as per the following table.
HL7OO: resolve comments on HealthcareService.location.address.line[0..*] from A8.12.2.3 PRD-3 Provider address (XAD)
draft fix remove A10.1.1.2 MSH-6 Receiving facility (HD) HealthcareService to make generic
... When using the Australian Profile for Provider Directory Services, the values from this field must be copied from receiving party's HealthcareService.Endpoint[x].au-receivingfacility as published in the directory of the messaging system being used for the transaction.
The provider directory IG allows endpoints to be referenced from HealthcareServices, PractitionerRoles, and Locations. There are valid scenarios where the acknowledgement endpoint may not be referenced from the HealthcareService. We should just say the endpoint that the acknowledgements are to be sent to rather than specifying "HealthcareService".
Update specification to include mapping between FHIR elements and PV1-9 to support intended recipient addressing for ORM, ORR, ORU messages
PractitionerRole.location.address
Should this be PractitionerRole.location.address.line? This needs to be copied into Appendix 10.
HealthcareService.location.address
Should this be HealthcareService.location.address.line? Move to Appendix 10.
ContactPoint.use
Should this be ContactPoint.system? HL7OO: done in A10.1.2.2.5.1 Individual Practitioner providers and
applied in A10.1.2.2.5.1 Individual Practitioner providers
transaction
It would be helpful to add a sentence saying that receivers may not populate au-receivingapplication and if it not populated, then MSH-5 can be omitted.
HL7OO: drafted in A10.1.3.2 MSH-5 Receiving application (HD)
published
Linkage to au-receivingfacility appears broken
HL7OO drafted into A10.1.1.2 MSH-6 Receiving facility (HD)
au-receivingfacility
this link does not resolve - i think it should be -
HL7OO: clarify use of PV1-9 for target recipient and allow additional repeats for consulting doctor in table 00139
...
In the Australian setting for ORU messaging, the first repeat of this field is used to identify the target provider for this each message. A location specific ID is used and the field should not repeat as each message is unique for the target providerof the target provider for this message must be placed in the first repeat and will be unique for each instance of messages to be routed. Where available the Medicare provider number is used as this provides for a location specific identifier. Messages should be routed based on this field and only the first repeat is used.
The consulting doctors can be specified in the second or following repeats of this field.
In the Australian context, where possible, this XCN data must be populated using the method described in A10.1.2.1 XCN Datatype.
...
4 Observation Reporting
Examples include reporting the amount of inspired carbon dioxide for blood gasses, the point in the menstrual cycle for cervical pap tests, and other conditions that influence test interpretations
Could we either consider changing this field to FT or making \.br\ valid for the ST datatype. If there are multiple separate additional clinical information points in this field it will make it easier to read if they are on separate lines.
HL7OO: we can't edit the datatype definition that would have massive consequences
HL7OO: options:
repeating field extension possibility.
2. escaped version of a line break. - problems platform specific line break
32. @Kieron McGuire - Contact @Brett Esler to have pages for Profile URIs (FHIR Provider Directory) & update link for FHIR R4 Value sets to return user to correct version of HL7 Standard
33. @Jared Davison – create a checklist prior to final draft Standard being published
41. @David McKillop to provide presentation on ADHA Diagnostic Report FHIR Implementation Guide (20 – 30 mins) after 06 October meeting
43. @Jared Davison to review draft Standard to ensure no other reversions have occurred
47. @Dalisay Giffard to share authorised outcomes of Queensland Health meeting discussions on gender identification
54.@Jakub Sielewicz to ensure @Jared Davison’s work on A10.1 Addressing messages Introduction is consistent with ADHA’s Secure Messaging Implementation Guidance Paper
New Meeting actions:
56. @Jared Davison to write to HL7.au PA working group re routability extensions to be proposed at next PA working group meeting 18.11.20
Next Meeting: Tuesday 01 December 2020 10:30 – 12:00 AEDT