References to other Chapters

7

• 7
  Chapter 7
  • 7.1 PURPOSE
    • 7.1.1 Purpose and Scope
    • 7.1.2 New Record Type
  • 7.2 TRIGGER EVENTS AND MESSAGE DEFINITIONS
    • 7.2.1 ORU Unsolicited Transmission of an Observation
    • 7.2.2 Query for results of observation
  • 7.3 MESSAGE SEGMENTS
    • 7.3.1 OBX - RESULT-/Ergebnis
  • 7.4 A Proposed Coding Scheme for CPT extensions.
  • 7.5 EXAMPLE TRANSACTIONS
    • 7.5.1 Query/Response
      • 7.5.1.1 Query
      • 7.5.1.2 Response
    • 7.5.2 Continuation Query
    • 7.5.3 Unsolicited
  • 7.6 OUTSTANDING ISSUES

7
Chapter 7

7.1 PURPOSE

The Ancillary Data Reporting Transaction Set provides for the transmission of clinical data (of any kind) between an observing service, e.g., clinical laboratory, radiology, nursing service, physician discharge summary, and a requesting service, e.g., ward or clinic.
This chapter defines the "record oriented" transmission of data, e.g., clinical observations. Record oriented "results" are sent as structured records. The receiving system processes these results with "understanding" of the meaning of these fields. This chapter deals with unsolicited data transmission, such as the transmission of clinical observations, e.g., lab results, from a departmental system such as the clinical lab, an obstetrical ultrasound, or admission history/physical to an HIS system. It relates closely to chapter V about queries. The result messages that are sent in the unsolicited mode can also be sent in a query or solicited mode. It also relates to chapter IV, Order Entry. The hierarchy of segments transmitted for orders is a near subset of that transmitted for results.
The order segment (OBR, for Observation Request) is in some sense a turn-around-document. Some of its fields are completed upon order entry, and some are completed upon receipt in the observing service (e.g., Lab) and others upon the completion of observation. The order segment always returns with its associated results as part of a result transmission and the order segment is needed to fully interpret them.
In some cases (e.g., when a package of diagnostic studies is ordered), a single order segment may be burst into many independent order segments in the lab. Each of these separate order segments must be returned with their corresponding result segments as part of a transmission of a report. For example, if a hospital defined a "routine labs" package to be: electrolytes, urinalyses and CBC, the receiving lab system will usually burst the received order segment into 3 order segments, one for each of the contained batteries.
Remember that the Other Order Segment (ORO) (previously Order Detail or ORD), the Observation Order (OBR) (previously LTS), and the Pharmacy Order (RX1) segments are mutually exclusive. One and only one of these may be included with each order.
The definitions given for the observation request and observation results segments are almost identical to those of ASTM 1238-88 with respect to the field contents, order, representation and maximum field lengths of the patient record. The specification of the first 12 patient identifying fields is also nearly identical. In addition we encourage the use of the "universal" test identifiers, (related to the CPT-4 codes) and the conventions for bacterium names given in ASTM 1238-88. (Standard Specifications for transferring Clinical Laboratory Data messages Between Independent Computer Systems. American Society of Testing and Materials, 1916 Race St, Philadelphia, Pa, 19103.)

The results as defined in this chapter can be sent in response to a query or as unsolicited updates. A single report can be sent or reports can be batched.
This chapter defines the transactions at the seventh level, i.e., the abstract messages. Various schemes may be used to generate the actual characters that comprise the messages according to the communications environment. The HL7 Encoding Rules will be used where there is not a complete Presentation Layer. This is described in Chapter 1, "Relationship to Other Protocols." The examples included in this chapter were constructed using the HL7 Encoding Rules.

7.1.1 Purpose and Scope

This document describes a general framework for the transmission of patient specific observation reports. It is intended to cover all types of patient specific data except pharmacy (which is a special case). Examples include radiology reports, EKG reports, surgical pathology reports, discharge summaries, admission history and physical exam, operative notes, clinic encounter notes, nursing data and others.

