Should you require any more information or have encountered a problem, please call the support helpdesk on (07) 5456 6000.

Introduction

It is very common for providers to see patients without full records of past reports and investigations results. Once patient permission is obtained copies of past reports are often requested from organisations thought to be in possession of data on a patient. This can make a critical difference to patient care and can avoid the costly repetition of tests already available on a patient. This report will define a mechanism of using HL7V2 order messages to request historical reports on a patient. This allows the automation of this common practice and facilitates the rapid acquisition of historical data. The process is designed as an asynchronous interchange to allow any authentication (potentially human) to occur before results are actually returned. It is designed to allow the existing result delivery mechanisms to be used to deliver the requested results using the existing message types.

Message Selection

A standard order message is used to initiate the interaction. In the current Australian environment this is a "ORM^O01" message and the initial receipt and be acknowledged by a simple "ACK" message or an "ORR" message as per AS4700.2. A filler that does not support the mechanism has an opportunity at this level to reject the request immediately either by using an error ACK or an ORR message with a ORC Order Control value of "UA" (Unable to accept). Once the request has been validated and the privacy concerns dealt with, the filler application can respond to the order in the normal way by sending an ORU message/messages containing the data of interest. Using the standard mechanisms described in AS4700.2 will mark the order(s) as complete, even if no data is discovered or transmitted. Addressing of the returned results is handled by the use of the ordering provider.

While standard order message protocols are being used, this request does have features of a query for results. The HL7 Standard does provide mechanisms for result queries, but the response is an "ORF" message rather than an "ORU" message and this is not supported by many systems. Like most orders there is also an element of discretion on the part of the filler as to what is returned and a human decision phase may be required in some cases. It is for these reasons that the protocol uses order messages, rather than HL7 queries. As we are not requesting any new results to be performed and may not know exactly which investigations have been performed the main role of this specification is to identify the order message as a request for historical results and allow a query mechanism to be implemented using standard order message segments. This mechanism is not specific to pathology results, but can be used for all types of historical report requests.

Identifying Order as Request for Historical Results

It is important that the filler can identify the order message as a request for existing results, rather than a request for new results to be performed. The ORC-1 order control is to still be valued as "NW" for new orders, as the results are still new to the requester. The ORC-7 (Quantity/Timing) End date/Time value being set is one marker but in order to make it clear that this is a request for existing results the ORC-16 (Order control reason(CE)) is to be valued with the code "|410513005^In the past^SCT|" which is a SNOMED-CT qualifier value. This field qualifies the ORC-1 "NW" value to indicate that we are requesting existing results new to the requester which have been performed in the past. Systems processing orders can check the value of this field to identify order messages that are for historical data. In the filler workflow management this is an important consideration and this field value is required to be present.

Specifying Results of Interest

1. Who are the results for.

The patient name and identifiers are to be included in the PID segment as per normal to allow the Filler to identify the patient in the filler system. No wild card parameters are allowed in this part of the query and enough identifying information must be provided to allow the Filler to match the patient on their own system.

2. What type of Investigation(s).

The standard order mechanism uses OBR-4 (Universal Service ID) to identify the investigation/service being requested. This is also used here. This is a CE (Coded Value) field and if the code for the requested investigation is known it may be used. Commonly however these codesets are not standardised and an alternative mechanism can be used.

Values usually used for OBR-24 (Diagnostic Service Section ID) can be used here. These are drawn from HL7 table 74 and can be used with a coding system of "HL70074". Using these it is possible to specify that you are for instance only interested in Microbiology results or Haematology results. It is also permissible to use a wild card specification of "*" which would appear in the messages as "|*^All results^HL70074| ". As the OBR segment can repeat is is possible to specify multiple specific tests, or types of tests that are requested. It is also permissible to use the text component of the OBR-4 field to request one specific test type without including a code or coding system. eg "|^Full Blood Count|" This would require human intervention to perform the result selection and the more specific the request can be the better. If standardised request codes become available they can also be used with site agreement. It is also possible to add free text notes to the order as per the standard and if desired further information can be provided by including clinical data in OBX segments under the OBR segment.

3. When was it done.

It is desirable to specify the time interval in which historical results are of interest. Many systems do not have older results easily accessible and if no time interval is specified it is assumed to be the last 12 months. The interval of interest is specified in ORC-7 (Timing/Quantity). The fields which should be valued are the Start Date/Time Component and the End Date/Time Component. The End Date/Time Component must be valued with date of the request. The Start Date/time component is assumed to be 12 months prior to the request unless it is explicitly valued. In some cases results going back years may be desired and if this is the case the earliest appropriate date is the patients birth date.

4. How many results are to be returned.

In some patients thousands of results may be available and it is desirable to allow some limit on the number of returned results. In other cases the requester may only be interested in the last result available and when this is the case the ORC-7 (Timing/Quantity) Total Occurrences component (NM) should be valued with the appropriate number of reports. It is assummed that the most recent result(s) is desired when this is transmitted.

  • No labels