HL7 Query messages,
the next step in German systems integration ?

Abstract

This paper describes the query-response mechanism in general and lists the main categories of query messages as used internationally. A detailed description of 2 types of HL7 query messages can be found in appendix A.

1. Introduction

The data sent in unsolicited updates is not tailored to the requirements of a specific receiver-application. It typically broadcasts a wide range of data to all systems that may or may not require the information. The query mechanism is used when there is a need for a Client to retrieve a specific set of data, where the scope of data is limited by the request (e.g. to a specific patient or to a certain timeframe).

A typical example of why applications have a need for queries is a specialised application such as used by a radiotherapy department. This application has a need to import patient demographics data that have been entered into the Patient Administrative System (PAS, a.k.a. HIS) system prior to an encounter with the radiotherapy department. It is impractical to force the users of the radiotherapy application to re-key the data as displayed by the PAS system into the radiotherapy application. Given that the patients who receive radiotherapy form a very small subset of all patients known to the PAS system, it is also impractical to update (e.g. based on unsolicited update messages) the radiotherapy patient database with all patients known to the PAS system. The best solution in this case is for the radiotherapy application to send a query to the PAS system for the full demographic details of a specific patient.

The following represents typical examples of queries:

• Data regarding a single patient, e.g., send the demographic information or all lab results for patient #123456
• Data regarding multiple patients, e.g., send the list of patients whose attending physician is Dr. #123
• Data that is not patient related, e.g., send the occupancy status of all beds for ward #INT-1.
• Data within a specified time range, e.g., send all serum glucose results, reported between January 1, 2006 through December 31, 2006, for patient #123456.

2. The use of queries

Based on the use of query messages worldwide, the state of the systems integration in the German market, and the issues relevant to German healthcare, the prime candidates for query messages in Germany are:

1. Patient Demographics.
An application determines a need for demographics data about a specific patient and sends a query to the system that owns the patient demographics data.

For demographics data, the PAS system is mostly the 'owner' the demographics data. In regional settings where patients may have multiple identifiers the Master Patient Index (MPI) keeps track of the patient demographics. Demographic data includes elements like name, address, date of birth, sex, general practitioner, and may include patient location (if currently admitted), attending physician, diagnoses, and insurance information.

2. Observations (Laboratory results)
An application queries the laboratory systems for specific observations in order to provide additional clinical information to its users.

Observations may be generated by all departments, e.g. laboratory, radiology and pathology. The observations may contain structured data or textual reports.

3. Diagnoses/procedures
If diagnoses/procedures related to the same episode of care are entered into (or of importance to) multiple applications, queries may have to be used to obtain a complete list of all diagnoses/procedures.

There are 2 scenarios where these queries would be helpful: The PAS system querying a subsystem to see what diagnoses/procedures have been created by the subsystem, this in order for the PAS system to merge (and 'optimise') the codes for billing purposes, and a subsystem that queries the PAS system for the diagnoses codes to provide additional clinical information to its users.