The initial ASTM-HL7 order and result records accommodated most of the result reporting needs of the clinical laboratory and of diagnostic services with numeric or short text observations. They did not, however, satisfy the requirements of services that generate narrative reports such as nuclear medicine, physician consultants, cardiac echo, obstetrical ultrasound, endoscopy, or surgical pathology. The following describes extensions to ASTM-HL7, designed to accommodate the reporting requirements of such services. These extensions permit the ordering and reporting of almost all clinical information. They do not accommodate scheduling. This will require a separate new segment and effort. For this version the LRS (Lab results) segment has been replaced by the OBX (Results) segment to emphasize that it may be used to report any kind of simple clinical results.

7.1.2 New Record Type

With the new result record type (OBX) defined in this section, one can construct almost any clinical report as a two-level hierarchy, with an order record (OBR) at the upper level and one or more result records at the lower level. One result record (OBX) would be transmitted for each component of a diagnostic report, such as an EKG or obstetrical ultrasound. The description, the diagnostic impression, and the recommendation would each be transmitted as separate "observations" under the order record for the study. If numeric or multiple choice answers were part of a report, these would be sent as additional result records.
For this version of the HL7 Standard, results are transmitted as OBX segments. This replaces the OBS segment of the previous draft and the "R" record type in ASTM 1238.
The principal difference between OBX and the previous result segment is the addition of three fields: VALUE TYPE, OBSERVATION SUB-ID, and PROBABILITY. The VALUE TYPE field defines the structure of the observation result field. If the VALUE TYPE is CE then the result must be a coded entry with the 6 component structure defined in chapter 4, e.g., an ICD9-cm code. If the VALUE TYPE is TX then the result will be bulk text, as might be required to report the narrative description of a chest xray report.
The narrative description of a study would be sent as an "OBX" record type with VALUE TYPE equal to FT (Formatted Text). The diagnostic impression would be sent as a result record type "OBX" with value type equal to CE (coded entry).

7.2 TRIGGER EVENTS AND MESSAGE DEFINITIONS

The triggering events that follow are all served by the ORU (Observational report - Unsolicited) or the ORF (Observational Report Response) messages in combination with ACK and QRY. Each triggering event is listed below, along with the messages exchanged, and the segments that comprise the messages. The notation used to describe the sequence, optionality, and repeating of segments is described in Chapter II, "Format for Defining Abstract Messages."

7.2.1 ORU Unsolicited Transmission of an Observation

ORU Observational Results Unsolicited) Chapter
MSH Message Header II
MSA Message Acknowledgement II
{ [PID Patient Identification III
[{NTE}] Notes and comments II
[PV1] ] Patient Visit III
{[ORC] Order common IV
OBR Observations Report ID VII
{[NTE]} Notes and comments II
{[OBX] Result VII
{[NTE]} Notes and comments II
}
}
}
[DSC] Continuation Pointer

ACK Acknowledgement Chapter
MSH Message header II
MSA Message acknowledgement II

For each patient order (OBR segment) more results may be transmitted depending upon the number of observations generated by the order. Each such result can consist of one or more result segments (OBX). Comments may be transmitted either with the OBR or any of the result segments. The optional PV1 segment is present mainly to permit transmission of patient visit information such as current location with an order.

7.2.2 Query for results of observation

QRY Query Chapter
MSH Message Header II
QRD Query Definition V
QRF Query Filter V

ORF Observational Report Chapter
MSH Message Header II
MSA Message Acknowledgement II
{ QRD Query Definition V
[ QRF ] Query Filter V
[ PID ] PATIENT ID III
[{NTE]}}
{ [ ORC ] Order common
OBR Observation request VII
{[NTE]} Notes and comments II
{[OBX] Result VII
{[NTE]} Notes and comments II
}
}
}
[DSC] Continuation Pointer V

Notes:

Display oriented results reporting is described in Chapter V. The QRD and QRF segments are defined there.

The subject filters contained in the QRD and QRF segments are defined by local agreement between the inquiring system and the ancillary system.

The SET ID fields in the various segments (including PID) are used to denote repetition.

The RESULTS LEVEL field of the QRD determines the amount of data requested. See Chapter V.

