Date
stated started 10am (AEST) and finished finished 12.05pm (AEST)
Next meeting 10am (AEST) 14th November
Attendees
- Former user (Deleted)
- Former user (Deleted)
- Former user (Deleted)
Dalisay Giffard (QH) (left at 11.30am AEST)
- Former user (Deleted) (joined from 11am AEST)
Apologies
...
| Item | Who | Notes |
|---|---|---|
| ||
| Change of requirement in specification from Australian Digital Health Agency (Agency) | Jared, Andrew | The Agency are concerned about time frame for developing vendor implementation of the spec and have changed tack by just wanting a REF message with only a pdf display segment, where systems only requirement is to be able to display the pdf. Discussion on this being the lowest base requirement and all other atomic data would be lost ie a lost opportunity to get some standardisation of the REF atomic data eg allergies and medications. |
| Review of Appendix 5 HL7au:000002 | Jared | Re: HL7au:000002 - "The system receiving messages must ensure the received message is adequately identified (HD component of EI must be valued as well)." Seemed to have come from the AS 4700.2 doc. Discussion on use of term "adequately identified". Compared to HL7au:000004.2, added a comment regarding " resulted in this CP being edited. Andrew and Jared to take this offline to progress. |
| Jared's feedback spreadsheet dicussed (feedback from one vendor) | Jared | Mainly directed to handling pdf, so it required other formats eg HTML the conformance doesn't need to be as strong. |
| Discussion regarding Australian vendor capability | Jared, Andrew | Vendors who aren't able to comply with the standard understand that the standard is something that needs to be complied with, but many haven't actually made any changes or attempted to be compliant with the standard. |
| Discussion on criteria for producing an ACK | Jared, Andrew | Systems should be able to produce an ACK upon receiving a message, but some systems are reliant upon specific trigger from the messaging provider to produce an ACK. |
| Discussion on requirements | Andrew | Discussion on restricting to one OBR and PDF display segment, but if a system sends medications, allergy information, then systems should be able to handle it, but that has been thought to be "more" than is needed ie just a REF with a display pdf. |
| Formatting the new version | Jared | The pdf generated version needs some hard formatting of each table. DMc to look at the old version which has the formatting and then need to copy these formats to the new version of the standard. |
| Reviewed Vince's feedback of standard | Jared | Jared reviewed the changes that required committee feedback and made appropriate changes as directed by c'tee. Changed Appendix 5 to "Normative". |
...
- Former user (Deleted) & Former user (Deleted) to progress the discussion on Appendix 5 conformance point (in table) HL7au:000004.2.
- Former user (Deleted) to do formatting changes to tables from draft to snapshot to provide a PDF version.
- ADHA and REF message - if a highly constrained message has to be used then it is a constrained message described in this standard ie 1 ORU and 1 REF message with a single OBR with at least a PDF rendering
- Former user (Deleted) - Need to action Vince's point 5
- Former user (Deleted) & Former user (Deleted) Ensure validator issues are addressed in standrd