4. Bed occupation In hospitals where the PBX system (Deutsch: Telefonanlage) tracks the patient location within the organization, and has the latest and most reliable data related to bed occupation, other systems may want to update their data by sending a query for bed occupation data to the PBX system. Some PBXes track the location of all patients, this to allow them to use 1 specific telephone extension number irrespective of their physical location. The patients have received a PIN number to enable them to have phone conversations; the associated costs are invoiced after they have been discharged. In these situations the quality of the patient location data in the PBX is often of better quality than the patient location data in the PAS system. 5. Insurance coverage (Eligibility) In circumstances where the insurance coverage of a patient is uncertain, a healthcare provider organisation sends a request for information concerning a person's insurance coverage to public or private healthcare insurers. This request is for validating whether a patient has healthcare benefits coverage in effect for a specified date, i.e. if there is an insurance policy. The purpose of this query is to identify the extent to which a patient has insurance coverage as the outcome may impact what services will be rendered to the patient. 6. Schedule information A person wanting information about schedules, appointments and open slots therein, causes an application to query the application that manages the schedules for detailed information. The information that the querying application receives may be used to create resource-specific working lists, or form the basis for a subsequent appointment request (booking an open slot). 3. Queries and 'Thin clients' The ever-increasing use of internet technologies has lead to relatively simple applications that allow clinical data to be viewed by means of a web browser. The underlying technology could be a simple as a collection of (server generated) HTML pages, or it could be a Java applet. These 'Thin client' applications typically don't have support for the persistent storage of data on the client. Therefore its functionality depends on its ability to retrieve various elements of data components from various systems. If the thin client isn't closely coupled with a specific application it could use an open-standard query interface as offered by the various applications in the healthcare provider organization. These could range from Corba, J2EE, JMS (to name a few candidates) to HL7 query messages. The queries and their associated replies could be formatted as XML messages. These can be easily transformed into HTML using an XSLT. By using a stylesheet to display them in a proper fashion, the XML response to the query can be immediately displayed by the browser. The use of internet technologies and the support for query interfaces is set to increase in healthcare. One of the reasons is the tendency for regional healthcare provider organizations to increase cooperation. This will only be possible if the information owned by an individual healthcare provider organization can be made available to other organisations.

Queries in SAP IS-H The IS-H SAP module, like all other SAP modules, supports queries by means of the SAP Exchange Infrastructure. The SAP Exchange Infrastructure is a key component when there is a need to integrate into SAP, allowing SAP customers to instantly participate in collaborative business scenarios and marketplaces. More specifically, it provides SAP customers with the ability to connect to any number of SAP applications and mySAP.com. It also offers integration to non-SAP applications, facilitating business-to-business transaction in an EDI-like manner. An XML document can be sent to SAP via the SAP Exchange Infrastructure, and it responds by sending an XML document, using the HTTP transport protocol. Using the SAP Exchange Infrastructure all APIs provided by IS-H (e.g. BAPIs and RFCs) can be called, provided that the Client application has the rights to do so. In a healthcare setting these XML documents can easily be translated to and from other standards such as HL7. All hospitals that use IS-H should therefore consider installing the SAP Exchange Infrastructure and using its capabilities to allow other applications to send queries to IS-H.

4. Summary

There is currently no support for query interfaces in Germany. Most organizations are using messaging to convey information related to basic data categories. The query/response mechanism allows an application to query a system that 'owns' a particular category of data for specific information relevant to the querying application. The use of query messages can be especially useful in regional cooperation projects to allow access to data by other organisations. Typical queries include a query for patient demographic information or a query for laboratory results.

5. References

[HL7Query] "HL7 Query Messages", (section 2.8 of HL7 version 2.2/ section 5.10.2 of HL7 2.4), http://www.hl7.org/
[HL7ADTQuery] "HL7 Patient Administration Query messages", (section 3.2.9 of HL7 version 2.2/ section 3.3.19 of HL7 2.4), http://www.hl7.org/
[HL7ORUQuery] "HL7 Observation Query messages", (section 7.2.2 of HL7 version 2.2/ section 7.3.3 of HL7 2.4), http://www.hl7.org/

---

Appendix A: HL7 v2 Query Messages

This part of the paper contains the technical details of HL7 query messages. HL7 supports various query types: original mode queries and enhanced queries. Prior to HL7 version 2.4 the only mode used for query messages was the original mode. The Query Standard, like the HL7 Standard in general, has been evolving since its inception in Version 2.1. Version 2.4 introduces a new methodology intended to supercede the previous generation of queries. This appendix will focus on the original mode queries.

This section describes the use of record-oriented original mode queries [HL7Query]. In the original mode queries, separate trigger events are used to differentiate between the various queries. In addition, some of the functional chapters define queries and responses with separate trigger events.

QRY^Q01^QRY_Q01	Generic Query
MSH	Message Header
QRD	Query Definition
[ QRF ]	Query Filter

Figure A.1 - QRY message definition

Figure A.1 shows the structure of HL7 query messages. The parameters of an HL7 query are carried by the QRD (Query Details) and QRF (Query Filter) segments. Because these segments are intended to be used by all queries, the content of these segments are only loosely defined in HL7.