It is important to realize that for the database type query "QRY", the WHEN DATA START and WHEN DATA END fields of the QRF refer to the "database" time of the records (when they were last changed, modified, updated, or deleted), not the time of data acquisition or some other time.

7.3 MESSAGE SEGMENTS

The Ancillary Data Reporting segments are defined here. In some cases the comments about fields are longer than the space available for field notes in the HL7 Data Dictionary. In these cases the field notes in this section are annotated with "See Data Notes." The Data Notes section can be found under "Implementation Considerations", below. This section contains the full definition for the OBR segment which is also the order segment for diagnostic studies and clinical observations (see Chapter IV).
SEGMENT: OBR - OBSERVATION REQUEST /Leistungsanforderung

The OBR segment is used to transmit information about the order.

FIELD NOTES: OBR OBSERVATION REQUEST

1. 00520 SET ID - OBSERVATION REQUEST. For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2, and so on.

2. 00732 PLACER ORDER #. This is a composite field. The first subcomponent is a string of up to 15 characters that identifies an individual order segment (e.g., OBR). It is assigned by the placer (ordering system). It identifies an order uniquely among all orders from a particular ordering application. The second subcomponent contains the APPLICATION ID of the placing system. The two subcomponents are separated by a subcomponent delimiter. The APPLICATION ID is a string of up to six(6) characters that will be uniquely associated with an application. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign their APPLICATION ID's.

This field is identical to the field of the same name in the ORC segment (see Chapter IV).

3. 00733 FILLER ORDER #. This is a composite field. The first subcomponent is a string that identifies an individual order segment (e.g., OBR). It is assigned by the order filling (receiving) system. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory).

The second subcomponent is the filler APPLICATION ID. (See PLACER ORDER # field for a definition of the APPLICATION ID).

This field is identical with the field of the same name in the ORC segment (See Chapter IV for details).

The FILLER ORDER # is a permanent identifier for an order and its associated observations.

4. 00523 UNIVERSAL SERVICE IDENT.. This field should contain an identifier code for the requested observation/battery/service. This can be based on local and/or "universal" codes. We recommend the "universal" identifier defined in ASTM 1238-88. See OBX field 3. The structure of this coded entry data type is described in the control section.

5. 00524 PRIORITY. Not used. Previously priority(e.g., STAT, ASAP), but that information is carried as the 6th component of the Timing-quantity field(field 27).

6. 00529 REQUESTED DATE-TIME. Not used. Previously requested date-time. That information is now carried in the 4th component of the TIMING-QUANTITY field (field 27).

7. 00530 OBSERVATION DATE/TIME. (Formerly, Specimen Collection D/T). The actual date and time the observation was obtained from the patient. In the case of a specimen-associated study, this field shall represent the date and time the specimen was collected or obtained. (Results only field except when specimen drawn by placer.)

8. 00531 OBSERVATION END DATE/TIME. This field shall contain the end date and time of a study or timed specimen collection. If an observation takes place over a substantial period of time, it will indicate when the observation period ended. For observations made at a point in time, it will be null. (Results field except when specimen drawn by placer).

9. 00532 COLLECTION VOLUME. For laboratory tests, the volume of a specimen. Default units - ML. Units should be expressed in the ANSI Standard unit abbreviations (ISO-2955,1977). Results only field except when specimen drawn by placer).

10. 00533 COLLECTOR IDENTIFIER. When a specimen is required for the study, this field will identify the person, department, or facility that collected the specimen. Either name of ID code, or both, may be present.

11. 00534 SPECIMEN ACTION CODE. Indicates the action to be taken with respect to the specimens that accompany or precede this order. There is some overlap between this field and the ORDER CONTROL field of the ORC. The field is retained for compatibility with ASTM. There is some overlap between this field and the ORDER CONTROL and STATUS fields of the ORC. This exists for historical reasons and for compatibility with ASTM. The value of this field should be consistent with the ORC fields. If there is incompatibility, the ORC value should be used. Refer to table 0065 for valid entries.

12. 00535 DANGER CODE. This field shall contain a code and/or text indicating any known or suspected specimen hazards, e.g., blood from a hepatitis patient. Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, free text without a code must be preceded by a component delimiter.

