2020-08-11 Meeting Notes

Owned by Former user (Deleted)
Last updated: Sept 21, 2020
3 min read

 11:00 AEST


Attendees

@Andrew McIntyre (Co-Chair)

@Michael Legg (Co-Chair)

@Angus Millar

@David McKillop

@Jared Davison 

@Kieron McGuire

@Kyle Macdonald

@Philip Wilford

@Roger Hill

@Scott Ferris

@Tony Cruice

@Vincent McCauley

@Vanessa Cameron (Secretariat)


Apologies

@Brett Esler

@Christian Holmes

@Dalisay Giffard

@Danielle Tavares-Rixon

@Eric Browne

@Jakub Sielewicz

@Lars Becker

@Liam Barnes

@Michael Osborne

@Paul Carroll

@Roger Hill

@Robert Flatman


Goals: To address remaining HL7v2-FHIR issues not discussed in Meeting 14 on 21 July 2020

Discussion items (included the following):

  • Notes from Meeting 14 on 21 July 2020 were accepted by members in attendance

8 Acknowledgements - Read receipts – KyM feels removing user-specific information from MSH-3 could mitigate potential privacy/security issue.  Human acknowledgment is desirable but not essential.  Exception reporting allows ability to reply to sender that something is wrong with message; currently no automated method to tell message sender there is a readability issue.  Each application has their own mechanism for not showing a result to a user once it has been read, with only new message content being highlighted to user as a reminder to view content. Samples of Positive and Negative read ACK available in 8.1.3 Accept vs Application Acknowledgements 3. Sender to Intermediary with multiple ACKS.  2 Patient Administration 2.1.8.6 MSA-6 Error condition (CE) 00023 – suggest could include examples where an ACK was read.  Input of name of person reading the message in MSH-3 would cause significant issues re HealthLink’s current use & policies in place.  Unable to achieve consensus on how best to resolve this issue, but consensus to retain 8.1.4 User Read Acknowledgements and related samples messages.  KyM to take issue offline to discuss with  HealthLink executive team & provide feedback prior to next meeting.

 

Action item 25 - 2.1.9.8 MSH-8 Security (ST) 00008  - need a place to add retrieval key for electronic orders, don’t need to specify token as a barcode as each application will interpret data via its own binary token.  Purpose is to provide a token (scheme identifier + access code) to a user, allowing retrieval of the order; order needs to know it’s token. MSH-8 being used internationally for security labelling, but Australian use not currently specified in AU Std; requires agreed sender/receiver protocol or cannot be interpreted properly.  Suggested use case: repository retrieval with specific query parameter.  Two issues identified 1) Is it appropriate to put binary token information in this place? A number of specialised applications already use MSH-8 field e.g. defining security level of message.  Is this field only to be used for orders?  Could be constrained to orders request message (pathology or diagnostic imaging), but need to understand all potential areas of conflict first before resolution possible 2) Is there enough information provided to assist developers to utilise this field appropriately?  Developers must understand the purpose of the token and know where to place it to be able to use it.  If there is data in MSH-8, applications receiving information point to point, don’t need to do anything to retrieve data; but application needs a place to store the data.  Current MSH-8 configuration enables several types of retrieval models but also keeps package of information together in native message type.  There are benefits to having token, but more is required to ensure correct function.  Unable to resolve MSH-8 issues discussed during meeting, will continue in next meeting.  As a way forward, members to agree on 1) use case for token  2) where to put token  3) valid reasons to include token in pathology / radiology messages

       

 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 – pending
  • 32. @Kieron McGuire - Contact Brett to have pages for Profile URIs (FHIR Provider Directory) and update link for FHIR R4 Value sets which should also return user to correct version of the Standard
  • 33. @Jared Davison – create a checklist prior to final draft Standard being published
  • 34. @Tony Cruice – Provide successful read message acknowledgement sample for 8.1.3 Accept vs Application Acknowledgments
  • 35.  Continue MSH-8 discussions 1) use case for token  2) where to put token  3) valid reasons to include token in pathology / radiology messages

 New Meeting actions:

  • 36. @Kyle Macdonald to take MSH-3 issue back to HealthLink executive team & provide feedback prior to next meeting
  • 37. @Vince McCauley to look at existing rules and provide potential conflicts

 

Next meeting: Tuesday 01 September 2020 11:00 AEST