2020-12-08 Meeting Notes

 10:00 AEDT

Attendees

@Andrew McIntyre (Co-Chair)

@Michael Legg (Co-Chair)

@Dalisay Giffard

@Jakub Sielewicz

@Jared Davison 

@Kyle Macdonald

@Philip Wilford

@Scott Ferris

@Tarun Narayan

@Tony Cruice

@Vanessa Cameron (Secretariat)


Apologies

@Angus Millar

@Brett Esler

@Christian Holmes

@Danielle Tavares-Rixon

@David McKillop

@Eric Browne

@Kieron McGuire

@Lars Becker

@Liam Barnes

@Michael Osborne

@Nick Ferris

@Paul Carroll

@Roger Hill

@Robert Flatman

@Vincent McCauley

  

Brief introduction to HL7 O&O wg purpose and welcome to Tarun Narayan, Solutions Architect NSWHP working on standardisation of HL7 project, joining the group for the first time

              

Goals:   1) Address remaining HL7v2-FHIR issues not discussed in Meeting 22 Tue 01 Dec 2020

 

Discussion items (included the following):

Notes from Meeting 22 on 01 December 2020 were accepted by members in attendance.

RACGP Standards with respect to safe reporting of pathology results and SPIA Standards distributed to all – if not yet received, please email @Vanessa Cameron. 

 7. Patient Referral

No feedback was received from wg on work undertaken in Meeting 22 with respect to 7.2.2. Patient Referral Acknowledgment Message structure (RRI_I12) - RF1, PID or PRD in ACK message awareness of RF1, PID or PRD currently being used in ACK message.  Decision to make all 3 segments optional as there may be sensitive patient information contained within these segments.  Proposal appears to align with both RACGP and SPIA Standards. 

 

RRI^I12^RRI_I12 Referral response Information message structure

1

2

3

4

5

6

7

8

MSH                               Message Header

MSA                               Message Acknowledgment

[ERR]                             Error

[

  RF1                               Referral Information

  {PRD}                             Provider Data

  PID                               Patient Identification

]

 

Receivers must not return clinical information to the originating referrer such as reports or results in the Referral Response Information (RRI). 

The RF1, PID, and PRD  segments must echo what was received in the referral message (REF).

Note that the RRI may contain personally identified information, therefore the handling of the message must account for the potentially sensitive nature and that RF1, PID, PRD may be group has been made optional in future versions for privacy reasonsfor backward compatibility.

 

7.3.3 PRD - Provider Data segment should reference Appendix 10 PRD mapping on how to do Ref message addressing as currently missing, similar to A8.12 Addressing; wording to be clarified.  Now incorporated in its own subsection 7.1.2.1 Addressing

...

Appendix 8 defines a simplified referral profile. Section 7 Patient Referral defines a number of segments which allow more complex referral interactions but also have a significantly higher level of difficulty and use of this functionality will require negotiation with endpoints. For most purposes the simplified referral messages is recommended. Appendix 8 makes reference to this section for details. 

7.1.2.1 Addressing 

The provider or facility identifier (in PRD-7) for the PRD marked with IR meaning "Intended Recipient" (in PRD-1) is used to address each instance of the message to an endpoint. Appendix 10 defines field mapping for addressing individual instances of a REF message to a provider or healthcare facility when using the Australian Profile for Provider Directory Services. 

7.1.3 Patient referral and responses

...

When sending a referral message to another provider, the intended recipient for the instance of that provider message must be identified. Only one provider PRD segment may be marked the intended recipient (IR) specified in the provider role field.

...

 7.6 Correcting referrals and 9.3.2.2. RF1-2 Referral priority (CE)

 Added instructions for correcting referrals sent in error (new section 7.6 Correcting referrals sent in error added) plus reference in RF1-1.

 ...When a corrected referral snapshot is sent, all information from the previous snapshot identified by the same RF1-6 Originating referral identifier (EI) must be replaced with the current snapshot. e.g. Allergies, Medication, Results, etc.

See section 7.6 Correcting referrals sent in error. 

7.3.2.2 RF1-2 Referral priority (CE) 

Anchor


RF1-2


RF1-2


Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

...

Referral messages may contain multiple display segments.

7.6 Correcting referrals sent in error 

Anchor


7.6


7.6