13. 00536 RELEVANT CLINICAL INFO.. Additional clinical information about the patient or specimen will be provided here. This field is used to report the suspected diagnosis and clinical findings on requests for interpreted diagnostic studies. Examples include: reporting the amount of inspired dioxide for blood gasses; the point in the menstrual cycle for cervical pap tests; and other conditions that influence test interpretations. For some orders this information may be sent on a more structured form as a series of "result" segment that immediately follow the order segment as described in Chapter IV.

14. 00537 SPECIMEN RECEIVED DATE/TIME. For observations requiring a specimen, the actual login time at the diagnostic service. (Results only field)

15. 00538 SPECIMEN SOURCE. This is a three component field. The first component contains the specimen source name or code (as a CE data type component). (Even in the case of observations whose name implies the source, a source may be required, e.g., blood culture-heart blood.) The second component should include additives to the specimen such as Heparin, EDTA, or Oxlate, when applicable. The third is a free text component describing the method of collection when that information is a part of the order. When method of collection is logically an observation result, it should be included as a result segment. The components of the CE data elements become sub-components of the first component of the SPECIMEN SOURCE field. Refer to table 0070 for valid entries.

16. 00539 ORDERING PROVIDER. The identification of the provider who ordered the test. Either the ID code, or the name, or both may be present. This is the same as field 12 in the ORC.

17. 00540 ORDER CALL-BACK PHONE NUM. A telephone number for reporting a status or a result using the Standard format with extension and/or beeper number when applicable.

18. 00541 PLACERS FIELD #1. User Field #1. Text sent by the placer will be returned with the results.

19. 00542 PLACERS FIELD #2. Similar to Placer field #1.

20. 00543 FILLERS FIELD #1. Field in the order definable for any use by the filler (diagnostic service).

21. 00544 FILLERS FIELD #2. Similar to Filler Field #1.

22. 00546 RESULTS RPT/STATUS CHNG - DATE/TIME. Date-Time Results Reported or Status Changed. This field is used to indicate the date and time the results are composed into either a report and released or when a status, as defined in ORDER STATUS, is entered or changed. (Results field only). When other systems (such as office or clinical database systems) query the laboratory system for untransmitted results, the information in this field may be used to control processing on the communications link. Usually, the ordering service would only want those results for which the reporting date/time is greater than the date/time the inquiring system last received results.

23. 00547 CHARGE TO PRACTICE. This field contains the charge to the ordering entity for the studies performed when applicable. The first component is a dollar amount when known by the filler. The second is a charge code when known by the filler (results only).

24. 00548 DIAGNOSTIC SERV SECT ID. This optional identifier shall denote the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to table 0074 for valid entries.

25. 00734 RESULT STATUS. The status of order per ASTM 1238-88, P-9.4.26. A suggested set of codes is defined in table 0123. Results only field. Refer to table 0123 for valid entries.
26. 00550 LINKED RESULTS. This field is used in microbiology "child results" to contain the name of the micro-organism identified by the parent result. The organism should be identified exactly as it is in the parent culture. This information can alternately be presented in a Standard observation result segment. This field is only present when the parent result is identified by field 29, parent accession number.

27. 00735 QUANTITY/TIMING. This field is used to capture information about how many services to perform at one service time, how often the service times are repeated, and to fix duration of the request. See note A at the end of this section for details.

28. 00551 RESULT COPIES TO. A repeating composite field that identifies the people that are to receive copies of the results. By local convention, either the ID # or name may not be present.

29. 00737 PARENT ACCESSION #. This field is identical to the PARENT # of the ORC segment (see Chapter IV). This field relates a child back to its parent when a parent-child relationship exists. The parent-child mechanism is described under the ORDER CONTROL field notes (see Segment ORC field notes in Chapter IV). PARENT is a two component field. The first component contains the FILLER ORDER # of the parent order. It is required when the order is a child. The second component is optional and contains the PLACER ORDER # of the parent. The components of the PLACER ORDER # and the FILLER ORDER # are transmitted in sub-components of the two components of this field. For example, observations that are spawned by previous observations, e.g., antibiotic susceptibles spawned by blood cultures, need to record the parent (blood culture) FILLERS ORDER # here.

