This chapter defines three messages. The first is a generalized Query Message
intended to support most types of queries between two systems. The second is a
generalized Response Display Message where the responding system formats the
data for direct output to a display. The third is the unsolicited version of
the generalized Response display message. (It is acknowledged by a generic ACK
message.)
The following represents typical examples of queries supported by the
Standard:
For data regarding a single patient, e.g., send all lab results for patient
#123456.
For data regarding multiple patients, e.g., send the list of patients whose
attending physician is Dr. #123.
For data that is not patient related, e.g., send the age specific normal values
for serum protein.
The variety of potential queries is almost unlimited. There was no attempt
here to define a Standard that would cover every possible query. Instead, the
Standard embraces the most common queries that are likely to occur in a
hospital. For each common query there is a corresponding unsolicited
update.
In particular, there is no implication that a specific system must support
generalized queries to comply with the Standard. Rather, these transactions
provide a format, or a set of tools to support queries to the extent desired by
the institution. The resources available and local policies will influence the
type of queries that are implemented.
It is anticipated that there will be a future message segment that will
accommodate a much more powerful query language-type query, probably based on
SQL. See discussion on this topic under "Outstanding Issues."
The response to queries can be:
- Data in a format suitable for display purposes ("display oriented data"),
or
- Data in a format which explicitly denotes field content ("record
oriented").
The Display Response Message below describes the display oriented type of
response. The content and format of record oriented responses to queries
require functionally specific capabilities. The committees responsible for
functionally specific chapters define them within those chapters.
Responses to queries can be either immediate or deferred. The query describes
this as the expected response time. In the immediate mode, the responding
process gives the response immediately or in a short period during which the
requesting process will wait for the response.
One use of queries is to retrieve data from one application for presentation to
users of another. This approach might be used for users of a patient care
system retrieving data from lab or other ancillaries. It also might permit
users of a pharmacy system to retrieve a patient's lab results from the lab
system or non-pharmacy order data from the patient care system. Almost any
other application system could be the source of data or the system initiating
the query for its users.
Of particular interest is the case where the enquiring user formulates the
query on-line at the terminal of one system and waits while that system sends
the query to another. He gets the response and displays it at their terminal.
When the user is formulating such a query she may only have limited
understanding of what data is available for a given patient. Sometimes the
user's preference would be to make a simple query such as "give me recent data
in reverse chronological sequence" rather than "give me data for yesterday,"
since there may be some data available for today, or there may be data from two
days ago that is of interest. The user will look at the data returned and
simply quit looking at it after he or she has found the part that is of
interest. (The time frames or the sort sequence may differ, or the user may
wish to impose some selectivity on the response, but the general principle
remains the same. The user would prefer to make a vague statement of the
interest, have the data presented in order of decreasing likelihood of
interest, and quit when he or she has seen enough.)
While beneficial to the user, this way of requesting data could be very
burdensome when the resulting query takes place over an inter-application
interface. If the responding system were to retrieve, format, and send all the
data the user might like to see, the processing load would be extremely high
and the response time unacceptable.
The continuation query provides a way to permit the users to formulate queries
loosely while limiting the processing burden on the responding system. The
initial query specifies the general constraints of the query and an amount of
data to be returned. (For example, the query might be for lab results for
patient #12379 and 44 lines would be requested.) The responding system
retrieves and formats the specified amount of data and returns it with a
special key field called the continuation pointer. The initiating
system presents the requested data to the user and retains the continuation
pointer field. The internal structure of the value is not known to the
initiating system.
If, after viewing the data, the user requests more, the initiating system sends
the query again in a format that is identical with the first, except that the
continuation pointer field value is included and the requested amount of data
may be changed. The responding system uses the continuation pointer field as a
key into its database to continue retrieval and formatting of the results. If
the user does not request more data, no further messages are exchanged.
Often the lines of display text will fall into logical groups that differ from
the physical size of screen or printer page. For example, a complete battery
or an entire radiology report might be thought of as comprising a logical
group, though they might have as few as six or as many as 120 lines. Knowledge
of the logical break points in the display data can be useful to the
application system that is displaying or printing data. For this reason the
Logical Break Point data field is included in the Display Data (DSP) segment.
The sending application (the one that formats the data) places the logical
break points where appropriate. If there is a particular ancillary result ID
associated with the data delineated by the Logical Break Point, the value of
this ID also can be returned inthe DSP segment. Then if the user selects the
area of the display delineated by the logical break point, the displaying
system can query for the associated result ID.
These are the trigger events associated with queries:
(1) a need occurs for immediate access to data that may be available from
another application, this may be an initial request for data or a
continuation
(2) a need occurs for deferred access to data that may be available from
another application
When display data is involved, these trigger events are served by the Query
(QRY) and Display Response (DSR) and ACK messages. When the query is for
record oriented data, the QRY message is used, but the response message is
specific to a functional area. Record oriented queries are described in other
chapters. Display oriented queries are described here.
Each triggering event is listed below, with the applicable form of the message
exchange. The notation used to describe the sequence, optionality, and
repeating of segments is described in Chapter II, "Format for Defining Abstract
Messages."
QRY Query Message Chapter
MSH Message Header II
QRD Query Definition V
[ QRF ] Query Filter V
DSC Continuation Pointer V
DSR Display Response Message Chapter
MSH Message Header II
MSA Message Acknowledgement II
QRD Query Definition V
[ QRF ] Query Filter V
{ DSP } Display Data V
DSC Continuation Pointer V
The QRF and QRD segments from the QRY are echoed back in the response. The DSC
segment contains the Continuation Pointer (if any).
For clarity, A is the system initiating the query and B is the system sending
the responses. Multiple queries and responses are permitted within single
messages. The responses to a given query may be broken into several separate
DSR messages. A single DSR message may contain responses to more than one QRY.
QRY (A to B) Query Message Chapter
MSH Message Header II
QRD Query Definition V
[ QRF ] Query Filter V
DSC Continuation Pointer V
MCF (B to A) General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
DSR (B to A) Display Response Message Chapter
MSH Message Header II
QRD Query Definition V
[ QRF ] Query Filter V
{ DSP } Display Data V
DSC Continuation Pointer V
ACK (A to B) General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
There is simple extension to the DSR message usage that allows for unsolicited
update display messages to be sent in HL7 format from one system to another.
Trigger events for the unsolicited update are generally the completion of a
particular action (concerning a given patient). For example, a lab test might
be completed, generating a STAT unsolicited display message to be sent to the
appropriate location.
The display message can be generated to fit a variety of needs for unsolicited
updates between systems. These are situations where the update information
does not need to be captured by the receiving system's database, but only
displayed, either on a visual medium (such as a pc or a crt) or on printed
medium.
The extension consists of:
UDM Unsolicited Display Message Chapter
MSH Message Header II
URD Results/update definition V
[ URS ] Results/update selection criteria V
{ DSP } Display data V
DSC Continuation Pointer V
ACK General Acknowledgement Chapter
MSH Message Header II
MSA Message Acknowledgement II
Note that the UDM message can be continued in a manner analogous to that of the
DSR message, by use of the DSC segment and the continuation pointer field in
the MSH. Thus if a UDM needed to be continued as 3 separate UDM messages, the
first message would contain:
MSH (no continuation pointer)
...
...
...
...
DSC (with continuation pointer)
The second message would contain:
MSH (continuation pointer (to first message))
...
...
...
...
DSC (with continuation pointer)
The last message would then contain:
MSH (continuation pointer (to second message))
...
...
...
...
(no DSC, since last)
Note that this scheme works equally well with non-display messages, such as the
Unsolicited Update ORU message (see chapter 7).
Since these are unsolicited messages, intervening messages (from other systems)
may be sent to the receiving application while the sections of the particular
message are being continued. The continuation pointer field in the MSH segment
enables the receiving system to keep track of extraneous intervening messages.
The HL7 query also can be used to query for a batch in the following manner:
a. Use the value BB or BL of the "Deferred Response Type" (field 5) of the QRD
segment to specify a batch response. The query will be acknowledged with a
general acknowledgement as in the "Deferred Access" example above.
b. In addition, insert into the batch file the QRD and QRF segments as
follows:
[FHS] (file header segment)
{ [BHS] (batch header segment)
[QRD] (the QRD and QRF define the
[QRF] query that this batch
is a response to)
{ MSH (one or more HL7 messages)
....
....
....
}
[BTS] (batch trailer segment)
}
[FTS] (file trailer segment)
c. The acknowledgement of a batch is described in Chapter II.
The DSC segment is used in the continuation protocol.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
60 |
ST |
00167 |
CONTINUATION POINTER |
FIELD NOTES: DSC CONTINUATION POINTER
1. 00167 CONTINUATION POINTER. See description of "Continuation Fields" in
Chapter V. In an initial query, this field is null. If the responder returns a
value of null or "not present", then there is no more data to fulfill any
future continuation requests.
The DSP segment is used to contain data that has been preformatted by the
sender for display. The semantic content of the data is lost; the data is
simply treated as lines of text.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
4 |
SI |
00570 |
SET ID - DISPLAY DATA | |||
2 |
4 |
SI |
00571 |
DISPLAY LEVEL | |||
3 |
300 |
TX |
R |
00153 |
DATA LINE | ||
4 |
2 |
ST |
00154 |
LOGICAL BREAK POINT | |||
5 |
20 |
TX |
00599 |
RESULT ID |
FIELD NOTES: DSP DISPLAY DATA
1. 00570 SET ID - DISPLAY DATA. Used optionally to number multiple display
segments. See comments in text on relationship of SET ID and DISPLAY LEVEL.
2. 00571 DISPLAY LEVEL. Individual sites or applications may assign numbering
to define groups of data elements.
3. 00153 DATA LINE. This field contains an actual line as it should be
displayed. As described for the TX data type, highlighting and other special
display characteristics may be included.
4. 00154 LOGICAL BREAK POINT. Non-null if this line is the last line of a
logical break point in the response as defined by the responding system. See
discussion of "Logical Data Groups" in the text.
5. 00599 RESULT ID. If the user selects a result (defined by the logical break
point field) from the screen display corresponding to a record in which the
RESULT ID field is non-null, the application can initiate a second query (a
separate session) to the ancillary with the "What department data code" filled
in with this non-null value (e.g., the ancillary accession number or its
equivalent). The ancillary response will contain the report referenced by this
accession number. The ancillary should correlate the RESULT ID with the
"LOGICAL BREAK POINT" field as follows: If more than one line of text is sent
per result, theRESULT ID field should be only non-null for a DSP segment that
contains a non-null LOGICAL BREAK POINT. This field may be broken into
components by local agreement. A common example might be to include ORDER
NUMBER, FILLER ORDER NUMBER, and UNIVERSAL SOURCE IDENTIFIER. Whenever such
fields are used as components of the RESULT ID, their components will be sent
as subcomponents.
The QRD segment is used to define a query.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
19 |
TS |
R |
00156 |
QUERY DATE/TIME | ||
2 |
1 |
ID |
R |
0106 |
00158 |
QUERY FORMAT CODE | |
3 |
1 |
ID |
R |
0091 |
00159 |
QUERY PRIORITY | |
4 |
10 |
ST |
R |
00160 |
QUERY ID | ||
5 |
1 |
ID |
0107 |
00161 |
DEFERRED RESPONSE TYPE | ||
6 |
19 |
TS |
00162 |
DEFERRED RESPONSE DATE/TIME | |||
7 |
5 |
CQ |
R |
0126 |
00164 |
QUANTITY LIMITED REQUEST | |
8 |
20 |
ST |
R |
Y |
00168 |
WHO SUBJECT FILTER | |
9 |
3 |
ID |
R |
Y |
0048 |
00169 |
WHAT SUBJECT FILTER |
10 |
20 |
ST |
R |
Y |
00170 |
WHAT DEPARTMENT DATA CODE | |
11 |
20 |
ST |
Y |
00171 |
WHAT DATA CODE VALUE QUAL. | ||
12 |
1 |
ID |
0108 |
00701 |
QUERY RESULTS LEVEL |
FIELD NOTES: QRD QUERY DEFINITION
1. 00156 QUERY DATE/TIME. Date the query was generated by the application
program.
2. 00158 QUERY FORMAT CODE. Refer to table 0106 for valid codes.
TABLE 0106 QUERY FORMAT CODE
------------------------------------------------------------
VALUE DESCRIPTION
D Response in display format
R Response in Record-oriented format
3. 00159 QUERY PRIORITY. The time frame in which the response is expected.
Refer to table 0091 for valid codes. Table values and subsequent fields specify
time frames for response.
TABLE 0091 QUERY PRIORITY
------------------------------------------------------------
VALUE DESCRIPTION
D Deferred
I Immediate
4. 00160 QUERY ID. Unique identifier for the query. Assigned by the querying
application. Returned intact by the responding application.
5. 00161 DEFERRED RESPONSE TYPE. Refer to table 0107 for valid entries.
TABLE 0107 DEFERRED RESPONSE TYPE
------------------------------------------------------------
VALUE DESCRIPTION
B Before the DATE/TIME specified
L Later than the DATE/TIME specified
6. 00162 DEFERRED RESPONSE DATE/TIME. The date/time before or after which to
send a deferred response. If not present, the response can be sent when its
available. (See Deferred Response Type above).
7. 00164 QUANTITY LIMITED REQUEST. The maximum length of the response that can
be accepted by the requesting system. Valid responses are numerical values
given in the units specified in the second component. Refer to table 0126 for
valid entries. Default is LI lines.
TABLE 0126 QUANTITY LIMITED REQUEST
------------------------------------------------------------
VALUE DESCRIPTION
CH Characters
LI Lines
PG Pages
RD Records
ZO Locally defined.
8. 00168 WHO SUBJECT FILTER. Identifies the subject, or who the inquiry is
about.
9. 00169 WHAT SUBJECT FILTER. Describes the kind of information that is
required to satisfy the request. Valid codes are the type of transaction
inquiry.
TABLE 0048 WHAT SUBJECT FILTER
------------------------------------------------------------
VALUE DESCRIPTION
ADV Advice/Diagnosis
ANU Nursing Unit Lookup
APN Patient name lookup
APP Physician Lookup
CAN Cancel. Used to cancel a query
DEM Demographics
FIN Financial
MRI Most recent inpatient
MRO Most recent outpatient
ORD Order
OTH Other
PRO Procedure
RES Result
STA Status
10. 00170 WHAT DEPARTMENT DATA CODE. Possible contents include test number,
procedure number, drug code, item number, order number, etc. The contents of
this field are determined by the contents of the previous field. This field
could contain multiple occurrences separated by repetition delimiters.
11. 00171 WHAT DATA CODE VALUE QUAL. What data code value qualifier. A window
or range to further refine the inquiry. This field would contain start/stop
separated by component separators.
12. 00701 QUERY RESULTS LEVEL. Used to control level of detail in results.
Refer to table 0108 for valid codes. See chapters IV and VII.
TABLE 0108 QUERY RESULTS LEVEL
------------------------------------------------------------
VALUE DESCRIPTION
O Order plus order status
R Results without bulk text
S Status only
T Full Results
The QRF segment is used with the QRD segment to refine the content of a query
further.
SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME
--- --- -- --- ---- ---- ----- --------------------------------
1 20 ST R Y 00173 WHERE SUBJECT FILTER
2 19 TS 00174 WHEN DATA START DATE/TIME
3 19 TS 00176 WHEN DATA END DATE/TIME
4 20 ST Y 00178 WHAT USER QUALIFIER
5 20 ST Y 00179 OTHER QRY SUBJECT FILTER
FIELD NOTES: QRF QUERY FILTER
1. 00173 WHERE SUBJECT FILTER. Identifies the department, system, or subsystem
to which the query pertains. This field may repeat as in "LAB^HEMO", etc.
2. 00174 WHEN DATA START DATE/TIME. Data representing dates and times equal or
after this value should be included.
3. 00176 WHEN DATA END DATE/TIME. Data representing dates and times the same as
or before this date should be included.
4. 00178 WHAT USER QUALIFIER. An identifier to further define characteristics
of the data of interest.
5. 00179 OTHER QRY SUBJECT FILTER. A filter defined locally for use between
two systems. This filter uses codes and field definitions which have specific
meaning only to the applications and/or site involved.
The URD segment is used in sending unsolicited updates about orders and
results. It is almost identical with the QRD segment.
SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME
--- --- -- --- ---- ---- ----- --------------------------------
1 19 TS 00600 R/U DATE/TIME
2 1 ID 0109 00601 REPORT PRIORITY
3 20 ST R Y 00602 R/U WHO SUBJECT DEFINITION
4 3 ID Y 0048 00603 R/U WHAT SUBJECT DEFINITION
5 20 ST Y 00605 R/U WHAT DEPARTMENT CODE
6 20 ST Y 00607 R/U DISPLAY/PRINT LOCATIONS
7 1 ID 0108 00702 R/U RESULTS LEVEL
FIELD NOTES: URD RESULTS/UPDATE DEFINITION
1. 00600 R/U DATE/TIME. Date the update was generated by the application
program.
2. 00601 REPORT PRIORITY. The priority associated with this report or update.
Refer to table 0109 for valid codes.
TABLE 0109 REPORT PRIORITY
------------------------------------------------------------
VALUE DESCRIPTION
R Routine
S Stat
3. 00602 R/U WHO SUBJECT DEFINITION. Definition of the subject, or who the
report is about.
4. 00603 R/U WHAT SUBJECT DEFINITION. Describes the kind of information that
is provided in the report. Valid codes are the type of transaction inquiry.
Refer to table 0048 for valid codes.
TABLE 0048 WHAT SUBJECT FILTER
------------------------------------------------------------
VALUE DESCRIPTION
ADV Advice/Diagnosis
ANU Nursing Unit Lookup
APN Patient name lookup
APP Physician Lookup
CAN Cancel. Used to cancel a query
DEM Demographics
FIN Financial
MRI Most recent inpatient
MRO Most recent outpatient
ORD Order
OTH Other
PRO Procedure
RES Result
STA Status
5. 00605 R/U WHAT DEPARTMENT CODE. Possible contents include test number,
procedure number, drug code, item number, order number, etc. The contents of
this field are determined by the contents of the previous field. This field
could contain multiple occurrences separated by repetition delimiters.
6. 00607 R/U DISPLAY/PRINT LOCATIONS. A list of the locations to which the
report should be distributed.
7. 00702 R/U RESULTS LEVEL. Used to control level of detail in results. Refer
to table 0108 for valid codes. Default level is T for full results. See
Chapters IV and VII.
TABLE 0108 QUERY RESULTS LEVEL
------------------------------------------------------------
VALUE DESCRIPTION
O Order plus order status
R Results without bulk text
S Status only
T Full Results
The URS segment is identical with the QRF segment, except that, if the name of
any field contains "Query" (of "QRY"), this word has been changed to "Results"
(See field 5).
SEQ LEN DT R/O RP/# TBL# ITEM# ELEMENT NAME
--- --- -- --- ---- ---- ----- --------------------------------
1 20 ST R Y 00608 R/U WHERE SUBJECT DEFINITION
2 19 TS 00609 R/U WHEN DATA START DATE/TIME
3 19 TS 00610 R/U WHEN DATA END DATE/TIME
4 20 ST Y 00611 R/U WHAT USER QUALIFIER
5 20 ST Y 00612 R/U OTHER RESULTS SUBJECT DEFINI
FIELD NOTES: URS UNSOLICITED SELECTION
1. 00608 R/U WHERE SUBJECT DEFINITION. Identifies the department, system, or
subsystem to which the result pertains. This field may repeat as in "LAB^HEMO",
etc.
2. 00609 R/U WHEN DATA START DATE/TIME. Date/time the result starts. (if
applicable).
3. 00610 R/U WHEN DATA END DATE/TIME. Date/time the result ends. (if
applicable).
4. 00611 R/U WHAT USER QUALIFIER. An identifier to define further the
characteristics of the data that are of interest.
5. 00612 R/U OTHER RESULTS SUBJECT DEFINITION. A further qualifier defined
locally for use between two systems. This filter uses codes and field
definitions that have specific meaning only to the application and/or site
involved.
Query for all lab results on patient #12233. The query is made at 11:00 a.m.,
9/11/87. The Query anticipates an immediate display-oriented response.
MSH|^~\|ICU||LAB01|||QRY|MSG00001|P|2.1<CR>
QRD|198709111012|D|I|4387|^Q0I||20^LI|12233|RES|ALL<CR>
The response to the above query might look like the following:
MSH|^~\|LAB01||ICU|||DSR|ZXT23461|P|2.1<CR>
MSA|AA|MSG00001P<CR>
QRD|198709111012|D|I|4387|||20|^LI|12233|RES|ALL<CR>
DSP|||RESULTS FOR PATIENT#12233 SMITH, JOHN H. 09/11/87<CR>
DSP|||SPECIMEN#H85 COLLECTED 09/11/87 /07/0/0<CR>
DSP<CR>
DSP|||ELECTROLYTES<CR>
DSP||| SODIUM 140 [135-148] MEQ/L STAT<CR>
DSP||| POTASSIUM 4.0 [3.5-5.0] MEQ/L STAT<CR>
DSP||| CHLORIDE 89 [95-111] MEQ/L STAT<CR>
DSP||| CO2 20 [20-30] MEQ/L STAT<CR>
DSP||||LB<CR>
DSP|||CBC<CR>
DSP||| HEMOGLOBIN [13.5-18.0]<CR>
DSP||| HEMATOCRIT 45 [40-54] %<CR>
DSP||| RED CELL COUNT 5.0 [4.6-6.2] M/MM3<CR>
DSP||| MCHC 32 [32-36] G/DL<CR>
DSP||| MCH 28 [26-32] PG<CR>
DSP||| MCV 85 [81-101] FL<CR>
DSP||| WHITE CELL CNT 7.5 [5.0-10.0] K/MM3<CR>
DSP||||LB<CR>
DSP|||SPECIMEN#B24 COLLECTED 9/10/87<CR>
DSC|12333H85;12<CR>
A continuation query would echo back the contents of the Continuation Pointer
in the DSC segment:
MSH|^~\|ICU||LAB01|||QRY^Q01|MSG00003|P|2.1<CR>
QRD|198709111012|D|I|4387|||20^LI|12233|RES|ALL<CR>
DSC|12333H85;12<CR>
This response shows that there is no further data by leaving the Continuation
Pointer not present. This could be done by sending the DSC segment id with no
data, but the example does the same thing by totally omitting the DSC
segment.
MSH|^~\|LAB01||ICU|||DSR|ZXT23469|P|2.1<CR>
MSA|AA|MSG00003|<CR>
QRD|198709111012|D|I|4387|||20|^LI|12233|RES|ALL<CR>
DSP|||RESULTS FOR PATIENT#12233 SMITH, JOHN H. 09/11/87<CR>
DSP|||SPECIMEN#H85 COLLECTED 09/10/87 /07/0/0<CR>
DSP<CR>
DSP|||ELECTROLYTES<CR>
DSP||| SODIUM 136 [135-148] MEQ/L STAT<CR>
DSP||| POTASSIUM 4.2 [3.5-5.0] MEQ/L STAT<CR>
DSP||| CHLORIDE 91 [95-111] MEQ/L STAT<CR>
DSP||| CO2 25 [20-30] MEQ/L STAT<CR>
DSP||||LB<CR>
1. The particular allowable values for the filters in the QRD and QRF segments
are determined among cooperating applications during implementation.
2. The format chosen for the query segments are very general. This might be
read by prospective implementors to imply that the requirement for using the
Standard is the ability to respond to a wide variety of inquiries. This is not
the intent. The format here can be used with specific restrictions in any
interface.
1. SQL is an emerging Standard for formulating general purpose queries. It may
serve as a replacement for the "Who/What Filter" approach used herein. There
are considerable theoretical and practical obstacles that must be overcome,
however. The benefits of SQL may be realized by forming a conceptual model of
the data structure of applications and using this model as a basis for SQL
queries. Members of the Query/Response committee will explore this approach.