The query type is identified by QRD-9 (What subject filter). The key for searching of the query is either stored in QRD-8 ("Who") or QRD-10 ("What"). QRD-8 is used if the subject of the query is a person; QRD-10 is used if it is not.

The structure of the response message consists of a few query-specific segments followed by a sequence of segments as defined by a particular HL7 chapter. This is mostly a segment sequence as it is also used in event-triggered messages defined by the same chapter.

Query for demographics data

An application determines a need for ADT data about a patient and sends a query to the ADT system. The query for patient demographics data (i.e. a QRY^A19 query message with an ADR^A19 response) is the query that is most often used internationally. [HL7ADTQuery]

QRY^A19^QRY_A19	Patient Query
MSH	Message Header
QRD	Query Definition
[ QRF ]	Query Filter

Figure A.2 - QRY^A19 message definition

Figure A.2 contains the definition of the demographics query. The query type (QRD-9: What subject filter) contains DEM (Query for patient demographics data based on patients' ID), APN (Query for patient demographics data based on patients' name) or any of the query types defined in HL7 chapter 3.

The storyboard for the example message shown in figure A.3 is as follows: "Ms. Anderson is a Registration Staff working at University Medical Center (UMC). She is authorised to admit patients on behalf of the physician who is affiliated with the hospital. Dr. Bowen has notified the Registration Office that his patient, Mr. Bauer, will arrive at a scheduled time, and that the registration office of the hospital has performed a pre-admit on Mr.Doe, assigning him a unique hospital wide patient ID number. As part of the admitting process, Ms. Anderson enters Mr. Bauer's (new) patient ID number into the system, which retrieves back his demographics. She confirms these with Mr. Bauer as part of the admitting procedure."

MSH|^~\&|KIS||CommServer||200811111017||QRY^A19||P|2.2|
QRD|200811111016|R|I|Q1004|||1^RD|10000437363|DEM|||

Figure A.3 - QRY^A19 message example

The message shown in figure A.3 is a query message (QRY) for a patients' demographics data (DEM) based on the patient ID "10000437363". The query has to be dealt with immediately (I) by the receiving application. The response message may contain a maximum of 1 record (1^RD), the data is to be sent as structured data (R), not in the form of text. An example of a response message is shown in figure A.4.

MSH|^~\&|CommServer||KIS||200811111017||ADR^A19||P|2.2 
MSA|AA 
QRD|200811111016|R|I|Q1004|||1^RD|10000437363|DEM
PID|||10000437363|508003|Bauer^Fritz^^^||19631101|M|||Mercedesstr 12^^Bergheim^^68123^D|||||M|
NK1|1|Bauer^Karin|Ehefrau
PV1||S|CHI1^2W^1^CHI|R||||20 56 344^Antonius^ Markus^^^Dr.med.^^^Königstr. 112^69939^Haarheim/M.
   ^06146^61011|20 56 344^Antonius^Markus^^^Dr.med.^^^Königstr. 112^69939^Haarheim/M.^06146^
   61011|N|||||||||9800703||K|||||||||||||||||||||||200311110928
DG1|1||355.9^355.9 Neuropathie onA^I9|||EL|||||||||1
DG1|2||386.-^386.- Schwindel^I9|||EL|||||||||2
DG1|3||087.9^087.9 Borreliose^I9|||EL|||||||||3
PR1|1||1-502.6^1-502.6 Biopsie durch Inzision am Unterschenkel^ICPM||20031107|P
PR1|2||5-940^5-940 Operationslagerung^ICPM|||P
PR1|3||5-900^5-900 Einfache Wiederherstellung der Kontinuität an Haut und Unterhaut^ICPM|||P
IN1|1|0||NAK|Innenstr. 52 ^^Hannover^^30014||||||||207714 ||10035|Bauer^Fritz||19631101|
   Mercedesstr 12^^Bergheim^^68123

Figure A.4 - ADR^A19 message example