30. 00625 TRANSPORTATION MODE. Used to indicate how (or whether) to transport a patient, when applicable. Refer to table 0124 for valid codes.

31. 00626 REASON FOR STUDY. This is a field which can be sent as code or as text using the conventions for coded fields given in the Control Section (Chapter II). This is required for some studies to obtain proper reimbursement.

32. 00627 PRINCIPAL RESULT INTERPRETER. Record the identity of the physician or other clinician who interpreted the observation and is responsible for the reports content.

33. 00628 ASSISTANT RESULT INTERPRETER. When applicable, record the clinical observer who assisted with the interpretation of this study.

34. 00630 TECHNICIAN. When applicable, this field identifies the performing technician.

35. 00629 TRANSCRIPTIONIST. When applicable, this field identifies the report transcriber.

36. 00736 SCHEDULED - DATE/TIME. When applicable (e.g., action code in field 11 = "S"), record the date/time the filler scheduled an observation. This is a result of a request to schedule a particular test and provides a way to inform the placer of the date/time a study is scheduled (result only).
Note A - Quantity Timing Notes
The quantity-timing field provides a means of specifying when the service described by the order segment is to be performed and how frequently. It is a multi-component field that can have repeats, i.e., more than one quantity-timing specification, separated by repeat delimiters, may appear . The components of a single quantity timing specification are as follows:
1) QUANTITY Indicates the quantity of the service that should be provided at each service interval. E.g, if 2 blood cultures to be obtained q 4 hours, the quantity would be 2. If 3 units of blood are to be typed and cross matched the quantity would be 3. The default value is 1. When units are required they can be added, specified by a subcomponent delimiter.
2) INTERVAL Determines the interval between repeated services. The default is one time only. Suggested codes are given below.
a) Q<integer>S = every <integer> seconds
b) Q<integer>M = every <integer> minutes
c) Q<integer>H = every <integer> hours
d) Q<integer>D = every <integer> days
e) Q<integer>W = every <integer> weeks
f) Q<integer>L = every <integer> month (Lunar cycle)
g) Q<integer>J = repeats on a particular day of the week (from the French word Jure=day). Count week days from 1=Monday through 7=Sunday.
(In the above if <integer> is missing the rate is assumed to be 1)
h) BID = twice a day at institution specified times (e.g., 9AM-4PM)
i) TID = three times a day at institution specified times (e.g., 9AM - 4PM - 9PM)
j) QID = four times/day at institution specified times (e.g., 9AM - 11AM - 4PM - 9PM)
(Note - none of the above are equivalent to their Q<integer>H counterpart. QID is not = Q6H. The former is unequally spaced. The latter is equally spaced)
k) QAM = in the morning at institution specified time
l) QSHIFT = during each of 3 eight hour shifts at institution specified times