No delete mechanism exists for REF messages and if a report has been sent in error, then this should be stated in a correction to the original message with the same RF1-6 Originating Referral Identifier. Use Correction status in RF1-1 to indicate this. 

4. Observation Reporting

HL7OO: Fix LN errors in examples below.


Here's what changed:

...

 

MIME Type

Mime

 

application

x-hl7-cda-xdm-zip

HL7 CDA when packaged in XDM ZIP format

application

fhir+xml; fhirVersion=[version]

Atomic HL7 FHIR resource content in XML format *

application

fhir+json; fhirVersion=[version]

Atomic HL7 FHIR resource content in JSON format *

text

csv

Comma separated file format

application

vnd.ms-powerpoint

Powerpoint presentation

application

vnd.openxmlformats-officedocument.presentationml.presentation

Powerpoint presentation

application

vnd.openxmlformats-officedocument.wordprocessingml.document

Microsoft Word .docx file

application

vnd.ms-excel

Excel spreadsheet xls

*Refer to the FHIR specification for appropriate values of the version variable. e.g. "4.0" https://www.hl7.org/fhir/versioning.html 

Code Block

title

Encapsulated data (attachments)

ORC|RE||2.25.263498878813690208021966154988434320272^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO||CM|||||||0191324T^MCINTYRE^ANDREW^^^^^^AUSHICPR^L^^^UPIN
OBR|1||2.25.263498878813690208021966154988434320272^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO|18842-5^Discharge Summarization Note^LNote^LN|||20140825103830|||||||||2671351T^Doctor^Good^^^Dr^^^AUSHICPR||||||20140825103830||PHY|F||^^^20140825103830
OBX|1|ED|18842-5^Discharge Summarization Note^LN||^application^x-hl7-cda-xdm-zip^base64^UEsDBBQ
OBX|2|ED|HTML^Display format in HTML^AUSPDI||^text^html^Base64^PD94bWwgdmVyc2lvbj0iMS4wIj8+Cjwh....
OBX|3|ED|PDF^Display in PDF Format^AUSPDI||^application^pdf^Base64^JVBERi0xLjQNCiXi48/TDQolDQol...ORC|RE||12123-1^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO||CM|||||||0191324T^MCINTYRE^ANDREW^^^^^^AUSHICPR^L^^^UPIN
 
ORC|RE||12123-2^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO||CM|||||||0191324T^MCINTYRE^ANDREW^^^^^^AUSHICPR^L^^^UPIN
OBR|3||12123-2^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO|52033-8^General correspondence^LN Note^LNote^LN|||20140825103830|||||||||2671351T^Doctor^Good^^^Dr^^^AUSHICPR||||||20140825103830||PHY|F||^^^20140825103830
OBX|1|ED|52033-8^General correspondence^LN|2|^application^octet-stream^Base64^...||||||F
OBX|2|ED|PDF^Display format in PDF^AUSPDI||^application^pdf^Base64^...||||||F|||20170322
 
ORC|RE||12123-3^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO||CM|||||||0191324T^MCINTYRE^ANDREW^^^^^^AUSHICPR^L^^^UPIN
OBR|4||12123-3^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO|52033-8^General correspondence^LN Note^LNote^LN|||20140825103830|||||||||2671351T^Doctor^Good^^^Dr^^^AUSHICPR||||||20140825103830||PHY|F||^^^20140825103830
OBX|1|ED|PDF^Display format in PDF^AUSPDI|Supporting Letter|^application^pdf^Base64^...||||||F|||20170322
OBX|1|ED|RTF^Display format in RTF^AUSPDI|Supporting Letter|^application^rtf^Base64^...||||||F
 
ORC|RE||12123-4^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO||CM|||||||0191324T^MCINTYRE^ANDREW^^^^^^AUSHICPR^L^^^UPIN
OBR|5||12123-4^Good Hospital^1.2.36.1.2001.1003.0.8003629900024197^ISO|52070-0^Workers compensation^LN|||20140825103830|||||||||2671351T^Doctor^Good^^^Dr^^^AUSHICPR||||||20140825103830||PHY|F||^^^20140825103830
OBX|1|ED|PDF^Display format in PDF^AUSPDI|claimform1|^application^pdf^Base64^...||||||F|||20170322

 ...