The definition of the response message is as shown in figure A.5. (Note: some segments have been omitted). The contents of the response messages are structured in the same way as other messages in HL7 chapter 3.

ADR^A19^ADR_A19	ADT Response
MSH	Message Header
MSA	Message Acknowledgment
[ERR]	Error
[ QAK ]	Query Acknowledgment
QRD	Query Definition
[ QRF ]	Query Filter
{
PID	Patient Identification
[{ ROL }]	Role
[{ NK1 }]	Next of Kin / Associated Parties
PV1	Patient Visit
[ PV2 ]	Patient Visit - Additional Info.
[{ ROL }]	Role
[{ OBX }]	Observation/Result
[{ AL1 }]	Allergy Information
[{ DG1 }]	Diagnosis Information
[ DRG ]	Diagnosis Related Group
[{
PR1	Procedures
[{ ROL }]	Role
}]
[{ GT1 }]	Guarantor
[{
IN1	Insurance
[ IN2 ]	Insurance Additional Info.
[{ ROL }]	Role
}]
[ ACC ]	Accident Information
}

Figure A.5 - ADR^A19 message definition

Query for observations

An application determines a need for observation data about a patient and sends a query to the lab system. The query for laboratory results (i.e. a QRY^R02 query message with an ORF^R04 response) is used regularly. [HL7ORUQuery]

QRY^R02^QRY_R02	Result Query
MSH	Message Header
QRD	Query Definition
[ QRF ]	Query Filter

Figure A.6 - QRY^R02 message definition

Figure A.5 contains the definition of the observation query message. The query type (QRD-9: What subject filter) contains RES (Query for results).

The query shown in figure A.7 is a query of the EKG system for the data for a particular patient number 0123456-1 for reports that have been modified or created since 1/1/2006.

MSH|^~\&|MyEPA||EKG||||QRY^R02|CDB22222|P|2.2
QRD|200804180943|R|I|Q4412|||10^RD|0123456-1|RES
QRF|EKG||200801010000

Figure A.7 - QRY^R02 message example

This query message (QRY) for results (RES) is based on the patient ID "01234456-1". The query has to be dealt with immediately (I) by the receiving application. The response message may contain a maximum of 10 records (10^RD), the data is to be sent as structured data (R), not in the form of text. A filter specifies that the results should be after a specific date (20030101). An example of a response message is shown in figure A.8 below.

MSH|^~\&|EKG||MyEPA||||ORF^R04|X981672|P   
MSA|AA|CDB22222|P   
QRD|200804180943|R|I|Q4412|||10|RD|0123456-1|RES   
QRF|EKG||200301010000   
PID|1||0123456-1||Nordstein^Peter^H|||||||9821111   
OBR|1|43215^OE|98765^EKG|93000^EKG REPORT|R|200801111000|200801111330|||RMT||||200801111330|-|
   P030||||||200801120930||||||02^126666|A111|Viranyi^Andrew
OBX|1|ST|93000.1^VENTRICULAR RATE(EKG)||91|/MIN|60-100   
OBX|2|ST|93000.2^ATRIAL RATE(EKG)||/MIN|60-100   
OBX|3|ST|93000.3^PR INTERVAL||0|/MSEC|1.06-.10   
OBX|4|ST|93000.4^QRS INTERVAL||.368|/MSEC|.18-.22    
               ...   
OBX|8|CE|93000&IMP^EKG DIAGNOSES|1|^ATRIAL FIBRILATION   
OBX|9|CE|93000&IMP^EKG DIAGNOSIS|2|^ST DEPRESSION  
OBX|10|FT|93000&ADT^EKG COMMENT||\.br\ 1. Ein vergleich mit einem EKG vom 31.10.2002 zeigt, 
   dass die ventrikulär Frequenz um 30 bpm gestiegen ist.\.br\2. Die Kriterien für einen 
   Seitenwandinfarkt sind nich länger gegeben.

Figure A.8 - ORF^R04 message example

---

About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training, mentoring and advice in integration standards and technologies.
See http://www.ringholm.com or call +31 318 589 789 for additional information.