m) QOD = every other day
n) QHS = every day before the hour of sleep
o) QPM = in the evening at institution specified time
p) C = service is provided continuously between the start time and the stop time
q) U <spec> = for future, where <spec> is the Service intervals defined/processed by syntax of UNIX crontab
r) Once = one time only. This is also the default when this component is null
3) DURATION Indicates how long the service should continue after it is started. Coded as follows.
S<integer> do for <integer> seconds
M<integer> do for <integer> minutes
H<integer> do for <integer> hours
D<integer> do for <integer> days
W<integer> do for <integer> weeks
L<integer> do for <integer> months
X<integer> do for <integer> times at interval specified in the order.
A request for 2 blood cultures Q2H X3 would imply obtaining 2 blood cultures 3 different times at 2 hour intervals for a total of 6 blood cultures. T<integer> do at the interval and amount stated until a total of <integer> "DOSAGE" is accumulated. Units would be assumed to be the same as in the QUANTITY field. Default do indefinitely INDEF do indefinitely
4) START D/T This may be specified by the orderer, in which case it indicates the earliest D/T at which the services should be started. In many cases, however, the start date timewill be implied, or will be defined by other fields in the order record (e.g., urgency - STAT). In such case this field will be empty.
The filling service will often record a value in this field after receipt of the order however, and compute an end time on the basis of the start date-time for their internal use.
5) END D/T When filled in by the requester of the service, this field should be the latest date-time that the service should be performed. If it has not been performed by the specified time, it should not be performed at all. The requester may not fill in this value, yet the filling service may fill it in on the basis of the instruction they receive and the actual start time.
Regardless of the value of the end date-time, the service should be stopped at the earliest of the date/times specified by either the duration or the end date/time.
6) PRIORITY Describes the urgency of the request. Four values are suggested:
S= Stat. With highest priority.
A= ASAP. Fill after S orders.
R= Routine.
T= Timing critical. This is a request implying that it is critical to come as close as possible to the requested time, e.g., for a trough antibiotic level.
The default for PRIORITY is R.
7) CONDITION Free text description of conditions under which the service should be done, e.g., "PRN pain" or "as needed to control blood pressure".
8) TEXT Full text - as entered - version of the instruction (optional).
9) CONJUNCTION If non-null, indicates that a second timing specification is to follow using the repeat delimiter. This field can take three values:
S Synchronous. Do the next specification after this one (unless otherwise constrained by the START D/T and END D/T).
An "S" specification implies that the second timing sequence follows the first, e.g., when an order is written to measure blood pressure Q15 minutes for the 1st hour, then every 2 hours for the next day.
A Asynchronous. Do the next specification in parallel with this one (unless otherwise constrained by the START D/T and END D/T). The conjunction of "A" specifies two parallel instructions, as are sometimes used in medications. E.g., prednisone given at 1 tab on Mon, Wednes, Fri, and at 1/2 tab on Tues, Thurs, Sat, Sun.
C This is an actuation time. It will be followed by a completion time for the service. This code allows one to distinguish between the time and priority at which a service should be actuated (e.g., blood should be drawn) and the time and priority at which should be completed (e.g., results should be reported).
For continuous or periodic services the point at which the service is actually stopped is determined by the components END D/T, DURATION, whichever indicates an earlier stopping time. Ordinarily, only one of these components would be present, but if one requested an EKG with the following specification:
^1^QAM^X3^D10
then the EKG would be done for only three days since the number of repeats (3) defined the earlier stopping time.
Examples:
3^once
Perform the service at one point in time, e.g., order 3 units of blood to be given once 1^QHS^X2 Perform the service twice at bedtime, e.g., give a unit of blood at bedtime on two sequential nights 1^C^3D Do a service continuously for 3 days
1^Q1H^X4^^^^PVCs>10/min
Perform an EKG every hour up to a maximum of 4 EKGs, if patient is having more than 10 PVCs per minute. 1^/U32 14 * * 3 Perform a service every Tuesday at 2:32 p.m.
1^^^^198911210800
Perform a test before 11/21/89 0800, e.g., some pre-op laboratory tests.
1^Q3600S^X5^198911051030
Perform a service every hour for 5 hours starting at 10:30 am 11/5/89, i.e., draw a blood glucose
1^QAM^X3^^^^^S\1^QOD^4D^^^if K+>5.5.
Perform a service every morning for three times, then do it every other morning for 4 days (i.e., max twice) if the serum potassium is greater than 5.5.
^^^198812120800^^T^^Trough specimen for MIC^C\^^^^^R
Draw a blood specimen exactly at 8:00am on 12/12/1988,and report results routinely.

7.3.1 OBX - RESULT-/Ergebnis

The OBX segment is used to transmit one or more patient results, based on the number of observations generated by the order.

*Length is variable depending upon value table.

FIELD NOTES: OBX RESULT

1. 00559 SET ID - OBSERVATION SIMPLE. Sequence number. For compatibility with ASTM.

2. 00676 VALUE TYPE. This field may be any legitimate HL7 data type within Table 0125.

