| Table of Contents | ||
|---|---|---|
|
A11.1 Purpose
This document provides guidance for indicating that patient consent has been provided for a diagnostic services report to be uploaded to a shared eHealth repository (i.e. Personally Controlled Electronic Health Record System, PCEHR) using a HL7™ V2 message.
A11.2 Introduction
This Technical Specification constrains the usage of order and response messages and standardises terminology in some areas to allow a specific use case to be implemented using the existing Australian and International HL7™ V2 standards.
It introduces no new message types to those that have already been defined in AS 4700.2-2012.
The methodology used for the HL7™ V2 Indication of Consent message is the same as the method used for requesting historical results described in HB 5530-2013 A guide to accessing historical reports from pathology providers.
A11.3 The Indication of Consent Message
A11.3.1 General
Although providing consent for a report to be transmitted to a shared repository such as the PCEHR, is a new activity, delivering the indication message from the patient’s healthcare provider to the diagnostics provider can be accommodated with existing messaging channels. When the healthcare provider indicating the consent uses a standard order message (ORM^O01) the diagnostics provider may respond asynchronously with an ORR^O02. The diagnostics provider can then transmit the diagnostics results report to the shared repository.
In the context of an indication of consent of a diagnostics result report, the function of this message is to communicate that consent has been withdrawn or not withdrawn to a diagnostics service provider for the report to be sent to a shared repository. The ORM message is initiated by a patient’s health care provider at either the time or request for the investigation or at the time of review.
A11.3.2 ORM^O01 trigger event
The trigger event in the ORM^O01 is represented as with the ORC-1 value being either “SC” (Status Change) or “NW” (New Order).
With the use of the ORM^O01 message, it is important that diagnostic providers are able to distinguish an authorisation for a result report to be posted to a repository e.g. PCEHR, from a pathology/laboratory new test order. This should be readily differentiated by the contents of ORC-1 where the authorisation will contain “SC” and a new diagnostics request will contain “NW”.
The current HL7™ V2 standards in Australia allows for all of the order message requirements listed in HL7™ Sections 4.2 to 4.6 to be satisfied when they are needed.
Table 2 describes the structure of the diagnostics order message (ORM). Refer to HL7™ V2.4, section 4.4.1.
This message profile can be used in two modes. One as a part of a new order or when consent is being revised at the time or reviewing a report.
TABLE 1
DIAGNOSTICS ORDER (ORM^O01) MESSAGE STRUCTURE
| ORM^O01^ORM_O01 | Usage | Segment Description | HL7™ V2.4, Chapter |
|---|---|---|---|
MSH | R | Message Header | 2 |
PID | R | Patient Identification | 3 |
[PV1] | RE | Patient Visit | 3 |
[IN1] | RE | Insurance | 6 |
[GT1] | RE | Guarantor | 6 |
{ |
|
|
|
ORC | R | Common Order | 4 |
[ |
|
|
|
OBR | RE | Observation Request | 4 |
[{OBX}] | RE | Observation/Result | 7 |
] |
|
|
|
} |
|
|
|
A11.3.3 Indication of Consent and posting to the PCEHR
The communication of consent status provides the diagnostic services provider guidance regarding the posting of a report to the PCEHR and will depend on the contents of OBX-3 when the content is “|728301000168101^Patient consent to upload healthcare document^SCT|” and OBX-5 is set to “|728321000168105^Patient consent not withdrawn^SCT|” then the report has the appropriate patient consent to be uploaded to the shared repository.
If no indication of consent message is sent, standing consent is assumed and the diagnostic report should be sent to the PCEHR provided the patient has not withdrawn consent through other channels and the patient has a PCEHR.
In order to avoid storing information in the PCEHR system for consumers who are not registered for a PCEHR, systems must first check whether the consumer has a PCEHR. This can be achieved by calling the doesPCEHRExist function on the national PCEHR Service through the B2B Gateway or through the use of the message described in this document.
The response to a doesPCEHRexist query will be “Yes” in the following cases:
- The Consumer has a PCEHR and they have elected to automatically notify healthcare providers that it exists (i.e. they have not dissented to the “advertise’ function’).
- The Consumer has a PCEHR and has elected not to automatically notify healthcare providers that it exists but the requesting healthcare provider/diagnostic service provider is on their access list.
Diagnostic Service reports may be sent to the PCEHR where the response to the doesPCEHRexist query is “Yes”.
The response to a doesPCEHRexist query will be “No” in the following cases:
- The Consumer does not have a PCEHR.
- The Consumer has a PCEHR however they have elected not to automatically notify healthcare providers that it exists and the requesting healthcare provider/diagnostic service provider is not on the access list.
Diagnostic Service reports are not to be sent to the PCEHR where the response to the doesPCEHRexist query is “No” unless the consumer has confirmed to the Diagnostic Service Provider that they have a PCEHR record and they would like the report sent to the PCEHR. This specification also includes the ability for a healthcare provider to indicate to another that a PCEHR record exists. In the event when a healthcare provider has indicated to the diagnostic service provider that a PCEHR exists it is not required to do the doesPCEHRexist query as the record may be hidden.
A11.4 Indication of Consent message criteria mapping
Table 2 outlines the fields used for specific selection criteria.
...