7. Patient Referral

The patient referral is carried in the follow in message structure.

A large number of MDM^T02 messages are present in patient history records in PMS systems. How will MDM content be transmitted as supporting information to a REF? Supporting ORU information is placed in an OBR/OBX block but OBR does not exist for MDM messages.


HL7OO: we have examples of how to include CDA in REF message. Also see 4.26 Non-Displayable Supporting data



7. Patient Referral



Provider Name


Should Provider Name or Provider Identifiers be Conditional C otherwise what is the point of a PRD with just a Provider Role and nothing else.




HL7OO: Added Conditionality.




HL7OO: change optionality of PRD-2,PRD-7 to Conditional. Required when PRD-1 has IR.

Here's what changed:

...

SEQ

LEN

DT

OPT

RP/#

TBL#

ITEM#

ELEMENT NAME

1

250

CE

R

Y

0286

01155

Provider Role

2

250

XPN

O C†

Y

 

01156

Provider Name

3

250

XAD

O

Y

 

01157

Provider Address

4

60

PL

O

 

 

01158

Provider Location

5

250

XTN

O

Y

 

01159

Provider Communication Information

6

250

CE

O

 

0185

00684

Preferred Method of Contact - Provider

7

100

CM

O C†

Y

 

01162

Provider Identifiers

8

26

TS

O

 

 

01163

Effective Start Date of Provider Role

9

26

TS

O

 

 

01164

Effective End Date of Provider Role

† ALERT: Variance with HL7 2.4 International. Provider details are required in the PRD segment that is addressing a message (i.e. when PRD-1 includes an "Intended Recipient" - IR). 

7.3.3.1 PRD-1 Provider role (CE) 01155 

Anchor


PRD-1


PRD-1

...





6. Identifiers – changes as discussed in HL7.au Patient Administration wg

 


 


* UPIN must be used for Australian Medicare Provider numbers.


Note Table 6-1. Identifier examples needs updating. 


 

 


 


|049960CT^PRN^AUSHICPR|


Required updating to UPIN. Due to * "UPIN must be used for Australian Medicare Provider numbers."  



Value

Description

Comment

UPIN*

Medicare/CMS (formerly HCFA)’s Universal Physician
Identification numbers

Class: Insurance
An identifier for a provider within the CMS/Medicare program. A globally unique identifier for the provider in the Medicare program.





* UPIN must be used for Australian Medicare Provider numbers. 

** NOI is not present in the most recently published table of HL7 0203 in HL7 v2.8.2, though it is has been accepted for publication in HL7 V2.9. The allocation of these identifiers is not always at the correct level of granularity and many organisations are not registered and alternative identifiers are often used. Pathology Labs are identified using the AUSNATA code with there NATA number. 

...


This is an example of how to populate a Medicare provider number into PRD-7

This may conflict with what is shown in Table 6.1 at 6 Identifiers? There it's |049960CT^PRN^AUSHICPR|



 Outstanding Meeting actions:

  • 17. @Brett Esler  - Update links to all Standards on the HL7 Australia O&O WG page – Australian Diagnostics and Referral Messaging – Localisation of HL7 v2.4 Standard is still referenced as ‘Current Draft Standard’ as per  https://confluence.hl7australia.com/display/OO/Current+Draft+Standards

  •  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

  • 45. @Jared Davison to prepare PDF of draft Standard

  • 64. @Jared Davison tried to move A11.3 The Indication of Consent into draft Standard as an appendix, but has a lot of PCHR-specific content, not generic enough for O&O.  Needs governance to review before next meeting

New Meeting actions:

  • 65. RACGP Standards with respect to safe reporting of pathology results and SPIA Standards distributed to all – if not yet received, please email @Vanessa Cameron. 
  • 66. Noted that final meeting will focus on reviewing all remaining comments to ascertain if draft Standard is ready for public comment

 

 Final Meeting for 2020: Tuesday 15 December 2020 @ 10:00 – 11:30 AEDT

 

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Or call in (audio only)

+61 2 8318 0010,,191187227#   Australia, Sydney

Phone Conference ID: 191 187 227#

 

+61 2 8318 0010,191187227#   Australia, Sydney

+64 4-280 8090 New Zealand, Wellington

+1 647-749-7023 Canada, Toronto