3. 00560 OBSERVATION IDENTIFIER. Unique identifier for the observation. The format is that of the Coded Element. Example: 93000.3^P-R interval. Bacteria should be reported using nomenclature given in the Manual of Clinical Microbiology, Lenette et al., American Society of Microbiology, Washington, DC 1988.
When local codes are used as the first identifier in this field we strongly encourage sending the universal identifier as well to permit receivers to equivalence results from different providers of the same service(e.g., a hospital lab and commercial lab that provides serum potassium to a nursing home). Currently the universal identifier is a combination of CPT4 codes and extensions developed by ASTM. These cover all of the common test results and physiologic variables (e.g., BP, Pulse) and are available from ASTM(1916 Race St, Philadelphia, PA 19103) or from the REGENSTRIEF INSTITUTE (1001 W. 10th St., 5th floor,Indianapolis, IN 46202).

4. 00769 OBSERVATION SUB-ID. The purpose of this field is to provide a mechanism to distinguish between results that have the same OBSERVATION IDENTIFIER within a given OBR. Thus, the combination of FILLER NUMBER # or PLACER ORDER #, OBSERVATION IDENTIFIER, and this field uniquely identifies a result. Leaving this field null means either changes and deletions happen at the OBR level or that multiple occurrences of the OBSERVATION IDENTIFIER cannot occur in this OBR group, i.e., "battery".

5. 00561 OBSERVATION RESULTS. The length and contents of this field are determined by the VALUE TYPE field. For example, an ECG P-R interval might have a result of 0.08. This field should contain an "atomic" result and should not repeat. However, there is one special circumstance in which it may appear to repeat: when multiple codes are required to define a single result for VALUE TYPE equal to CE.

6. 00562 UNITS. When applicable, the units for numeric results shall appear here. Units should be stated in Standard abbreviation as defined by ISO 2955. units are case insensitive.

7. 00563 REFERENCES RANGE. Numeric values should be reported in the following form: (lower limit-upper limit). e.g., for potassium, 3.5 - 4.5. For alphabetical values, the normal value should be reported, e.g., NEGATIVE.

8. 00564 ABNORMAL FLAGS. A table lookup indicating the normalcy status of the result. If the observation is an antibiotic susceptibility - the interpretation codes are: S=sensitive; R=resists; I=interval; MS=moderately sensitive; VS=very sensitive. (See ASTM 1238 - review for more details). Refer to table 0078 for valid entries.

9. 00639 PROBABILITY. This field reports the probability of a result being true for results with categorical values. It mainly applies to discrete coded results. It is a decimal number represented as an ASCII string that must be between 0 and 1, inclusive.

10. 00565 NATURE OF ABNORMAL TEST. Refer to table 0080 for valid codes.

11. 00566 OBSERV RESULT STATUS. Refer to table 0085 for valid codes.

12. 00567 DATE LAST OBS NORMAL VALUES. . Null if there are no normals or units. If present, a change in this date compared to the receiving system's test dictionary should trigger a manual review of the results to determine whether they are equal to the existing results for the test.

7.4 A Proposed Coding Scheme for CPT extensions.

The following is a proposed coding scheme for CPT4 extensions that is intended to permit arbitrary depth of data while maintaining upward compatibility with previous CPT4 ASTM 1238 extensions.
- Each defined code has an associated record type and data type with which it is allowed to be used. For example the Standard lab test MCV is 85021.11 and is associated with the OBS segment type and consequently the ST data type.
- A complete test code is made up of a primary part plus zero or more fixed-meaning extensions each separated by a subcomponent delimiter (we use and in the example as the subcomponent delimiter).
- Fixed-meaning extensions are those for which the meaning is independent of the preceding primary codes and ordinary extension.
- Fixed-meaning extensions begin with an upper case alpha character.
- The last extension in the code is associated with a data type and this determines the data type of the whole.
- A partial list of fixed-meaning extensions is:
Extension Name Type
IMP Diagnostic Impression CE
REC Recommendation CE
CNP Recommended Confirming Procedure CE
MED Procedure Medication CE
ANT Anatomic Site CE
RDT Readers Description UT
TCM Technician's Comment UT
ADT Addendum UT
ITM Diagnosis Onset Date TS
RTM Diagnosis Resolved Date TS
DEV Device used to produce observation CE

7.5 EXAMPLE TRANSACTIONS

7.5.1 Query/Response

The following is a query the EKG system for the data for a particular patient number 0123456-1 for reports that have been modified or created since 1/1/88.

7.5.1.1 Query

MSH|^\|CBD||EKG|||QRY|CDB22222|P<CR>
QRD|198904180943|R|I|Q4412|||10|RD|0123456-1|RES<CR>
QRF|EKG||198801010000<CR>

7.5.1.2 Response

MSH|^\|EKG||CDB|||ORF|X981672|P<CR>
MSA|AA|CDB22222|P<CR>
QRD|198904180943|R|I|Q4412|||10|RD|0123456-1|RES<CR>
QRF|EKG||198804010000<CR>
PID|7|0123456-1||ROBERTSON^JOHN^H|||||||9821111<CR>
OBR|7|||93000^EKG REPORT|R|198801111000|198801111330|||RMT||||
1988011 11330|?|P030||||||198801120930||||||88-126666
|A111|VIRANYI ^ANDREW<CR>
OBX|1|ST|93000.1^VENTRICULAR RATE(EKG)||91|/MIN|60-100<CR>
OBX|2|ST|93000.2^ATRIAL RATE(EKG)||/MIN|60-100<CR>
OBX|3|ST|93000.3^PR INTERVAL||0|/MSEC|1.06-.10<CR>
OBX|4|ST|93000.4^QRS INTERVAL||368|/MSEC|.18-.22<CR>
...
...
...
OBX|8|CE|93000&IMP^EKG DIAGNOSES||^ATRIAL FIBRILATION<CR>
OBX|9|CE|93000&IMP^EKG DIAGNOSIS||^ST DEPRESSION<CR>
OBX|109|FT||93000&ADT^EKG COMMENT||\.in+4\\.ti-4\ 1. When compared with EKG of 31-oct-88 ventricular rate has increased by 30
bpm.\.sp\\.ti-4\ 2. Criteria for Lateral infarct are no
longer present.<cr>
OBR|2|||93000^EKG REPORT||198810311004|198810311004||||?||| 198810311004|?|P030||||||198810311744||||||88-126689|A122|
BREAL|WILLIAM<CR>
...
...
...
DSC|1896X22;0123456-1<CR>

7.5.2 Continuation Query

MSH|^\|CDB||EKG|||QRY|CDB22289|P<CR>
QRD|198904180943|R|I|Q4412|||10|RD|0123456-1|RES<CR>
QRF|EKG||1988040100000<CR>
DSC|1896X22;0123456-1<CR>

CONTINUATION:
MSH|^\|EKG||CDB|||ORF|X981672|P<CR>
MSA|AA|CDB22289|P<CR>
QRD|198904180943|R|I|Q4412|||10|RD|0123456-1RES<CR>
QRF|EKG||198804010000<CR>
PID||0123456-1||ROBERTSON^JOHN^H|||||||9821111<CR>
OBR| ...
...
...
...

7.5.3 Unsolicited

The following is an unsolicited transmission of radiology data.
MSH|^\|XRAY||CDB|||ORU|K172|P<CR>
PID|1|0123456-1||ROBERTSON^JOHN^H|||||||9821111<CR>
OBR|1|X89-1501|71020^CHEST XRAY AP & LATERAL|R|198703291530|
19873290800|||JBM|N <CR>
OBX|1|CE|71020&IMP^RADIOLOGIST'S IMPRESSION|^MASS LEFT LOWER
LOBE|||A<CR>
OBX|2|CE|71020&IMP||^INFILTRATE RIGHT LOWER LOBE|||A<CR>
OBX|3|CE|71020&IMP||^HEART SIZE NORMAL|||N<CR>
OBX|4|FT|71020&GDT||circular density (2 x 2 cm) is seen in the
posterior segment of the LLL. A second, less well-defined
infiltrated circulation density is seen in the R mid lung
field and appears to cross the minor fissure#<CR>
OBX|5|CE|71020&REC||71020^Follow up CXR 1 month||30-45|<CR>

7.6 OUTSTANDING ISSUES

1. We have not completed universal code extensions for many diagnostic studies.

2. The issue of corrected reports and where to put the ID, date, and reason for the correction is not yet finalized. For now users could record the previous result, the date and time it was corrected, who corrected it, and the reason in a comment (NTE) record following the corrected result.