Chapter Chair/Editor: |
Clement
J. McDonald, MD |
Chapter Chair/Editor: |
Hans
Buitendijk |
Chapter Editor: |
Helen
Stevens |
Editor: Clinical Trials |
Susan
Rea Welch |
Editor: Product Experience |
J.
Marc Overhage, MD, PhD |
Editor: Product Experience |
Robert
Heiser |
Editor: Waveform Data |
Fritz
Friedhoff |
Editor: Waveform Data |
Ernie
Jacobs, MD |
Editor: Waveform Data |
Wayne
Tracy |
Editor: Waveform Data |
Terry
Lagerlund |
This
chapter describes the transaction set required for sending structured
patient-oriented clinical data from one computer system to another. A common
use of these transaction sets will be to transmit observations and results of
diagnostic studies from the producing system (e.g., clinical laboratory system,
EKG system) (the filler), to the ordering system (e.g., HIS order entry,
physician's office system) (the placer). However, the transaction set is not
limited to such transactions. Observations can be sent from producing systems
to archival medical record systems (not necessarily the order placer) and from
such medical record systems to other systems that were not part of the ordering
loop, e.g., an office practice system of the referring physician for inpatient
test results ordered by an inpatient surgeon. This chapter also provides
mechanisms for registering clinical trials and methods for linking orders and
results to clinical trials and for reporting experiences with drugs and
devices. These transaction sets permit the transmission of any kind of clinical
observations including (but not limited to) clinical laboratory results, the
results of imaging studies (excluding the image), EKG pulmonary function
studies, measures of patient status and condition, vital signs, intake and
output, severity and/or frequency of symptoms, drug allergies, problem lists,
diagnostic lists, physician and nursing history, physicals, progress notes,
operative notes and so on. An observation can be one of many data types. The
main ones are text, numbers and codes. This provides the flexibility needed to
transmit observations that are recorded as continuous values (e.g., glucose,
diastolic blood pressure), as categorical values, e.g., patient position
(sitting, reclining or standing), VDRL (reactive, weakly reactive or
nonreactive), or as text. An entire History and Physical could be transmitted
as an observation whose value is one large chunk of formatted text.
This chapter provides mechanisms for transmitting structured,
record-oriented reports. This means that individual observations are
transmitted as separate logical entities (objects), and within this entity,
separate fields are defined for identifying the observation, its values, its
units, normal ranges, etc., such that the receiving system can "understand,"
reorganize and/or react to the contents of these messages. Structured reports
are to be distinguished from text-oriented reports which can also be
transmitted via HL7 using the UDM message described in Chapter 2. The latter
are ASCII images of nonstandard printed reports intended for display to humans.
For practical purposes their contents are not understandable to the computer.
Observations may be transmitted in a solicited (in response to a query) or
unsolicited mode. In the solicited mode, a user requests a set of observations
according to criteria transmitted by the user. The sending system responds with
existing data to satisfy the query (subject to access controls). Queries do
not elicit new observations by the target system, they simply retrieve old
observations. (See Chapter 2 for full discussion of the query
transmission.)
The unsolicited mode is used primarily to transmit the values of new
observations. It is the mode used by producing services to return the values of
observations requested by an ordering system. A laboratory system, for
example, would usually send the results of an AM electrolytes to the ordering
HIS via the unsolicited mode. An intensive care system would send the blood
pressures to the same HIS by the same mode. Calling such transactions
unsolicited may sound like a misnomer, but is not. The placing service
solicits the producing service to make the observation. It could also (through
a query) solicit the value of that observation after it has been made.
However, such an approach would demand continuous polling of the producing
system until the result was produced. Using the unsolicited mode, the
producing service returns the value of an observation as soon as it is
available. The unsolicited mode can also be used to transmit new results to a
system (e.g., an archival medical record system) that did not order the
observation. The transactions that define these modes are more fully described
in Section7.2, "Trigger Events & Message Definitions."
Observations are usually ordered and reported as sets (batteries) of many
separate observations. Physicians order electrolytes (consisting of sodium,
potassium, chloride, bicarbonate) or vitals (consisting of diastolic blood
pressure, systolic blood pressure, pulse, and temperature). Moreover, tests
that we may think of as single entity, e.g., cardiac echo, usually yield
multiple separate measurements, e.g., left ventricular diameter, left atrial
diameter, etc. Moreover, observations that are usually reported as text (e.g.,
the review of systems from the history and physical) can also be considered a
set of separately analyzable units (e.g., cardiac history, pulmonary history,
genito-urinary history, etc.). We strongly suggest that all text clinical
reports be broken down into such separate analyzable entities and that these
individual entities be transmitted as separate OBX segments. Because many
attributes of a set of observations taken at one time will be identical, one
OBR segment serves as a header for the report and carries the information that
applies to all of the individual observations in the set. In the case of
ordered observations, the OBR segment is a "turn-around document" like the
manual request forms it replaces. It carries information about the order to
the producing service; a copy of the OBR with additional fields completed is
returned with the observations to the requesting service.
Not all observations are preceded by an order. However, all observations
whether explicitly ordered or initiated without an order are reported with an
OBR segment as the report header.
The major segments (OBR, OBX) defined in this chapter, their fields, and the
code tables have been defined in collaboration with ASTM E31.11 with the goal
of keeping HL7 observation transmission the same as ASTM E1238 in pursuit of
the goals of ANSI HISPP and the Message Standards Developers Subcommittee.
(Some sections of this chapter have been taken with permission directly from
the E1238-91 document and vice versa in pursuit of those goals).
The OBR segment provides information that applies to all of the observations
that follow. It includes a field that identifies a particular battery (or
panel or set) of observations (e.g., electrolytes, vital signs or Admission
H&P). For simplicity we will refer to the observation set as the battery.
The battery usually corresponds to the entity that is ordered or performed as a
unit. (In the case of a query, observation sets may be a more arbitrary
collection of observations.) The OBX segment provides information about a
single observation, and it includes a field that identifies that single
observation (e.g., potassium, diastolic blood pressure or admission diagnosis).
Both of these fields assume master tables that define coding systems (the
universe of valid identifying codes) for batteries and observations,
respectively. These tables will usually be part of the producing and sending
services application and (usually) include many other useful pieces of
information about the observation or battery. Segments for transmitting such
master file information between systems that produce and systems that use
clinical information are described in Chapter 8.
This Standard does not require the use of a particular coding system to
identify either batteries or single observations In the past, local
institutions tended to invent their own unique code systems for identifying
test and other clinical observations because standard codes were not available.
Such local code systems sufficed for transmitting information within the
institutions but presented high barriers to pooling data from many sources for
research or for building medical record systems. However, standard code systems
such as LOINC® and SNOMED now exist for many of these purposes, and we
strongly encourage their use in observation reporting. These codes can be sent
either as the only code or they can be sent along with the local historic code
as the second code system in a CE code.
In past versions of the HL7 standard, Appendix A to Chapter 7 presented
suggestions for constructing clinical codes from existing procedure code
systems such as CPT4. Appendix A is now part of the Implementation Guide and
contains LOINC® codes for most laboratory tests and many common clinical
variables and codes for reporting observations from the laboratory, 12-lead
EKG, cardiac echoes, obstetrical ultrasounds, radiology reports, history and
physical findings, tumor registries, vital signs, intake and outputs, and more.
The most recent version of the LOINC® database, which includes records for
more than 26,000 observations and includes codes, names, synonyms and other
attributes (such as the molecular weights of chemical moieties) for each
observation, is available from the Regenstrief Institute file server at
http://www.regenstrief.org/loinc/loinc.htm . Codes for
Neurophysiologic variables (EEG, EMG, Evoked potentials) are provided in
Appendix X2 of ASTM E1467. Some parts of this document (the discussion and
tables defining units, the discussion of the rules of mapping observations to
OBX segments, and some of the examples at the end of the chapter have been
copied (with permission) from ASTM E1238.
As is true throughout this Standard, the emphasis should be on the abstract
messages, defined without regard to the encoding rules. The example messages,
however, are based upon the HL7 encoding rules.
Following this Purpose and general information section, the remainder of this chapter is organized into four main subject areas; General, Clinical Trials, Product Experience and Waveform. Sections 7.1 to 7.4 document the trigger events, message definitions, segment definitions and examples for general observation reporting. Sections 7.5 to 7.8 include all information related to Clinical Trials. Sections 7.9 to 7.12 include all information related to Product Experience messaging, and sections 7.13 and 7.16 includes Waveform messaging information. Outstanding issues are listed in section 7.17
Person or service that requests (places order for) an observation battery, e.g., the physician, the practice, clinic, or ward service, that orders a lab test, X-ray, vital signs, etc. The meaning is synonymous with, and used interchangeably with, requestor. See ORC-2-placer order number, Section 4.3.1.2, "Placer order number."
Person, or service, who produces the observations (fills the order) requested by the requestor. The word is synonymous with "producer" and includes diagnostic services and clinical services and care providers who report observations about their patients. The clinical laboratory is a producer of lab test results (filler of a lab order), the nursing service is the producer of vital signs observations (the filler of orders to measure vital signs), and so on. See ORC-3-filler order number, Section 4.3.1.3, "Filler order number."
A
set of one or more observations identified as by a single name and code number,
and treated as a shorthand unit for ordering or retrieving results of the
constituent observations. In keeping with the mathematical conventions about
set, a battery can be a single observation. Vital signs, electrolytes, routine
admission tests, and obstetrical ultrasound are all examples. Vital signs
(conventionally) consist of diastolic and systolic blood pressure, pulse, and
respiratory rate. Electrolytes usually consist of Na+, K+, Cl-, and HCO3-.
Routine admission tests might contain CBC, Electrolytes, SMA12, and Urinalysis.
(Note that the elements of a battery for our purposes may also be batteries).
Obstetrical ultrasound is a battery made up of traditional component
measurements and the impression, all of which would be returned as separate
results when returned to the requestor. A test involving waveform recording
(such as an EKG) can be represented as a battery comprised of results of many
categories, including digital waveform data, labels and annotations to the
data, measurements, and the impression
The word battery is used in this specification synonymously with the word
profile or panel. The individual observation elements within a battery may be
characteristic of a physiologic system (e.g., liver function tests), or many
different physiologic systems.
A measurement of a single variable or a single value derived logically and/or algebraically from other measured or derived values. A test result, a diastolic blood pressure, and a single chest X-ray impression are examples of observations. In certain circumstances, tracings and images may be treated by HL7 as individual observations and sent as a single OBX. These include waveform data described in Section 7.15, "Waveform - Trigger Events & Message Definitions," and encapsulated data aggregates using the ED data type described in Section 2.8.14, "ED-encapsulated data," (which can represent actual images, audio data, etc.).
A
typed aggregate of fields (fields) describing one complete aspect of a message.
For example, the information about one order is sent as type of segment (OBR),
the information related to an observation is sent as another segment (OBX).
The segment in a message is analogous to a record in a database, and in
previous versions of the Standard we used record in place of the word segment.
We have changed the nomenclature to be consistent with HL7 and other standards
organizations in this version.
One specific attribute of a segment, for example, patient diagnosis, which may contain aggregates of fields further refining the basic attribute.
Some fields may contain many repeat fields. For example, the diagnoses field may contain many different diagnoses.
A field entry may also have discernible parts or components. For example, the patient's name is recorded as last name, first name, and middle initial, each of which is a distinct entity separated by a component delimiter (sub-subfield in ASTM E1238-94).
Narrative
reports from services such as Radiology usually consist of a number of
subcomponents (e.g., a chest X-ray report may consist of a description, an
impression, and a recommendation). Other studies, such as echocardiograms,
contain analogous components, as well as numeric observations (e.g., left
ventricular and diastolic diameter). Surgical pathology reports may contain
information about multiple specimens and reports: the anatomic source, the
gross description, the microscopic description, and a diagnostic impression for
each specimen.
The current Standard treats each component of a narrative report as a separate
"test" or observation. Just as a CHEM12 is transmitted as an order segment
(OBR) plus 12 OBX segments, a chest X-ray would be transmitted as an order
(OBR) segment plus three OBX segments, one for the description, one for the
impression, and one for the recommendations. Similarly, an EKG report would be
transmitted as an order segment (OBR), two OBX segments for the impression and
recommendation, and additional OBX segments for each EKG measurement, e.g. the
PR interval, QR interval, QRS axis, and so on.
We have defined code suffixes for constructing observation IDs for the common
components of narrative reports (see Figure 7-1). The observation identifier
for each such component is obtained by concatenating the observation battery ID
(the ID in OBR-4-universal service ID of the preceding OBR from any
coding system) with the appropriate suffix. The observation ID for a chest
X-ray impression, for example, would be the chest X-ray observation ID (if
CPT4, it would be 71020), a subcomponent delimiter, and the suffix, IMP, i.e.,
71020&IMP.
This same combining rule applies to other coding systems including local and
universal procedural codes (see Chapter 4). For example, if a local code for
EKG was E793, and the locally agreed upon designation for that local code was
EKG, the impression would be identified as E793&IMP^^99EKG.
Note: The "99EKG" in the 3rd component is included to indicate a local
code. The EKG's description, in this case, would be E793&GDT^^99EKG.
Although it is strongly discouraged, the sender and receiver may agree to allow
the omission of the observation ID component of a result segment when it is the
same as the observation ID of the preceding OBR. In this case, only the
ampersand and the suffix would have to be sent, e.g., &IMP or &REC, in
OBX-3-observation identifier of a result segment. The full code would
be assumed as the test identifier (recorded in the order segment) plus the
category identifier recorded in the observation segment.
Coded Results |
Suffix |
Type |
|---|---|---|
Diagnostic Impression |
IMP |
CE |
Recommendation |
REC |
CE |
Confirming procedures |
CNP |
CE |
Procedure Medication |
MED |
CE |
Anatomic Site |
ANT |
CE |
Device/Instrument |
DEV |
CE |
Serial # Device/Instrument |
SER |
ST |
Bulk Text Reports |
||
Gross Or General Description Of The Study |
GDT |
TX or FT |
Microscopic Or Secondary Description |
MDT |
TX or FT |
Technician's Comment |
TCM |
TX or FT |
Addendum Note |
ADT |
TX or FT |
Other |
||
Diagnosis Onset Date/Time |
ITM |
TS |
Diagnosis Resolution Date/Time |
RTM |
TS |
Comparison Study |
CMS |
CE |
Comparison Date/Time |
CMT |
TS |
Comparison Results |
CMR |
CE |
Comparison Change |
CMC |
CE |
Predicted Value |
PRD |
ST |
Percent Predicted |
PPR |
ST |
After Drug Observed |
AFD |
ST |
Predicted Value After Drug |
ADP |
ST |
Percent Predicted After Drug |
APP |
ST |
Timing Information |
TIM |
TS |
Channel Definition Data |
CHN |
CD |
Waveform Digital Data |
WAS |
NA or MA |
Waveform Annotation |
ANO |
CE |
The following subsections define each of the suffices except for the specialized waveform suffices, which are defined in Section 7.14.1.8.2, "Maximum data value (NM)."
When
the suffix is IMP (OBX-3-observation identifier), the result is a
diagnosis or finding, stored as a CE data type. Multiple result segments with
an IMP suffix can be used if there are multiple parts to the study and each
have an associated diagnosis (for example, the awake and sleep portion of an
EEG). Each of these would have a different observation sub-ID. Multiple
result segments with an IMP suffix can also be used if there are separate
diagnoses corresponding to separate anatomic sites; in this case, the site for
each diagnosis (each result segment with an IMP suffix) must be specified by an
immediately preceding result segment with a suffix of ANT (see Section 7.2.4.5,
"Anatomic site (ANT)"), which also has the same observation sub-ID. When
multiple distinct diagnostic impressions are being reported, for example,
mitral valve prolapse and aortic stenosis, each distinct impression should be
sent in a separate OBX segment. More than one code may be included within one
coded result segment, but only when such codes are modifiers of the principal
impression, e.g., to report additional detail about the finding, not to report
an entirely different finding. In this case, the OBX-5-observation
value field may repeat, with each instance or repetition specifying one of
the related coded impressions.
The coded data type for impressions does not mean that a reporting service must
actually code all such impressions. The diagnostic impression can be sent as
dictated text, but the text should be sent in the second component of the CE
data type without a code to distinguish it from code, i.e. it should be
preceded by a component delimiter, e.g., ^congestive heart failure.
When multiple separate text impressions are being reported, they should be
reported in separate OBX segments to indicate that they are distinct impressions.
When
the suffix is REC (OBX-3-observation identifier), the value is a CE
result, representing the reading physician's recommendations about repeat
testing, follow up or therapy. For example, when an ambiguous lesion result is
seen on a mammogram, the reading physician might recommend a repeat mammogram
in six months, or a needle biopsy immediately. The recommended procedures are
recorded as codes and/or text descriptions in the coded identifier structure.
If more than one follow up study is recommended, each such recommendation is
sent in a separate REC.
The confirming procedure OBX suffix identifies additional studies used to confirm the diagnosis reported in the IMP OBX. If, for example, electron microscopy was done to confirm a surgical pathology diagnosis, the identifier for electron microscopy OBX-3-observation identifier would be stored as the value field of an observation ID with a confirming procedure suffix. Confirming procedures are most important in surgical pathology reports. But they might also be used by services such as endoscopy, to record the fact that a biopsy, culture, etc., was taken during the procedure. If more than one confirming procedure was used, each is sent in a separate result segment with observation ID suffix CNP.
A
coded result segment with a suffix of MED (OBX-3-observation identifier)
indicates that the segment contained information about medication given as part
of the procedure -- contrast medication, medication intended to invoke a
physiologic response (e.g., to be used in stress testing) or premedication.
When patients receive more than one procedure medication, each medication
should be reported in a separate OBX medication segment. If the transmitting
system has codes available for medications, they would be recorded as the first
component of OBX-3-observation identifier. The name and/or the dosages
could be included in the second component of OBX-5-observation value.
A coded result segment with a suffix of MED (procedure medication) may also be
used to define a medication administered during recording of digital waveform
data or other extended diagnostic procedure, e.g., exercise test. These may be
displayed by the receiving system overlaid with the other events reported. The
procedure medication is assumed to pertain to and be associated with the data
recorded at the time specified in OBX-14-date/time of the observation,
of the OBX segment labeled with MED, when present.
Some diagnostic studies include observations about more than one anatomic site within one report. If, for example, a patient had an appendectomy incidental to gallbladder surgery, the pathologist's assessment of both specimens would usually be included under a single specimen number in one report. Each distinct anatomic site would be reported as a separate OBX segment with a suffix of ANT (OBX-3-observation identifier). More than one coded anatomic location may be included within a single OBX segment only when such additional codes are used to construct an identity for a single site. In this case only, the OBX-5-observation value field may repeat, with each instance or repetition specifying one of the related locations. Each OBX segment with an ANT suffix could be followed by one or more OBX segments with an IMP or other suffix to transmit the diagnostic impression(s) associated with the anatomic site. These impressions or recommendations would be associated with a single anatomic site via a common observation ID.
When required, the instrument or device which generated an observation can be transmitted as an additional result of the study. In this case, the suffix of OBX-3-observation identifier is DEV. Examples include: an automated instrument in the laboratory; an imaging device and model number in radiology; or an automatic blood pressure machine on the ward. The device is specified as a coded entry in anticipation that these identifiers could be specified as codes. Initially, we expect that most of the information about devices will be transmitted as text in the second component of the CE identifier.
Vendor's serial number of the device which generated the observation.
The general description suffix identifies the description component of a diagnostic study. In the case of anatomic pathology, it applies to the macroscopic (gross) description of the specimen. If the description consists of multiple paragraphs, the paragraphs should be separated by repeat delimiters so that the receiving computer can display them as paragraphs. It will not be necessary to include a description segment for a report when the impression segment says it all, e.g., for normal studies or studies such as EKG, whose reports are traditionally terse.
For most studies, a secondary description will not be needed. In the case of surgical pathology, however, the microscopic description is a separate part of the report. It describes the histology as seen through the microscope. The microscopic description will be sent in a segment with the suffix MDT in OBX-3-observation identifier. If the microscopic description consists of multiple paragraphs, the paragraphs should be separated by repeat delimiters so that the receiving computer can display them as paragraphs.
This is free text stored in a result segment whose OBX-3-observation identifier has a suffix of TCM for technician comment. It is used to record information about technical performance of the procedure, usually recorded by the technician.
Use to report information that is added as an addendum after the original dictation and sent as a separate labeled section of the report.
Use to record the date-time that a problem was first perceived to exist.
Use to record the date-time that a problem became inactive, i.e., the problem was cured or remitted.
When the reader of a diagnostic report compares the results for the current study with those of a previous study, this suffix allows them to report the nature of the comparison study as a separate result, i.e., an OBX segment with a segment whose observation ID has a suffix of CMS. Ordinarily, this would not be required because the observation ID in the other comparison OBXs would identify the test, if any of the other comparison values were transmitted.
When the reader of a diagnostic procedure compares the current results with a previous study, this suffix allows them to report the date-time of the previous study (time optional) as a separate result within the current report.
When the reader of a diagnostic procedure compares the current results with those of a previous study on the same patient, this suffix allows them to report the results (impression) of the previous study as a discrete result within the current report.
When
a diagnostic service reports a comparison between the current and a previous
study, this suffix is used to report the degree of change (e.g., much worse,
worse, minimal worsening, no change, slightly better, better, much better,
returned to normal) as a separate result within the report.
In current dictation, information about comparison is usually contained in the
descriptions of the study. The provision of the comparison suffixes listed
above do not imply a requirement to send this information as separate
components. The comparison variables are only meant to be enabling. When a
system would like to transmit them as discrete report components, these
suffixes give them the option.
When an observation has a predicted value as is the case for many spirometry tests, this suffix identifies the predicted observation as distinguished from the actual observation. The AS4 code for forced vital capacity is 94010.1 (see the HL7 Implementation Guide). The predicted forced vital capacity would be 94010.1&PRD.
This is a computed observation = (actual observation)/(predicted observation. For forced vital capacity the percent predicted would be identified as 94010.1&PPR.
An observation might be taken before and after a drug is given. This occurs especially in Spirometry. The predose observation is identified by the base ID. The post drug measure is identified by the AFD suffix. Using the AS4 base code for the forced vital capacity the post drug result would be identified by 94010.1&AFD.
The post drug predicted value is identified by the suffix, ADP. Following the pattern of the above example, it would be 94010.1&ADP.
The percent predicted after drug is identified by applying the suffix, APP to the base code - 94010.1&APP if using the AS4 code for forced vital capacity.
This suffix is used only for transmitting waveform data. It is fully described in Section 7.14.2.1.
This suffix is used only for transmitting waveform data. It is fully described in Section 7.16.4.
This suffix is used only for transmitting waveform data. It is fully described in Section 7.16.5.
This suffix is used only for transmitting waveform data. It is fully described in Section 7.16.6.
The recently introduced LOINC® codes (See Figure 7-2 for full information) may be more useful to many users. Code system information, including LOINC®, has been moved from Appendix 7A to the Implementation Guide.
Various
fields of data type CE which are used in segments defined both in the current
chapter and other chapters, are used to transmit information about diagnoses,
observation results, procedures, health outcomes, and drugs administered.
Figures 7-2 and 7-3 (which were located in Chapter 2 in previous versions) list
some common coding schemes for these types of information. The values in the
second column of the table would be used in component 3 (and optionally,
component 6) of a CE field to identify the coding scheme used.
Refer to section 7.18.1 for the contents of the User
-defined
Table
0396 - Coding system.
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 2, "Format for defining abstract messages."
The
OUL message is designed to accommodate the laboratory processes of laboratory
automation systems. The ORU message is still fully supported by HL7 for
transmitting laboratory results to other systems.
With the type (OBX) defined in this chapter, and the OBR defined in Chapter 4,
one can construct almost any clinical report as a three-level hierarchy, with
the PID segment defined in Chapter 3 at the upper level, an order record (OBR)
at the next level and one or more observation records (OBX) at the bottom.
One result segment (OBX) is transmitted for each component of a diagnostic
report, such as an EKG or obstetrical ultrasound or electrolyte battery.
The CTD segment in this trigger is used to transmit temporary patient contact
details specific to this order.
ORU^R01 |
Unsolicited Observation Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
{ |
||
[ |
||
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NK1}] |
Next of Kin/Associated Parties |
3 |
[{NTE}] |
Notes and Comments |
2 |
[ |
||
PV1 |
Patient Visit |
3 |
[PV2] |
Patient Visit - Additional Info |
3 |
] |
||
] |
||
{ |
||
[ORC] |
Order common |
4 |
O BR |
Observations Report ID |
7 |
{[NTE]} |
Notes and comments |
2 |
[CTD] |
Contact Data |
11 |
{ |
||
[OBX] |
Observation/Result |
7 |
{[NTE]} |
Notes and comments |
2 |
} |
||
[{FT1}] |
Financial Transaction |
6 |
{[CTI]} |
Clinical Trial Identification |
7 |
} |
||
} |
||
[DSC] |
Continuation Pointer |
2 |
ACK^R01 |
Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message header |
2 |
MSA |
Message acknowledgment |
2 |
Note:
The ORC is permitted but not required in this message. Any information
that could be included in either the ORC or the OBR must be included in the OBR
on reporting. Notice also that the ORU (and the QRY) messages accommodate
reports about many patients.
Many report headers (OBR) may be sent beneath each patient segment, with many
separate observation segments (OBX) beneath each OBR. Note segments (NTE) may
be inserted after any of the above segments. The note segment applies to the
entity that immediately precedes it, i.e., the patient if it follows the PID
segment, the observation if it follows the OBR segment, and the individual
result if it follows the OBX segment.
*
This message was designed to accommodate laboratory automation systems. It
permits the communication of the following kinds of information in addition to
the results themselves: relation of the analysis results to a particular
container with patient sample (SAC segment),
* relation of the analysis results to a particular container with QC sample and
the lot and manufacturer information about this sample (SAC-SID segments),
* basic identification data (lot, manufacturer, etc.) of the reagents and other
substances involved in the generation of analysis results (TCD-SID
segments).
If the results are for QC specimen container, then the patient related segments
(e.g., PID, PD1, PV1, PV2) are optional.
Refer to Chapter 13 Laboratory Automation for examples of usage.
OUL^R21^OUL_R21 |
Unsolicited Laboratory Observation Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
[NTE] |
Notes and Comments |
2 |
[ |
||
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NTE}] |
Notes and Comments (for Patient ID) |
2 |
] |
||
[ |
||
PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit - Additional Information |
3 |
] |
||
{ |
||
[ |
||
SAC |
Specimen Container Details |
13 |
[SID] |
Substance Identifier |
13 |
[{OBX}] |
Additional Specimen Characteristics |
7 |
] |
||
[ORC] |
Common Order |
4 |
OBR |
Observation |
7 |
[{NTE}] |
Notes and Comments (for Detail) |
2 |
{ |
||
[OBX] |
Observation Result |
7 |
[TCD] |
Test Code Detail |
13 |
{[SID]} |
Substance Identifier |
13 |
[{NTE}] |
Notes and Comments |
2 |
} |
||
[{CTI}] |
Clinical Trial Identification |
7 |
} |
||
[DSC] |
Continuation Pointer |
2 |
The
query response format options are described in chapter 5, Section 5.2.4
"Response format".
The QRD segment is defined in Chapter 5 Section 5.10.5.3, "QRD - original style
query definition segment." The Query Result Level field of the QRD determines
the amount of data requested.
The QRF segment is defined in Chapter 5, Section 5.10.5.4, "QRF - original
style query filter segment."
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 count the
number of segments of one kind transmitted at one level of the hierarchy.
The CTD segment in this trigger is used to transmit temporary patient contact
details specific to this order.
QRY^R02^QRY_R02 |
Query |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
QRD |
Query Definition |
2 |
QRF |
Query Filter |
2 |
ORF^R04^ORF_R04 |
Observational Report |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
QRD |
Query Definition |
2 |
[QRF] |
Query Filter |
2 |
{ |
||
[ |
||
PID |
Patient ID |
3 |
[{NTE}] |
Notes and Comments |
3 |
] |
||
{ |
||
[ORC] |
Order common |
|
OBR |
Observation request |
7 |
{[NTE]} |
Notes and comments |
2 |
[CTD] |
Contact Data |
11 |
{ |
||
[OBX] |
Observation/Result |
7 |
{[NTE]} |
Notes and comments |
2 |
} |
||
{[CTI]} |
Clinical Trial Identification |
7 |
} |
||
} |
||
[ERR] |
Error |
2 |
[QAK] |
Query Acknowledgement |
5 |
[DSC] |
Continuation Pointer |
2 |
The full definitions of many segments required for reporting clinical observations are included in other chapters. The patient identifying segment (PID) is provided in Chapter 3. The NTE segment is in Chapter 2.
In
the reporting of clinical data, the OBR serves as the report header. It
identifies the observation set represented by the following atomic
observations. It includes the relevant ordering information when that applies.
It contains many of the attributes that usually apply to all of the included
observations.
When a set of observations is ordered, the order message contains an OBR
segment. However, observations can be collected and reported without an
antecedent order. When observations are reported, the report message also
includes one or more OBR segments. So,
the OBR segment is like a turn-around document. Some fields in the OBR segment
apply only to the ordering message and some to the reporting message. To those
familiar with healthcare procedures, these should be obvious from their names
(e.g., transcriptionist or principal result interpreter could only apply to the
reporting phase). However, we have also flagged them in Figure 7-4 to indicate
whether placer, filler, or both may send data in a given field.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
O |
00237 |
Set ID - OBR |
||
2 |
22 |
EI |
C |
00216 |
Placer Order Number |
||
3 |
22 |
EI |
C |
00217 |
Filler Order Number |
||
4 |
250 |
CE |
R |
00238 |
Universal Service Identifier |
||
5 |
2 |
ID |
X |
00239 |
Priority - OBR |
||
6 |
26 |
TS |
X |
00240 |
Requested Date/Time |
||
7 |
26 |
TS |
C |
00241 |
Observation Date/Time # |
||
8 |
26 |
TS |
O |
00242 |
Observation End Date/Time # |
||
9 |
20 |
CQ |
O |
00243 |
Collection Volume * |
||
10 |
250 |
XCN |
O |
Y |
00244 |
Collector Identifier * |
|
11 |
1 |
ID |
O |
0065 |
00245 |
Specimen Action Code * |
|
12 |
250 |
CE |
O |
00246 |
Danger Code |
||
13 |
300 |
ST |
O |
00247 |
Relevant Clinical Info. |
||
14 |
26 |
TS |
C |
00248 |
Specimen Received Date/Time * |
||
15 |
300 |
CM |
O |
0070 |
00249 |
Specimen Source * |
|
16 |
250 |
XCN |
O |
Y |
00226 |
Ordering Provider |
|
17 |
250 |
XTN |
O |
Y/2 |
00250 |
Order Callback Phone Number |
|
18 |
60 |
ST |
O |
00251 |
Placer Field 1 |
||
19 |
60 |
ST |
O |
00252 |
Placer Field 2 |
||
20 |
60 |
ST |
O |
00253 |
Filler Field 1 + |
||
21 |
60 |
ST |
O |
00254 |
Filler Field 2 + |
||
22 |
26 |
TS |
C |
00255 |
Results Rpt/Status Chng - Date/Time + |
||
23 |
40 |
CM |
O |
00256 |
Charge to Practice + |
||
24 |
10 |
ID |
O |
0074 |
00257 |
Diagnostic Serv Sect ID |
|
25 |
1 |
ID |
C |
0123 |
00258 |
Result Status + |
|
26 |
400 |
CM |
O |
00259 |
Parent Result + |
||
27 |
200 |
TQ |
O |
Y |
00221 |
Quantity/Timing |
|
28 |
250 |
XCN |
O |
Y/5 |
00260 |
Result Copies To |
|
29 |
200 |
CM |
O |
00261 |
Parent |
||
30 |
20 |
ID |
O |
0124 |
00262 |
Transportation Mode |
|
31 |
250 |
CE |
O |
Y |
00263 |
Reason for Study |
|
32 |
200 |
CM |
O |
00264 |
Principal Result Interpreter + |
||
33 |
200 |
CM |
O |
Y |
00265 |
Assistant Result Interpreter + |
|
34 |
200 |
CM |
O |
Y |
00266 |
Technician + |
|
35 |
200 |
CM |
O |
Y |
00267 |
Transcriptionist + |
|
36 |
26 |
TS |
O |
00268 |
Scheduled Date/Time + |
||
37 |
4 |
NM |
O |
01028 |
Number of Sample Containers * |
||
38 |
250 |
CE |
O |
Y |
01029 |
Transport Logistics of Collected Sample * |
|
39 |
250 |
CE |
O |
Y |
01030 |
Collector's Comment * |
|
40 |
250 |
CE |
O |
01031 |
Transport Arrangement Responsibility |
||
41 |
30 |
ID |
O |
0224 |
01032 |
Transport Arranged |
|
42 |
1 |
ID |
O |
0225 |
01033 |
Escort Required |
|
43 |
250 |
CE |
O |
Y |
01034 |
Planned Patient Transport Comment |
|
44 |
250 |
CE |
O |
0088 |
00393 |
Procedure Code |
|
45 |
250 |
CE |
O |
Y |
0340 |
01316 |
Procedure Code Modifier |
46 |
250 |
CE |
O |
Y |
0411 |
01474 |
Placer Supplemental Service Information |
47 |
250 |
CE |
O |
Y |
0411 |
01475 |
Filler Supplemental Service Information |
Note: The complete description of these fields is provided below as well as in Chapter 4.
The
daggered (+) items in this segment are not created by the placer known to the
filler, not the placer. They are created by the filler and valued as needed
when the OBR segment is returned as part of a report. Hence on a new order
sent to the filler, they are not valued. There is an exception when the filler
initiates the order. In that case, the filler order number is valued and the
placer order number may be blank. They are valued by the filler as needed when
the OBR segment is returned as part of a report.
The starred (*) fields are only relevant when an observation is associated with
a specimen. These are completed by the placer when the placer obtains the
specimen. They are completed by the filler when the filler obtains the
specimen.
OBR-7-observation date/time and OBR-8-observation end date/time
(flagged with #) are the physiologically relevant times. In the case of an
observation on a specimen, they represent the start and end of the specimen
collection. In the case of an observation obtained directly from a subject
(e.g., BP, Chest X-ray), they represent the start and end time of the
observation.
Definition: For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field is a case of the Entity Identifier data type (See
2.8.13, "EI - Entity identifier"). The first component is a string that
identifies an individual order (e.g., OBR). A limit of fifteen (15) characters
is suggested but not required. It is assigned by the place (ordering
application). It identifies an order uniquely among all orders from a
particular ordering application. The second through fourth components contain
the application ID of the placing application in the same form as the HD data
type (Section 2.8.18, "HD - Hierarchic designator"). The second component,
namespace ID, is a user-defined coded value that will be uniquely associated
with an application. A limit of six (6) characters is suggested but not
required. A given institution or group of intercommunicating institutions
should establish a unique list of applications that may be potential placers
and fillers and assign unique application IDs. The components are separated by
component delimiters.
There are three situations in which the true placer is somewhat arbitrary (and
thus not unique):
a) in ORC-1-order control value of RO, following an RU replacement;
b) in ORC-1-order control value of CH (child orders); and
c) in ORC-1-order control value of SN (send number).
See the Table Notes under ORC-1-order control for the details of how the
ORC-2-placer order number is assigned in these cases.
A given institution or group of intercommunicating institutions should
establish a list of applications that may be potential placers and fillers of
orders and assign each a unique application ID. The application ID list
becomes one of the institution's master dictionary lists that is documented in
Chapter 8. Since third-party applications (those other than the placer and
filler of an order) can send and receive ORM and ORR messages, the placer
application ID in this field may not be the same as any sending and receiving
application on the network (as identified in the MSH segment).
ORC-2-placer order number is the same as OBR-2-placer order
number. If the placer order number is not present in the ORC, it must be
present in the associated OBR and vice versa. If both fields, ORC-2-placer
order number and OBR-2-placer order number, are valued, they must
contain the same value. When results are transmitted in an ORU message, an ORC
is not required, and the identifying placer order number must be present
in the OBR segments.
These rules apply to the few other fields that are present in both ORC and OBR
for upward compatibility (e.g., quantity/timing, parent numbers, ordering
provider, and ordering call back numbers).
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field is the order number associated with the filling
application. It is a case of the Entity Identifier data type (Section 2.8.13,
"EI - Entity Identifier"). Its first component is a string that identifies an
order detail segment (e.g., OBR). A limit of fifteen (15) characters is
suggested but not required. It is assigned by the order filler (receiving)
application. This string must uniquely identify the order (as specified in the
order detail segment) from other orders in a particular filling application
(e.g., clinical laboratory). This uniqueness must persist over time.
The second through fourth components contain the filler application ID, in the
form of the HD data type (see Section 2.8.18, "HD - hierarchic designator").
The second component is a user-defined coded value that uniquely defines the
application from other applications on the network. A limit of six (6)
characters is suggested but not required. The second component of the filler
order number always identifies the actual filler of an order.
A given institution or group of intercommunicating institutions should
establish a list of applications that may be potential placers and fillers of
orders and assign each a unique application ID. The application ID list
becomes one of the institution's master dictionary lists that is documented in
Chapter 8. Since third- party applications (those other than the placer and
filler of an order) can send and receive ORM and ORR messages, the filler
application ID in this field may not be the same as any sending and receiving
application on the network (as identified in the MSH segment).
ORC-3-filler order number is the same as OBR-3-filler order
number. If the filler order number is not present in the ORC, it must be
present in the associated OBR. (This rule is the same for other identical
fields in the ORC and OBR and promotes upward and ASTM compatibility.) This is
particularly important when results are transmitted in an ORU message. In this
case, the ORC is not required and the identifying filler order number must be
present in the OBR segments.
The filler order number (OBR-3 or ORC-3) also uniquely identifies an
order and its associated observations. For example, suppose that an
institution collects observations from several ancillary applications into a
common database and this common database is queried by yet another application
for observations. In this case, the filler order number and placer order
number transmitted by the common database application would be that of the
original filler and placer, respectively, rather than a new one assigned by the
common database application.
Similarly, if a third-party application, not the filler or placer, of an order
were authorized to modify the status of an order (say, cancel it), the
third-party application would send the filler an ORM message containing an ORC
segment with ORC-1-order control equal to "CA" and containing the
original placer order number and filler order number, rather than assign either
itself.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is the identifier code for the requested
observation/test/battery. This can be based on local and/or "universal" codes.
We recommend the "universal" procedure identifier. The structure of this CE
data type is described in the control section.
Definition: This field has been retained for backward compatibility only. It is not used. Previously priority (e.g., STAT, ASAP), but that information is carried as the sixth component of OBR-27-quantity/timing.
Definition: This field has been retained for backward compatibility only. This is not used. Previously requested date/time. That information is now carried in the fourth component of the OBR-27-quantity/timing.
Definition: This field is the clinically relevant date/time of the observation. In the case of observations taken directly from a subject, it is the actual date and time the observation was obtained. In the case of a specimen-associated study, this field shall represent the date and time the specimen was collected or obtained. (This is a results-only field except when the placer or a third party has already drawn the specimen.) This field is conditionally required. When the OBR is transmitted as part of a report message, the field must be filled in. If it is transmitted as part of a request and a sample has been sent along as part of the request, this field must be filled in because this specimen time is the physiologically relevant date-time of the observation.
Definition: This field is 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. This is a results field except when the placer or a party other than the filler has already drawn the specimen.
Components:
<quantity (NM)> ^ <units (CE)>
Subcomponents of units: <identifier (ST)> & <test (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (IS)>
Definition: For laboratory tests, the collection volume is the volume of a
specimen. The default unit is ML. Specifically, units should be expressed in
the ISO Standard unit abbreviations (ISO-2955, 1977). This is a results-only
field except when the placer or a party has already drawn the specimen. (See
Chapter 7 for full details about units.)
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: When a specimen is required for the study, this field will
identify the person, department, or facility that collected the specimen.
Either name or ID code, or both, may be present.
Definition:
This field is the action to be taken with respect to the specimens that
accompany or precede this order. The purpose of this field is to further
qualify (when appropriate) the general action indicated by the order control
code contained in the accompanying ORC segment. For example, when a new order
(ORC - "NW") is sent to the lab, this field would be used to tell the lab
whether or not to collect the specimen ("L" or "O"). Refer to HL7 Table
0065 - Specimen action code for valid values.
Value |
Description |
|---|---|
A |
Add ordered tests to the existing specimen |
G |
Generated order; reflex order |
L |
Lab to obtain specimen from patient |
O |
Specimen obtained by service other than Lab |
P |
Pending specimen; Order sent prior to delivery |
R |
Revised order |
S |
Schedule the tests specified below |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is the code and/or text indicating any known or
suspected patient or specimen hazards, e.g., patient with active tuberculosis
or 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.
Definition: This field contains any additional clinical information about the patient or specimen. 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 carbon 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 OBX segments (see Chapter 7) that immediately follow the order segment.
Definition: For observations requiring a specimen, the specimen received date/time is the actual login time at the diagnostic service. This field must contain a value when the order is accompanied by a specimen, or when the observation required a specimen and the message is a report.
Components:
<specimen source name or code (CE)> ^ <additives (TX)> ^
<freetext (TX)> ^ <body site (CE)> ^ <site modifier (CE)> ^
<collection method modifier code (CE)>
Subcomponents of specimen source name or doe: <identifier (ST)> &
<test (ST)> & <name of coding system (IS)> & <alternate
identifier (ST)> & <alternate text (ST)> & <name of
alternate coding system (ST)>
Subcomponents of body site: <identifier (ST)> & <test (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (ST)>
Subcomponents of site modifier: <identifier (ST)> & <test
(ST)> & <name of coding system (IS)> & <alternate
identifier (ST)> & <alternate text (ST)> & <name of
alternate coding system (ST)>
Subcomponents of collection method modifier code: <identifier (ST)>
& <test (ST)> & <name of coding system (IS)> &
<alternate identifier (ST)> & <alternate text (ST)> &
<name of alternate coding system (ST)>
Definition: This field identifies the site where the specimen should be
obtained or where the service should be performed.
Veterinary medicine may choose the tables supported for the components of this
field as decided by their industry.
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.) Refer
to HL7 table 0070 - Specimen source codes for valid
entries.
The second component should include free text 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 the method of collection is
logically an observation result, it should be included as a result segment.
The fourth component specifies the body site from which the specimen was
obtained, and the fifth is the site modifier. For example, the site could be
antecubital fossa, and the site modifier "right." The components of the CE
fields become subcomponents.
Refer to section 7.18.2 for the contents of HL7 Table 0163 - Body
site.
The fifth component indicates whether the specimen is frozen as part of the
collection method. Suggested values are F (Frozen); R (Refrigerated). If the
component is blank, the specimen is assumed to be at room temperature.
Refer to section 7.18.3 for the contents of HL7 Table 0070 - Specimen
source codes.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the provider who ordered the test. Either
the ID code or the name, or both, may be present. This is the same as
ORC-12-Ordering provider.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^
<telecommunication use code (ID)> ^ <telecommunication equipment type
(ID)> ^ <email address (ST)> ^ <country code (NM)> ^
<area/city code (NM)> ^ <phone number (NM)> ^ <extension
(NM)> ^ <any text (ST)>
Definition: This field is the telephone number for reporting a status or a
result using the standard format with extension and/or beeper number when
applicable.
Definition: This field is user field #1. Text sent by the placer will be returned with the results.
Definition: This field is similar to placer field #1.
Definition: This field is definable for any use by the filler (diagnostic service).
Definition: This field is similar to filler field #1.
Definition: This field specifies the date/time results reported or status changed. This field is used to indicate the date and time that the results are composed into a report and released, or that a status, as defined in ORC-5-order status, is entered or changed. (This is a results field only.) When other applications (such as office or clinical database applications) query the laboratory application for un-transmitted results, the information in this field may be used to control processing on the communications link. Usually, the ordering service would want only those results for which the reporting date/time is greater than the date/time the inquiring application last received results.
Components:
<dollar amount (MO)> ^ <charge code (CE)>
Subcomponents of dollar amount: <quantity (NM)> &
<denomination (ID)>
Subcomponents of charge code: <identifier (ST)> & <test
(ST)> & <name of coding system (IS)> & <alternate
identifier (ST)> & <alternate text (ST)> & <name of
alternate coding system (IS)>
Definition: This field is 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).
Definition:
This field is 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 HL7
Table 0074 - Diagnostic service section ID for valid entries.
Value |
Description |
|---|---|
AU |
Audiology |
BG |
Blood gases |
BLB |
Blood bank |
CUS |
Cardiac Ultrasound |
CTH |
Cardiac catheterization |
CT |
CAT scan |
CH |
Chemistry |
CP |
Cytopathology |
EC |
Electrocardiac (e.g., EKG, EEC, Holter) |
EN |
Electroneuro (EEG, EMG,EP,PSG) |
HM |
Hematology |
ICU |
Bedside ICU Monitoring |
IMG |
Diagnostic Imaging |
IMM |
Immunology |
LAB |
Laboratory |
MB |
Microbiology |
MCB |
Mycobacteriology |
MYC |
Mycology |
NMS |
Nuclear medicine scan |
NMR |
Nuclear magnetic resonance |
NRS |
Nursing service measures |
OUS |
OB Ultrasound |
OT |
Occupational Therapy |
OTH |
Other |
OSL |
Outside Lab |
PAR |
Parasitology |
PAT |
Pathology (gross & histopath, not surgical) |
PHR |
Pharmacy |
PT |
Physical Therapy |
PHY |
Physician (Hx. Dx, admission note, etc.) |
PF |
Pulmonary function |
RAD |
Radiology |
RX |
Radiograph |
RUS |
Radiology ultrasound |
RC |
Respiratory Care (therapy) |
RT |
Radiation therapy |
SR |
Serology |
SP |
Surgical Pathology |
TX |
Toxicology |
URN |
Urinalysis |
VUS |
Vascular Ultrasound |
VR |
Virology |
XRC |
Cineradiograph |
Definition:
This field is the status of results for this order. This conditional field is
required whenever the OBR is contained in a report message. It is not required
as part of an initial order.
There are two methods of sending status information. If the status is that of
the entire order, use ORC-15-order effective date/time and
ORC-5-order status. If the status pertains to the order detail segment,
use OBR-25-result status and OBR-22-results report/status change -
date/time. If both are present, the OBR values override the ORC values.
This field would typically be used in a response to an order status query where
the level of detail requested does not include the OBX segments. When the
individual status of each result is necessary, OBX-11-observ result
status may be used. Refer to HL7 Table 0123 - Result status
for valid entries.
Value |
Description |
|---|---|
O |
Order received; specimen not yet received |
I |
No results available; specimen received, procedure incomplete |
S |
No results available; procedure scheduled, but not done |
A |
Some, but not all, results available |
P |
Preliminary: A verified early result is available, final results not yet obtained |
C |
Correction to results |
R |
Results stored; not yet verified |
F |
Final results; results stored and verified. Can only be changed with a corrected result. |
X |
No results available; Order canceled. |
Y |
No order on record for this test. (Used only on queries) |
Z |
No record of this patient. (Used only on queries) |
Components:
<OBX-3-observation identifier of parent result (CE)> ^ <OBX-4-sub-ID
of parent result (ST)> ^ <part of OBX-5 observation result from parent
(TX) see discussion>
Subcomponents of OBX-3-observation identifier or parent result:
<identifier (ST)> & <test (ST)> & <name of coding system
(IS)> & <alternate identifier (ST)> & <alternate text
(ST)> & <name of alternate coding system (ST)>
Definition: This field is defined to make it available for other types of
linkages (e.g., toxicology). This important information, together with the
information in OBR-29-parent, uniquely identifies the parent result's
OBX segment related to this order. The value of this OBX segment in the parent
result is the organism or chemical species about which this battery reports.
For example, if the current battery is an antimicrobial susceptibility, the
parent result's identified OBX contains a result which identifies the organism
on which the susceptibility were run. This indirect linkage is preferred
because the name of the organism in the parent result may undergo several
preliminary values prior to finalization.
The third component may be used to record the name of the microorganism
identified by the parent result directly. The organism in this case should be
identified exactly as it is in the parent culture.
We emphasize that this field does not take the entire result field from the
parent. It is meant only for the text name of the organism or chemical
subspecies identified. This field is included only to provide a method for
linking back to the parent result for those systems which could not generate
unambiguous Observation IDs and sub-IDs.
This field is present only when the parent result is identified by
OBR-29-parent and the parent spawn child orders for each of many
results. (See Chapter 7 for more details about this linkage.)
A second mode of conveying this information is to use a standard observation
result segment (OBX). If more than one organism is present,
OBX-4-observation subID is used to distinguish them. In this case, the
first OBX with subID N will contain a value identifying the Nth microorganism,
and each additional OBX with subID N will contain susceptibility values for a
given antimicrobial test on this organism.
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration> ^ <start
date/time (TS)> ^ <end date/time (TS)> ^ <priority (ID)> ^
<condition (ST)> ^ <text (TX)> ^ <conjunction (ID)> ^
<order sequencing> ^ <occurrence duration (CE)> ^ <total
occurrences (NM)>
Definition: This field contains information about how many services to perform
at one service time and how often the service times are repeated, and to fix
duration of the request. See Section 4.2, "Quantity/Timing (TQ)
Definition."
ORC-7-quantity/timing is the same as OBR-27-quantity/timing. If
the ORC-7 and OBR-27 are both valued, then both should be valued exactly the
same. If the quantity/timing is not present in the ORC, it must be present in
the associated OBR. (This rule is the same for other identical fields in the
ORC and OBR and promotes upward and ASTM compatibility.) This is particularly
important when results are transmitted in an ORU message. In this case, the
ORC is not required and the identifying filler order number must be present in
the OBR segments.
For example, if an OBR segment describes a unit of blood, this field might
request that three (3) such units be given on successive mornings. In this
case ORC-7-quantity/timing would be "1^XQAM^X3".
ORC-7-quantity/timing is the same as OBR-27-quantity/timing.
To send information about "collection time", use the `text' component of the TQ
data type in either the ORC-7 or OBR-27. Use the Note segment (NTE) to send
`special instructions' information for a test/service (e.g., draw specimen from
left arm).
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field is the people who are to receive copies of the results.
By local convention, either the ID number or the name may be absent.
Components:
<parent's placer order number (EI)> ^ <parent's filler order number
(EI)>
Subcomponents of parent's placer order number: <entity identifier
(ST)> & <namespace ID (IS)> & <universal ID (ST)> &
<universal ID type (IS)>
Subcomponents of parent's filler order number: <entity identifier
(ST)> & < <namespace ID (IS)> & <universal ID (ST)>
& <universal ID type (IS)>
Definition: This field is identical to ORC-8-parent. This field
relates a child to its parent when a parent/child relationship exists. For
example, observations that are spawned by previous observations, e.g.,
antimicrobial susceptibilities spawned by blood cultures, need to record the
parent (blood culture) filler order number here. The parent/child mechanism is
described under the order control field notes (see Segment ORC field notes in
Section 4.3.1.1.1, "Table notes for order control codes of ORC." It is
required when the order is a child.
Parent is a two-component field. The first component contains the parent's
placer order number. The second component is optional and contains the
parent's filler order number. The components of the placer order number and
the filler order number are transmitted in subcomponents of the two components
of this field.
Definition:
This field identifies how (or whether) to transport a patient, when
applicable. Refer to HL7 Table 0124 - Transportation mode for
valid codes.
Value |
Description |
|---|---|
CART |
Cart - patient travels on cart or gurney |
PORT |
The examining device goes to patient's location |
WALK |
Patient walks to diagnostic service |
WHLC |
Wheelchair |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is the code or text using the conventions for coded
fields given in Chapter 2, Control. This is required for some studies to
obtain proper reimbursement.
Components:
<name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <patient location
type (IS)> ^ <building (IS)> ^ <floor (IS)>
Subcomponents of name: <ID number (ST)> & <family name
(ST)> & <given name (ST)> & <middle initial or name
(ST)> & <suffix (e.g., JR. III) (ST)> & <prefix (e.g.,
DR)> & <degree (e.g., MD) (ST)> & <source table (IS)>
& <assigning authority (HD)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the physician or other clinician who
interpreted the observation and is responsible for the report content.
Components:
<name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <patient location
type (IS)> ^ <building (IS)> ^ <floor (IS)>
Subcomponents of name: <ID number (ST)> & <family name
(ST)> & <given name (ST)> & <middle initial or name
(ST)> & <suffix (e.g., JR. III) (ST)> & <prefix (e.g.,
DR)> & <degree (e.g., MD) (ST)> & <source table (IS)>
& <assigning authority (HD)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the clinical observer who assisted with the
interpretation of this study.
Components:
<name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <patient location
type (IS)> ^ <building (IS)> ^ <floor (IS)>
Subcomponents of name: <ID number (ST)> & <family name
(ST)> & <given name (ST)> & <middle initial or name
(ST)> & <suffix (e.g., JR. III) (ST)> & <prefix (e.g.,
DR)> & <degree (e.g., MD) (ST)> & <source table (IS)>
& <assigning authority (HD)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the performing technician.
Components:
<name (CN)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <patient location
type (IS)> ^ <building (IS)> ^ <floor (IS)>
Subcomponents of name: <ID number (ST)> & <family name
(ST)> & <given name (ST)> & <middle initial or name
(ST)> & <suffix (e.g., JR. III) (ST)> & <prefix (e.g.,
DR)> & <degree (e.g., MD) (ST)> & <source table (IS)>
& <assigning authority (HD)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the report transcriber.
Definition: This field is the date/time the filler scheduled an observation, when applicable (e.g., action code in OBR-11-specimen action code = "S"). 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).
Definition: This field identifies the number of containers for a given sample. For sample receipt verification purposes; may be different from the total number of samples which accompany the order.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is the means by which a sample reaches the diagnostic
service provider. This information is to aid the lab in scheduling or
interpretation of results. Possible answers: routine transport van, public
postal service, etc. If coded, requires a user-defined table.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is for reporting additional comments related to the
sample. If coded, requires a user-defined table. If only free text is reported,
it is placed in the second component with a null in the first component, e.g.,
^difficult clotting after venipuncture and ecchymosis.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is an indicator of who is responsible for arranging
transport to the planned diagnostic service. Examples: Requester, Provider,
Patient. If coded, requires a user-defined table.
Definition:
This field is an indicator of whether transport arrangements are known to have
been made. Refer to HL7 Table 0224 - Transport arranged
for valid codes.
Value |
Description |
|---|---|
A |
Arranged |
N |
Not Arranged |
U |
Unknown |
Definition:
This field is an indicator that the patient needs to be escorted to the
diagnostic service department. Note: The nature of the escort requirements
should be stated in the OBR-43-planned patient transport comment
field. See HL7 Table 0225 - Escort required for valid values.
Value |
Description |
|---|---|
R |
Required |
N |
Not Required |
U |
Unknown |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is the code or free text comments on special
requirements for the transport of the patient to the diagnostic service
department. If coded, requires a user-defined table.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a unique identifier assigned to the procedure,
if any, associated with the Universal Service ID reported in field 4.
User-defined Table 0088 - Procedure code is used as the HL7 identifier
for the user-defined table of values for this field. This field is a CE data
type for compatibility with clinical and ancillary systems. This field will
usually contain the HCPCS code associated with the order.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the procedure code modifier to the procedure
code reported in field 44, when applicable. Procedure code modifiers are
defined by regulatory agencies such as HCFA and the AMA. Multiple modifiers
may be reported. User-defined Table 0088 - Procedure code is used as the
HL7 identifier for the user-defined table of values for this field.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains supplemental service information sent from the
placer system to the filler system for the universal procedure code reported in
OBR-4 Universal Service ID. This field will be used to provide ordering
information detail that is not available in other, specific fields in the OBR
segment. Multiple supplemental service information elements may be reported.
Refer to User-defined table 0411 - Supplemental service information
values for suggested values.
This field can be used to describe details such as whether study is to be done
on the right or left, for example where the study is of the arm and the order
master file does not distinguish right from left or whether the study is to be
done with or without contrast (when the order master file does not make such
distinctions).
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains supplemental service information sent from the
filler system to the placer system for the procedure code reported in OBR-4
Universal Service ID. This field will be used to report ordering
information details that is not available in other, specific fields in the OBR
segment. Typically it will reflect the same information as was sent to the
filler system in OBR-46-Placer supplemental information unless the
order was modified in which case the filler system will report what was
actually performed using this field. Multiple supplemental service information
elements may be reported. Refer to User-defined Table 0411 -
Supplemental service information values for suggested values.
This field can be used to describe details such as whether study is to be done
on the right or left, for example where the study is of the arm and the order
master file does not distinguish right from left or whether the study is to be
done with or without contrast (when the order master file does not make such
distinctions).
Value |
Description |
|---|---|
1ST |
First |
2ND |
Second |
3RD |
Third |
4TH |
Fourth |
5TH |
Fifth |
ANT |
Anterior |
A/P |
Anterior/Posterior |
BLT |
Bilateral |
DEC |
Decubitus |
DST |
Distal |
LAT |
Lateral |
LFT |
Left |
LLQ |
Left Lower Quadrant |
LOW |
Lower |
LUQ |
Left Upper Quadrant |
MED |
Medial |
OR |
Operating Room |
PED |
Pediatric |
POS |
Posterior |
PRT |
Portable |
PRX |
Proximal |
REC |
Recumbent |
RLQ |
Right Lower Quadrant |
RGH |
Right |
RUQ |
Right Upper Quadrant |
UPP |
Upper |
UPR |
Upright |
WCT |
With Contrast |
WOC |
Without Contrast |
WSD |
With Sedation |
Individual implementations may extend this table using other appropriate vocabularies.
The
OBX segment is used to transmit a single observation or observation fragment.
It represents the smallest indivisible unit of a report. Its structure is
summarized in Figure 7-5.
Its principal mission is to carry information about observations in report
messages. But the OBX can also be part of an observation order (see Section
4.2, "Order Message Definitions"). In this case, the OBX carries clinical
information needed by the filler to interpret the observation the filler makes.
For example, an OBX is needed to report the inspired oxygen on an order for a
blood oxygen to a blood gas lab, or to report the menstrual phase information
which should be included on an order for a pap smear to a cytology lab.
Appendix 7A includes codes for identifying many of pieces of information needed
by observation producing services to properly interpret a test result. OBX is
also found in other HL7 messages that need to include patient clinical
information.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
O |
00569 |
Set ID - OBX |
||
2 |
2 |
ID |
C |
0125 |
00570 |
Value Type |
|
3 |
250 |
CE |
R |
00571 |
Observation Identifier |
||
4 |
20 |
ST |
C |
00572 |
Observation Sub-ID |
||
5 |
65536[1] |
* |
C |
Y[2] |
00573 |
Observation Value |
|
6 |
250 |
CE |
O |
00574 |
Units |
||
7 |
60 |
ST |
O |
00575 |
References Range |
||
8 |
5 |
IS |
O |
Y/5 |
0078 |
00576 |
Abnormal Flags |
9 |
5 |
NM |
O |
00577 |
Probability |
||
10 |
2 |
ID |
O |
Y |
0080 |
00578 |
Nature of Abnormal Test |
11 |
1 |
ID |
R |
0085 |
00579 |
Observation Result Status |
|
12 |
26 |
TS |
O |
00580 |
Date Last Observation Normal Value |
||
13 |
20 |
ST |
O |
00581 |
User Defined Access Checks |
||
14 |
26 |
TS |
O |
00582 |
Date/Time of the Observation |
||
15 |
250 |
CE |
O |
00583 |
Producer's ID |
||
16 |
250 |
XCN |
O |
Y |
00584 |
Responsible Observer |
|
17 |
250 |
CE |
O |
Y |
00936 |
Observation Method |
|
18 |
22 |
EI |
O |
Y |
01479 |
Equipment Instance Identifier |
|
19 |
26 |
TS |
O |
01480 |
Date/Time of the Analysis |
Definition: This field contains the sequence number. For compatibility with ASTM.
Definition:
This field contains the format of the observation value in OBX. It must be
valued if OBX-11-Observ result status is not valued with an `X". If the
value is CE then the result must be a coded entry. When the value type is TX
or FT then the results are bulk text. The valid values for the value type of
an observation are listed in HL7 Table 0125 - Value type.
The observation value must be represented according to the format for the data
type defined in Chapter 2, Section 2.9, "Data Types." For example, a PN
consists of 6 components, separated by component delimiters.
Although NM is a valid type, observations which are usually reported as numbers
will sometimes have the string (ST) data type because non-numeric characters
are often reported as part of the result, e.g., >300 to indicate the result
was off-scale for the instrument. In the example, ">300", ">" is a
symbol and the digits are considered a numeric value. However, this usage of
the ST type should be discouraged since the SN (structured numeric) data type
now accommodates such reporting and, in addition, permits the receiving system
to interpret the magnitude.
All HL7 data types are valid, and are included in Table 0125 except CM, CQ, SI,
and ID. For a CM definition to have meaning, the specifics about the CM must
be included in the field definition. OBX-5-observation value is a
general field definition that is influenced by the data type OBX-3, so
CMs are undefined in this context. CQ is invalid because units for
OBX-5-observation value are always specified explicitly in an OBX
segment with OBX-6 units. SI is invalid because it only applied to HL7
message segments, and ID because it requires a constant field definition.
The RP value (reference pointer) must be used if the actual observation value
is not sent in OBX but exists somewhere else. For example, if the observation
consists of an image (document or medical), the image itself cannot be sent in
OBX. The sending system may in that case opt to send a reference pointer. The
receiving system can use this reference pointer whenever it needs access to the
actual image through other interface standards, e.g., DICOM, or through
appropriate data base servers.
Value |
Description |
|---|---|
AD |
Address |
CE |
Coded Entry |
CF |
Coded Element With Formatted Values |
CK |
Composite ID With Check Digit |
CN |
Composite ID And Name |
CP |
Composite Price |
CX |
Extended Composite ID With Check Digit |
DT |
Date |
ED |
Encapsulated Data |
FT |
Formatted Text (Display) |
MO |
Money |
NM |
Numeric |
PN |
Person Name |
RP |
Reference Pointer |
SN |
Structured Numeric |
ST |
String Data. |
TM |
Time |
TN |
Telephone Number |
TS |
Time Stamp (Date & Time) |
TX |
Text Data (Display) |
XAD |
Extended Address |
XCN |
Extended Composite Name And Number For Persons |
XON |
Extended Composite Name And Number For Organizations |
XPN |
Extended Person Name |
XTN |
Extended Telecommunications Number |
The
full definition of these data types is given in Chapter 2, Section 2.9, "Data
Types." The structured numeric (SN) data type, new to version 2.3, provides
for reporting ranges (e.g., 3-5 or 10-20), titres (e.g., 1:10), and
out-of-range indicators (e.g., >50) in a structured and computer
interpretable way.
We allow the FT data type in the OBX segment but its use is discouraged.
Formatted text usually implies a meaningful structure e.g., a list of three
independent diagnoses reported on different lines. But ideally, the structure
in three independent diagnostic statements would be reported as three separate
OBX segments.
TX should not be used except to send large amounts of text. In the TX
data type, the repeat delimiter can only be used to identify paragraph breaks.
Use ST to send short, and possibly encodable, text strings.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a unique identifier for the observation. The
format is that of the Coded Element (CE). Example: 8625-6^P-R interval^LN.
In most systems the identifier will point to a master observation table
that will provide other attributes of the observation that may be used by the
receiving system to process the observations it receives. A set of message
segments for transmitting such master observation tables is described in
Chapter 8. The relation of an observation ID to a master observation table is
analogous to the relationship between a charge code (in a billing record) and
the charge master.
When local codes are used as the first identifier in this field we strongly
encourage sending a 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). LOINC® is an HL7 approved code system for the Observation
identifier. It covers observations and measurements, such as laboratory tests,
physical findings, radiology studies, and claims attachments and can be
obtained from www.regenstrief.org/loinc/loinc.ht
m.
One possible universal identifier is LOINC® codes for laboratory
and clinical measurements (see User-defined Table 0396 and the HL7
www list server) and Appendix X2 of ASTM E1467 for neurophysiology tests.
Definition:
This field is used to distinguish between multiple OBX segments with the same
observation ID organized under one OBR. For example, a chest X-ray report
might include three separate diagnostic impressions. The standard requires
three OBX segments, one for each impression. By putting a 1 in the Sub-ID of
the first of these OBX segments, 2 in the second, and 3 in the third, we can
uniquely identify each OBX segment for editing or replacement.
The sub-identifier is also used to group related components in reports such as
surgical pathology. It is traditional for surgical pathology reports to
include all the tissues taken from one surgical procedure in one report.
Consider, for example, a single surgical pathology report that describes the
examination of gallbladder and appendix tissue. This report would be
transmitted roughly as shown in Figure 7-2.
Distinct Observations |
88304&ANT |
88304&GDT |
80304&MDT |
80304&IMP |
Sub ID 1st Group |
1 |
1 |
1 |
1 |
Sub ID 2nd Group |
2 |
2 |
2 |
2 |
The
use of Sub IDs to group results is equivalent to defining a table, and the use
of sub IDs to distinguish repeats is just a special case, represented by one
column in this table.
However, this approach introduces ambiguities if we have a set of repeating
observations within a group, e.g., if the appendix observations include two
impressions as in the 8th and 9th OBXs shown in Figure 7-7. This really
represents the existence of a row nested within a single cell of the table
given above.
Definition:
This field contains the value observed by the observation producer.
OBX-2-value type contains the data type for this field according to
which observation value is formatted. It is not a required field because some
systems will report only the normalcy/abnormalcy (OBX-8), especially in
product experience reporting.
Representation
This field contains the value of OBX-3-observation identifier of the
same segment. Depending upon the observation, the data type may be a number
(e.g., a respiratory rate), a coded answer (e.g., a pathology impression
recorded as SNOMED), or a date/time (the date/time that a unit of blood is sent
to the ward). An observation value is always represented as the data type
specified in OBX-2-value type of the same segment. Whether numeric or
short text, the answer shall be recorded in ASCII text.
Reporting logically independent observations
The main sections of dictated reports, such as radiologic studies or history
and physicals, are reported as separate OBX segments. In addition, each
logically independent observation should be reported in a separate OBX segment,
i.e. one OBX segment should not contain the result of more than one
logically independent observation. This requirement is included to assure that
the contents of OBX-6-units, OBX-8-abnormal flags, and
OBX-9-probability can be interpreted unambiguously. The electrolytes
and vital signs batteries, for example, would each be reported as four separate
OBX segments. Two diagnostic impressions, e.g., congestive heart failure and
pneumonia, would also be reported as two separate OBX segments whether reported
as part of a discharge summary or chest X-ray report. Similarly, two bacterial
organisms isolated in a single bacterial culture would be reported as two
separate OBX segments.
Though two independent diagnostic statements cannot be reported in one
OBX segment, multiple categorical responses are allowed (usually as CE data
types separated by repeat delimiters), so long as they are fragments
(modifiers) that together construct one diagnostic statement. Right upper lobe
(recorded as one code) and pneumonia (recorded as another code), for example,
could be both reported in one OBX segment. Such multiple "values" would be
separated by repeat delimiters.
Multiple OBX segments with the same observation ID and Sub ID
In some systems, a single observation may include fragments of more than
one data type. The most common example is a numeric result followed by coded
comments (CE). In this case, the logical observation can be sent in more than
one OBX segment. For example, one segment of numeric or string data type for
the numeric result and another segment of CE data type for coded comments. If
the producer was reporting multiple coded comments they would all be sent in
one OBX segment separated by repeat delimiters because they all modified a
single logical observation. Multiple OBX segments with the same observation ID
and sub ID should always be sent in sequence with the most significant OBX
segment (the one that has the normal flag/units and or reference range and
status flag) first. The value of OBX-6 through 12 should be null in any
following OBX segments with the same OBX-3-observation identifier and
OBX-4-observation sub-ID. For the purpose of replacement or deletion,
multiple OBX segments with the same observation ID and sub ID are treated as a
unit. If any are replaced or deleted, they all are replaced.
Coded values
When an OBX segment contains values of CE data types, the observations are
stored as a combination of codes and/or text. In Section 7.5.3, "CSS -
clinical study data schedule segment," examples of results that are represented
as CE data types are shown in the first and second OBX segments of OBR 1 and
the first and second OBX segments of OBR 2. The observation may be an
observation battery ID (for recommended studies), a diagnostic code or finding
(for a diagnostic impression), or an anatomic site for a pathology report, or
any of the other kinds of coded results.
It is not necessary to always encode the information stored within a coded
observation. For example, a chest X-ray impression could be transmitted as
pure text even though it has a CE data type. In this case, the test must be
recorded as the second component of the result code, e.g.,
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE.|...<cr>
However, separate impressions, recommendations, etc., even if recorded as pure
text, should be recorded in separate result segments. That is, congestive
heart failure and pneumonia should not be sent as:
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE AND
PNEUMONIA|...<cr>
but as:
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE|...<cr>
OBX|2|CE|71020&IMP|2|^PNEUMONIA|....<cr>
Even better would be fully-coded results that include computer understandable
codes (component 1) instead of, or in addition to, the text description
(component 2). One may include multiple values in a CE value and these can be
mixtures of code and text, but only when they are needed to construct one
diagnosis, impression, or concept. When text follows codes as an independent
value it would be taken as a modifier or addenda to the codes. E.g.,
OBX|1|CE|710120&IMP^CXR|1|428.0^CONGESTIVE HEART FAILURE^I9C~^MASSIVE
HEART|...<cr>
The text in component 2 should be an accurate description of the code in
component 1. Likewise, if used, the text in component 5 should be an accurate
description of the code in component 4.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Background: When an observation's value is measured on a continuous scale, one
must report the measurement units within the units field of the OBX segment.
Since HL7 Version 2.2 of the specification, all fields that contain units are
of data type CE. The default coding system for the units codes consists of the
ISO abbreviation for a single case unit (ISO 2955-83) plus extensions that do
not collide with ISO abbreviations. We designate this coding system as ISO+
(see Figure 7-13). Both the ISO unit's abbreviations and the extensions are
defined in Section 7.4.2.6.2, "ISO and ANSI customary units abbreviations."
The ISO+ abbreviations are the codes for the default coding system.
Consequently, when ISO+ units are being used, only ISO+ abbreviations need be
sent, and the contents of the units field will be backward compatible to HL7
Version 2.1.
We
strongly encourage observation producers to use ISO+ abbreviated units
exclusively, but permit the use of other code systems, including US customary
units (ANSI X3.50) and locally defined codes where necessary. Local units are
designated L or 99zzz where z is an alphanumeric character (see Figures
7-2 and 73). ANSI X3.50 - 1986 provides an excellent description of these
standards, as well as a table of single case abbreviations for US customary
units such as foot or gallon.
We had originally intended to include the ANSI X3.50 - 1986 US customary units
in the default ISO+ coding system. However, there are overlaps between ISO's
abbreviations and the abbreviations for US customary units. For example,
ft is the abbreviation for foot in US customary units and for femtotesla
in ISO; pt is the abbreviation for pint in US customary and for
picotesla in ISO. (Be aware that the ANSI document also differs from the ISO
document regarding the abbreviation of a few ISO units, as well.) In order to
avoid potential ambiguity, we have defined another coding system, designated
ANS+. It includes the US customary units (e.g., feet, pounds) and ISO
abbreviations defined in ANSI X3.50 - 1986, as well as other non-metric units
listed in Figure 7-13 and the ISO combinations of these units. Be aware that a
few of the ANSI ISO unit abbreviations differ from their abbreviations
in ISO (see note at bottom of Figure 7-13).
Because the ANS+ specification includes both ISO and US customary units,
as well as miscellaneous non-metric units, some of the abbreviations are
ambiguous. Although there should be little confusion, in the context of a
particular observation, this ambiguity is a good reason for avoiding ANS+ unit
codes when possible.
When ANS+ units codes (abbreviations) are being transmitted, ANS+ must
be included in the third (sixth) component of the field. If the units of
distance were transmitted as meters (ISO+) it would be transmitted as m
because ISO+ is the default coding system for units. However, if transmitted
in the US customary units of feet, the units would be transmitted as
ft^^ANS+. When required, the full text of the units can be sent as the
second component in keeping with the CE data type conventions.
Both ISO and ANSI also provide a set of mixed case abbreviations, but these
abbreviations cannot be translated to single case without loss of meaning, and
should not be used in this specification whose content is required to be case
insensitive.
ISO
builds its units from seven base dimensions measured as meters, kilograms,
seconds, amperes, kelvins, moles and candelas (see Figure 7-6). Other units
can be derived from these by adding a prefix to change the scale and/or by
creating an algebraic combination of two or more base or derived units.
However, some derived units have acquired their own abbreviations (see Figure
7-6). Abbreviations for U.S. customary units are given in Figure 7-6.
The ISO rules, well explained in ANSI X3.50, provide a way to create units of
different scales by adding multiplier prefixes. These prefixes can be
expressed as words or abbreviations. In this Standard we are only
concerned with the abbreviations.
Units |
Abbreviation |
Units |
Abbreviation |
Units |
Abbreviation |
Base units code/abbreviations |
|||||
ampere |
a |
kelvin |
k |
meter |
m |
candela |
cd |
Kilogram |
kg |
mole |
mol |
second |
s |
||||
Derived units with specified name and abbreviation |
|||||
coulomb |
c |
hour |
Hr |
pascal |
pal |
day |
d |
joule |
J |
volt |
v |
degree Celsius |
cel |
minute (ti) |
Min |
watt |
w |
farad |
f |
newton |
N |
weber |
wb |
hertz |
hz |
ohm |
Ohm |
year |
ann |
Other units |
|||||
atomic mass unit |
u |
grey |
gy |
minute of arc |
mnt |
Bel |
b |
henry |
h |
radian |
rad |
Decibel |
db |
liter |
l |
siemens |
sie |
Degree |
deg |
lumen |
Lm |
steradian |
sr |
Gram |
g |
lux |
Lx |
tesla |
t |
See ISO 2955-1983 for full set |
The
ISO abbreviations for multiplier prefixes are given in Figure 7-12. Prefixes
ranging from 10-24 (1/billion billionth) to 1024 (a
billion billion) are available. The single case abbreviation for kilo (x1000)
is k. A unit consisting of 1000 seconds would be abbreviated as
ks, 1000 grams as kg, 1000 meters as km, and so on. Some
prefixes share the abbreviation of a base unit. Farad and femto, for example,
(10-18) both have the abbreviation of f. To avoid confusion,
ISO forbids the use of solitary prefixes. It also deprecates the use of two
prefixes in one complex unit. Thus, f always means farad, ff
would mean 1 million billionth of a farad. Compound prefixes are not
allowed.
A unit can be raised to an exponential power. Positive exponents are
represented by a number immediately following a unit's abbreviation, i.e., a
square meter would be denoted by m2. Negative exponents are signified by a
negative number following the base unit, e.g., 1/m2 would be
represented as m-2. Fractional exponents are expressed by a numeric
fraction in parentheses: the square root of a meter would be expressed as
m(1/2). The multiplication of units is signified by a period (.) between the
units, e.g., meters X seconds would be denoted m.s. Notice that spaces
are not permitted. Division is signified by a slash (/) between two units,
e.g. meters per second would be denoted as m/s. Algebraic combinations
of ISO unit abbreviations constructed by dividing, multiplying, or
exponentiating base ISO units, are also valid ISO abbreviations units.
Exponentiation has precedence over multiplication or division. For example,
microvolts squared per hertz (a unit of spectral power) would be denoted
uv2/hz and evaluated as uv 2/hz while microvolts
per square root of hertz (a unit of spectral amplitude) would be denoted
uv/hz(1/2) and evaluated as uv/hz½. If more than one division
operator is included in the expression the associations should be parenthesized
to avoid any ambiguity, but the best approach is to convert a/(b/c) to a.c/b or
a.c.b-1 to simplify the expression.
The ISO code is a grammar for building units. The rules for building these
units are found in Figures 7-6 and 7-8. Figure 7-7 should be used only with
English units and should not be used in conjunction with Figure 7-8. The ISO+
table (Figure 7-13) includes the most common such units constructed from this
grammar (as well as important non-ISO units). Other ISO units derived from the
grammar are valid as well.
Units |
Abbreviation |
Units |
Abbreviation |
Units |
Abbreviation |
LENGTH |
VOLUME |
TIME |
|||
inch |
in |
cubic foot |
cft |
year |
yr |
foot |
ft |
cubic inch |
cin |
month |
mo |
mile (statute) |
mi |
cubic yard |
cyd |
week |
wk |
nautical mile |
nmi |
tablespoon |
tbs |
day |
d |
rod |
rod |
teaspoon |
tsp |
hour |
hr |
yard |
yd |
pint |
pt |
minute |
min |
quart |
qt |
second |
sec |
||
gallon |
gal |
||||
ounce (fluid) |
foz |
||||
AREA |
MASS |
||||
square foot |
sqf |
dram |
dr |
||
square inch |
sin |
grain |
gr (avoir) |
||
square yard |
syd |
ounce (weight) |
oz |
||
pound |
lb |
||||
Other ANSI units, derived units, and miscellaneous |
|||||
**British thermal unit |
btu |
**degrees Fahrenheit |
degf |
**millirad |
mrad |
cubic feet/minute |
cft/min |
**feet/minute |
ft/min |
**RAD |
rad |
Note: The abbreviations for conventional U.S. units of time are the same as ISO, except for year. ISO = ANN, AMSI = yr. The metric units in X3.50 are the same as ISO, except for: pascal ("pa" in ANSI, "pal" in ISO); ANSI uses "min" for both time and arc while ISO uses "mnt" for minutes of arc; and in ISA seconds are abbreviated "s", in ANSI, "sec". |
|||||
This list is not exhaustive. Refer to ANSI X3.50-1986, Table 1, for other metric and standard U.S. units. |
|||||
**Non-metric units not explicitly listed in ANSI |
Prefix |
Code |
Prefix |
Code |
||
|---|---|---|---|---|---|
yotta* |
1024 |
ya |
yocto |
10-24 |
y |
zetta* |
1021 |
za |
zepto |
10-21 |
z |
exa |
1018 |
ex |
atto |
10-18 |
a |
peta |
1015 |
pe |
femto |
10-15 |
f |
tera |
1012 |
t |
pico |
10-12 |
p |
giga |
109 |
g |
nano |
10-9 |
n |
mega |
106 |
ma |
micro |
10-6 |
u |
kilo |
103 |
k |
milli |
10-3 |
m |
hecto |
102 |
h |
centi |
10-2 |
c |
deca |
101 |
da |
deci |
10-1 |
d |
*These abbreviations are not defined in the ISO specification for single case abbreviations. |
Figure
7-9 lists the abbreviations for common ISO derived units. It also includes
standard unit abbreviations for common units, e.g., Milliequivalents, and
international units, mm(Hg), and for counting per which we denote by a division
sign, a denominator, but no numerator, e.g., /c, that are not part of the above
referenced ISO standards. We have extended the units table to better
accommodate drug routes and physiologic measures, and otherwise fill in gaps in
Version 2.2.
We have generally followed the IUPAC 1995 Silver Book2 in the
definitions of units. However, IUPAC specifies standards for reporting or
displaying units and employs 8-bit data sets to distinguish them. This Standard
is concerned with the transmission of patient information. Therefore, we
have restricted ourselves to case insensitive alphabetic characters and a few
special characters (e.g., ".", "/", "(", ")", "*", and "_") to avoid any
possible confusion in the transmission. Therefore, we use ISO 2955-1983
(Information processing -- representation of SI and other units in systems with
limited character sets) and ANSI X3.50-1986 (Representations for U.S.
customary, SI, and other units to be used in systems with limited character
sets) case insensitive units abbreviations where they are defined. This means
that in some cases, IUPAC abbreviations have different abbreviations in ISO+
even when the IUPAC abbreviations use only standard alphabetic characters. For
example, Pascal is abbreviated Pa in IUPAC but PAL in ISO+
(following ISO 2955) because Pa in a case insensitive context also means
Picoampere. However, the requirements for transmission do not preclude
usage of IUPAC standards for presentation on paper or video display reports to
end-users.
All unit abbreviations are case insensitive. One could write milliliters as ML,
ml, or mL. In this table we have used lower case for all of the abbreviations
except for the letter L which we represent in upper case so that readers
will not confuse it with the numeral one (1). This is just a change in
presentation, not a change in the Standard. Systems should continue to
send the codes as upper or lower case as they always have.
Refer to section 7.18.4 for the contents of figure 7-9 - Common ISO derived
units & ISO+ extensions.
Local codes can be used for the units by indicating the code source of 99zzz in the third component (where 99zzz is an alpha-numeric string). In the case of local codes, the text name of the codes or the description of the units should also be transmitted (in the second component), so that the receiving system can compare the results with results for the same measurement sent by another service (refer to Chapter 2, Section 2.9, "Data Types"). An "L" should be stored in the third component to indicate that the code is locally defined. More specialized local code designations, as specified in the CE data type definition, can also be employed.
Components:
for numeric values in the format:
d) lower limit-upper limit (when both lower and upper limits are defined, e.g.,
for potassium 3.5 - 4.5)
e) > lower limit (if no upper limit, e.g., >10)
f) < upper limit (if no lower limit, e.g., <15)
alphabetical values: the normal value may be reported in this location
Definition: When the observation quantifies the amount of a toxic substance,
then the upper limit of the range identifies the toxic limit. If the
observation quantifies a drug, the lower limits identify the lower therapeutic
bounds and the upper limits represent the upper therapeutic bounds above which
toxic side effects are common.
Definition:
This field contains a table lookup indicating the normalcy status of the
result. We strongly recommend sending this value when applicable. (See ASTM
1238 - review for more details). Refer to User-defined Table 0078 -
Abnormal flags for valid entries.
When the laboratory can discern the normal status of a textual report, such as
chest X-ray reports or microbiologic culture, these should be reported as N
when normal and A when abnormal. Multiple codes, e.g., abnormal and worse,
would be separated by a repeat delimiter, e.g., A~W.
Value |
Description |
|---|---|
L |
Below low normal |
H |
Above high normal |
LL |
Below lower panic limits |
HH |
Above upper panic limits |
< |
Below absolute low-off instrument scale |
> |
Above absolute high-off instrument scale |
N |
Normal (applies to non-numeric results) |
A |
Abnormal (applies to non-numeric results) |
AA |
Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units) |
null |
No range defined, or normal ranges don't apply |
U |
Significant change up |
D |
Significant change down |
B |
Better--use when direction not relevant |
W |
Worse--use when direction not relevant |
S |
Susceptible. Indicates for microbiology susceptibilities only. |
R |
Resistant. Indicates for microbiology susceptibilities only. |
I |
Intermediate. Indicates for microbiology susceptibilities only. |
MS |
Moderately susceptible. Indicates for microbiology susceptibilities only. |
VS |
Very susceptible. Indicates for microbiology susceptibilities only. |
Results may also be reported in shorthand by reporting the normalcy status without specifying the exact numeric value of the result. Such shorthand is quite common in clinical notes, where physicians will simply say that the glucose result was normal. Such shorthand reporting is also seen in drug experience reporting. In such cases, the result can be reported in the OBX by reporting the normalcy code in OBX-8-abnormal flags without specifying any value in OBX-5-observation value.
Definition: This field contains 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.
Definition:
This field contains the nature of the abnormal test. Refer to HL7 Table
0080 - Nature of abnormal testing for valid values. As many of the
codes as apply may be included, separated by repeat delimiters. For example,
normal values based on age, sex, and race would be codes as A~S~R.
Value |
Description |
|---|---|
A |
An age-based population |
N |
None - generic normal range |
R |
A race-based population |
S |
A sex-based population |
Definition:
This field contains the observation result status. Refer to HL7 table 0085
- Observation result status codes interpretation for valid values.
This field reflects the current completion status of the results for one
Observation Identifier.
It is a required field. Previous versions of HL7 stated this implicitly by
defining a default value of "F." Code F indicates that the result has
been verified to be correct and final. Code W indicates that the result
has been verified to be wrong (incorrect); a replacement (corrected) result may
be transmitted later. Code C indicates that data contained in the
OBX-5-observation value field are to replace previously transmitted
(verified and) final result data with the same observation ID (including
suffix, if applicable) and observation sub-ID usually because the previous
results were wrong. Code D indicates that data previously transmitted
in a result segment with the same observation ID (including suffix) and
observation sub-ID should be deleted. When changing or deleting a result,
multiple OBX segments with the same observation ID and observation sub-ID are
replaced or deleted as a unit. Normal progression of results through
intermediate (e.g., `gram positive cocci') to final (e.g., `staphylococcus
aureus') should not be transmitted as C (correction); they should be
transmitted as P or S (depending upon the specific case) until
they are final.
There are situations where the observation battery required for the order needs
to be dynamically specified at the time of ordering. That is, this battery is
then defined by the set of OBX segments transmitted along with the order and
generated by the placing system. For example, timed measurements of
serum glucose challenge tests may vary among laboratories. One institution may
report them at -30, -15, 0, 30, 60, and 120 minutes, while another may report
them at -30, 0, 30, 60, 90, and 120 minutes. Master file entries may exist for
each individual element of the battery but not for the battery itself. Another
example may be Renin Studies where the specification may be done upon ordering
without having a master file definition for each permutation of the possible
element. The OBX segments in the ORM message can be used to create dynamic
specifications to accommodate these permutations without defining pre-existing
master file definitions for the battery itself. The result status field in the
OBX can be used to indicate whether the OBX in the ORM message is used to
provide a dynamic specification or is used to communicate a result as context
to the order. The status of O shall be used to indicate that the OBX segment is
used for a dynamic specification of the required result. An OBX used for a
dynamic specification must contain the detailed examination code, units, etc.,
with OBX-11 valued with O, and OBX-2 and OBX-5 valued with
null.
Value |
Description |
|---|---|
C |
Record coming over is a correction and thus replaces a final result |
D |
Deletes the OBX record |
F |
Final results; Can only be changed with a corrected result. |
I |
Specimen in lab; results pending |
N |
Not asked; used to affirmatively document that the observation identified in the OBX was not sought when the universal service ID in OBR-4 implies that it would be sought. |
O |
Order detail description only (no result) |
P |
Preliminary results |
R |
Results entered -- not verified |
S |
Partial results |
X |
Results cannot be obtained for this observation |
U |
Results status change to final without retransmitting results already sent as `preliminary.' E.g., radiology changes status from preliminary to final |
W |
Post original as wrong, e.g., transmitted for wrong patient |
Definition:
This field contains the changes in the observation methods that would make
values obtained from the old method not comparable with those obtained from the
new method.
Null if there are no normals or units. If present, a change in this date
compared to date-time recorded, the receiving system's test dictionary should
trigger a manual review of the results to determine whether the new observation
ID should be assigned a new ID in the local system to distinguish the new
results from the old.
Definition:
This field permits the producer to record results-dependent codes for
classifying the observation at the receiving system. This field should be
needed only rarely, because most classifications are fixed attributes of the
observation ID and can be defined in the associated observation master file
(see description in Chapter 8).
However, there are a few cases when such controls vary with the value of the
observation in a complex way that the receiving system would not want to
re-calculate. An example is an antimicrobial susceptibility result. Some
systems prefer to display only the susceptibility results of inexpensive
antimicrobials depending upon the organism, the source of the specimen and the
patient's allergy status. The sending service wants to send all of the
susceptibilities so that certain privileged users (e.g., Infectious Disease
specialists) can review all of the results but nonprivileged users would see
only the "preferred" antimicrobials to which the organism was susceptible. We
expect that other cases also occur.
Definition:
This field is required in two circumstances. The first is when the
observations reported beneath one report header (OBR) have different
dates/times. This could occur in the case of queries, timed test sequences, or
clearance studies where one measurement within a battery may have a different
time than another measurement.
It is also needed in the case of OBX segments that are being sent by the placer
to the filler, in which case the date of the observation being transmitted is
likely to have no relation to the date of the requested observation. In
France, requesting services routinely send a set of the last observations along
with the request for a new set of observations. The date of these observations
is important to the filler laboratories.
In all cases, the observation date-time is the physiologically relevant
date-time or the closest approximation to that date-time. In the case of tests
performed on specimens, the relevant date-time is the specimen's collection
date-time. In the case of observations taken directly on the patient (e.g.,
X-ray images, history and physical), the observation date-time is the date-time
that the observation was performed.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a unique identifier of the responsible
producing service. It should be reported explicitly when the test results are
produced at outside laboratories, for example. When this field is null, the
receiving system assumes that the observations were produced by the sending
organization. This information supports CLIA regulations in the US. The code
for producer ID is recorded as a CE data type. In the US, the Medicare number
of the producing service is suggested as the identifier.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: When required, this field contains the identifier of the
individual directly responsible for the observation (i.e., the person who
either performed or verified it). In a nursing service, the observer is
usually the professional who performed the observation (e.g., took the blood
pressure). In a laboratory, the observer is the technician who performed or
verified the analysis. The code for the observer is recorded as a CE data
type. If the code is sent as a local code, it should be unique and unambiguous
when combined with OBX-15-producer ID.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
This optional field can be used to transmit the method or procedure by which an
observation was obtained when the sending system wishes to distinguish among
one measurement obtained by different methods and the distinction is not
implicit in the test ID. Chemistry laboratories do not usually distinguish
between two different methods used to measure a given serum constituent (e.g.,
serum potassium) as part of the test name. See the LOINC® Users Manual[3] for a more complete discussion of these
distinctions. If an observation producing service wanted to report the method
used to obtain a particular observation, and the method was NOT embedded in the
test name, they can use this field.
The Centers for Disease Control and Prevention (CDC) Method Code (CDCM) (see
Figure 7-3) is one candidate code system for reporting methods/instruments.
EUCLIDES method codes are another. User-defined tables are an alternative.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field identifies the Equipment Instance (e.g., Analyzer,
Analyzer module, group of Analyzers,...) responsible for the production of the
observation. This is the identifier from an institution's master list of
equipment, where the institution is specified by the namespace ID or if
it is blank, then by the "Producer's ID" (OBX-15). It should be possible to
retrieve from this master list the equipment type, serial number, etc., however
it is not planned to transfer this information with every OBX. The repeating of
this field allows for the hierarchical representation of the equipment (lowest
level first), e.g., module of an instrument, instrument consisting of modules,
cluster of multiple instruments, etc.
Definition: This field is used to transfer the time stamp associated with generation of the analytical result by the instrument specified in Equipment Instance Identifier (see above).
The
following 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/88.
These examples use LOINC® clinical codes. The response ends with a
continuation pointer. A continuation query follows, in reply to which a
continuation response is sent.
Query (QRY)
MSH|^~\&|CBD||EKG||198905201200||QRY^R02|CDB22222|P|...<cr>
QRD|198904180943|R|I|Q4412|||10|RD|0123456-1|RES|...<cr>
QRF|EKG||198801010000|...<cr>
Response
MSH|^~\&|EKG||CDB||198905201201||ORF^R04|X981672|P|...<cr>
MSA|AA|CDB22222|P|...<cr>
QRD|198904180943|R|I|Q4412|||10|RD|0123456-1|RES|...<cr>
QRF|EKG||198804010000|...<cr>
PID|1||0123456-1||ROBERTSON^JOHN^H||||||||982-1111|...<cr>
OBR|1|43215^OE|98765^EKG|93000^EKG REPORT|
||198801111330|||1235^TAYLOR^ROBERT^M||||
198801111330||P030||||||198801120930||||||P011^PRESLEY^ELVIS^AARON^^^MD|43214^OE|...<cr>
OBX|1|ST|8897-1^QRS COMPLEX^LN||91|/MIN|60-100||||F|...<cr>
OBX|2|ST|8894-8^P WAVE^LN||92|/MIN|60-100||||F|...<cr>
OBX|3|ST|8625-6^P-R INTERVAL^LN||0|/MSEC|1.06-.10||||F|...<cr>
OBX|4|ST|8633-0^QRS DURATION^LN||.368|/MSEC|.18-.22||||F|...<cr>
...
...
...
OBX|8|CE|8601-7^EKG IMPRESSION^LN|1|^ATRIAL FIBRILATION||||||F|...<cr>
OBX|9|CE|8601-7^EKG IMPRESSION^LN|2|^ST DEPRESSION||||||F|...<cr>
OBX|10|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.|||||F|...<cr>
OBR|2|43217^OE|98767^EKG|93000^EKG
REPORT|||198810311004|||||||198810311004||P030||||||198810311744||||||
P011^PRESLEY^ELVIS^AARON^^^MD |43213^OE |...<cr>
...
...
...
DSC|1896X22;0123456-1|...<cr>
Continuation query
MSH|^~\&|CDB||EKG||198905201204||QRY^R02|CDB22289|P|...<cr>
QRD|198904180943|R|I|Q4412|||10|RD|0123456-1|RES|...<cr>
QRF|EKG||1988040100000|...<cr>
DSC|1896X22;0123456-1|...<cr>
Continuation response
MSH|^~\&|EKG||CDB||198905201205||ORF^R04|X981672|P|...<cr>
MSA|AA|CDB22289|P|...<cr>
QRD|198904180943|R|I|Q4412|||10|RD|0123456-1|RES|...<cr>
QRF|EKG||198804010000|...<cr>
PID|1||0123456-1||ROBERTSON^JOHN^H||||||||982-1111|...<cr>
OBR| ...<cr>
The
following is an unsolicited transmission of radiology data.
MSH|^~\&|XRAY||CDB||200006021411||ORU^R01|K172|P|...<cr>
PID|...<cr>
OBR|1|X89-1501^OE|78912^RD|71020^CHEST XRAY AP \T\
LATERAL|||19873290800|||9218^MASTERS^JOHN^B|...<cr>
OBX|1|CE|71020&IMP^RADIOLOGIST'S IMPRESSION|4|^MASS LEFT LOWER
LOBE|||A|||F|...<cr>
OBX|2|CE|71020&IMP|2|^INFILTRATE RIGHT LOWER LOBE|||A|||F|...<cr>
OBX|3|CE|71020&IMP|3|^HEART SIZE NORMAL|||N|||F|...<cr>
OBX|4|FT|71020&GDT|1|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#||||||F|...<cr>
OBX|5|CE|71020&REC|5|71020^Follow up CXR 1 month||30-45||||F|...<cr>
Laboratory
message: electrolytes, CBC, sed rate, blood cultures and susceptibilities
MSH|...<cr>
PID|...<cr>
Electrolytes:
OBR|1|870930010^OE|CM3562^LAB|2432-6^ELECTROLYTES HCFA 98 PANEL^LN|
||198703290800|||
401-0^INTERN^JOE^^^^MD^L| ||||SER|^SMITH^RICHARD^W.^^^DR.|(319)377-4400|
This is requestor field #1.|Requestor field #2|Diag.serv.field #1.|
Diag.serv.field #2.|198703311400|||F|...<cr>
OBX|1|NM|2951-2^SODIUM^LN||150|mmol/L|136-148|H||A|F|19850301|...<cr>
OBX|2|NM|2823-3^POTASSIUM^LN||4.5|mmol/L|3.5-5|N||N|F|19850301|...<cr>
OBX|3|NM|2075-0^CHLORIDE^LN||102|mmol/L|94-105|N||N|F|19850301|...<cr>
OBX|4|NM|2028-9^CARBON
DIOXIDE^LN||27|mmol/L|24-31|N||N|F|19850301|...<cr>
CBC:
OBR|2|870930011^OE|HEM3268^LAB|24359-2HEMOGRAM+DIFFERENTIAL PANEL^LN|
||198703290800|||401-0 ^
INTERN^JOE^^^^MD^L|||||BLDV|^SMITH^RICHARD^W.^^^DR.|(319)377-4400|This is
requestor field #1.|This is Requestor field #2.|This is lab field #1.|Lab field
#2.|198703311400|||F|...<cr>
OBX|1|NM|718-7^HEMOGLOBIN^LN||13.4|GM/DL|14-18|N||S|F|19860522|...<cr>
OBX|2|NM|4544-3^HEMATOCRIT^LN||40.3|%|42-52|L||S|F|19860522|...<cr>
OBX|3|NM|789-8^ERYTHROCYTES^LN||4.56|10*6/ml|4.7-6.1|L||S|F|19860522|...<cr>
OBX|4|NM|787-2^ERYTHROCYTE MEAN CORPUSCULAR VOLUME:^LN
||88|fl|80-94|N||S|F|19860522|...<cr>
OBX|5|NM|785-6^ERYTHROCYTE MEAN CORPUSCULAR HEMOGLOBIN:^LN
||29.5|pg|27-31|N||N|F|19860522|...<cr>
OBX|6|NM|786-4^ERYTHROCYTE MEAN CORPUSCULAR HEMOGLOBIN CONCENTRATION:^LN
||33|%|33-37|N||N|F|19860522|...<cr>
OBX|7|NM|6690-2^LEUKOCYTES^LN||10.7|10*3/ml|4.8-10.8|N||N|F|19860522|...<cr>
OBX|8|NM|770-8^NEUTROPHILS/100 LEUKOCYTES^LN/100
LEUKOCYTES:^LN||68|%|||||F|...<cr>
OBX|9|NM|736-9^LYMPHOCYTES/100 LEUKOCYTES:^LN||29|%|||||F|...<cr>
OBX|10|NM|5905-5^MONOCYTES/100 LEUKOCYTES:^LN||1|%|||||F|...<cr>
OBX|11|NM|713-8^EOSINOPHILS/100 LEUKOCYTES:^LN||2|%|||||F|...<cr>
Sed rate:
OBR|3|870930011^OE|HEM3269^LAB|4537-7^ERYTHROCYTE SEDIMENTATION RATE^LN
|||198703290800|||
401-0^INTERN^JOE^^^^MD^L|||||BLDV|^SMITH^RICHARD^W.^^^DR.|(319)377-4400|
This is requestor field #1.|This is Requestor field #2.|This is lab field
#1.|Lab field #2.|198703311400|||F|...<cr>
OBX|1|NM|4537-7^ERYTHROCYTE SEDIMENTATION RATE:^LN|
|7|MM/HR|0-10|N||S|F|19860522|...<cr>
Parent micro result, identifies organism
OBR|4|2740X^OE|BC376^MIC|87040^Blood culture| ||198703290800|||
99-2^JONES^COLLECTOR||^Hepatitis risk||198703290830|BLDV|
4010^INTERN^JOE^^^^MD^L|321-4321 X3472^^^^^^^3472|Requestor field 1|Requestor
field 2|
Producer's field 1|Producer's field 2|198703301000|35.00|MB|F|...<cr>
OBX|1|CE|600-7^MICROORGANISM IDENTIFIED^LN|1|^E Coli|||A|||F|...<cr>
OBX|2|CE|600-7^MICROORGANISM IDENTIFIED^LN|2|^S Aureus|||A|||F|...<cr>
Child micro result, gives antimicrobials susceptibilities for organism
identified in first OBX of parent
OBR|5|2740X^OE|BC402^MIC|87186^Antibiotic MIC||
|198703290800||||G|^Hepatitis Risk||198703290830|BLDB
|401.0^INTERN^JOE^^^^MD^L|321-4321 X3472^^^^^^^3472|||||198703310900|40.00
|MB|F|600-7&MICROORGANISM
IDENTIFIED&LN^1|||2740X&OE^BC376&MIC|...<cr>
OBX|1|ST|28-1^AMIPICILLIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>
OBX|2|ST|60-4^CARBENICILLIN:SUSC:PT:ISLT:QN:MIC^LN||<16|ug/ml||S|||F|...<cr>
OBX|3|ST|267-5^GENTAMICIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>
OBX|4|ST|496-0^TETRACYCLINE:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...<cr>
OBX|5|ST|408-5^PIPERACILLIN:SUSC:PT:ISLT:QN:MIC^LN||<8|ug/ml||S|||F|...<cr>
OBX|6|ST|145-3^CEFUROXIME:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>
OBX|7|ST|161-0^CEPHALOTHIN:SUSC:PT:ISLT:QN:MIC^LN||<8|ug/ml||S|||F|...<cr>
OBX|8|ST|20-8^AMOXICILLIN+CLAVULANATE:SUSC:PT:ISLT:QN:MIC^LN
||<4|ug/ml||S|||F|...<cr>
OBX|9|ST|173-5^CHLORAMPHENICOL:SUSC:PT:ISLT:QN:MIC^LN||<4|ug/ml||S|||F|...<cr>
OBX|10|ST|508-2^TOBRAMYCIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>
OBX|11|ST|12-5^AMIKACIN:SUSC:PT:ISLT:QN:MIC^LN||<4|ug/ml||S|||F|...<cr>
OBX|12|ST|516-5^TRIMETHOPRIM+SULFMOETHOXAZOLE:SUSC:PT:ISLT:QN:MIC^LN|
|<2/38|ug/ml||S|||F|...<cr>
OBX|13|ST|76-0^CEFAZOLIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>
OBX|14|ST|116-4^CEFOXITIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>
OBX|15|ST|141-2^CEFTRIAXONE:SUSC:PT:ISLT:QN:MIC^LN||<4|ug/ml||S|||F|...<cr>
OBX|16|ST|133-9^CEFTAZIDIME:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>
OBX|17|ST|185-9^CIPROFLOXACIN:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...<cr>
Second micro child result, gives susceptibilities or organism identified by
Second OBX of parent
OBR|6|2740X^OE|BC403^MIC|87186^Antibiotic MIC| ||198703290800||||G|
^Hepatitis risk||198703290830|BLDV|401.0^INTERN^JOE^^^^MD^L|321-4321
X3472^^^^^^^3472|||||
198703310900|40.00|MB|F|600-7&MICROORGANISM IDENTIFIED &LN^2|
||2740X&OE^BC376&MIC|...<cr>
OBX|1|ST|28-1^AMPICILLIN:SUSC:PT:ISLT:QN:MIC^LN||<8|ug/ml||R|||F|...<cr>
OBX|2|ST|193-3^CLINDAMYCIN:SUSC:PT:ISLT:QN:MIC^LN||<.25|ug/ml||S|||F|...<cr>
OBX|3|ST|267-5^GENTAMICIN:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...<cr>
OBX|4|ST|233-7^ERYTHROMYCIN:SUSC:PT:ISLT:QN:MIC^LN||<.5|ug/ml||S|||F|...<cr>
OBX|5|ST|383-0^OXACILLIN:SUSC:PT:ISLT:QN:MIC^LN||<.5|ug/ml||S|||F|...<cr>
OBX|6|ST|524-9^VANCOMYCIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>
OBX|7|ST|6932-8^PENICILLIN:SUSC:PT:ISLT:QN:MIC^LN||<8|ug/ml||R|||F|...<cr>
OBX|8|ST|161-0^CEPHALOTHIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>
OBX|9|ST|173-5^CHLORAMPHENICOL:SUSC:PT:ISLT:QN:MIC^LN||<4|ug/ml||S|||F|...<cr>
OBX|10|ST|12-5^AMIKACIN:SUSC:PT:ISLT:QN:MIC^LN||<16|ug/ml||S|||F|...<cr>
OBX|11|ST|185-9^CIPROFLOXACIN:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...<cr>
OBX|12|ST|428-3^RIFAMPIN:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...<cr>
This
example of the body of reports shows the following observation from what are
usually free text reports. The text within these examples that begins with
**-- and ends with --** are explanatory comments, not a formal part of the
message. The following outline shows the segments that are included in this
example message.
a) patient identifying record (PID)
b) EKG order record (OBR)
c) EKG coded result record (OBX)
d) EKG result records (OBX):
1) ventricular rate
2) atrial rate
3) QRS width
4) PR interval
e) order record for chest x-ray (OBR)
f) two diagnostic impressions for CXR (OBX)
g) description record for CXR (OBX)
h) a recommendation record for CXR (OBX)
i) an order record for surgical pathology (OBR)
j) a gross description record for pathology showing use of anatomy fields
(OBX)
k) a microscopic description record for pathology (OBX)
l) vital signs request (OBR)
m) six vital signs (OBX)
n) part of the physical history (OBR & OBX)
o) end record
MSH|...<cr>
PID|...<cr>
Order record for EKG
OBR|1|P8753^OE|EK5230^EKG|93000^EKG|||198703290800|||401
0^INTERN^JOE^^^^MD^L|...<cr>
Two interpretation records for EKG
OBX|1|CE|93000&IMP^EKG|1|^Sinus bradycardia|||A|||F|...<cr>
OBX|2|CE|93000&IMP^EKG|2|^Occasional PVCs|||A|||F|...<cr>
Four numeric results for EKG
OBX|3|NM|8897-1^QRS COMPLEX RATE ^LN|
|80|/min|60-100|||||F|...<cr>
OBX|4|NM|8894-8^PULSE RATE^LN||80|/min
|60-100||||F|...<cr>
OBX|5|NM|8633-0^QRS DURATION ^LN||.08|msec
|.06-.10||||F|...<cr>
OBX|6|NM|8625-6^P-R INTERVAL ^LN||.22|msec
|.18-.22||||F|...<cr>
Order record for CXR
OBR|2|P8754^OE|XR1501^XR|71020^Chest X-ray AP \T\ Lateral|||198703290800|||
401-0^INTERN^JOE^^^^MD^L|...<cr>
Two CXR diagnostic impressions
OBX|1|CE|71020&IMP^Radiologist's
Impression|1|.61^RUL^ACR~.212^Bronchopneumonia^ACR|||A|||F|...<cr>
OBX|2|CE|71020&IMP|2|51.71^Congestive heart
failure^ACR|||A|||F|...<cr>
CXR Description with continuation records
OBX|3|TX|71020&GDT||Infiltrate probably representing bronchopneumonia in
the right
lower lobe. Also pulmonary venous congestion cardiomegaly and cephalization,
indicating early congestive heart failure.|...<cr>
Recommendations about CXR report to follow up one month with a repeat CXR
OBX|4|CE|71020&REC||71020^Followup CXR 1 month^AS4||||||F|...<cr>
Order record for pathology report
OBR|3|P8755^OE|SP89-739^SP|88304^Surgical Path
Report|||198703290800|||401-0^INTERN^JOE^^^^MD^L|...<cr>
OBX|1|CE|88304&ANT^Surgical Path Report|1|Y0480-912001^orbital
region^SNM||||||F|...<cr>
Gross description record (with overflow) for pathology
OBX|2|TX|88304&GDT^GrossSpecimenDescription|1|The specimen is received in
four containers. The first is labeled with the patient's name and consists of
three fragments of reddish-brown tissue each of which measures 2 mm in greatest
dimension. They are wrapped in tissue paper and submitted in toto in a single
cassette|...<cr>
Microscopic description record for pathology
OBX|3|TX|88304&MDT^MicroscopicDescription|1|Sections of the first specimen
received for frozen section diagnosis reveal thick walled, ramifying vessels
lined by a single layer of flattened endothelial cells. The thick smooth
muscle walls exhibit no malignant cytologic features nor do the endothelial
lining cells. Within the same specimen are also found fragments of fibrous
connective tissue, bone, and nerve which are histologically
unremarkable||||||F|...<cr>
Vital signs using LOINC® codes as observation identifiers
OBR|4|P8756^OE|N2345^NR|3000.02^VITAL SIGNS|
||198703290800|||401-0^INTERN^JOE^^^^MD^L|...<cr>
OBX|1|NM|8462-4^INTRAVASCULAR
DIASTOLIC:PRES:^LN||90|mm(hg)|60-90||||F|...<cr>
OBX|2|NM|8479-8^INTRAVASCULAR SYSTOLIC:PRES:^LN||120|mm(hg)
|100-160||||F|...<cr>
OBX|3|NM|8478-0^INTRAVASCULAR
MEAN:PRES:^LN||100|mm(hg)|80-120|N|||F|...<cr>
OBX|4|NM|8867-4^HEART BEAT RATE^LN||74|/min|60-100|N|||F|...<cr>
OBX|5|ST|8357-6^BLOOD PRESSURE METHOD^LN||MANUAL BY
CUFF||||||F|...<cr>
OBX|6|ST|8886-4^HEART RATE METHOD^LN||MANUAL BY PALP||||||F|...<cr>
Part of the patient's history
OBR|5|P8568^OE|HX2230^CLN||2000^HISTORY| ||198703290800||401
0^INTERN^JOE^^^^MD^L||...<cr>
OBX|1|CE|8661-1^CHIEF COMPLAINT^LN||...<cr>
OBX|2|ST|8674-4^HISTORY SOURCE^LN||PATIENT||||||F|...<cr>
OBX|3|TX|8684-3^PRESENT ILLNESS^LN||SUDDEN ONSET OF CHEST PAIN. 2 DAYS,
PTA ASSOCIATED WITH NAUSEA, VOMITING \T\ SOB. NO RELIEF WITH ANTACIDS
OR NTG. NO OTHER SX. NOT PREVIOUSLY ILL.||||||F|...<cr>
.
.
and so on.
Organisms
and other observations/tests are reported using multiple OBX segments. The
granularity expected for HL7culture reports is one observation per organism.
All OBX segments which have the same observation ID and sub-ID are part of a
single observation.
Each organism in a culture battery is assigned a unique OBX-4-observation
sub-ID (and is therefore a separate observation). The organism name is
given in OBX-5-observation value (results). It is recommended, but not
required, that the organism name may change over time, but the corresponding
observation sub-ID never changes. (The observation ID will be identical for
all organisms reported.)
Recommended:
OBX|1|CE|organism^413^L|1|^E. Coli||||||F|...<cr>
OBX|2|CE|organism^413^L|2|^S. Aureus||||||F|...<cr>
Not recommended:
OBX|1|CE|organism1^413^L|1|^E. Coli||||||F|...<cr>
OBX|2|CE|organism2^413^L|1|^S. Aureus||||||F|...<cr>
Each
antimicrobial should be reported as a separate (OBX) observation where the
Observation ID is a code for the antimicrobial. (OBXs for non-antimicrobials
observations and related information may be present in the same battery.)
MIC and disk diffusion (Kirby Bauer) susceptibility results can be combined in
the same OBX segment. An OBX can contain a MIC value (in OBX-5-observation
value (results)) and OBX-8-abnormal flag that indicates whether the
organism is sensitive, resistant, or intermediate (see HL7 table 0078-
Abnormal flags under abnormal flag fields).
Or, an OBX can contain a disk diffusion result string (e.g., sensitive)
in the Observation Results field and the disk diffusion interpretation in
OBX-8-abnormal flags (e.g., S).
A susceptibility battery may only contain results corresponding to a single
organism that has been previously reported in a culture battery.
The
following is the preferred, but not required method of organizing data about
antimicrobial susceptibility.
A susceptibility battery may only contain results corresponding to a single
organism that has been previously reported in a culture battery.
A susceptibility battery is always a child order to a culture battery.
OBR-29-parent (parent's filler order number) in the susceptibility OBR
is equal to OBR-3-filler order number in the parent culture OBR and is
used to link the two batteries logically.
The susceptibility battery also contains a linkage back to a particular
organism in the culture battery. OBR-26-parent result of the
susceptibility OBR contains two components--OBX-3-observation identifier
(code only) and OBX-4-observation sub-ID of the OBX in the culture
battery which contains the organism name.
The identity of an organism/isolate is expected to be refined over time. When
an organism identification changes, the parent culture battery can be resent
without resending the child susceptibility battery.
The case may occur where a susceptibility battery is reported on an organism
which has not yet been identified. In this case, it is required that a
placeholder OBX for the organism name be reported in the corresponding culture
battery so that OBR-26-parent result in the susceptibility OBR will
point to a valid organism OBX in the culture battery. Transmission of an
organism OBX (in the culture battery) with the Sub-ID field valued must precede
the susceptibility battery which uses the identical Sub-ID in OBR-26-parent
result.
Discussion and examples:
Order micro results (blood culture)
MSH|^~\&|LAB1||DESTINATION||19910127105114||ORU^R01|LAB1003929|...<cr>
PID|...<cr>
PV1|...<cr>
ORC|NW|...<cr>
OBR|1|A485388^OE|H29847^LAB1|1234^BLOOD CULTURE|||...<cr>
Result for culture
ORC|RE|...<cr>
OBR|1|A485388^OE|H29847^LAB1|1234^BLOOD CULTURE||...<cr>
OBX|1|FT|SDES^SOURCE||BLOOD-RAPID||||||F|...<cr>
OBX|2|FT|EXAM^MICROSCOPIC||GRAM POSITIVE COCCI IN
GROUPS||||||F|...<cr>
OBX|3|FT|600-7^MICROORGANISM IDENTIFIED^LN|1|ISOLATE 1||||||F|...<cr>
Result for susceptibility
ORC|RE|...<cr>
OBR|1|A485388^OE|H29848^LAB1|BT1^SUSCEPTIBILITY
BATTERY||||||123^MANSFIELD^CHARLES| ||||||||||||||||600-7&MICROORGANISM
IDENTIFIED&LN ^1|||A485388&OE^H29847&LAB1|...<cr>
OBX|1|NM|6932-8^PENICILLIN^LN||0.5|||R|||F|...<cr>
OBX|2|NM|347-5^NAFCILLIN^LN||1|||R|||F|...<cr>
OBX|3|ST|193-3^CLINDAMYCIN^LN||<=0.1|||S|||F|...<cr>
Result for Culture ID
ORC|RE|...<cr>
OBR|1|A485388^OE|H29847^LAB1|1234^BLOOD CULTURE||...<cr>
OBX|1|FT|600-7^ MCIROORGANISM IDENTIFIED^LN |1|STAPH
EPI||||||F|...<cr>
New result for culture ID
ORC|RE|...<cr>
OBR|1|A485388^OE|H29847^LAB1|1234^BLOOD CULTURE||...<cr>
OBX|1|FT|600-7^MCIROORGANISM IDENTIFIED^LN|1|STAPH EPI SERO TYPE
3||||||F|...<cr>
Assumptions
1. All OBXs in the parent order must employ the same coding scheme.
2. The Sub-ID of the parent OBXs (result) cannot change.
Suppose
an order has been placed to the EKG system for three EKGs to be performed on
successive days. These results can be reported in various ways.
1. The EKG application needs to communicate to anyone the results of the 1st
EKG:
ORU message:
MSH|...<cr>
PID|...<cr>
OBR|1||89-551^EKG|93000^EKG REPORT|...<cr> // 1ST child OBR.
OBX|1|ST|93000.1^VENTRICULAR RATE (EKG)|...<cr>
OBX|2|ST|93000.2^|...<cr>
...
...
OBX|14|FT|93000.14^EKG COMMENT|...<cr>
OBR|...<cr> // other observation
segments to follow
* Notice that this report is without reference to the original order.
* No ORC is required because the identifying Fillers Order Number (and other
ORC fields) are carried in the OBR segment.
2. The EKG application needs to communicate to anyone the original order
information, the details of the child orders, the fact of the child spin off,
and the results of all three EKGs:
ORU message:
MSH|...<cr>
PID|...<cr>
ORC|PA|A226677^OE|89-450^EKG|...<cr> // original order's
ORC.
OBR|1|||93000^EKG REPORT|...<cr> // original order segment
ORC|CH|A226677^OE|89-451^EKG|...<cr> // 1st child ORC.
OBR|1|||93000^EKG REPORT|...<cr> // 1st EKG child OBR.
OBX|1|ST|...<cr> // 1st EKG report
OBX|2|ST|...<cr>
...
OBX|14|FT|...<cr>
ORC|CH|A226677^OE|89-452^EKG|...<cr> // 2nd child ORC.
OBR|1|||93000^EKG REPORT|...<cr> // 2nd EKG child OBR.
OBX|1|ST|...<cr> // 2nd EKG report
OBX|2|ST|...<cr>
...
OBX|14|FT|...<cr>
ORC|CH|A226677^OE|89-453^EKG|...<cr> // 3rd child ORC.
OBR|1|||93000^EKG REPORT|...<cr> // 3rd EKG child OBR.
OBX|1|ST|...<cr> // 3rd EKG report
OBX|2|ST|...<cr>
...
OBX|14|FT|...<cr>
... // Other parts of message might follow.
In this case, we are transmitting the information about the fact of child spin
off, the original order and the results all at the same time. Thus, this form
of the ORU message reports not only the results of an order, but all of its
associated ordering information including the original OBR for three EKGs that
was replaced by three separate OBR EKG segments.
Reporting
body weight and height with a creatinine clearance.
MSH|...<cr>
PID|...<cr>
ORC|NW|...<cr> // New order.
OBR|1|P42^PC||2164-2^CREATININE RENAL CLEARANCE: QN^LN|...<cr>
OBX|1|NM|3141-9^BODY WEIGHT:^LN||62|kg|...<cr>
OBX|2|NM|3137-7^BODY HEIGHT:^LN||190|cm|...<cr>
ORC|NW|...<cr> // Next order.
Academic
medical institutions, academic research coordinating centers, and
industry-based research organizations often have computer systems that support
registration, compliance and safety monitoring, and outcomes analysis for
clinical trials. Patients on these trials may receive their treatment and
evaluation at one research facility or at many different medical facilities.
Clinical trials systems could message other applications that a patient is
registered on a clinical trial. Several functional examples follow: (1) Some
of the data required to monitor or analyze outcomes on the trial are generated
in other medical computer systems, such as pharmacy, laboratory, or clinical
applications. These applications may tag patients on clinical trials so that
data may be sent back to the clinical trials system. (2) Order entry systems
could also use patient registration information: they could display standard
order sets for the protocol or particular treatment/evaluation phases of a
complex protocol. They could pass the clinical trials status on to service
provider applications to initiate a results report to the clinical trials
system. It could also be passed to billing applications that may use
specialized procedures for research-related costs. (3) Nursing and pharmacy
systems can use information on patients' clinical trials status for care plans
or dispensing authorization (auxiliary to the physician's prescription),
respectively. There could be many other uses of this message since a patient's
involvement on a clinical trial affects all concurrent medical care.
To meet monitoring and analysis requirements, patient registration, treatment,
diagnostic, and study summary data are reported to study sponsors like
pharmaceutical or medical device companies, regulatory agencies, and data
management centers for collaborative studies. Automated procedures must be
used to transfer these voluminous data among the participant computer systems
in a cost-efficient and timely manner. The following additions to HL7 aim to
specify standard messaging transactions to automate such reporting as well as
to enable communication of clinical trials registration data to relevant
medical applications as described above.
The objectives of the clinical trials messages and segments are to identify
that patients are registered on clinical trials, have entered a study-specific
phase of treatment or evaluation, or to indicate the study protocol's data
schedule. Messages include OBR (Section 4.5.1, "OBR - observation request
segment"), OBX (Section 7.4.2, "OBX - observation/result segment"), RXA
(Section 4.8.14, "RXA - pharmacy /treatment administration segment"), and RXR
(Section 4.8.3, "RXR - pharmacy/treatment order segment") segments to report
observations or drug administration that are relevant to the study. In
addition to study-related clinical data, OBX segments may contain the results
of study variables according to master code tables such as the Health Outcomes
Variables (HL7 Implementation Guide). There are also master segments to
describe the clinical trial, its treatment phases, and its scheduled date-time
points for message recipients. These are analogous to the Test/Observation
Master Segments (Chapter 8), with the trials, phases, or scheduled time points
treated as the OMX treats observation identifiers.
A scientifically rigorous study of individual outcomes to some process of healthcare intervention. Clinical trials usually involve medical treatments so this document will use the term treatment, rather than the broader term intervention. A clinical trial design may randomly assign and compare one treatment approach with another, or generate safety and efficacy data on a single treatment approach. The clinical trial has a protocol for the patient's course of treatment and/or evaluation. There is usually a schedule for collection of data to measure compliance, safety, and outcomes.
A
treatment and/or observation interval of a clinical trial. A phase may
represent an interval with a specific treatment regimen assigned randomly or
otherwise, with each regimen of a progression of treatments, or with an
evaluation component only. Generally, for each phase, there is an explicit
patient management, evaluation, and data collection schedule. Each of these
phases may have associated safety, outcome, and quality-control variables. A
simpler study design need not use the phase structures.
The phase structure serves several purposes in the clinical trials messages.
Other computer systems may need to know that the patient has begun a phase with
a particular treatment regimen or diagnostic schedule, such as the pharmacy or
order entry systems. When reporting study data, observations and variables
often describe particular phase instances. For example, each course of
treatment may have its own values for the same set of observations or
variables. Phase instances may also have distinct data schedules that need to
be linked to submitted data.
Several examples follow with each line depicting a phase.
Alternating
treatment plus observation intervals:
__________> _________> _________> _________> ...
Rx A Rx B Rx A Rx B
Random
assignment to two courses each of treatment A or B, all responding patients to
treatment C, continue with observation and a diagnostic regimen after all
treatment phases are completed. Treatment phases include the evaluation
component for that course of treatment:
___________> __________
Rx A Crs 1 Rx A Crs 2
\> __________> __________> _______
/ Rx C Crs 1 Rx C Crs 2
Observe
___________> __________/
Rx B Crs 1 Rx B Crs 2
Random
assignment to placebo or treatment A, both taken daily and evaluated
monthly.
___________> __________> __________> __________> . . .
Month 1 Month 2 Month 3 Month 4
The
treatment, diagnostic, and procedural requirements, as well as data collection
due dates, scheduled on a timeline for most clinical trials. As data are
reported, they may need to reflect the scheduled time point that they satisfy.
Clinical trials quality control requires attention to compliance between the
protocol's schedule and patient data records.
The data schedule will be keyed by time points relative to the study. Some
data may be due prior to and at the conclusion of the study and/or one or more
of its phases. Some are interim within the study or its phases depending on
protocol events such as administration of treatment, arbitrary time intervals
instated to make and record assessments, or some clinical milestone such as
relapse of disease. Often, multiple data parameters are scheduled at the same
time point. Several examples follow:
Treatment 1st - 3rd Years |
||||||||||||||||||
Reg |
Rand |
Months |
||||||||||||||||
3 |
6 |
9 |
12 |
18 |
24 |
30 |
36 |
42 |
48 |
54 |
60 |
66 |
72 |
78 |
84 |
|||
Disease Staging |
X |
|
||||||||||||||||
H & P |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
Assess Adverse Events and Outcome Variables |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
Chest PAL X-ray |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
||
CBC, Diff, Plt |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
||||||
SMA 12 |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|||||
Cholesterol and Triglyceride |
X |
X |
X |
X |
X |
X |
X |
X |
X |
|||||||||
Electrolytes |
X |
|||||||||||||||||
Plasma Retinoic Acid |
X |
X |
||||||||||||||||
Cotinine Level (nonsmokers) |
X |
|
Prior to Each Cycle |
|
Every 3 Cycles |
|
|
Informed Consent |
X |
X |
|||
H & P Neurologic |
X1 |
X |
|||
Vital Signs |
X1 |
X2 |
X |
||
Disease Staging |
X |
X3 |
X |
||
ECG |
X1 |
X4 |
|||
Radiology* |
X |
X5 |
X |
||
Chest X-ray |
X |
X |
X |
||
Bone Marrow Bx. |
X6 |
||||
HCG |
X1 |
||||
Assess Adverse Events |
X |
X |
|||
CBC, Diff, Plt |
X1 |
X7 |
X |
||
UA, PT, PTT |
X1 |
X |
|||
SMA12, Mg, CEA |
X1 |
X |
X |
1.
Within 3 days prior to start of infusion.
2. At 0,10,30, and 60 minutes after start of drug administration and one-half
hour after test drug infusion ends for cycles 1 and 2. For subsequent cycles
at 0 and 10 minutes after start of drug administration, and at the end of
infusion.
3. Record tumor measurements at the end of every cycle if assessable clinically
by physical examination or with simple X-ray.
4. Continuous ECG monitoring during infusion if necessary, due to bradycardia
(<50 beats/min) or other significant cardiac findings.
5. When measurable disease requires complex radiologic studies such as CT or
radionucleide scans.
6. To be done at baseline (if clinically indicated) at the option of the
investigator and also during study if patient has prolonged myelosuppression
(WBC<2000 cells/mm3>14 days).
7. Blood counts will be done twice weekly during cycles 1 and 2, then
weekly.
* Radionucleide scan and X-ray of the bones, CT scans of the chest, pelvis, and
brain only when clinically indicated.
Day
1 |
Day
1 |
|
|
|
H & P |
X |
X |
||
Creat, Bili, SGOT |
X |
|||
Urinalysis |
X |
|||
Pain Diagnosis |
X |
|||
Opioid Dose Strand |
X |
X |
X |
X |
Non-opioid Analgesic |
X |
X |
X |
|
Medications for Side Effects |
X |
X |
X |
|
Phone Report: Pain and Side Effects |
X |
|||
Visual Analog Scales |
X |
X |
X |
X |
Pain Evaluation Form |
X |
X |
The event type will be carried in the message header segment.
The
data are entered in a clinical trials or other patient data system and
broadcast to other facility systems such as order entry, pharmacy, accounting,
and nursing systems. They can be transmitted in batch mode or broadcast to
outside-facility computer systems, including diagnostic and patient management
systems. It is assumed that proper routing and security mechanisms are in
place.
Event |
Description |
|---|---|
C01 |
Register a patient on a clinical trial |
C02 |
Cancel a patient registration on clinical trial (for clerical mistakes since an intended registration should not be canceled) |
C03 |
Correct/update registration information |
C04 |
Patient has gone off a clinical trial |
C05 |
Patient enters phase of clinical trial |
C06 |
Cancel patient entering a phase (clerical mistake) |
C07 |
Correct/update phase information |
C08 |
Patient has gone off phase of clinical trial |
CRM^C01-C08^CRM_C01 |
Clinical Study Registration Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
{ |
||
PID |
Patient Identification |
3 |
[PV1] |
Patient Visit |
3 |
CSR |
Clinical Study Registration |
7 |
{[CSP]} |
Clinical Study Phase |
7 |
} |
Data
are entered in the clinical trials system or may reside in laboratory,
pathology, radiology, pharmacy and/or other clinical applications. Most
clinical trials data - clinical observations and study variables - will be
communicated in OBR and OBX segments. The CSR, CSP, and CSS segments will
identify the specific association these OBR and OBX have to the clinical trial.
Data can be broadcast or transmitted in batch mode to study sponsors or the
data management center for collaborative studies.
Event |
Description |
|---|---|
C09 |
Automated time intervals for reporting, like monthly |
C10 |
Patient completes the clinical trial |
C11 |
Patient completes a phase of the clinical trial |
C12 |
Update/correction of patient order/result information |
CSU^C09-C12^CSU_C09 |
Unsolicited Study Data Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
{ |
PID repeat group open |
|
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NTE}] |
Notes and comments |
2 |
[ |
PV1 optional group open |
|
PV1 |
Patient Visit |
3 |
[PV2] |
Patient Visit - Additional Info |
3 |
] |
PV1 optional group close |
|
CSR |
Clinical Study Registration |
7 |
{ |
CSP repeat group open |
|
[CSP] |
Clinical Study Phase |
7 |
{ |
CSS repeat group open |
|
[CSS] |
Clinical Study Data Schedule |
7 |
{ |
ORC repeat group open |
|
[ORC] |
Common Order |
4 |
OBR |
Observation Battery |
7 |
{OBX} |
Observation Results |
7 |
} |
ORC repeat group close |
|
{ |
ORC repeat group open |
|
[ORC] |
Common Order |
4 |
{ |
RXA repeat group open |
|
RXA |
Pharmacy Administration |
4 |
RXR |
Pharmacy Route |
4 |
} |
RXA repeat group close |
|
} |
ORC repeat group close |
|
} |
CSS repeat group close |
|
} |
CSP repeat group close |
|
} |
PID repeat group close |
The
CSR segment will contain fundamental administrative and regulatory information
required to document a patient's enrollment on a clinical trial. This segment
is all that is required if one needs to message another system that an
enrollment has taken place, i.e., from clinical trials to pharmacy, accounting,
or order entry systems. The CSR segment may also be used to identify that OBR,
OBX, RXA, and RXR segments that follow represent data applicable to the
identified study.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
60 |
EI |
R |
01011 |
Sponsor Study ID |
||
2 |
60 |
EI |
O |
01036 |
Alternate Study ID |
||
3 |
250 |
CE |
O |
01037 |
Institution Registering the Patient |
||
4 |
30 |
CX |
R |
01038 |
Sponsor Patient ID |
||
5 |
30 |
CX |
O |
01039 |
Alternate Patient ID - CSR |
||
6 |
26 |
TS |
R |
01040 |
Date/Time Of Patient Study Registration |
||
7 |
250 |
XCN |
O |
Y |
01041 |
Person Performing Study Registration |
|
8 |
250 |
XCN |
R |
Y |
01042 |
Study Authorizing Provider |
|
9 |
26 |
TS |
C |
01043 |
Date/time Patient Study Consent Signed |
||
10 |
250 |
CE |
C |
01044 |
Patient Study Eligibility Status |
||
11 |
26 |
TS |
O |
Y/3 |
01045 |
Study Randomization Date/time |
|
12 |
250 |
CE |
O |
Y/3 |
01046 |
Randomized Study Arm |
|
13 |
250 |
CE |
O |
Y/3 |
01047 |
Stratum for Study Randomization |
|
14 |
250 |
CE |
C |
01048 |
Patient Evaluability Status |
||
15 |
26 |
TS |
C |
01049 |
Date/time Ended Study |
||
16 |
250 |
CE |
C |
01050 |
Reason Ended Study |
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID).
Definition: The field contains the universal identifier for the clinical
trial. Since many clinical trials are collaborative and multi-centered, and
since one goal of these standards is to promote automated data exchange among
sites, the primary identifier should come from the sponsor. The coding system
component may reference the sponsor. Example:
T93-0807^NCI (where NCI refers to the National Cancer Institute).
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains an alternate identifier that may be used as
agreed upon by messaging parties. For example, the sending application may
code its internal study number here.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field distinguishes the institution where registration
occurred. The legal approval to give patients access to a trial lies with the
Internal Review Board for the institution. Universal healthcare provider
facility codes should be used when they exist. Currently coding systems must
be devised by users.
Components:
<ID (ST)> ^ <check digit (ST)> ^ <code identifying the check
digit scheme employed (ID)> ^ < assigning authority (HD)> ^
<identifier type code (ID)> ^ < assigning facility (HD) ^
<effective date (DT)> ^ <expiration date (DT)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> * <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> * <universal ID type (ID)>
Definition: This field contains the main patient identification for the study.
The sponsor patient ID allows automation of records on patients treated at
various institutions. The sponsor patient ID should be unique for each patient
participating on the study identified in CSR-1-sponsor study ID.
Components:
<ID (ST)> ^ <check digit (ST)> ^ <code identifying the check
digit scheme employed (ID)> ^ < assigning authority (HD)> ^
<identifier type code (ID)> ^ < assigning facility (HD) ^
<effective date (DT)> ^ <expiration date (DT)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> * <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> * <universal ID type (ID)>
Definition: This field may be the sending application's patient
identification. Coding conventions may be used as agreed upon by users.
Definition: This field contains the date of the patient registration is mandatory. The time component is optional. The time stamp for a registration may be useful. For example, patients may be randomized at the pharmacy according to the order in which they were registered.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the healthcare facility employee who actually
phoned, submitted a form, or interactively registered the patient on the
clinical trial. This is generally done under authorization from the attending
physician or a principal or collaborating investigator.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the healthcare provider, generally the
attending physician, who is accountable that the patient is eligible for the
trial and has signed an informed consent. National standard healthcare
provider codes should be used when they exist. This field is required for the
patient registration trigger event (C01).
Definition: This field contains the consent form signing date is collected to provide a checkpoint that the consent form was obtained. Since many trials involve unapproved drugs and other treatment modalities, the consent form is highly important to document and store. This field is required for the patient registration trigger event (C01). The time component is optional.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field indicates whether the patient was an appropriate
candidate for the trial. It is important for quality control and data
analysis. The code set will vary among clinical trials. An example answer set
is: Yes, No, By Approval, Not Assessed, Unknown. This field is
required for the patient registration trigger event (C01).
Definition: This field contains the date the patient was randomized. The time component is optional. Up to three randomizations are supported. Sequential randomizations are listed in chronological order.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains codes that must be developed by users. The
blind treatment assignment may be communicated as a dummy text: ^blind
or if a coded treatment assignment must also be communicated:
1^blind^local_code. If more than one randomization occurs, the second and
third repetitions will correspond to the second and third repetitions of
CSR-11-study randomization date/time, if they exist.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: Many studies have stratified randomization schemas. The strata
codes must be developed for each clinical trial. This field is important for
statistical analysis of the study results. The second and third repetitions
will correspond to the second and third repetitions of CSR-11-study
randomization date/time and CSR-12-randomized study arm, if they
exist.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field categorizes the inclusion of this patient's data for
various analyses. The patient's data may be evaluable for analysis of adverse
events but not for outcomes. Or it may be evaluable for some outcomes and not
others. The coding systems will vary among trials. This field is required for
the off-study trigger event (C04).
Definition: This field contains the date the patient completes or is otherwise removed from the study. This field is required for the off-study event (C04). The time component is optional.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This information is important for quality control and data
analysis. The coding systems will vary among trials. An example answer set
is: Adverse Events, Completed Trial, Death, Drug Resistance, Intercurrent
Illness, Lost to Follow up, No Response to Therapy, Noncompliance, Progression
of Disease, Protocol Violation, Refused Further Therapy. This field is
required for the off-study trigger event (C04).
The
CSP segment contains information on a patient's status for a particular phase
of the study. This segment is optional and is useful when a study has
different evaluation intervals within it. (See Section 7.6.1.2, "
Phase
of a clinical trial:Phase of a Clinical Trial." The CSP segment is implemented
on a study-specific basis for messaging purposes. The fact that the patient
has entered a phase of the study that represents a certain treatment approach
may need to be messaged to other systems, like pharmacy, nursing, or order
entry. It is also important to sponsors and data management centers for
tracking patient progress through the study and monitoring the data schedule
defined for each phase. It may subsume OBR and OBX segments that follow it to
indicate that these data describe the phase.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
250 |
CE |
R |
01022 |
Study Phase Identifier |
||
2 |
26 |
TS |
R |
01052 |
Date/time Study Phase Began |
||
3 |
26 |
TS |
O |
01053 |
Date/time Study Phase Ended |
||
4 |
250 |
CE |
C |
01054 |
Study Phase Evaluability |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the phase of the study that a patient has
entered. The set of codes will generally be developed for each clinical trial,
although there are patterns that trials in particular disease or prevention
categories may follow. The phase structure will be based on data collation and
reporting needs for the study. It is an operational structure and need not be
discussed in the clinical trial protocol documentation or even made known to
patient care or data collection personnel. The coding system will usually be
developed by the sponsor for multicentered clinical trials to standardize the
receipt of automated data. Local codes could be added if an additional local
message is desired. Otherwise, local coding conventions will be used.
Example: 2^Init Rx, Crs 1^NCI T93-0807 Phases
Definition: This field contains the date the patient began this phase interval. The time is optional.
Definition: This field contains the date the patient ended this phase interval.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the disposition of the patient's data for this
phase interval for quality control and data analysis purposes. The set of
codes will vary across clinical trials. An example answer set: Complete,
Adverse Events Only, Outcome Only, None, Unknown.
The
Clinical Study Data Schedule (CSS) segment is optional depending on whether
messaging of study data needs to be linked to the scheduled data time points
for the study. (See Section 7.6.1.3, "data schedule.") The CSS segment
enables communication of data schedules and adherence that ranges from the
basic to the elaborate. Use of the segment must be planned for each
implementation. Each CSS segment will subsume observation and drug
administration segments that follow, indicating that they satisfy this
scheduled time point.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
250 |
CE |
R |
01055 |
Study Scheduled Time Point |
||
2 |
26 |
TS |
O |
01056 |
Study Scheduled Patient Time Point |
||
3 |
250 |
CE |
O |
Y/3 |
01057 |
Study Quality Control Codes |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the time point for which some instance of data
for the clinical trial was scheduled. The time point may be expressed in any
coded format. Some examples of time point values are: Prestudy,
Pretreatment, 4 times/day, Weekly, Every 3 days, Every course, At Relapse, At
Off Study. Alternatively, frequency values from Section 4.4.2, "Interval
component (CM)," (the Interval component of the TQ Timing/Quantity data type
could be used.) Time point naming conventions and usage must be specified by
implementers.
Definition: This field contains the date/time that the scheduled time point should occur for this patient. The date/time may be used for a reference in reviewing the actual dates on which scheduled items that follow in OBR segments occur for the patient. The time component is optional.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: In clinical settings, the actual date of a treatment or
procedure may vary considerably from the due date. Various coding
systems may be used to evaluate the adherence to the schedule or acceptability
of the data. Coding systems will vary among trials.
The
CTI segment is an optional segment that contains information to identify the
clinical trial, phase and time point with which an order or result is
associated.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
60 |
EI |
R |
01011 |
Sponsor Study ID |
||
2 |
250 |
CE |
C |
01022 |
Study Phase Identifier |
||
3 |
250 |
CE |
O |
01055 |
Study Scheduled Time Point |
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains the universal identifier for the clinical
trial. The coding system is as described in CSR-1-sponsor study ID.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the phase of the study that a patient has
entered. See CSP-1-study phase identifier for details of coding systems.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies a time point in the clinical trial phase.
CTI-2-study phase identifier must be valued if CTI-3-study scheduled
time point is valued. Should correspond to CSS-1-study scheduled time
point.
The clinical study master segment (CMO) is described in Chapter 8 section 8.11.2.
The clinical study phase master segment (CMI) is described in Chapter 8, section 8.11.3.
The clinical study schedule master segment is described in Chapter 8, section 8.11.4.
MSH|^~\&|PDMS|MDACC|ORDER
ENTRY|MDACC|200006021649||CRM^C01|...<cr>
PID|1||223892||King^Sally^Brown||19530117|...<cr>
CSR|DM94-004^MDACC||MDACC|3||19941013||342^^^^^^^PDMS|
|||||1005^^^^^^^MDACC|19941013|Y^Meets All Requirements^PDMS|...<cr>
MSH|^~\&|PDMS|MDACC|PHARM|MDACC|200006050925||CRM^C05|...<cr>
PID|1||352352||West^Mary^L.||19230213|...<cr>
CSR|ID91-025^MDACC||MDACC|301||19941005||342^^^^^^^PDMS
|||19941201|2^blind^PDMS|
12^Smoker,Stage
II,<60^PDMS|...<cr>
CSP|2^Treatment^PDMS|19941201|...<cr>
MSH|^~\&|PDMS|MDACC|CTMS|NCI|200006050927||CSU^C09|...<cr>
PID|1||235925||J^F^M||19350616|...<cr> [note:anonymous]
CSR|T93-080^NCI|ID93-030^^MDACC|MDACC|14||19941205|...<cr>
CSS|^Prestudy|19941204|C^compliant^NCI<cr>
OBR|1|1234|1234|3^EligibilChecklist^StudyFormsList|||19941205|...<cr>
Note: The clinical trials section probably needs its own definition of OBR.
OBR-2&3 have condition rules indicating that the placer and filler numbers
must be present in either the ORC or the OBR. Since an ORC is not present,
then these fields must be populated in the OBR. My guess is that clinical
trials aren't interested in the placer and filler number.
OBX|1|CE|ELIG1^Elig Crit 1^NCI|Text Elig Crit 1|Y|...<cr>
OBX|2|CE|ELIG2^Elig Crit 2^NCI||Y|...<cr>
OBR|2|1235|1235|4^Prestudy Form^StudyFormsList|||19941205|...<cr>
OBX|1|CE|QOL^Quality of Life^NCI||2\T\3\T\2\T\4\T\2^SPITZER|...<cr>
OBX|2|CE|PRICHEM^Prior Chemo^NCI||Yes|...<cr>
OBX|3|CE|PRIBIOL^Prior Biologics^NCI||No|...<cr>
OBX|4|NM|NUMREM^Number Prior Remissions^NCI||2|...<cr>
OBR|3|932^OE|243789^LAB|88304^SURG PATH REPORT|||19940101|...<cr>
OBX|1|CE|88304&ANT|1|9999^PANCREAS^SNM|...<cr>
OBX|2|CE|88304&IMP|2|9999^ADENOCARCINOMA^SNM|...<cr>
OBR|4|933^OE|243790^LAB|85022^CBC|||199412050800|...<cr>
OBX|1|NM|718-7^HEMOGLOBIN:^LN||13.4|GM/DL|14-18|N||S|F|19860522|...<cr>
[cbc values]
OBX|2|NM|4544-3^HEMATOCRIT:^LN||40.3|%|42-52|L||S|F|19860522|...<cr>
OBX|3|NM|789-8^ERYTHROCYTES:^LN||4.56|10*6/ml|4.7-6.1|L||S|F|19860522|...<cr>
OBX|4|NM|787-22^ERYTHROCYTE MEAN CORPUSCULAR VOLUME:^LN||88|fl
|80-94|N||S|F|19860522|...<cr>
OBX|5|NM|785-6^ERYTHROCYTE MEAN CORPUSCULAR HEMOGLOBIN:^LN||29.5|pg
|27-31|N||N|F|19860522|...<cr>
OBX|6|NM|786-4^ERYTHROCYTE MEAN CORPUSCULAR HEMOGLOBIN
CONCENTRATION:^LN||33|%|33-37|N||N|F|19860522|...<cr>
OBX|7|NM|6690-2^LEUKOCYTES:^LN||10.7|10*3/ml|4.8-10.8|N||N|F|19860522|...<cr>
OBX|8|NM|764-1^NEUTROPHILS BAND FORM/100
LEUKOCYTES:^LN||2|%|||||F|...<cr>
OBX|9|NM|769-0^NEUTROPHILS SEGMENTED/100 LEUKOCYTES:^LN||67|%|||||F
|...<cr>
OBX|10|NM|736-9^LYMPHOCYTES/100 LEUKOCYTES:^LN||29|%|||||F|...<cr>
OBX|11|NM|5905-5^MONOCYTES/100 LEUKOCYTES:^LN||1|%|||||F|...<cr>
OBX|12|NM|713-8^EOSINOPHILS/100 LEUKOCYTES:^LN||2|%|||||F|...<cr>
OBR|5|934^OE|243791^LAB|80004^ELECTROLYTES|||199412050800|...<cr>
OBX|1|NM|2947-0^SODIUM:^LN||150|mmol/l|136-148|H||A|F|19850301
|...<cr>
OBX|2|NM|2823-3^POTASSIUM:^LN||4.5|mmol/l|3.5-5|N||N|F|19850301|...<cr>
[electrolytes values]
OBX|3|NM|2069-3^CHLORIDE:^LN||102|mmol/l|94-105|N||N|F|19850301|...<cr>
OBX|4|NM|2028-9^CARBON DIOXIDE.TOTAL:^LN||27|mmol/l|24-31|N||N|F
|19850301|...<cr>
CSP|^Course 1|19941205|19950120|Y^Toxicity and Response^NCI |...<cr>
CSS|^Course Completion|19950120|...<cr>
OBR|1|935^OE|243791^LAB|2039-6^CARCINOEMBRYONIC
AG:^LN|||19941008|...<cr>
OBX|1|NM|2039-6^CARCINOEMBRYONIC AG:^LN||15.2|IU |...<cr>
OBR|2|1236|1236|10^Course Completion Form^StudyPhaseFormsList|||19950120
|...<cr>
OBX|1|CE|CRSRESP^Course Response^NCI||4^Partial Response|...<cr>
OBX|2|NM|DRUGDISP^Capsules Dispensed^NCI||60|...<cr>
OBX|3|NM|DRUGRETN^Capsules Returned^NCI||5|...<cr>
OBX|4|ID|DXCOMP^Diagnostic Tests Compliance^NCI||Y|...<cr>
OBX|5|CE|PERSTAT^Performance Status^NCI||3^ZUBRODS|...<cr>
OBR|3|1237|1237|9999^Adverse
Events|...<cr> |
[Note: Needs to maintain compatibility with ongoing product experience message efforts.] |
OBX|4|CE|9999&GRADE|1|M^MODERATE|...<cr> |
[Note2: There are other possible OBX suffixes defined by FDA: APEX/ NADIR, ACTION, THERAPY, OUTCOME, RECHALLENGE.] |
Patients
experience symptoms, manifest signs or develop diseases or syndromes while
exposed to medical devices and/or drugs. Evidence suggests that some of these
symptoms, signs, diseases or syndromes may develop as a consequence of the
products used. Examples include the development of clear cell adenocarcinoma
of the vagina in the daughters of mothers treated with diethylstilbestrol
during pregnancy and gastrointestinal bleeding in patients treated with
non-steroidal anti-inflammatory drugs. While it is difficult to prove
causality, strong evidence exists in many cases.
It is important to document such experiences during the development and testing
of products to identify potential adverse effects but also during routine use
of the product to identify serious adverse effects which occur infrequently.
The latter is the realm of pharmacoepidemiology and post-marketing
surveillance.
Adverse events are important for product manufacturers as signal generating
hypotheses concerning drug kinetics or dynamics, often in special populations
of patients. Adverse events are important for regulators in ensuring that
manufacturers protect the public health in assessments of risk and benefits,
including special populations, and that they promptly and thoroughly
investigate individual events and clusters of events. Adverse events are
especially important for practitioners and patients who always deal with a
special population of one individual who may be having an event and a
practitioner seeking information about related events seen with the same or
similar products.
Reporting has usually focused on serious and unexpected events.
Serious, if defined unambiguously, focuses attention on those events of most
importance to the patient and practitioner. Expected events are those which
prior experience has demonstrated to be probabilistically linked to the product
and are generally included in product labeling.
Because of the risks associated with the uses of drugs and medical devices, a
system of surveillance has been established in most developed countries. With
globalization of the marketplace, the need to share this information across
national boundaries has increased. Currently most reporting is performed using
a series of forms, including CIOMS, yellow cards, the FDA's 1639 and MedWatch
forms and the Japanese form, which are sent:
* from identified reporting sources to regulatory bodies
* from identified reporting sources to product manufacturers
* between regulatory bodies
* within product manufacturers
* within regulatory bodies
* from product manufacturers to regulatory bodies
* from regulatory bodies to the WHO Collaborative Drug Surveillance Center
Any chemical compound that may be used on or administered to humans or animals as an aid in the diagnosis, treatment or prevention of disease or other abnormal condition, for the relief of pain or suffering, or to control or improve any physiological condition (Dorland's Illustrated Medical Dictionary 27th edition).
Something contrived for or used in the diagnosis (vascular catheters), treatment (thermotherapy units) or prevention of disease or other abnormal condition, for the relief of pain or suffering or to control or improve any physiologic condition, including instrumentation and implanted devices (prosthetic cardiac valves, pacemakers, hip prostheses).
A drug or medical device.
Drug name that is not protected by a trademark, usually descriptive of its chemical structure; sometimes called a public name. In the US, most generic drug names are assigned by the US Adopted Name Council (USAN). Other generic names in common use are the National Formulary (NF) and the US Pharmacopoeia (USP) names. Figure 7-3 lists other available drug coding systems.
Proprietary names that are registered to protect the name for the sole use of the manufacturer holding the trademark.
*
Pre-marketing: Any untoward medical occurrence in a patient or clinical
investigation subject administered a pharmaceutical product and which does not
necessarily have a causal relationship with this treatment.
* Post-marketing/European Union: Any undesirable experience occurring to a
patient treated with a pharmaceutical product whether or not considered related
to the medicinal product.
* Post-marketing/US: Any adverse event associated with the use of a drug in
humans, whether or not considered drug related, including the following: An
adverse event occurring in the course of the use of a drug product in
professional practice; an adverse event occurring from drug overdose; an
adverse event occurring from drug withdrawal; and any failure of expected
pharmacologic action.
* WHO: Any untoward medical occurrence that may present during treatment with a
pharmaceutical product but which does not necessarily have a causal
relationship with this product.
*
Pre-marketing: All noxious and unintended responses to a medicinal product
related to any dose.
* Post-marketing/WHO: A response to a drug which is noxious and unintended, and
which occurs at doses normally used in man for prophylaxis, diagnosis, or
therapy of disease or for the modification of physiologic function
* Post-marketing/European Union: A reaction which is harmful and unintended and
which occurs at doses normally used in man for the prophylaxis, diagnosis, or
treatment of disease or the modification of physiological function.
* Post-marketing/US: Any undesirable effect reasonably associated with the use
of the drug, that may occur as part of the pharmacological action of the drug
or may be unpredictable.
An exposure which truly does increase or decrease the probability of a certain outcome.
When an event occurs a product may be suspected as causing the event but rarely can it be proven particularly at an early stage of the product's life. Certain information about the relationship between the product and the event can reinforce the belief in a causal relationship between the product and the event while others can decrease the probability that there is a causal relationship.
Many geopolitical entities have established agencies/authority responsible for regulating products used in health care. The agencies are collectively referred to as regulatory agencies.
The organization which is responsible for the manufacture of a product. This will usually be the entity, which holds the marketing authorization for the product.
The organization which holds the authority to market a product. This will often be the organization, which manufactures the product.
An
adverse product reaction which:
* is fatal (results in death)
* is life threatening
* requires hospitalization or prolongation of a hospitalization
* results in persistent or significant disability/incapacity
* results in a congenital anomaly/birth defect.
Medical and scientific judgment should be exercised in deciding whether
expedited reporting is appropriate in other situations, such as important
medical events that may not be immediately life threatening or result in
hospitalization but may jeopardize the patient or may require intervention to
prevent one of the other outcomes listed in the definition above. These should
also be considered serious.
Expected
events are those which prior experience has demonstrated to be
probabilistically linked to the product and are generally included in product
labeling.
Pre-marketing: An adverse reaction, the nature or severity of which is not
consistent with the applicable product information (e.g., Investigator's
Brochure for an unapproved investigational product).
Post-marketing/European Union: This relates to an adverse reaction which is not
mentioned in any EC summary of product characteristics (SPC). In the absence
of any European SPC, an international document prepared by the marketing
authorization holder containing all relevant safety information which the
marketing authorization holder considers should be listed for the medicinal
product in all countries where the medicinal product is marketed (Care Data
Sheet).
Post-marketing/US current: Unexpected means an adverse drug experience that is
not listed in the current labeling for the drug product and includes an event
that may be symptomatically and pathophysiologically related to an event listed
in the labeling but differs from the event because of greater severity or
specificity.
Post-marketing/US (proposed): The applicant's core safety data sheet shall be a
document prepared by the applicant that contains all relevant safety
information, including adverse drug experiences, which the applicant believes
should e listed for the drug in all countries where the drug is marketed. It
may be used by the applicant as the reference document by which an adverse drug
experience is judged to be expected or unexpected for purposes of this
post-marketing periodic report.
Post-marketing/WHO: An adverse reaction, the nature or severity of which is not
consistent with domestic labeling or market authorization, or expected from
characteristics of the drug.
Gabrielli
ER. Standard specification for drug therapy documentation. ASTM Committee
E31.12 July (1993).
Kessler DA. Introducing MEDWatch. JAMA 269: 2765-2768(1993).
Kurata JH, Overhage JM, Gabrielli E, Jones JK. International Data Standards
for Hospital-based Drug Surveillance. M.D. Computing 12(1) 50-57 (1995).
Moore N, Montera d, Coulson R, DeAbajo F, Kreft-Jais C, Biron A, Monteaugudo J.
The single case format: proposal for a structured message for the telematic
transmission of information on individual case reports in pharmacovigilance.
Pharmacoepidemiology and Drug Safety 3: 157-162 (1994)
Thompson WL. A modest proposal for enhancing the safety and effectiveness of
use of human drugs, biologics and devices and animal health products with human
health implications through cost-effective health informatics tools supporting
a global database of safety reports as a joint ICH E2, M1 and M2 initiative.
Private communication. March (1995)
The
message header segment will care one of three event types at MSH-9-message
type.
Event |
Description |
|---|---|
P07 |
PEX - Unsolicited initial individual product experience report |
P08 |
PEX - Unsolicited update individual product experience report |
P09 |
SUR - Summary product experience report |
The
primary application of this message is to transfer information related to an
adverse event occurring while a patient was exposed to a product.
PEX^P07-P08^PEX_P07 |
Product Experience Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
[PD1] |
Additional Demographics |
3 |
[{NTE}] |
Notes and comments |
2 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit - Additional Info |
3 |
{ |
||
PES |
Product Experience Sender |
7 |
{ |
||
PEO |
Product Experience Observation |
7 |
{ |
||
PCR |
Potential Causal Relationship |
7 |
[ |
||
RXE |
Pharmacy/Treatment Encoded Order |
4 |
[{RXR}] |
Pharmacy/Treatment Route |
4 |
] |
||
[{ |
||
RXA |
Pharmacy/Treatment Administration |
4 |
[RXR] |
Pharmacy/Treatment Route |
4 |
}] |
||
[{PRB}] |
Detail problem segment |
12 |
[{OBX}] |
Observation/Result Segment |
7 |
[{NTE}] |
Notes and comments |
2 |
[ |
||
NK1 |
Associated parties segment |
2 |
[ |
||
RXE |
Pharmacy/Treatment Encoded Order |
4 |
[{RXR}] |
Pharmacy/Treatment Route |
4 |
] |
||
[{ |
||
RXA |
Pharmacy/Treatment Administration |
4 |
[RXR] |
Pharmacy/Treatment Route |
4 |
}] |
||
[{PRB}] |
Detail Problem Segment |
12 |
[{OBX}] |
Observation/Results Segment |
7 |
] |
||
[{ |
||
CSR |
Clinical study registration |
7 |
[{CSP}] |
Clinical study phase segment |
7 |
}] |
||
}}} |
The
PID segment provides the patient identification information including
institutional identification numbers, date of birth and in the case of patients
who die, information about their death. Patients are frequently identified
only by their initials which can be represented in the PID segment, e.g. the
initials JMO would appear as J^M^O in the name field of the PID segment. The
EVN segment identifies the type of transaction that is being sent -- primarily
it specifies who the sender is and implies which information is expected to be
included in the message. A message sent from a healthcare provider, for
example, might contain minimal information, while a message from a
pharmaceutical manufacturer might contain nearly complete information.
The PES or Product Experience Sender segment provides information about the
message sender and its knowledge of the event. The heart of the product
experience message is the product experience observation (PEO) segment and the
PCR segments clustered under it. The PEO segment identifies a clinical event
and the PCR segments identify products which are potentially causally related
to the event. There may be more than one product which is potentially related
to the event so multiple PCR segments can be included. RXE and RXR segments
can be repeated and provide information about the products the patient was
exposed to at the time of the event (typically excluding those used to treat
the event). Details about the administration of the products identified in the
PCR segments should be described with RXE and RXR segments. Repeated PRB
segments provide information about diagnoses which represent comorbid
conditions. The repeated OBX segments are used to send patient observations
such as height, weight, last menstrual period, and laboratory results.
Analytical commentary can be included in the NTE segment. This commentary will
typically be the sender's analysis of the event and the potentially causally
related products. Finally, the CSR and CSP segments can optionally be included
if the event occurred during a formal clinical trial in order to describe the
trial.
When a product experience relates to an exposure which occurred indirectly
(transmammary or transplacentally for example), the individual experiencing the
adverse effect -- the fetus or child -- would be described in the PID segment
and the individual via which they are exposed in the NK1 segment. The first
set of RXE segments would typically indicate the drugs which to which the fetus
or child was exposed. Additional codes for the route are defined in this
Appendix to allow the suspected routes of exposure to be represented. The
second set of RXE/RXR segment - those clustered under the NK1 segment - would
represent the route by which the mother or father was exposed to the drug.
Early spontaneous abortion would normally be treated as an adverse effect on
the mother rather than on the fetus, and the PID would refer to the mother.
The second set of PRB/OBX segments reflects the problems/observations
associated with the individual via which they were exposed.
Each message contains information about a single case including one patient
(PID), at least one sender (PES), one or more events (PEO) and one or more
suspected products (PCR and RXE/RXA) for a minimal message. The structure of
the message allows actual administration information to be sent in the RXA if
known; if administration information is unavailable, or the adverse reaction
cannot be related to a single administration event, the RXE segment can be used
to send prescription level information. Additional information may be included
based on availability and regulatory requirements.
The MSH segment specifies the character set (MSH-18) and the language
(MSH-19) used in the PEX message.
The PEX message is designed to accommodate required reporting of adverse
product events to the responsible regulatory agencies. In the United States,
the paper version of this report is Medwatch.
Sending
summary reports related to products constitutes a P09 event.
SUR^P09^SUR_P09 |
Summary Product Experience Report |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
{ |
||
FAC |
Facility |
7 |
{ |
||
PSH |
Product Summary Header |
7 |
PDC |
Product Detail Country |
7 |
} |
||
PSH |
Product Summary Header |
7 |
{ |
||
FAC |
Facility |
7 |
PDC |
Product Detail Country |
7 |
NTE |
Notes (for PCR) |
2 |
} |
||
ED |
Encapsulated Data |
2 |
} |
The
Summary Product Experience Report message can be divided into two separate
parts. Part 1 consists of a Facility segment which identifies the reporting
organization, a Product Summary Header segment which provides summary
information about the products and manufacturers, and a Product Detail Country
segment which provides country specific product identification and marketing
information. Part 2 consists of a repeating series of segments. These
segments could be used to represent data about each model of a medical device
(Part 2 of FDA Form 3417, for example). The Product Summary Header segment
provides manufacturer's data, under which repeating sets of Facility segments
(representing multiple manufacturing sites), a Product Detail Country segment
(representing marketing and product identification data) and the Note segment
(for other commentary) may follow. Finally, the Encapsulated Data (ED) segment
can be used to transmit images of documents, including any of the MIME
(Multimedia Internet Mail Extension) support formats such as JPEG, GIF, and
FAX.
Regulatory agencies require a variety of reports that are centered on the
product, not on a single patient. Some of these reports request information
just about the product, and some request information about the product combined
with a summary of the product experience reports on that product. These are
used by regulatory agencies to provide totals against which they can verify
that they have received and processed all of the relevant reports, and to
calculate denominators for computing event rates. If manufacturers begin to
transmit these reports electronically and regulatory agencies in turn
electronically confirm the receipt of such reports, the need for some of these
summary reports will decline.
The SUR message provides a mechanism for sending a variety of different summary
reports. In the United States, the Medical Device Reporting Annual
Certification and the Medical Device Reporting Baseline Report are examples of
such reports. Below, we use these two medical device reports to illustrate how
one would map the contents of this kind of report to the SUR message.
Manufacturers are required to submit a Baseline Report (FDA Form 3417 of
October, 1995 (when a device is first released. The focus of this report is a
single product. The first part requests information about the manufacturer of
the product (Questions 2a through 2g), e.g., the firm's name, street address,
city, country, type of firm (e.g., manufacturer, distributor, both); the
manufacturer's contact (Questions 3a through 3g). e.g., title, street address,
city, state, phone number, and whether the firm is an organization of a foreign
manufacturer. Most of this information can be transmitted as fields within the
FAC (Facility segment - the first segment in the SUR message following the
MSH). Question 1 (which asks the type of baseline report - initial or annual
update) and Question 7 (the date of the report) are reported in the PSH
(Product Summary Header) segment that follows the FAC segment in the SUR
message. The second part of the Baseline Report form also includes information
about the device name (Question 2), generic name (Question 3), device model
number (Question 4), device catalogue number (Question 5), other device
identifier (Question 6), product code (Question 7), and device family (Question
8), related device information (Question 9), the basis for marketing the device
(Question 10), device life (Question 11), the date the device was first
marketed (Question 12), the date the device ceased being marketed (Question
13), whether the device was the subject of a 522 study (Question 14), and the
number of devices manufactured, distributed, and in current use (Question 15).
All of these questions with the exception of #9 are represented in the PDC
segment. Questions 16a and 16b are represented by nested PSH segments.
The Medical Device Reporting Annual Certification form consists of two parts.
Part 12 transmits information describing the firm submitting the report
(Questions 2a through 2h) and the individual who completed the report
(Questions 3a through 3g). These questions are represented in the FAC segment.
Question 1 (period covered by the certification) corresponds to the PSH
segment. Part 2, Question 3, which details one or more individual devices, can
be transmitted in the repeating FAC and PSH segments. Figure 7-19 summarizes
the mapping between questions on these two FDA forms and the SUR message.
Baseline Report |
Annual Certification |
SUR |
|---|---|---|
MSH |
||
Part
1 |
Part
1 |
{ FAC |
Part
1 |
Part
1 |
{PSH |
PDC |
||
} |
||
Part
2 |
Part
2 |
PSH |
Part
2 |
Part
2 |
{ FAC |
Part
2 |
PDC |
|
NTE |
||
} |
||
Part
2 |
ED |
|
} |
SEQ |
LEN |
DT |
OPT |
RP/ # |
TBL # |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
250 |
XON |
O |
Y |
01059 |
Sender Organization Name |
|
2 |
250 |
XCN |
O |
Y |
01060 |
Sender Individual Name |
|
3 |
250 |
XAD |
O |
Y |
01062 |
Sender Address |
|
4 |
250 |
XTN |
O |
Y |
01063 |
Sender Telephone |
|
5 |
75 |
EI |
O |
01064 |
Sender Event Identifier |
||
6 |
2 |
NM |
O |
01065 |
Sender Sequence Number |
||
7 |
600 |
FT |
O |
Y |
01066 |
Sender Event Description |
|
8 |
600 |
FT |
O |
01067 |
Sender Comment |
||
9 |
26 |
TS |
O |
01068 |
Sender Aware Date/Time |
||
10 |
26 |
TS |
R |
01069 |
Event Report Date |
||
11 |
3 |
ID |
O |
Y/2 |
0234 |
01070 |
Event Report Timing/Type |
12 |
1 |
ID |
O |
0235 |
01071 |
Event Report Source |
|
13 |
1 |
ID |
O |
Y |
0236 |
01072 |
Event Reported To |
Components:
<organization name (ST)> ^ <organization name type code (IS)>
^<ID Number (NM)> ^ <check digit (NM)> ^ <code identifying the
check digit scheme employed (ID)> ^ <assigning authority (HD)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^
<name representation code (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> * <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> * <universal ID type (ID)>
Definition: This field contains the name of the organization sending the
message. Coded lists of manufacturers such as that from the World Health
Organization database might be used in the component of the coded name to
identify the source code type. If sent from an individual, this field may not
be sent.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the name of the contact individual. If sent by
an organization, the individuals in the organization who serve as primary
contact points correspondence regarding this event.
Components:
In Version 2.3 and later, replaces the AD data type. <street address
(SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or
province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^
< address type (ID)> ^ <other geographic designation (ST)>
^ <county/parish code (IS)> ^ <census tract (IS)> ^
<address representation code (ID)> ^ <address validity range
(DR)>
Definition: This field contains the postal address of the message sender to
which correspondence regarding the experience being reported should be directed.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication
use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email
address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^
phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the telephone number of the message sender to
which telephone communications regarding the experience being reported should
be directed. An electronic mail address can be specified in this field.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: The first component of this field contains the product
manufacturer's unique alphanumeric identifier for this specific event. This
identifier will be used on all subsequent communications regarding this event.
For events reported to the FDA, the identifier is: the FDA assigned
manufacturer or distributor number; a hyphen; the 4-digit year; a hyphen; and a
consecutive 5-digit sequence number for each report filled by the sender that
year. For example, the event identifier for the third event reported in 1996
by a manufacturer whose FDA-assigned registration number is 1234567 would be
1234567-1993-3. Organizations without a FDA-assigned registration number
should use 0000000 until assigned a number. Reports from other facilities
should use the 10-digit HCFA number left padded with zeros in place of the
FDA-assigned registration number. The second through fourth components are
defined in exactly the same way as the three components of the hierarchic
designator (HD) data type (Section 2.8.18, "HD - hierarchic designator").
Definition: This field contains sequentially assigned integer values which distinguish messages which share the same sender event identification element. 0 for initial report, 1 for second, and so on.
Definition: This field contains the summary narrative text description of the event that occurred written by the sender, which may include a description of the nature of the event, how the product was involved, any environmental conditions that may have influenced the event, and patient follow-up or required treatment. Note that laboratory results can be encoded as OBX segments rather then including them in the narrative. By representing clinical information in OBX segments rather than in the narrative, these data become much more useful and flexible.
Definition: This field contains the text commentary regarding the report being made, such as disclaimers, which is not necessarily part of the report.
Definition: This field identifies the date the sender became aware of the event.
Definition: This field contains the date the message was originally sent to the regulatory agency.
Definition:
This field contains the timing type of report as required by regulatory
agency. Refer to HL7 Table 0234 - Report timing for valid
values.
Value |
Description |
|---|---|
CO |
Correction |
AD |
Additional information |
RQ |
Requested information |
DE |
Device evaluation |
PD |
Periodic |
3D |
3 day report |
7D |
7 day report |
10D |
10 day report |
15D |
15 day report |
30D |
30 day report |
Definition:
This field identifies the source from which the sender learned about the
event. Multiple sources may be reported by repeating the element.
If the source of the report is a clinical trial, the CSR and CSP segments can
be included to define the study. Refer to HL7 Table 0235 - Report
source for valid values.
Value |
Description |
|---|---|
C |
Clinical trial |
L |
Literature |
H |
Health professional |
R |
Regulatory agency |
D |
Database/registry/poison control center |
N |
Non-healthcare professional |
P |
Patient |
M |
Manufacturer/marketing authority holder |
E |
Distributor |
O |
Other |
Definition:
This field indicates all the entities to whom the entity submitting the report
has reported the event. Repeat the element if the report was submitted to more
than one entity. Refer to HL7 Table 0236 - Event reported to for
valid values.
Value |
Description |
|---|---|
M |
Manufacturer |
L |
Local facility/user facility |
R |
Regulatory agency |
D |
Distributor |
Details
related to a particular clinical experience or event are embodied in the PEO
segment. This segment can be used to characterize an event which might be
attributed to a product to which the patient was exposed. Products with a
possible causal relationship to the observed experience are described in the
following PCR (possible causal relationship) segments. The message format was
designed to be robust and includes many optional elements which may not be
required for a particular regulatory purpose but allow a complete
representation of the drug experience if needed.
A PEX message can contain multiple PEO segments if the patient experienced more
than one event but must contain at least one PEO segment.
SEQ |
LEN |
DT |
OPT |
RP/ # |
TBL # |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
250 |
CE |
O |
Y |
01073 |
Event Identifiers Used |
|
2 |
250 |
CE |
O |
Y |
01074 |
Event Symptom/Diagnosis Code |
|
3 |
26 |
TS |
R |
01075 |
Event Onset Date/Time |
||
4 |
26 |
TS |
O |
01076 |
Event Exacerbation Date/Time |
||
5 |
26 |
TS |
O |
01077 |
Event Improved Date/Time |
||
6 |
26 |
TS |
O |
01078 |
Event Ended Data/Time |
||
7 |
250 |
XAD |
O |
Y |
01079 |
Event Location Occurred Address |
|
8 |
1 |
ID |
O |
Y |
0237 |
01080 |
Event Qualification |
9 |
1 |
ID |
O |
0238 |
01081 |
Event Serious |
|
10 |
1 |
ID |
O |
0239 |
01082 |
Event Expected |
|
11 |
1 |
ID |
O |
Y |
0240 |
01083 |
Event Outcome |
12 |
1 |
ID |
O |
0241 |
01084 |
Patient Outcome |
|
13 |
600 |
FT |
O |
Y |
01085 |
Event Description From Others |
|
14 |
600 |
FT |
O |
Y |
01086 |
Event From Original Reporter |
|
15 |
600 |
FT |
O |
Y |
01087 |
Event Description From Patient |
|
16 |
600 |
FT |
O |
Y |
01088 |
Event Description From Practitioner |
|
17 |
600 |
FT |
O |
Y |
01089 |
Event Description From Autopsy |
|
18 |
250 |
CE |
O |
Y |
01090 |
Cause Of Death |
|
19 |
250 |
XPN |
O |
Y |
01091 |
Primary Observer Name |
|
20 |
250 |
XAD |
O |
Y |
01092 |
Primary Observer Address |
|
21 |
250 |
XTN |
O |
Y |
01093 |
Primary Observer Telephone |
|
22 |
1 |
ID |
O |
0242 |
01094 |
Primary Observer's Qualification |
|
23 |
1 |
ID |
O |
0242 |
01095 |
Confirmation Provided By |
|
24 |
26 |
TS |
O |
01096 |
Primary Observer Aware Date/Time |
||
25 |
1 |
ID |
O |
0243 |
01097 |
Primary Observer's identity May Be Divulged |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field may be used to transmit the event identifier used by
other entities for this event. The entry would typically contain a unique
alphanumeric identifier assigned by an entity with the text component null or
repeating the unique alphanumeric identifier followed by the organization's
identifier. An event identifier might be GB1234^GB1234^PharmaGiant for example.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is the coded diagnosis or problem description which best
describes the event. A text representation of the coded item should routinely
be included. MEDDRA and WHO-ART are examples of appropriate coding schemes, as
are the patient and device codes included in the FDA Center for Devices and
Radiologic Health's coding manual for Form 3500A.
Definition: This field contains a report or best estimate of the date/time of onset of the event. The date/time can be recorded to any level of precision it is known (hour, day, month, year).
Definition: This field identifies the best estimate of the date/time the event was exacerbated.
Definition: This field identifies the best estimate of the date/time the event improved.
Definition: This field identifies the best estimate of the date/time the event resolved.
Components:
In Version 2.3 and later, replaces the AD data type. <street address
(SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or
province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^
< address type (ID)> ^ <other geographic designation (ST)>
^ <county/parish code (IS)> ^ <census tract (IS)> ^
<address representation code (ID)> ^ <address validity range
(DR)>
Definition: This field identifies the location at which the event started.
Often this will specify only the country in which the event started.
Definition:
This field is contains a classification of the type of product experience this
event is considered to represent. Refer to HL7 Table 0237 - Event
qualification for valid values.
Value |
Description |
|---|---|
I |
Interaction |
O |
Overdose |
A |
Abuse |
M |
Misuse |
D |
Dependency |
L |
Lack of expect therapeutic effect |
W |
Drug withdrawal |
B |
Unexpected beneficial effect |
Unexpected beneficial effects would not often be reported but are required by certain countries.
Definition:
This field indicates whether the event was judged as serious. If the event
did not meet the criteria for seriousness but the sender judges the event
significant on other grounds, the event can be identified as significant
[but not serious]. Refer to HL7 Table 0238 - Event
seriousness for valid values.
Value |
Description |
|---|---|
Y |
Yes |
S |
Significant |
N |
No |
Definition:
This field indicates whether the observed event was expected or unexpected as
judged. Refer to HL7 Table 0239 - Event expected for valid
values.
Value |
Description |
|---|---|
Y |
Yes |
N |
No |
U |
Unknown |
Definition:
This field identifies the consequence of the event on the patient. If
the consequence of the event is not understood or not available, the patient
outcome element may be used although neither is required. May be repeated if
more than one is appropriate. Refer to HL7 Table 0240 - Event
consequence for valid values.
Value |
Description |
|---|---|
D |
Death |
L |
Life threatening |
H |
Caused hospitalized |
P |
Prolonged hospitalization |
C |
Congenital anomaly/birth defect |
I |
Incapacity which is significant, persistent or permanent |
J |
Disability which is significant, persistent or permanent |
R |
Required intervention to prevent permanent impairment/damage |
O |
Other |
When
an event specific outcome is not available, the patient outcome element may be
used to represent the patient's overall outcome if that information is known.
Refer to HL7 Table 0241 - Patient outcome for valid values.
Value |
Description |
|---|---|
D |
Died |
R |
Recovering |
N |
Not recovering/unchanged |
W |
Worsening |
S |
Sequelae |
F |
Fully recovered |
U |
Unknown |
Definition: This field contains a summary narrative text description of the event that occurred written by the sender. Note that laboratory results can be encoded as OBX segments rather then including them in the narrative. By representing clinical information in OBX segments rather than in the narrative, these data become much more useful and flexible.
Definition: This field contains a summary narrative text description of the event provided by the original reporter. Note that laboratory results can be encoded as OBX segments rather then including them in the narrative.
Definition: This field contains a summary narrative text description of the event obtained directly from the patient. Note that laboratory results can be encoded as OBX segments rather then including them in the narrative, which will allow the data to be more readily represented and manipulated.
Definition: This field contains a summary narrative text description of the event provided by the practitioner most familiar with the event. Note that laboratory results can be encoded as OBX segments rather then including them in the narrative.
Definition: This field contains a summary narrative text description of the autopsy results. Note that laboratory results can be encoded as OBX segments rather then including them in the narrative.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the coded cause of death. May be repeated
as necessary to list multiple contributing causes. A text description can be
included by including text but no code or coding system. For example, if the
cause of death is to be determined at autopsy but results are not yet
available, the cause of death element could be ^Pending autopsy^. The
date/time of death can be sent in the PID and the autopsy results sent in the
event description from autopsy element of the PEO segment.
Components:
In Version 2.3, replaces the PN data type. <family name (FN)> ^
<given name (ST)> ^ <second and further given names or initials
thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g.,
DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <name type code (ID)
> ^ <name representation code (ID)> ^ <name context (CE)> ^
<name validity range (DR)> ^ <name assembly order (ID)>
Definition: This field identifies the name of the person who initially
described the event.
Components:
In Version 2.3 and later, replaces the AD data type. <street address
(SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or
province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^
< address type (ID)> ^ <other geographic designation (ST)>
^ <county/parish code (IS)> ^ <census tract (IS)> ^
<address representation code (ID)> ^ <address validity range
(DR)>
Definition: This field identifies the address of the person who initially
described the event.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication
use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email
address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^
phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field identifies the telephone number of the person who
initially described the event.
Definition:
This field contains the qualification of the primary observer which may assist
in assessing the validity of the observations. Refer to HL7 Table
0242 - Primary observer's qualification for valid values.
Value |
Description |
|---|---|
P |
Physician (osteopath, homeopath) |
R |
Pharmacist |
M |
Mid-level professional (nurse, nurse practitioner, physician's assistant) |
H |
Other health professional |
C |
Health care consumer/patient |
L |
Lawyer/attorney |
O |
Other non-health professional |
Definition: This field contains the qualification of the health professional who confirmed the observation if the primary observer was not a health professional. Refer to HL7 Table 0242 - Primary observer's qualification for valid values.
Definition: This field identifies the date/time the primary observer became aware of event.
Definition:
Indicates whether or not the primary observer, if known to the sender, grants
permission to disclose his or her identity to the product manufacturer for the
purpose of further investigating the event. If the element is absent, the
assumption should be made that permission is not granted. Refer to
HL7 Table 0243 - Identity may be divulged for valid values.
Value |
Description |
|---|---|
Y |
Yes |
N |
No |
NA |
Not applicable |
The
PCR segment is used to communicate a potential or suspected relationship
between a product (drug or device) or test and an event with detrimental effect
on a patient. This segment identifies a potential causal relationship between
the product identified in this segment and the event identified in the PEO
segment.
More than one PCR segment can be included in the message if more than one
product is possibly causally related to the event.
SEQ |
LEN |
DT |
OPT |
RP/ # |
TBL # |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
250 |
CE |
R |
01098 |
Implicated Product |
||
2 |
1 |
IS |
O |
0249 |
01099 |
Generic Product |
|
3 |
250 |
CE |
O |
01100 |
Product Class |
||
4 |
8 |
CQ |
O |
01101 |
Total Duration Of Therapy |
||
5 |
26 |
TS |
O |
01102 |
Product Manufacture Date |
||
6 |
26 |
TS |
O |
01103 |
Product Expiration Date |
||
7 |
26 |
TS |
O |
01104 |
Product Implantation Date |
||
8 |
26 |
TS |
O |
01105 |
Product Explantation Date |
||
9 |
8 |
IS |
O |
0244 |
01106 |
Single Use Device |
|
10 |
250 |
CE |
O |
01107 |
Indication For Product Use |
||
11 |
8 |
IS |
O |
0245 |
01108 |
Product Problem |
|
12 |
30 |
ST |
O |
Y/3 |
01109 |
Product Serial/Lot Number |
|
13 |
1 |
IS |
O |
0246 |
01110 |
Product Available For Inspection |
|
14 |
250 |
CE |
O |
01111 |
Product Evaluation Performed |
||
15 |
250 |
CE |
O |
0247 |
01112 |
Product Evaluation Status |
|
16 |
250 |
CE |
O |
01113 |
Product Evaluation Results |
||
17 |
8 |
ID |
O |
0248 |
01114 |
Evaluated Product Source |
|
18 |
26 |
TS |
O |
01115 |
Date Product Returned To Manufacturer |
||
19 |
1 |
ID |
O |
0242 |
01116 |
Device Operator Qualifications |
|
20 |
1 |
ID |
O |
0250 |
01117 |
Relatedness Assessment |
|
21 |
2 |
ID |
O |
Y/6 |
0251 |
01118 |
Action Taken In Response To The Event |
22 |
2 |
ID |
O |
Y/6 |
0252 |
01119 |
Event Causality Observations |
23 |
1 |
ID |
O |
Y/3 |
0253 |
01120 |
Indirect Exposure Mechanism |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the coded identity of the product (drug,
device, etc.) which is possibly causally related to the event. Includes the
product identity number such as NDC, model or catalogue numbers. If a coded
value is not available for the product a text description can be included as
the second component of the CE data. See Chapter 2 for a listing of some
recognized coding systems for drugs and devices.
Definition:
This field indicates whether the product used was a generic or a branded
product. Refer to User-defined Table 0249 - Generic product for
suggested values.
Value |
Description |
|---|---|
No suggested values defined |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the coded classification of the implicated
product. For drugs, this would usually be the drug class - calcium channel
blocking agents for nifedipine for example. For other products it would be the
generic type of device, e.g., urinary catheter, cardiac pacemaker. If a coded
value is not available for the class, a text description can be included.
Components:
<quantity (NM)> ^ <units (CE)>
Subcomponents of units: <identifier (ST)> & <test (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (IS)>
Definition: This field represents the total duration of therapy with product
listed. The treatment at the current dose and schedule are indicted in the
quantity timing attribute of the RXE segment but the patient may have been
treated for some time previously at a different dose or on a different
schedule. The quantity in the second component of the CQ should be a time
quantity.
Definition: This field indicates the date the product was manufactured.
Definition: This field contains the expiration date indicated on the product packaging.
Definition: If an implantable medical device, this field identifies the date device was implanted.
Definition: If an implantable medical device and it was removed, the field identifies the date it was removed.
Definition:
This field indicates whether the product was designed for a single use. Refer
to User-defined Table 0244 - Single use device for suggested
values.
Value |
Description |
|---|---|
No suggested values defined |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains coded representation of the problem or
diagnosis for which the product was used. See Chapter 2 for some coding
systems which might be chosen to transmit diagnoses or problems.
Definition:
A product problem would exist if a product malfunction could lead to death or
serious injury. Refer to User-defined Table 0245 - Product
problem for suggested values.
Value |
Description |
|---|---|
No suggested values defined |
Definition: This field is an alphanumeric descriptor which identifies the specific item or lot of drug. This descriptor would normally be obtained from the package labeling or item itself.
Definition:
This field indicates that the product is available for analysis.
User-defined Table 0246 -Product available for inspection is
used as the HL7 identifier for the user-defined table of values for this
field. If the product was returned to the manufacturer, this would be
indicated by including the date it was returned in the date product returned to
manufacturer element.
Value |
Description |
|---|---|
No suggested values defined |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field indicates the type of product evaluation performed.
The evaluation codes listed in SubPart B of the Coding Manual for FDA Form
3500A, "Type of Evaluation Performed" may be used. If no codes are available,
text may be sent in the second component of the field.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field identifies the status of product evaluation. Subpart A
Item H.3 of the Coding Manual for FDA Form 3500A may also be used. If no codes
are available, text may be sent in the second component of the field. Refer to
HL7 Table 0247 - Status of evaluation for valid values.
Value |
Description |
|---|---|
Y |
Evaluation completed |
P |
Evaluation in progress |
K |
Problem already known, no evaluation necessary |
X |
Product not made by company |
A |
Evaluation anticipated, but not yet begun |
D |
Product discarded -- unable to follow up |
C |
Product received in condition which made analysis impossible |
I |
Product remains implanted -- unable to follow up |
U |
Product unavailable for follow up investigation |
Q |
Product under quarantine -- unable to follow up |
R |
Product under recall/corrective action |
O |
Other |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the results of the product evaluation.
Definition:
This field contains the source of the product evaluated. Refer to HL7
Table 0248 - Product source for valid values.
Value |
Description |
|---|---|
A |
Actual product involved in incident was evaluated |
L |
A product from the same lot as the actual product involved was evaluated |
R |
A product from a reserve sample was evaluated |
N |
A product from a controlled/non-related inventory was evaluated |
Definition: If the product was returned to the manufacturer, this field contains the date it was returned may be reported.
Definition: This field identifies the qualification of the person operating the device when the event occurred. Refer to HL7 Table 0242 - Primary observer's qualification for valid values.
Definition:
This field represents the assessment of relatedness of the product to the
event. Refer to HL7 Table 0250 - Relatedness assessment for valid
values.
Value |
Description |
|---|---|
H |
Highly probable |
M |
Moderately probable |
S |
Somewhat probable |
I |
Improbable |
N |
Not related |
Definition:
This field indicates the action taken as a result of the event. Segment may
repeat if multiple categories of evidence are relevant. Refer to
HL7 Table 0251 - Action taken in response to the event for
valid values.
Value |
Description |
|---|---|
WP |
Product withdrawn permanently |
WT |
Product withdrawn temporarily |
DR |
Product dose or frequency of use reduced |
DI |
Product dose or frequency of use increased |
OT |
Other |
N |
None |
Definition:
This field contains observations made about the event which may bear on
causality. Refer to HL7 Table 0252 - Causality observations for
valid values. Segment may repeat if multiple categories of evidence are
relevant.
Value |
Description |
|---|---|
AW |
Abatement of event after product withdrawn |
BE |
Event recurred after product reintroduced |
LI |
Literature reports association of product with event |
IN |
Event occurred after product introduced |
EX |
Alternative explanations for the event available |
PL |
Effect observed when patient receives placebo |
TC |
Toxic levels of product documented in blood or body fluids |
DR |
Dose response observed |
SE |
Similar events in past for this patient |
OE |
Occurrence of event was confirmed by objective evidence |
OT |
Other |
Definition:
The patient identified in the PID segment, who experienced the event, might
have been exposed to the potential causal product via an intermediary, e.g., a
child might be exposed to a product through the placenta or in breast milk, or
a transfusion recipient might be exposed via a blood product. If this is the
case, the mechanism of product transmission is identified in this field, using
the valid values in HL7 Table 0253 - Indirect exposure mechanism.
If this field is populated, the identity of the person through whom the product
was transmitted is contained in NK1 and RXE segments which follow.
Value |
Description |
|---|---|
B |
Breast milk |
P |
Transplacental |
F |
Father |
X |
Blood product |
O |
Other |
SEQ |
LEN |
DT |
OPT |
RP/ # |
TBL # |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
60 |
ST |
R |
01233 |
Report Type |
||
2 |
60 |
ST |
O |
01297 |
Report Form Identifier |
||
3 |
26 |
TS |
R |
01235 |
Report Date |
||
4 |
26 |
TS |
O |
01236 |
Report Interval Start Date |
||
5 |
26 |
TS |
O |
01237 |
Report Interval End Date |
||
6 |
12 |
CQ |
O |
01238 |
Quantity Manufactured |
||
7 |
12 |
CQ |
O |
01239 |
Quantity Distributed |
||
8 |
1 |
ID |
O |
0329 |
01240 |
Quantity Distributed Method |
|
9 |
600 |
FT |
O |
01241 |
Quantity Distributed Comment |
||
10 |
12 |
CQ |
O |
01242 |
Quantity in Use |
||
11 |
1 |
ID |
O |
0329 |
01243 |
Quantity in Use Method |
|
12 |
600 |
FT |
O |
01244 |
Quantity in Use Comment |
||
13 |
2 |
NM |
O |
Y/8 |
01245 |
Number of Product Experience Reports Filed by Facility |
|
14 |
2 |
NM |
O |
Y/8 |
01246 |
Number of Product Experience Reports Filed by Distributor |
Definition: This field contains the name, title, or other description of the report. Typically, the field will include the agency name (e.g., FDA), agency component if applicable (e.g., CDRH) and the report type (e.g., Medical Device Reporting Baseline Report).
Definition: This field contains the form descriptor which describes the report. Typically, the field will include the agency name (e.g., FDA), agency component if applicable (e.g., CDRH) and the form number (e.g., 3417).
Definition: This field contains the date as assigned by the sender.
Definition: This field contains the date that marks the beginning of the time interval covered by the current report.
Definition: This field contains the date which marks the inclusive end of the time interval covered by the current report.
Components:
<quantity (NM)> ^ <units (CE)>
Subcomponents of units: <identifier (ST)> & <test (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (IS)>
Definition: This field is used to send the number of units of the product
manufactured during the reporting interval. The second component can be used
to specify the units for the quantity.
Components:
<quantity (NM)> ^ <units (CE)>
Subcomponents of units: <identifier (ST)> & <test (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (IS)>
Definition: This field is used to send the number of units of the product
which was distributed during the reporting interval. The second component can
be used to specify the units for the quantity.
Definition:
This field is used for measuring the quantity distributed. An explanation of
the method used for estimation can be included in PSH-9-quantity distributed
comment. Refer to HL7 Table 0329 - Quantity method for
valid values.
Value |
Description |
|---|---|
A |
Actual count |
E |
Estimated (see comment) |
Definition: This field is used for any explanatory text needed but in particular should provide a description of the estimation method used. If referring to the description used in a previous report, the comment should include the product identifier and data of that report.
Components:
<quantity (NM)> ^ <units (CE)>
Subcomponents of units: <identifier (ST)> & <test (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (IS)>
Definition: This field is used to send the number of units of the product
which were in use during the reporting interval. The second component can be
used to specify the units for the quantity.
Definition: This field contains the method used for measuring the quantity in use. An explanation of the method used for estimation can be included in PSH-12-quantity in use comment. Refer to HL7 Table 0329 - Quantity method for valid values.
Definition: This field can be used for any explanatory text needed but in particular should provide a description of the estimation method used. If referring to the description used in a previous report, the comment should include the product identifier and data of the report.
Definition: The field contains the number of product experience reports filed by facility.
Definition: This field contains the number of product experience reports filed by distributor.
SEQ |
LEN |
DT |
OPT |
RP/ # |
TBL # |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
250 |
XON |
R |
Y |
01247 |
Manufacturer/Distributor |
|
2 |
250 |
CE |
R |
01248 |
Country |
||
3 |
60 |
ST |
R |
01249 |
Brand Name |
||
4 |
60 |
ST |
O |
01250 |
Device Family Name |
||
5 |
250 |
CE |
O |
01251 |
Generic Name |
||
6 |
60 |
ST |
O |
Y |
01252 |
Model Identifier |
|
7 |
60 |
ST |
O |
01253 |
Catalogue Identifier |
||
8 |
60 |
ST |
O |
Y |
01254 |
Other Identifier |
|
9 |
250 |
CE |
O |
01255 |
Product Code |
||
10 |
4 |
ID |
O |
0330 |
01256 |
Marketing Basis |
|
11 |
60 |
ST |
O |
01257 |
Marketing Approval ID |
||
12 |
12 |
CQ |
O |
01258 |
Labeled Shelf Life |
||
13 |
12 |
CQ |
O |
01259 |
Expected Shelf Life |
||
14 |
26 |
TS |
O |
01260 |
Date First Marketed |
||
15 |
26 |
TS |
O |
01261 |
Date Last Marketed |
Components:
<organization name (ST)> ^ <organization name type code (IS)>
^<ID Number (NM)> ^ <check digit (NM)> ^ <code identifying the
check digit scheme employed (ID)> ^ <assigning authority (HD)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^
<name representation code (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> * <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> * <universal ID type (ID)>
Definition: This field contains the identity of the manufacturer/distributor.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the country to which this product detail is
relevant. ISO 3166 provides a list of country codes that may be used.
Definition: This field contains the name under which the product is marketed by this manufacturer.
Definition: This field contains the name used by the manufacturer to describe the family of products to which this product belongs.
Components<identifier
(ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^
<alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of
alternate coding system (IS)>
Definition: This field contains the name generically used to identify the
product.
Definition: This field contains the manufacturer's model identifier for the product.
Definition: This field contains the manufacturer's catalogue identifier for the product.
Definition: This field contains any other identifier used to for the product.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the product code from an external coding
system such as that used by the CDRH at the FDA.
Definition:
This field contains the basis for marketing approval. Refer to HL7
Table 0330 - Marketing basis for valid values.
Value |
Description |
|---|---|
510K |
510 (K) |
510E |
510 (K) exempt |
PMA |
Premarketing authorization |
PRE |
Preamendment |
TXN |
Transitional |
522S |
Post marketing study (522) |
Definition: This field contains the designation or description of the marketing basis.
Components:
<quantity (NM)> ^ <units (CE)>
Subcomponents of units: <identifier (ST)> & <text (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (IS)>
Definition: This field contains the shelf life of the product as labeled.
This will usually be in months or years. If there is no shelf life indicated
in the product labeling, this field will be empty.
Components:
<quantity (NM)> ^ <units (CE)>
Subcomponents of units: <identifier (ST)> & <text (ST)>
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (IS)>
Definition: This field contains the shelf life of the product expected by the
manufacturer. This will usually be in months or years.
Definition: This field contains the date the product was first marketed in the country.
Definition: This field contains the date the product was last marketed in the country. This field will be omitted if the product is still being marketed.
SEQ |
LEN |
DT |
OPT |
RP/ # |
TBL # |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
20 |
EI |
R |
01262 |
Facility ID-FAC |
||
2 |
1 |
ID |
O |
0331 |
01263 |
Facility Type |
|
3 |
250 |
XAD |
R |
Y |
01264 |
Facility Address |
|
4 |
250 |
XTN |
R |
01265 |
Facility Telecommunication |
||
5 |
250 |
XCN |
O |
Y |
01266 |
Contact Person |
|
6 |
60 |
ST |
O |
Y |
01267 |
Contact Title |
|
7 |
250 |
XAD |
O |
Y |
01166 |
Contact Address |
|
8 |
250 |
XTN |
O |
Y |
01269 |
Contact Telecommunication |
|
9 |
250 |
XCN |
R |
Y |
01270 |
Signature Authority |
|
10 |
60 |
ST |
O |
01271 |
Signature Authority Title |
||
11 |
250 |
XAD |
O |
Y |
01272 |
Signature Authority Address |
|
12 |
250 |
XTN |
O |
01273 |
Signature Authority Telecommunication |
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains the facility identifier.
Definition:
This field contains the type of facility. Refer to HL7 Table 0331 -
Facility type for valid values.
Value |
Description |
|---|---|
U |
User |
M |
Manufacturer |
D |
Distributor |
A |
Agent for a foreign manufacturer |
Components:
In Version 2.3 and later, replaces the AD data type. <street address
(SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or
province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^
< address type (ID)> ^ <other geographic designation (ST)>
^ <county/parish code (IS)> ^ <census tract (IS)> ^
<address representation code (ID)> ^ <address validity range
(DR)>
Definition: This field contains the facility's address.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication
use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email
address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^
phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the facility's telecommunication information.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ <name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the primary contact person's name.
Definition: This field contains the primary contact person's title.
Components:
In Version 2.3 and later, replaces the AD data type. <street address
(SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or
province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^
< address type (ID)> ^ <other geographic designation (ST)>
^ <county/parish code (IS)> ^ <census tract (IS)> ^
<address representation code (ID)> ^ <address validity range
(DR)>
Definition: This field contains the primary contact person's address.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication
use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email
address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^
phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the primary contact person's telecommunication
information.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or
further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)
(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^
<source table (IS)> ^ <assigning authority (HD)> ^ <name type
code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the
check digit scheme employed (ID)> ^ <identifier type code (IS)> ^
<assigning facility (HD)> ^ <name representation code (ID)> ^
<name context (CE)> ^ <name validity range (DR)> ^ < name
assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the name of the individual with signature
authority or who is responsible for the report.
Definition: This field contains the title of the individual with signature authority or who is responsible for this report.
Components:
In Version 2.3 and later, replaces the AD data type. <street address
(SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or
province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^
< address type (ID)> ^ <other geographic designation (ST)>
^ <county/parish code (IS)> ^ <census tract (IS)> ^
<address representation code (ID)> ^ <address validity range
(DR)>
Definition: This field contains the address of the individual with signature
authority or who is responsible for this report.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication
use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email
address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^
phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the telecommunication information of the
individual with signature authority of who is responsible for this report.
MSH|^-&|SAP||RAP||200006051512||PEX^P07|...<cr>
EVN|...<cr>
PID|1||""|A^A^A||19230616|F|||||||||||||||||Y|...<cr>
Note: This section probably needs to have its own definition of the PID.
PID-3 is a required field in chapter 3, but in the context of this section
probably shouldn't be required. I also removed PID-23, Birthplace (19950710).
A date is not a birthplace.
PES|Eli Lilly and Company||Lilly Corporate Center^^Indianapolis^IN^46285||
GB95070448A|0|||19950704|19950710|10D|...<cr>
PEO||^Awaiting results of autopsy|19950704||||^^^^^GB||S|N|D~H~O||Patient
admitted via casualty with increased shortness of breath and left sided chest
pain on 04 JUL 95 for assessment.~11-JUL-95 Patient admitted 09-JUL-95 at 11:30
PM with an 18 hour history of diarrhoea followed by collapse. On admission,
patient was exhausted and dehydrated. She had a rash on both breasts and
abdomen. Patient found to have deteriorating renal function. Patient commenced
IV fluid, however patient was found dead on 10-JUL-95 morning. Query vomited
and aspirated. Post mortem requested. Events possibly related to study
drug.|...<cr>
PCR|xxxxx^Wonder Drug 1^ATC|N|^antineoplastic|||||||^NON SMALL CELL LUNG
CANCER|...<cr>
RXE|1^^^19950629^19950710|xxxxx^Wonder Drug
1^ATC|1||TAB|||||||||||||||||M1|3||||NON SMALL CELL LUNG
CANCER|...<cr>
RXR|PO|...<cr>
Note: The message structure for the PEX does not allow repeating RXE/RXR
groups within a PCR group. This is probably a mistake in the message
definition table for the PEX messages.
PRB|AD|19950704|705^DYSPNEA^MEDR|...<cr>
PRB|AD|19950710|20143^DEATH^MEDR|...<cr>
PRB|AD|19950704|18330^CHEST PAIN^MEDR|...<cr>
PRB|AD|19950709|21197^DIARRHEA^MEDR|...<cr>
PRB|AD|19950709|6432^SYNCOPE^MEDR|...<cr>
PRB|AD|19950709|4966^DEHYDRATION^MEDR|...<cr>
PRB|AD|19950709|20544^KIDNEY FUNCTION ABNORMAL^MEDR|...<cr>
OBX|1|NM|804-5^lEUKOCYTES^LN||2300|10*3/ml|||||F|19940704|...<cr>
OBX|2|NM|770-8^NEUTROPHILS/100
LEUKOCYTES^LN||1.9|%|||||F|19950704|...<cr>
OBX|3|NM|6299-2^UREA NITROGEN^LN||22.3|mg%|||||F|19950709|...<cr>
OBX|4|NM|2160-0^CREATININE^LN||247|mmole|||||F|19950709|...<cr>
NTE|||Additional details must be obtained from the affiliate in order to assess
causality. A three day alert phone call was made to the FDA on
12-JUL-95|...<cr>
HL7
support for waveform data is intended to provide access to waveform data in a
variety of situations. Needs include remote access to waveform data, research,
and input to clinical decision making, as well as obtaining snippets of
waveform data to complete waveform data sets. In some cases, predominantly in
research oriented environments, a physician may want to manually interpret,
scale the raw data, and/or apply alternative algorithms to the raw data values.
In these environments, the review of waveform data includes the processing of
the raw data. The HL7 waveform data capabilities allow for these applications,
including data collection information such as skew between channels, in-band
with the waveform.
Waveform observations, like other results, can be transmitted in solicited mode
(in response to a query) or in unsolicited mode - see Section 7.15.1, "W01 -
waveform result, unsolicited transmission of requested information," for
discussion. In either mode of transmission the timing information, channel
definition, annotations, and digital time series data in the waveform recording
are treated as individual "observations" within a result "battery." For a
given "battery," each of the result fragments is transmitted in a separate OBX
segment, where the Observation ID suffix for the OBX is used to identify the
result fragment. To reduce ambiguity, an explicit framework for defining the
structure of waveform result messages is provided. The elements of that
framework include the following:
* Waveform specific data types which enable transmission of channel definition
and waveform data
* Waveform specific Observation ID suffixes (OBX-3-observation identifier)
which uniquely identify the category of waveform result in a given OBX
segment
* Fixed rules for combining OBX segments of each category in the waveform
response messages
* Explicit definition of which OBX fields may be populated for each category of
waveform result
* Unique trigger events which identify result messages which contain batteries
of waveform result OBX segments
Three waveform specific data types have been defined to enable transmission of waveform results.
<value1>
^ <value2> ^ <value3> ^ <value4> ^ ...
Definition: This data type is used to represent a series (array) of numeric
values, each one having a data type of NM. A field of this type may contain a
one-dimensional array (vector or row) of numbers. Also, by allowing the field
to repeat, a two-dimensional array (table) of numbers may be transmitted using
this format, with each row of the table represented as one repetition of the
field. Arrays which have one or more values not present may be transmitted
using this data type. "Not present" values are represented as two adjacent
component delimiters. If the absent values occur at the end of a row, the
trailing component delimiters may be omitted. If an entire row of a table has
no values, no component delimiters are necessary (in this case, there will be
two adjacent repetition delimiters). The maximum number of values in one
repetition of an NA format field is determined by the maximum field length.
Examples:
|125^34^-22^-234^569^442^-212^6| vector of 8 numbers
|1.2^-3.5^5.2~2.0^3.1^-6.2~3.5^7.8^-1.3| 3 x 3 array of numbers
|^2^3^4~5^^^8~9^10~~17^18^19^20| 5 x 4 array of numbers with
the values in positions
1,1), (2,2), (2,3), (3,3),
(3,4), (4,1), (4,2), (4,3),
and (4,4) not present
<sample
1 from channel 1>^<sample 1 from channel 2>^<sample 1 from channel
3> ...~
<sample 2 from channel 1>^<sample 2 from channel 2>^<sample
2 from channel 3> ...~
...
Definition: This data type is used to represent channel-multiplexed waveform
data, (e.g., the digitized values from an analog-to-digital converter or other
digital data source). Each value is of type NM, and represents a time sample
from a channel. This segment may contain data from one or more channels. The
waveform data is in channel-multiplexed format (that is, the values for all
channels for the first time sample are transmitted, then the values for the
next time sample, and so on until the requisite number of time samples have
been transmitted). Time samples are separated by repeat delimiters (~), and
channels within a sample are separated by component delimiters (^). The time
between samples (the sampling interval) is the reciprocal of the digitization
frequency as specified using the CD data type.
Examples:
|0^0^0~1^1^1~2^2^2~3^3^3~4^4^4~5^5^5| 3 channels (identical), 5 time-samples
|0~1~2~3~4~5~6~7~8~9~10| 1 channel, 11 time-samples
Components:
<channel identifier (CM)> ^ <waveform source (CM)> ^ <channel
sensitivity/units (CM)> ^ <channel calibration parameters (CM)> ^
<channel sampling frequency (NM)> ^ <minimum/maximum data values
(CM)>
Subcomponents of channel identifier: <channel number (NM)> &
<channel name (ST)>
Subcomponents of waveform source: <Source name 1 (ST)> &
<Source name 2 (ST)>
Subcomponents of channel sensitivity/units: <channel sensitivity
(NM)> & < unit of measure identifier (ST)> & < unit of
Measure Description (ST)> & < unit of Measure Coding System (IS)>
& <alternate unit of measure identifier (ST)> & <alternate
unit of Measure Description (ST)> & <alternate unit of Measure Coding
System (IS)>
Subcomponents of channel calibration parameters: < channel calibration
sensitivity correction factor (NM)> & < channel calibration baseline
(NM)> & < channel calibration time skew (NM)>
Subcomponents of minimum/maximum data values: < minimum data value
(NM)> & <maximum data value (NM)>
Definition: This data type is used for labeling of digital waveform data. It
defines a recording channel which is associated with one of the values in each
time sample of waveform data. Each channel has a number (which generally
defines its position in a multichannel display) and an optional name or label
(also used in displays). One or two named waveform sources may also be
associated with a channel (providing for the use of differential amplifiers
with two inputs). The other components of the channel definition data type are
optional. The individual components are defined as follows:
Subcomponents:
<channel number (NM)> & <channel name (ST)>
Definition: Two subcomponents separated by subcomponent delimiters (&)
which identify the channel, consisting of a channel number (required, maximum 4
characters, data type NM)and a channel name (optional, maximum 17 characters,
data type ST).
The channel number identifies the recording channel associated with a specified value in a time sample of data. It generally defines its position in a multichannel display.
Definition: The channel name is a text string used as a label in waveform data displays. If this name is not present, the channel label displayed is <source1>-<source2>, where <source1> and <source2> are the names of the two waveform sources connected to this channel, or, if only one waveform sources <source1> is specified, the channel label displayed when the channel name is not given is <source1>.
Subcomponents:
<Source name 1 (ST)> & <Source name 2 (ST)>
Definition: Identifies the source of the waveform connected to the channel.
Two names (each maximum of 8 characters, data type ST) separated by a
subcomponent delimiter (&) may be specified if it is necessary to
individually identify the two inputs for a waveform. Only one name need be
specified if the channel is connected to a single input. For example, in EKG
recordings typically only one name is used (such as I or II); in
electroencephalography, two names are typically used, one for each input of the
differential amplifier (such as F3 and C3). (NOTE: Although the SIG voted
to make waveform source a coded entry, this is not syntactically possible. We
do not have a sub-sub-component delimiter available to separate the sub-fields
of the proposed coded entry. Therefore, waveform source remains a string data
type.).
Definition: Identifies the first input for the waveform source.
Definition: Identifies the second input for the waveform source.
Subcomponents:
<channel sensitivity (NM)> & < unit of measure identifier
(ST)> & < unit of Measure Description (ST)> & < unit of
Measure Coding System (IS)> & <alternate unit of measure identifier
(ST)> & <alternate unit of Measure Description (ST)> &
<alternate unit of Measure Coding System (IS)>
Definition: This CM data type defines the channel sensitivity (gain) and the
units in which it is measured. This component consists of up to seven
subcomponents, separated from each other by subcomponent delimiters (&).
The first subcomponent specifies the sensitivity, while the remaining six
subcomponents are used to specify the units of the sensitivity, using a format
similar to the components of the coded entry (CE) data type. The subcomponents
of the channel sensitivity and units are as follows:
Defines the nominal value (maximum 20 characters, data type NM) that corresponds to one unit in the waveform data, that is, the effective resolution of the least significant bit of the ADC, and the polarity of the channel. The sensitivity incorporates both the amplifier gain and the actual ADC resolution. It does not, however, relate to the vertical scaling of a waveform display (it is, for example, a measure of voltage, not voltage per unit distance). For channels recording potential differences between two electrodes using a differential amplifier, a positive sensitivity indicates that a number in the waveform data which is greater than the channel baseline represents a potential at the first electrode which is more positive than that at the second electrode. A negative sensitivity indicates that a number in the waveform data which is greater than the channel baseline corresponds to a potential at the first electrode which is more negative than that at the second electrode.
Definition: A units designation (for example, uv, mv, v, pal, or mm(hg). Codes from the ISO+ extension of the standard SI single case unit abbreviations are presented as Figure 7-6, 7-7, and 7-8 in Section NNNN, the ANSI+ U.S. customary unit abbreviations, a superset of the ANSI standard which appears in Figure 7-9.
Definition: The full text name of the unit of measure identifier (for example, microvolt, millivolt, volt, pascal or millimeters of mercury) from a designated system of units.
Definition: The designated system of units. Refer to User-defined table 0396 - Coding System for suggested values.
Definition: An alternate units designation (for example, uv, mv, v, pal, or mm(hg) . Codes from the ISO+ extension of the standard SI single case unit abbreviations are presented as Figure 7-6, 7-7, and 7-8 in Section 7.4.2.6.2, the ANSI+ U.S. customary unit abbreviations, a superset of the ANSI standard which appears in Figure 7-9.
Definition: The full text name of the alternate unit of measure identifier (for example, microvolt, millivolt, volt, pascal or millimeters of mercury) from a designated system of units.
Definition: The alternate designated system of units. Refer to User-defined table 0396 - Coding System for suggested values.
Subcomponents:
< channel calibration sensitivity correction factor (NM)> & <
channel calibration baseline (NM)> & < channel calibration time skew
(NM)>
Definition: This component consists of three optional subcomponents (each a
maximum of 20 characters, data type NM), separated from each other by
subcomponent delimiters (&), which define corrections to channel
sensitivity, baseline, and channel time skew which may be derived from a
calibration procedure. The three subcomponents are as follows:
Definition: Defines a correction factor for channel sensitivity which may be derived from the last calibration procedure performed. The actual channel sensitivity is the nominal channel sensitivity given in the previous component multiplied by the unitless correction factor.
Definition: Defines the actual channel baseline (the data value which corresponds to a nominal input signal of zero). The actual baseline may differ from the ideal because of a dc offset in the amplifier connected to the ADC. The actual baseline values for all channels (which need not be integers) may be determined at the time of calibration as the average digitized values obtained when a zero input signal is connected to each channel.
Definition: Defines the time difference between the nominal sampling (digitization) time (which would be the same for all channels) and the actual sampling time of the channel, in seconds (or fractions thereof). This value will differ from zero when all channels in the montage are not sampled simultaneously, as occurs in systems which sample successive channels at regular time intervals. This value may be determined from a calibration procedure in which an identical time-varying signal is applied to all channels and interchannel time differences are estimated, or more commonly it may be taken from the manufacturer's specifications for the digitizing system used. For example, for a system which samples successive channels at regular time intervals t, the time skew of channel number n would be (n-1)t. The actual time of sampling (digitization) of sample number m of channel number n in such a system would be R + (m-1)/f + (n-1)t, where R is the reference time at the start of the epoch and f is the channel sampling frequency (t < 1/f).
Definition: Defines the sampling frequency in hertz of the channel, that is, the reciprocal of the time in seconds between successive samples (maximum 20 characters, data type NM). Note that this is the frequency of transmitted data, which may or may not be the actual frequency at which the data was acquired by an analog-to-digital converter or other digital data source (i.e. the data transmitted may be subsampled, or interpolated, from the originally acquired data.)
Subcomponents:
< minimum data value (NM)> & <maximum data value (NM)>
Definition: Defines the minimum and maximum data values which can occur in this
channel in the digital waveform data, that is, the range of the ADC (each
maximum of 20 characters, data type NM), and also specifies whether or not
nonintegral data values may occur in this channel in the waveform data. If the
minimum and maximum values are both integers (or not present), only integral
data values may be used in this channel. If either the minimum or the maximum
value contains a decimal point, then nonintegral as well as integral data
values may be used in this channel. The minimum and maximum data values are
separated by a component delimiter (&).
Definition:
Defines the minimum data value that can occur in this channel in the digital
waveform data, and also specifies whether or not nonintegral data values may
occur in this channel in the waveform data.
For an n-bit signed ADC, the nominal baseline B = 0, and the
minimum (L) and maximum (H) values may be calculated as
follows:
L = -2n-1
H = 2n-1 - 1
For an unsigned n-bit ADC, the minimum value L = 0, and the
nominal baseline value (B) and maximum value (H) may be
calculated from the formulas,
B = 2n-1
H = 2n - 1
The actual signal amplitude A (for differentially amplified potential
measurements, the potential at electrode number one minus that at electrode
number two) may be calculated from the value D (range L to
H) in the waveform data using the actual baseline value B and the
nominal sensitivity S and actual sensitivity correction factor C
by the formula,
A = SC(D-B)
Definition:
Defines the maximum data value that can occur in this channel in the digital
waveform data, and also specifies whether or not nonintegral data values may
occur in this channel in the waveform data.
For an n-bit signed ADC, the nominal baseline B = 0, and the
minimum (L) and maximum (H) values may be calculated as
follows:
L = -2n-1
H = 2n-1 - 1
For an unsigned n-bit ADC, the minimum value L = 0, and the
nominal baseline value (B) and maximum value (H) may be
calculated from the formulas,
B = 2n-1
H = 2n - 1
The actual signal amplitude A (for differentially amplified potential
measurements, the potential at electrode number one minus that at electrode
number two) may be calculated from the value D (range L to
H) in the waveform data using the actual baseline value B and the
nominal sensitivity S and actual sensitivity correction factor C
by the formula,
A = SC(D-B)
Each
waveform channel in a recording contains timing, channel definition and digital
time series data. The category of waveform result transmitted in a given OBX
segment is determined by the Observation ID Suffix contained in
OBX-3-observation identifier. Four suffixes are provided for the different
categories of waveform result:
Observation |
Suffix |
Data Type |
Timing Information |
TIM |
TS |
Channel Definition |
CHN |
CD |
Waveform Data |
WAV |
NA or MA |
Waveform Annotation |
ANO |
CE |
The Observation Sub-ID is used to associate the TIM, CHN, and subsequent WAV, and ANO category result segments for a given channel or channels in a waveform response message.
Definition: The TIM category OBX result segment establishes the date and time of the first data point in a given Observation Sub-ID grouping of waveform channels. If there is a gap in the time sequence of waveform data, this should be indicated by the transmission of a new TIM category result segment prior to subsequent WAV category result segments with the same Observation Sub-ID. The data type is TS.
Definition:
The CHN category OBX result segment defines recording channels for digitally
sampled time-series waveforms. Subsequent WAV category result segments carry
the actual waveform samples. Each CHN category result segment defines one or
more channels; the OBX-5-Observation Value field may repeat to define
additional channels. Each instance or repetition is formatted as a CD data
type.
Each channel has a number (which generally defines its position in a
multichannel display) and an optional name or label (also used in displays).
One or two named waveform sources may also be associated with a channel
(providing for the use of differential amplifiers with two inputs). A channel
also has an associated sensitivity, calibration parameters (sensitivity
correction factor, baseline, and time skew), sampling frequency, and minimum
and maximum values. The sampling frequency refers to the number of samples per
unit time for the data reported in the subsequent WAV category result
segments.
When multiple channels are defined within a single CHN category result segment,
if the channel sensitivity/units (third component), sensitivity correction
factor (first subcomponent of component 4), baseline (second subcomponent),
time skew (third subcomponent), sampling frequency (fifth component), minimum
data value (first subcomponent of component 6), or maximum data value (second
subcomponent) is not present in any repetition of the OBX-5-observation
value field, the value given in the last repetition in which the item
was present may used by the receiver system. This is referred to as a
"sticky default." For example, if all channels have the same sensitivity,
sensitivity correction factor/baseline/time skew, sampling frequency, and
minimum/maximum data values, these may be specified for the first channel but
omitted in all subsequent channel definitions in the same CHN category result
segment, thus reducing the length of the segment. If the sensitivity
correction factor, baseline, or time skew is not present in the first channel
being defined, values of 1, 0, and 0 (respectively) may be used. No other
default values are assumed for components which are not present.
Definition:
The WAV category OBX result segment is used to transmit the actual waveform
data (the time-series digitized values from an analog-to-digital converter
(ADC) or other source of sampled digital data). WAV category result segments
are associated with their corresponding channel definitions (CHN category OBX
result segment) via the Observation Sub-ID. The number of channels defined in
the CHN category result segment specifies the number of channels of multiplexed
data contained in the WAV category result segments associated with it. For
example, if a CHN category result segment contains only a single channel
definition, then each WAV category result segment with the same Observation
Sub-ID contains only one channel of data. However, if a CHN category result
segment contains three channel definitions then each WAV category result
segment with the same Observation Sub-ID must contain three channels of data.
A given set of waveform data for all channels and at multiple successive times
may be transmitted in a single WAV category result segment (provided that the
length of the observation value field does not exceed the maximum defined field
length for OBX segments, 65536), or in multiple successive WAV category result
segments, possibly with interspersed result segments of other types (for
example, containing annotations, or comments).
The data type of the WAV category result segment can be NA (Numeric Array) or
MA (Multiplexed Array). Using the NA data type, the data values are formatted
in "channel-block", or "unmultiplexed" format. The digital samples for each
channel are separated using component delimiters, and successive channels are
separated using the repeat delimiter. Using the MA data type, the data values
are formatted in "channel multiplexed" format, i.e., the values for the first
time sample (all channels) are transmitted first, then the values for the
second time sample (all channels) are transmitted, and so on until all samples
have been transmitted. The digital samples for each channel are separated by
the component delimiter, and successive samples are separated by the repeat
delimiter. Channel multiplexed format can only be used if all of the
multiplexed channels have the same effective sampling frequency.
Definition:
The ANO category OBX segment is used to transmit waveform annotations (coded
entry associated with a given point in time during the waveform recording).
The ANO category result segments are referenced to their corresponding channel
definitions (CHN category OBX result segment ) via the Observation Sub-ID. The
number of channels defined in the CHN category result segment specifies the
number of channels of annotation contained in any ANO category result segments
associated with it. For example, if a CHN category result segment contains
only a single channel definition, then any ANO category result segments with
the same Observation Sub-ID will contain only one annotation coded entry.
However, if a CHN category result segment contains three channel definitions
then any ANO category result segments with the same Observation Sub-ID must
contain three separate annotation coded entries.
The data type of the ANO category result segment is CE. The annotation
coded entries for successive channels are separated using the repeat delimiter.
Adjacent repeat delimiters are used when there is no annotation coded entry for
a channel in a multichannel result segment. Refer to User defined
Table 0317 - Annotations for suggested values.
Value |
Description |
|---|---|
9900 |
Pace spike |
9901 |
SAS marker |
9902 |
Sense marker |
9903 |
Beat marker |
9904 |
etc. |
Response messages containing waveform results are identified by the trigger event provided in the message header segment (MSH-09, second component of message type). Separate trigger events have been defined to differentiate the solicited and unsolicited modes of transmission.
The waveform response unsolicited trigger event identifies ORU messages used to transmit waveform data which are results of an ordered test or series of observations. The W01 trigger event may also be used to identify ORU messages sent as the eventual response to a QRY message specifying a deferred mode query for waveform results/observations with record-oriented format (similar to the deferred response display mode DSR message type described in Chapter 2). One or more ORU messages with the W01 trigger event may result from this type of QRY message.
The W02 trigger event identifies QRF messages which are a response to a QRY message specifying an immediate mode query for waveform results/observations with record-oriented format.
A waveform result "battery" may contain one or more channels of digital waveform data. The Observation Sub-ID is used to logically associate the TIM, CHN and WAV category OBX segments which pertain to a given set of channels in the result "battery." Each Sub-ID group must contain at least one TIM, one CHN and one WAV category segment and at least one of the TIM category result segments must precede the first WAV category result segment in that group.
The
result category for a given OBX segment determines how specific fields in that
segment are valued. The following tables indicate the use of the OBX segment
for waveform components. The data types, lengths, optionality, and repeat
values listed do not replace the basic definition of the OBX segment in section
7.4.2.
The OPT/X column can take the values of R = Required, O = Optional, or X =
Ignored and not valued. OBX Fields marked with an X should not be valued in
Waveform response messages of specified Suffix type. Valuation of the
fields must match the value provided in the associated wave category OBX
segments, i.e., OBX with the same sub-ID must share the same result status.
When
using the OBX for the TIM category, OBX-2 should be valued to TS.
Consequently, OBX-5 should have a length of 26 given the format of the
TS data type. Note the expectations on which fields are required as well as the
fields that should not be valued.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
O |
00569 |
Set ID - OBX |
||
2 |
2 |
ID |
R |
0125 |
00570 |
Value Type |
|
3 |
250 |
CE |
R |
00571 |
Observation Identifier |
||
4 |
20 |
ST |
R |
00572 |
Observation Sub-ID |
||
5 |
26 |
TS |
R |
00573 |
Observation Value |
||
6 |
250 |
CE |
X |
00574 |
Units |
||
7 |
60 |
ST |
X |
00575 |
References Range |
||
8 |
5 |
ID |
X |
0078 |
00576 |
Abnormal Flags |
|
9 |
5 |
NM |
X |
Y/5 |
00577 |
Probability |
|
10 |
2 |
ID |
X |
0080 |
00578 |
Nature of Abnormal Test |
|
11 |
1 |
ID |
R |
0085 |
00579 |
Observation Result Status |
|
12 |
26 |
TS |
X |
00580 |
Date Last Observation Normal Values |
||
13 |
20 |
ST |
X |
00581 |
User Defined Access Checks |
||
14 |
26 |
TS |
X |
00582 |
Date/Time of the Observation |
||
15 |
250 |
CE |
X |
00583 |
Producer's ID |
||
16 |
250 |
CN |
X |
00584 |
Responsible Observer |
||
17 |
250 |
CE |
X |
Y |
00936 |
Observation Method |
|
18 |
22 |
EI |
O |
Y |
01479 |
Equipment Instance Identifier |
|
19 |
26 |
TS |
O |
01480 |
Date/Time of the Analysis |
When
using the OBX for the CHN category, OBX-2 should be valued to CD.
Consequently, OBX-5 could have a length of up to 65536 given the format
of the CD data type. Note the expectations on which fields are required as well
as the fields that should not be valued.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
|
SI |
O |
00569 |
Set ID - OBX |
||
2 |
2 |
ID |
R |
0125 |
00570 |
Value Type |
|
3 |
250 |
CE |
R |
00571 |
Observation Identifier |
||
4 |
20 |
ST |
R |
00572 |
Observation Sub-ID |
||
5 |
65536 |
CD |
R |
00573 |
Observation Value |
||
6 |
250 |
CE |
X |
00574 |
Units |
||
7 |
60 |
ST |
X |
00575 |
References Range |
||
8 |
5 |
ID |
X |
0078 |
00576 |
Abnormal Flags |
|
9 |
5 |
NM |
X |
Y/5 |
00577 |
Probability |
|
10 |
2 |
ID |
X |
0080 |
00578 |
Nature of Abnormal Test |
|
11 |
1 |
ID |
R |
0085 |
00579 |
Observation Result Status |
|
12 |
26 |
TS |
X |
00580 |
Date Last Observation Normal Values |
||
13 |
20 |
ST |
X |
00581 |
User Defined Access Checks |
||
14 |
26 |
TS |
X |
00582 |
Date/Time of the Observation |
||
15 |
250 |
CE |
X |
00583 |
Producer's ID |
||
16 |
250 |
CN |
X |
00584 |
Responsible Observer |
||
17 |
250 |
CE |
X |
Y |
00936 |
Observation Method |
|
18 |
22 |
EI |
O |
Y |
01479 |
Equipment Instance Identifier |
|
19 |
26 |
TS |
O |
01480 |
Date/Time of the Analysis |
Note: The length of the observation value field is variable, depending upon number of channels defined.
When
using the OBX for the WAV category, OBX-2 can be valued as either NM or
MA. Consequently, OBX-5 could have a length of up to 65536 given the
format of the data types. Note the expectations on which fields are required as
well as the fields that should not be valued.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
|
SI |
O |
00569 |
Set ID - OBX |
||
2 |
2 |
ID |
R |
0125 |
00570 |
Value Type |
|
3 |
250 |
CE |
R |
00571 |
Observation Identifier |
||
4 |
20 |
ST |
R |
00572 |
Observation Sub-ID |
||
5 |
65536 |
NA or MA |
C |
00573 |
Observation Value |
||
6 |
250 |
CE |
X |
00574 |
Units |
||
7 |
60 |
ST |
X |
00575 |
References Range |
||
8 |
5 |
ID |
O |
0078 |
00576 |
Abnormal Flags |
|
9 |
5 |
NM |
X |
Y/5 |
00577 |
Probability |
|
10 |
2 |
ID |
X |
0080 |
00578 |
Nature of Abnormal Test |
|
11 |
1 |
ID |
R |
0085 |
00579 |
Observation Result Status |
|
12 |
26 |
TS |
X |
00580 |
Date Last Observation Normal Values |
||
13 |
20 |
ST |
X |
00581 |
User Defined Access Checks |
||
14 |
26 |
TS |
X |
00582 |
Date/Time of the Observation |
||
15 |
250 |
CE |
X |
00583 |
Producer's ID |
||
16 |
250 |
CN |
O |
00584 |
Responsible Observer |
||
17 |
250 |
CE |
X |
00936 |
Observation Method |
||
18 |
22 |
EI |
O |
Y |
01479 |
Equipment Instance Identifier |
|
19 |
26 |
TS |
O |
01480 |
Date/Time of the Analysis |
Notes:
1. The length of the observation value field is variable, depending upon number
of channels and number of data points sampled.
2. Fields 8, 11 and 16 apply exclusively to the set of data points in the OBX.
They do not map to a particular data point or channel.
When
using the OBX for the ANO category, OBX-2 should be valued to CE.
Consequently, OBX-5 could have a length of up the 65536 given the format
of the data types. Note the expectations on which fields are required as well
as the fields that should not be valued.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
O |
00569 |
Set ID - OBX |
||
2 |
2 |
ID |
R |
0125 |
00570 |
Value Type |
|
3 |
250 |
CE |
R |
00571 |
Observation Identifier |
||
4 |
20 |
ST |
R |
00572 |
Observation Sub-ID |
||
5 |
250 |
CE |
C |
00573 |
Observation Value |
||
6 |
250 |
CE |
X |
00574 |
Units |
||
7 |
60 |
ST |
X |
00575 |
References Range |
||
8 |
5 |
ID |
O |
Y/5 |
0078 |
00576 |
Abnormal Flags |
9 |
5 |
NM |
X |
00577 |
Probability |
||
10 |
2 |
ID |
X |
0080 |
00578 |
Nature of Abnormal Test |
|
11 |
1 |
ID |
R |
0085 |
00579 |
Observation Result Status |
|
12 |
26 |
TS |
X |
00580 |
Date Last Observation Normal Values |
||
13 |
20 |
ST |
X |
00581 |
User Defined Access Checks |
||
14 |
26 |
TS |
O |
00582 |
Date/Time of the Observation |
||
15 |
250 |
CE |
X |
00583 |
Producer's ID |
||
16 |
250 |
CN |
O |
00584 |
Responsible Observer |
||
17 |
250 |
CE |
X |
Y |
00936 |
Observation Method |
|
18 |
22 |
EI |
O |
Y |
01479 |
Equipment Instance Identifier |
|
19 |
26 |
TS |
O |
01480 |
Date/Time of the Analysis |
Note: The length of the observation value field is variable, depending upon number of channels defined.
This
section gives four example messages of type ORU (unsolicited) that each contain
a three-channel waveform recording, with the same waveform in each channel.
These examples contain data for one patient. In these example message
transmissions, <cr> indicates an ASCII carriage return character
(ASCII 13).
The following is a detailed explanation of each of the segments contained in
the example messages:
Message Header (MSH) Segment - This specifies the delimiters
(|^~\&), sending application (SVL, meaning Sunnyville
Laboratory), receiving application (SVC, meaning Sunnyville Clinic),
date and time of transmission (March 24, 1990 at 10:12:15), message type
(ORU) and trigger event (W01), a message control ID that
identifies this message uniquely among all messages transmitted by this sender
(19264), processing ID (P, meaning production), and specification
version ID (2.3).
Patient ID (PID) Segment - This contains a sequence number
(1), external and internal patient IDs (both 4567890), and a
patient name (Mr. John Q Doe, Jr).
Order (OBR) Segment - This contains a sequence number (1),
placer order number (5678) and placer ID (SVC, meaning Sunnyville
Clinic), filler order number (1234) and filler ID (SVL, meaning
Sunnyville Laboratory), and test/observation ID (5, using a local coding
system that is known to the intended receiver, meaning a three-channel waveform
recording).
CHN Category Result (OBX) Segments - Using a value type of
CD (channel definition), these define each of the three data channels by
number and specify a label (waveform source) for each. The channel sensitivity
(0.5 mV), sampling frequency (200), and minimum and maximum data
values (-2048 to 2047) are specified for each channel in examples
1 and 2 and 4. In example 3, these are specified only for channel 1, but apply
by default to all subsequent channels. No baseline or calibration parameters
are specified, so defaults are used for all channels.
TIM Category Result (OBX) Segments - Using the data type TS (time
stamp), these define the start of the waveform data at a time 525 ms past
8:12:37 on March 24, 1990.
WAV Category Result (OBX) Segments - The data may be transmitted
in either "channel-block" (unmultiplexed) format using the NA data type, or in
"channel-multiplexed" format using the MA data type. The three examples
demonstrate different ways of transmitting 3 waveform channels, with 25 samples
from each waveform channel. Note that in these examples, each waveform channel
is identical.
ANO Category Result (OBX) Segments - Annotation segments with a
single channel definition contain a single annotation string. Annotation
segments with multiple channel definitions contain a separate annotation string
for each defined channel - successive annotation strings are separated from
each other by the repeat delimiter. In the following examples, channel 1 has
been annotated at a time 565 ms past 8:12:37 on March 24, 1990; channel 3 has
been annotated at a time 605 ms past 8:12:37 on March 24, 1990.
MSH|^~\&|SVL||SVC||19900324101215||ORU^W01|...<cr>
PID|1||4567890||Doe^John^Q^Jr^Mr|...<cr>
OBR|1|5678^SVC|1234^SVL|5^three-channel waveform
recording^99SVL|...<cr>
OBX|1|CD|5&CHN^^99SVL|1|1^ONE^0.5&mv^^200^-2048&2047||||||F|...<cr>
OBX|2|TS|5&TIM^^99SVL|1|19900324081237.525||||||F|...<cr>
OBX|3|NA|5&WAV^^99SVL|1|0^1^2^3^4^5^6^7^8^7^6^5^4^3^2^1^0^-1^-2^-3^-4^-5^-6^-7^-8||||||F|...<cr>
OBX|4|CE|5&ANO^^99SVL|1|^Channel passing through
maxima||||||F|||19900324081237.565|...<cr>
OBX|5|CD|5&CHN^^99SVL|2|2^TWO^0.5&mv^^200^-2048&2047||||||F|...<cr>
OBX|6|TS|5&TIM^^99SVL|2|19900324081237.525||||||F|...<cr>
OBX|7|NA|5&WAV^^99SVL|2|0^1^2^3^4^5^6^7^8^7^6^5^4^3^2^1^0^-1^-2^-3^-4^-5^-6^-7^-8||||||F|...<cr>
OBX|8|CD|5&CHN^^99SVL|3|3^THREE^0.5&mv^^200^-2048&2047||||||F|...<cr>
OBX|9|TS|5&TIM^^99SVL|3|19900324081237.525||||||F|...<cr>
OBX|10|NA|5&WAV^^99SVL|3|0^1^2^3^4^5^6^7^8^7^6^5^4^3^2^1^0^-1^-2^-3^-4^-5^-6^-7^-8||||||F|...<cr>
OBX|11|CE|5&ANO^^99SVL|3|^Channel passing through
zero||||||F|||19900324081237.605|...<cr>
...
MSH|^~\&|SVL||SVC||19900324101215||ORU^W01|...<cr>
PID|1||4567890||Doe^John^Q^Jr^Mr|...<cr>
OBR|1|5678^SVC|1234^SVL|5^three-channel waveform
recording^99SVL|...<cr>
OBX|1|CD|5&CHN^^99SVL|1|1^ONE^0.5&mv^^200^-2048&2047~2^TWO^0.5&mv^^200^-2048&2047~3^THREE^0.5&mv^^200^-2048&2047||||||F|...<cr>
OBX|2|TS|5&TIM^^99SVL|1|19900324081237.525||||||F|...<cr>
OBX|3|NA|5&WAV^^99SVL|1|
0^1^2^3^4^5^6^7^8^7^6^5^4^3^2^1^0^-1^-2^-3^-4^-5^-6^-7^-8~
0^1^2^3^4^5^6^7^8^7^6^5^4^3^2^1^0^-1^-2^-3^-4^-5^-6^-7^-8~
0^1^2^3^4^5^6^7^8^7^6^5^4^3^2^1^0^-1^-2^-3^-4^-5^-6^-7^-8||||||F|...<cr>
OBX|4|CE|5&ANO^^99SVL|1|^Channel passing through
maxima||||||F|||19900324081237.565|...<cr>
OBX|5|CE|5&ANO^^99SVL|1|~~^Channel passing through
zero||||||F|||19900324081237.605|...<cr>
Note: This is an illegal construct per the message construction rules from
chapter 1: the repetition separator is used only if more than one occurrence is
transmitted. There is only one occurrence being sent here.
...
MSH|^~\&|SVL||SVC||19900324101215||ORU^W01|...<cr>
PID|1||4567890||Doe^John^Q^Jr^Mr|...<cr>
OBR|1|5678^SVC|1234^SVL|5^three-channel waveform
recording^99SVL|...<cr>
OBX|1|CD|5&CHN^^99SVL|1|1^ONE^0.5&mv^^200^-2048&2047~2^TWO~3^THREE||||||F|...<cr>
OBX|2|TS|5&TIM^^99SVL|1|19900324081237.525||||||F|...<cr>
OBX|3|MA|5&WAV^^99SVL|1|0^0^0~1^1^1~2^2^2~3^3^3~4^4^4~5^5^5~6^6^6~7^7^7~8^8^8~7^7^7~6^6^6~5^5^5~4^4^4~3^3^3~2^2^2~1^1^1~0^0^0~-1^-1^-1~-2^-2^-2~-3^-3^-3~-4^-4^-4~-5^-5^-5~-6^-6^-6~-7^-7^-7~-8^-8^-8||||||F|...<cr>
OBX|4|CE|5&ANO^^99SVL|1|^Channel passing through
maxima||||||F|||19900324081237.565|...<cr>
OBX|5|CE|5&ANO^^99SVL|1|~~^Channel passing through
zero||||||F|||19900324081237.605|...<cr>
Note: This is an illegal construct per the message construction rules from
chapter 1: "the repetition separator is used only if more than one occurrence
is transmitted." There is only one occurrence being sent here.
...
MSH|^~\&|SVL||SVC||19900324101215||ORU^W01|...<cr>
PID|1||4567890||Doe^John^Q^Jr^Mr|...<cr>
OBR|1|5678^SVC|1234^SVL|5^three-channel waveform
recording^99SVL|...<cr>
OBX|1|CD|5&CHN^^99SVL|1|1^ONE^0.5&mv^^200^-2048&2047||||||F|...<cr>
OBX|2|TS|5&TIM^^99SVL|1|19900324081237.525||||||F|...<cr>
OBX|3|NA|5&WAV^^99SVL|1|0^1^2^3^4^5^6^7^8||||||F|...<cr>
OBX|4|CE|5&ANO^^99SVL|1|^Channel passing through
maxima||||||F|||19900324081237.565|...<cr>
OBX|5|NA|5&WAV^^99SVL|1|7^6^5^4^3^2^1^0^-1^-2^-3^-4^-5^-6^-7^-8||||||F|...<cr>
OBX|6|CD|5&CHN^^99SVL|2|2^TWO^0.5&mv^^200^-2048&2047||||||F|...<cr>
OBX|7|TS|5&TIM^^99SVL|2|19900324081237.525||||||F|...<cr>
OBX|8|NA|5&WAV^^99SVL|2|0^1^2^3^4^5^6^7^8^7^6^5^4^3^2^1^0^-1^-2^-3^-4^-5^-6^-7^-8||||||F|...<cr>
OBX|9|CD|5&CHN^^99SVL|3|3^THREE^0.5&mv^^200^-2048&2047||||||F|...<cr>
OBX|10|TS|5&TIM^^99SVL|3|19900324081237.525||||||F|...<cr>
OBX|11|NA|5&WAV^^99SVL|3|0^1^2^3^4^5^6^7^8^7^6^5^4^3^2^1^0||||||F|...<cr>
OBX|12|CE|5&ANO^^99SVL|3|^Channel passing through
zero||||||F|||19900324081237.605|...<cr>
OBX|13|NA|5&WAV^^99SVL|3|-1^-2^-3^-4^-5^-6^-7^-8||||||F|...<cr>
...
Referenced
in 7.1.5 Cod
ing
Schemes
Value |
Description |
Comment / Source |
Category |
99zzz or L |
Local general code (where z is an alphanumeric character) |
Locally defined codes for purpose of sender or receiver. Local codes can be identified by L (for backward compatibility) or 99zzz (where z is an alphanumeric character). |
General code |
ACR |
American College of Radiology finding codes |
Index for Radiological Diagnosis Revised, 3rd Edition 1986, American College of Radiology, Reston, VA. |
Specific Non-Drug Code |
ART |
WHO Adverse Reaction Terms |
WHO Collaborating Centre for International Drug Monitoring, Box 26, S-751 03, Uppsala, Sweden. |
Drug code |
AS4 |
ASTM E1238/ E1467 Universal |
American Society for Testing & Materials and CPT4 (see Appendix X1 of Specification E1238 and Appendix X2 of Specification E1467). |
Specific Non-Drug Code |
AS4E |
AS4 Neurophysiology Codes |
ASTM's diagnostic codes and test result coding/grading systems for clinical neurophysiology. See ASTM Specification E1467, Appendix 2. |
Specific Non-Drug Code |
ATC |
American Type Culture Collection |
Reference cultures (microorganisms, tissue cultures, etc.), related biological materials and associated data. American Type Culture Collection, 12301 Parklawn Dr, Rockville MD, 20852. (301) 881-2600. http://www.atcc.org |
Specific Non-Drug Code |
C4 |
CPT-4 |
American Medical Association, P.O. Box 10946, Chicago IL 60610. |
Specific Non-Drug Code |
C5 |
CPT-5 |
(under development - same contact as above) |
Specific Non-Drug Code |
CAS |
Chemical abstract codes |
These include unique codes for each unique chemical, including all generic drugs. The codes do not distinguish among different dosing forms. When multiple equivalent CAS numbers exist, use the first one listed in USAN. USAN 1990 and the USP dictionary of drug names, William M. Heller, Ph.D., Executive Editor, United States Pharmacopeial Convention, Inc., 12601 Twinbrook Parkway, Rockville, MD 20852. |
Drug code |
CD2 |
CDT-2 Codes |
American Dental Association's Current Dental Terminology (CDT-2) code. American Dental Association, 211 E. Chicago Avenue,. Chicago, Illinois 60611. |
Specific Non-Drug Code |
CDCA |
CDC Analyte Codes |
As above, for CDCM |
|
CDCM |
CDC Methods/Instruments Codes |
Public Health Practice Program Office, Centers for Disease Control and Prevention, 4770 Buford Highway, Atlanta, GA, 30421. Also available via FTP: ftp.cdc.gov/pub/laboratory _info/CLIA and Gopher: gopher.cdc.gov:70/11/laboratory_info/CLIA |
Drug code |
CDS |
CDC Surveillance |
CDC Surveillance Codes. For data unique to specific public health surveillance requirements. Epidemiology Program Office, Centers for Disease Control and Prevention, 1600 Clifton Rd, Atlanta, GA, 30333. (404) 639-3661. |
Specific Non-Drug Code |
CE |
CEN ECG diagnostic codes |
CEN PT007. A quite comprehensive set of ECG diagnostic codes (abbreviations) and descriptions published as a pre-standard by CEN TC251. Available from CEN TC251 secretariat, c/o Georges DeMoor, State University Hospital Gent, De Pintelaan 185-5K3, 9000 Gent, Belgium or Jos Willems, University of Gathuisberg, 49 Herestraat, 3000 Leuven, Belgium. |
Specific Non-Drug Code |
CLP |
CLIP |
Simon Leeming, Beth Israel Hospital, Boston MA. Codes for radiology reports. |
Specific Non-Drug Code |
CPTM |
CPT Modifier Code |
Available from the AMA at the address listed for CPT above. These codes are found in Appendix A of CPT 2000 Standard Edition. (CPT 2000 Standard Edition, American Medical Association, Chicago, IL). |
Specific Non-Drug Code |
CST |
COSTART |
International coding system for adverse drug reactions. In the USA, maintained by the FDA, Rockville, MD. |
Drug code |
CVX |
CDC Vaccine Codes |
National Immunization Program, Centers for Disease Control and Prevention, 1660 Clifton Road, Atlanta, GA, 30333 |
Drug code |
DCL |
DICOM Class Label |
From the Message Standards Classes table of the SNOMED-DICOM-Microglossary. College of American Pathologists, Skokie, IL, 60077-1034 |
Specific Non-Drug Code |
DCM |
DICOM modality codes |
Dean Bidgood, MD; Duke University Medical Center, Durham NC. Digital Imaging and Communications in Medicine (DICOM). From NEMA Publications PS-3.1 - PS 3.12: The ACR-NEMA DICOM Standard. National Electrical Manufacturers Association (NEMA). Rosslyn, VA, 22209., 1992, 1993, 1995 |
Specific Non-Drug Code |
DQL |
DICOM Query Label |
HL7 Image Management Special Interest Group, Health Level Seven, Ann Arbor, MI. |
Specific Non-Drug Code |
E |
EUCLIDES |
Available from Euclides Foundation International nv, Excelsiorlaan 4A, B-1930 Zaventem, Belgium; Phone: 32 2 720 90 60. |
Specific Non-Drug Code |
E5 |
Euclides quantity codes |
Available from Euclides Foundation International nv (see above) |
Specific Non-Drug Code |
E6 |
Euclides Lab method codes |
Available from Euclides Foundation International nv, Excelsiorlaan 4A, B-1930 Zaventem, Belgium; Phone: 32 2 720 90 60. |
Specific Non-Drug Code |
E7 |
Euclides Lab equipment codes |
Available from Euclides Foundation International nv (see above) |
Specific Non-Drug Code |
ENZC |
Enzyme Codes |
Enzyme Committee of the International Union of Biochemistry and Molecular Biology. Enzyme Nomenclature: Recommendations on the Nomenclature and Classification of Enzyme-Catalysed Reactions. London: Academic Press, 1992. |
Specific Non-Drug Code |
FDDC |
First DataBank Drug Codes |
National Drug Data File. Proprietary product of First DataBank, Inc. (800) 633-3453, or http://www.firstdatabank.com. |
Drug code |
FDDX |
First DataBank Diagnostic Codes |
Used for drug-diagnosis interaction checking. Proprietary product of First DataBank, Inc. As above for FDDC. |
Drug code |
FDK |
FDA K10 |
Dept. of Health & Human Services, Food & Drug Administration, Rockville, MD 20857. (device & analyte process codes). |
Specific Non-Drug Code |
HB |
HIBCC |
Health Industry Business Communications Council, 5110 N. 40th St., Ste 120, Phoenix, AZ 85018. |
Specific Non-Drug Code |
HCPCS |
HCFA Common Procedure Coding System |
HCPCS: contains codes for medical equipment, injectable drugs, transportation services, and other services not found in CPT4. |
Specific Non-Drug Code |
HHC |
Home Health Care |
Home Health Care Classification System; Virginia Saba, EdD, RN; Georgetown University School of Nursing; Washington, DC. |
Specific Non-Drug Code |
HI |
Health Outcomes |
Health Outcomes Institute codes for outcome variables available (with responses) from Stratis Health (formerly Foundation for Health Care Evaluation and Health Outcomes Institute), 2901 Metro Drive, Suite 400, Bloomington, MN, 55425-1525; (612) 854-3306 (voice); (612) 853-8503 (fax); dziegen@winternet.com. See examples in the Implementation Guide. |
Specific Non-Drug Code |
HL7nnnn |
HL7 Defined Codes where nnnn is the HL7 table number |
Health Level Seven where nnnn is the HL7 table number |
General code |
HPC |
HCFA Procedure Codes (HCPCS) |
Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers.[4] |
Specific Non-Drug Code |
I10 |
ICD-10 |
World Health Publications, Albany, NY. |
Specific Non-Drug Code |
I10P |
ICD-10 Procedure Codes |
Procedure Coding System (ICD-10-PCS.) See http://www/hcfa.gov/stats/icd10.icd10.htm for more information. |
Specific Non-Drug Code |
I9 |
ICD9 |
World Health Publications, Albany, NY. |
Specific Non-Drug Code |
I9C |
ICD-9CM |
Commission on Professional and Hospital Activities, 1968 Green Road, Ann Arbor, MI 48105 (includes all procedures and diagnostic tests). |
Specific Non-Drug Code |
IBT |
ISBT |
International Society of Blood Transfusion. Blood Group Terminology 1990. VOX Sanquines 1990 58(2):152-169. |
Specific Non-Drug Code |
IC2 |
ICHPPC-2 |
International Classification of Health Problems in Primary Care, Classification Committee of World Organization of National Colleges, Academies and Academic Associations of General Practitioners (WONCA), 3rd edition. An adaptation of ICD9 intended for use in General Medicine, Oxford University Press. |
Specific Non-Drug Code |
ICDO |
International Classification of Diseases for Oncology |
International Classification of Diseases for Oncology, 2nd Edition. World Health Organization: Geneva, Switzerland, 1990. Order from: College of American Pathologists, 325 Waukegan Road, Northfield, IL, 60093-2750. (847) 446-8800. |
Specific Non-Drug Code |
ICS |
ICCS |
Commission on Professional and Hospital Activities, 1968 Green Road, Ann Arbor, MI 48105. |
Specific Non-Drug Code |
ICSD |
International Classification of Sleep Disorders |
International Classification of Sleep Disorders Diagnostic and Coding Manual, 1990, available from American Sleep Disorders Association, 604 Second Street SW, Rochester, MN 55902 |
Specific Non-Drug Code |
ISOnnnn |
ISO Defined Codes where nnnn is the ISO table number |
International Standards Organization where nnnn is the ISO table number |
General code |
IUPP |
IUPAC/IFCC Property Codes |
International Union of Pure and Applied Chemistry/International Federation of Clinical Chemistry. The Silver Book: Compendium of terminology and nomenclature of properties in clinical laboratory sciences. Oxford: Blackwell Scientific Publishers, 1995. Henrik Olesen, M.D., D.M.Sc., Chairperson, Department of Clinical Chemistry, KK76.4.2, Rigshospitalet, University Hospital of Copenhagen, DK-2200, Copenhagen. http://inet.uni-c.dk/~qukb7642/ |
Specific Non-Drug Code |
IUPC |
IUPAC/IFCC Component Codes |
Codes used by IUPAC/IFF to identify the component (analyte) measured. Contact Henrik Olesen, as above for IUPP. |
Specific Non-Drug Code |
JC8 |
Japanese Chemistry |
Clinical examination classification code. Japan Association of Clinical Pathology. Version 8, 1990. A multiaxial code including a subject code (e.g., Rubella = 5f395, identification code (e.g., virus ab IGG), a specimen code (e.g., serum =023) and a method code (e.g., ELISA = 022) |
Specific Non-Drug Code |
LB |
Local billing code |
Local billing codes/names (with extensions if needed). |
General code |
LN |
Logical Observation Identifier Names and Codes (LOINC®) |
Regenstrief Institute, c/o LOINC, 1050 Wishard Blvd., 5th floor, Indianapolis, IN 46202. 317/630-7433. Available from the Regenstrief Institute server at http://www.regenstrief.org/loinc/loinc.htm. January 2000 version has identifiers, synonyms and cross-reference codes for reporting over 26,000 laboratory and related observations and 1,500 clinical measures. |
Specific Non-Drug Code |
MCD |
Medicaid |
Medicaid billing codes/names. |
Specific Non-Drug Code |
MCR |
Medicare |
Medicare billing codes/names. |
Specific Non-Drug Code |
MDDX |
Medispan Diagnostic Codes |
Codes Used for drug-diagnosis interaction checking. Proprietary product. Hierarchical drug codes for identifying drugs down to manufacturer and pill size. MediSpan, Inc., 8425 Woodfield Crossing Boulevard, Indianapolis, IN 46240. Tel: (800) 428-4495. WWW: http://www.espan.com/medispan/pages/ medhome.html. As above for MGPI. |
Drug code |
MEDC |
Medical Economics Drug Codes |
Proprietary Codes for identifying drugs. Proprietary product of Medical Economics Data, Inc. (800) 223-0581. |
Drug code |
MEDR |
Medical Dictionary for Drug Regulatory Affairs (MEDDRA) |
Dr. Louise Wood, Medicines Control Agency, Market Towers, 1 Nine Elms Lane, London SW85NQ, UK Tel: (44)0 171-273-0000 WWW: http://www.open.gov.uk/mca/mcahome.htm |
Drug code |
MEDX |
Medical Economics Diagnostic Codes |
Used for drug-diagnosis interaction checking. Proprietary product of Medical Economics Data, Inc. (800) 223-0581. |
Drug code |
MGPI |
Medispan GPI |
Medispan hierarchical drug codes for identifying drugs down to manufacturer and pill size. Proprietary product of MediSpan, Inc., 8425 Woodfield Crossing Boulevard, Indianapolis, IN 46240. Tel: (800) 428-4495. |
Drug code |
MVX |
CDC Vaccine Manufacturer Codes |
As above, for CVX |
Drug code |
NDA |
NANDA |
North American Nursing Diagnosis Association, Philadelphia, PA. |
Specific Non-Drug Code |
NDC |
National drug codes |
These provide unique codes for each distinct drug, dosing form, manufacturer, and packaging. (Available from the National Drug Code Directory, FDA, Rockville, MD, and other sources.) |
Drug code |
NIC |
Nursing
Interventions |
Iowa Intervention Project, College of Nursing, University of Iowa, Iowa City, Iowa |
Specific Non-Drug Code |
NPI |
National Provider Identifier |
Health Care Finance Administration, US Dep't. of Health and Human Services, 7500 Security Blvd., Baltimore, MD 21244. |
Specific Non-Drug Code |
OHA |
Omaha System |
Omaha Visiting Nurse Association, Omaha, NB. |
Specific Non-Drug Code |
OHA |
Omaha |
Omaha Visiting Nurse Association, Omaha, NB. |
Specific Non-Drug Code |
POS |
POS Codes |
HCFA Place of Service Codes for Professional Claims (see http://www.hcfa.gov/medicare/poscode.htm). |
Specific Non-Drug Code |
RC |
Read Classification |
The Read Clinical Classification of Medicine, Park View Surgery, 26 Leicester Rd., Loughborough LE11 2AG (includes drug procedure and other codes, as well as diagnostic codes). |
Specific Non-Drug Code |
SDM |
SNOMED- DICOM Microglossary |
College of American Pathologists, Skokie, IL, 60077-1034. (formerly designated as 99SDM). |
Specific Non-Drug Code |
SNM |
Systemized Nomenclature of Medicine (SNOMED) |
Systemized Nomenclature of Medicine, 2nd Edition 1984 Vols 1, 2, College of American Pathologists, Skokie, IL. |
Specific Non-Drug Code |
SNM3 |
SNOMED International |
SNOMED International, 1993 Vols 1-4, College of American Pathologists, Skokie, IL, 60077-1034.. |
Specific Non-Drug Code |
SNT |
SNOMED topology codes (anatomic sites) |
College of American Pathologists, 5202 Old Orchard Road, Skokie, IL 60077-1034. |
Specific Non-Drug Code |
UC |
UCDS |
Uniform Clinical Data Systems. Ms. Michael McMullan, Office of Peer Review Health Care Finance Administration, The Meadows East Bldg., 6325 Security Blvd., Baltimore, MD 21207; (301) 966 6851. |
Specific Non-Drug Code |
UMD |
MDNS |
Universal Medical Device Nomenclature System. ECRI, 5200 Butler Pike, Plymouth Meeting, PA 19462 USA. Phone: 215-825-6000, Fax: 215-834-1275. |
Device code |
UML |
Unified Medical Language |
National Library of Medicine, 8600 Rockville Pike, Bethesda, MD 20894. |
Specific Non-Drug Code |
UPC |
Universal Product Code |
The Uniform Code Council. 8163 Old Yankee Road, Suite J, Dayton, OH 45458; (513) 435 3070 |
Specific Non-Drug Code |
UPIN |
UPIN |
Medicare/HCFA's universal physician identification numbers, available from Health Care Financing Administration, U.S. Dept. of Health and Human Services, Bureau of Program Operations, 6325 Security Blvd., Meadows East Bldg., Room 300, Baltimore, MD 21207 |
Specific Non-Drug Code |
W1 |
WHO rec# drug codes |
World Health organization record number code. A unique sequential number is assigned to each unique single component drug and to each multi-component drug. Eight digits are allotted to each such code, six to identify the active agent, and 2 to identify the salt, of single content drugs. Six digits are assigned to each unique combination of drugs in a dispensing unit. The six digit code is identified by W1, the 8 digit code by W2. |
Drug code |
W2 |
WHO rec# drug codes |
World Health organization record number code. A unique sequential number is assigned to each unique single component drug and to each multi-component drug. Eight digits are allotted to each such code, six to identify the active agent, and 2 to identify the salt, of single content drugs. Six digits are assigned to each unique combination of drugs in a dispensing unit. The six digit code is identified by W1, the 8 digit code by W2. |
Drug code |
W4 |
WHO rec# code with ASTM extension |
With ASTM extensions (see Implementation Guide), the WHO codes can be used to report serum (and other) levels, patient compliance with drug usage instructions, average daily doses and more (see Appendix X1 the Implementation Guide). |
Drug code |
WC |
WHO ATC |
WHO's ATC codes provide a hierarchical classification of drugs by therapeutic class. They are linked to the record number codes listed above. |
Drug code |
Referenced
in 7.3.1.15 Coding Schemes
Value |
Description |
|---|---|
BE |
Bilateral Ears |
OU |
Bilateral Eyes |
BN |
Bilateral Nares |
BU |
Buttock |
CT |
Chest Tube |
LA |
Left Arm |
LAC |
Left Anterior Chest |
LACF |
Left Antecubital Fossa |
LD |
Left Deltoid |
LE |
Left Ear |
LEJ |
Left External Jugular |
OS |
Left Eye |
LF |
Left Foot |
LG |
Left Gluteus Medius |
LH |
Left Hand |
LIJ |
Left Internal Jugular |
LLAQ |
Left Lower Abd Quadrant |
LLFA |
Left Lower Forearm |
LMFA |
Left Mid Forearm |
LN |
Left Naris |
LPC |
Left Posterior Chest |
LSC |
Left Subclavian |
LT |
Left Thigh |
LUA |
Left Upper Arm |
LUAQ |
Left Upper Abd Quadrant |
LUFA |
Left Upper Forearm |
LVG |
Left Ventragluteal |
LVL |
Left Vastus Lateralis |
NB |
Nebulized |
PA |
Perianal |
PERIN |
Perineal |
RA |
Right Arm |
RAC |
Right Anterior Chest |
RACF |
Right Antecubital Fossa |
RD |
Right Deltoid |
RE |
Right Ear |
REJ |
Right External Jugular |
OD |
Right Eye |
RF |
Right Foot |
RG |
Right Gluteus Medius |
RH |
Right Hand |
RIJ |
Right Internal Jugular |
RLAQ |
Rt Lower Abd Quadrant |
RLFA |
Right Lower Forearm |
RMFA |
Right Mid Forearm |
RN |
Right Naris |
RPC |
Right Posterior Chest |
RSC |
Right Subclavian |
RT |
Right Thigh |
RUA |
Right Upper Arm |
RUAQ |
Right Upper Abd Quadrant |
RUFA |
Right Upper Forearm |
RVL |
Right Vastus Lateralis |
RVG |
Right Ventragluteal |
Referenced
in 7.3.1.15 Coding Schemes
Referenced
in 7.3.2.6.2 - ISO and ANSI customary units abbreviations
Code/Abbr. |
Name |
|---|---|
/(arb_u) |
*1 / arbitrary unit |
/iu |
*1 / international unit |
/kg |
*1 / kilogram |
/L |
1 / liter |
1/mL |
*1 / milliliter |
10.L/min |
*10 x liter / minute |
10.L /(min.m2) |
*10 x (liter / minute) / meter2 = liter / (minute × meter2) |
10*3/mm3 |
*103 / cubic millimeter (e.g., white blood cell count) |
10*3/L |
*103 / Liter |
10*3/mL |
*103 / milliliter |
10*6/mm3 |
*106 / millimeter3 |
10*6/L |
*106 / Liter |
10*6/mL |
*106 / milliliter |
10*9/mm3 |
*109 / millimeter3 |
10*9/L |
*109 / Liter |
10*9/mL |
*109 / milliliter |
10*12/L |
*1012 / Liter |
10*3(rbc) |
*1000 red blood cells[dagger] |
a/m |
Ampere per meter |
(arb_u) |
*Arbitrary unit |
bar |
Bar (pressure; 1 bar = 100 kilopascals) |
/min |
Beats or Other Events Per Minute |
bq |
Becquerel |
(bdsk_u) |
*Bodansky Units |
(bsa) |
*Body surface area |
(cal) |
*Calorie |
1 |
*Catalytic Fraction |
/L |
Cells / Liter |
cm |
Centimeter |
cm_h20 |
* Centimeters of water =H20 (pressure) |
cm_h20.s/L |
Centimeters H20 / (liter / second) = (centimeters H20 × second) / liter (e.g., mean pulmonary resistance) |
cm_h20/(s.m) |
(Centimeters H20 / second) / meter = centimeters H20 / (second × meter) (e.g., pulmonary pressure time product) |
(cfu) |
*Colony Forming Units |
m3/s |
Cubic meter per second |
d |
Day |
db |
Decibels |
dba |
*Decibels a Scale |
cel |
Degrees Celsius |
deg |
Degrees of Angle |
(drop) |
Drop |
10.un.s/cm5 |
Dyne × Second / centimeter5 (1 dyne = 10 micronewton = 10 un) (e.g., systemic vascular resistance) |
10.un.s/(cm5.m2) |
((Dyne × second) / centimeter5) / meter2 = (Dyne × second) / (centimeter5 × meter2) (1 dyne = 10 micronewton = 10 un) (e.g., systemic vascular resistance/body surface area) |
ev |
Electron volts (1 electron volt = 160.217 zeptojoules) |
eq |
Equivalent |
f |
Farad (capacitance) |
fg |
Femtogram |
fL |
Femtoliter |
fmol |
Femtomole |
/mL |
*Fibers / milliliter |
g |
Gram |
g/d |
*Gram / Day |
g/dL |
Gram / Deciliter |
g/hr |
Gram / Hour |
g/(8.hr) |
*Gram / 8 Hour Shift |
g/kg |
Gram / Kilogram (e.g., mass dose of medication per body weight) |
g/(kg.d) |
(Gram / Kilogram) / Day = gram / (kilogram × day) (e.g., mass dose of medication per body weight per day) |
g/(kg.hr) |
(Gram / Kilogram) / Hour = gram / (kilogram × hour) (e.g., mass dose of medication per body weight per hour) |
g/(8.kg.hr) |
(Gram / Kilogram) /8 Hour Shift = gram / (kilogram × 8 hour shift) (e.g., mass dose of medication per body weight per 8 hour shift) |
g/(kg.min) |
(Gram / Kilogram) / Minute = gram / (kilogram × minute) (e.g., mass dose of medication per body weight per minute) |
g/L |
Gram / Liter |
g/m2 |
Gram / Meter2 (e.g., mass does of medication per body surface area) |
g/min |
Gram / Minute |
g.m/(hb) |
Gram × meter / heart beat (e.g., ventricular stroke work) |
g.m/((hb).m2) |
(Gram × meter/ heartbeat) / meter2 = (gram × meter) /
(heartbeat × meter2) |
g(creat) |
*Gram creatinine |
g(hgb) |
*Gram hemoglobin |
g.m |
Gram meter |
g(tot_nit) |
*Gram total nitrogen |
g(tot_prot) |
*Gram total protein |
g(wet_tis) |
*Gram wet weight tissue |
gy |
Grey (absorbed radiation dose) |
hL |
Hectaliter = 102 liter |
h |
Henry |
in |
Inches |
in_hg |
Inches of Mercury (=Hg) |
iu |
*International Unit |
iu/d |
*International Unit / Day |
iu/hr |
*International Unit / Hour |
iu/kg |
International Unit / Kilogram |
iu/L |
*International Unit / Liter |
iu/mL |
*International Unit / Milliliter |
iu/min |
*International Unit / Minute |
j/L |
Joule/liter (e.g., work of breathing) |
kat |
*Katal |
kat/kg |
*Katal / Kilogram |
kat/L |
*Katal / Liter |
k/watt |
Kelvin per watt |
(kcal) |
Kilocalorie (1 kcal = 6.693 kilojoule) |
(kcal)/d |
*Kilocalorie / Day |
(kcal)/hr |
*Kilocalorie / Hour |
(kcal)/(8.hr) |
*Kilocalorie / 8 Hours Shift |
kg |
Kilogram |
kg(body_wt) |
* kilogram body weight |
kg/m3 |
Kilogram per cubic meter |
kh/h |
Kilogram per hour |
kg/L |
Kilogram / liter |
kg/min |
Kilogram per minute |
kg/mol |
Kilogram / mole |
kg/s |
Kilogram / second |
kg/(s.m2) |
(Kilogram / second)/ meter2 = kilogram / (second × meter2) |
kg/ms |
Kilogram per square meter |
kg.m/s |
Kilogram meter per second |
kpa |
Kilopascal (1 mmHg = 0.1333 kilopascals) |
ks |
Kilosecond |
(ka_u) |
King-Armstrong Unit |
(knk_u) |
*Kunkel Units |
L |
Liter |
L/d |
*Liter / Day |
L/hr |
Liter / hour |
L/(8.hr) |
*Liter / 8 hour shift |
L/kg |
Liter / kilogram |
L/min |
Liter / minute |
L/(min.m2) |
(Liter / minute) / meter2 = liter / (minute ×
meter2) |
L/s |
Liter / second (e.g., peak expiratory flow) |
L.s |
Liter / second / second2 = liter × second |
lm |
Lumen |
lm/m2 |
Lumen / Meter2 |
(mclg_u) |
*MacLagan Units |
mas |
Megasecond |
m |
Meter |
m2 |
Meter2 (e.g., body surface area) |
m/s |
Meter / Second |
m/s2 |
Meter / Second2 |
ueq |
*Microequivalents |
ug |
Microgram |
ug/d |
Microgram / Day |
ug/dL |
Microgram / Deciliter |
ug/g |
Microgram / Gram |
ug/hr |
*Microgram / Hour |
ug(8hr) |
Microgram / 8 Hour Shift |
ug/kg |
Microgram / Kilogram |
ug/(kg.d) |
(Microgram / Kilogram) /Day = microgram / (kilogram × day) (e.g., mass dose of medication per patient body weight per day) |
ug/(kg.hr) |
(Microgram / Kilogram) / Hour = microgram / (kilogram × hours) (e.g., mass dose of medication per patient body weight per hour) |
ug/(8.hr.kg) |
(Microgram / Kilogram) / 8 hour shift = microgram / (kilogram × 8 hour
shift) |
ug/(kg.min) |
(Microgram / Kilogram) / Minute = microgram / (kilogram × minute) |
ug/L |
Microgram / Liter |
ug/m2 |
Microgram / Meter2 (e.g., mass dose of medication per patient body surface area) |
ug/min |
Microgram / Minute |
uiu |
*Micro international unit |
ukat |
*Microkatel |
um |
Micrometer (Micron) |
umol |
Micromole |
umol/d |
Micromole / Day |
umol/L |
Micromole / Liter |
umol/min |
Micromole / Minute |
us |
Microsecond |
uv |
Microvolt |
mbar |
Millibar (1 millibar = 100 pascals) |
mbar.s/L |
Millibar / (liter / second) =(millibar × second) / liter (e.g., expiratory resistance) |
meq |
*Milliequivalent |
meq/d |
*Milliequivalent / Day |
meq/hr |
*Milliequivalent / Hour |
meq/(8.hr) |
Milliequivalent / 8 Hour Shift |
meq/kg |
Milliequivalent / Kilogram (e.g., dose of medication in milliequivalents per patient body weight) |
meq/(kg.d) |
(Milliequivalents / Kilogram) / Day = milliequivalents / (kilogram × day) (e.g., dose of medication in milliequivalents per patient body weight per day) |
meq/(kg.hr) |
(Milliequivalents / Kilogram) / Hour = milliequivalents / (kilogram × hour) (e.g., dose of medication in milliequivalents per patient body weight per hour) |
meq/(8.hr.kg) |
(Milliequivalents / Kilogram) / 8 Hour Shift = milliequivalents / (kilogram × 8 hour shift) (e.g., dose of medication in milliequivalents per patient body weight per 8 hour shift) |
meq/(kg.min) |
(Milliequivalents / Kilogram) / Minute = milliequivalents / (kilogram × minute) (e.g., dose of medication in milliequivalents per patient body weight per minute) |
meq/L |
Milliequivalent / Liter |
Milliequivalent / Meter2 (e.g., dose of medication in milliequivalents per patient body surface area) |
|
meq/min |
Milliequivalent / Minute |
mg |
Milligram |
mg/m3 |
Milligram / Meter3 |
mg/d |
Milligram / Day |
mg/dL |
Milligram / Deciliter |
mg/hr |
Milligram / Hour |
mg/(8.hr) |
Milligram / 8 Hour shift |
mg/kg |
Milligram / Kilogram |
mg/(kg.d) |
(Milligram / Kilogram) / Day = milligram / (kilogram × day) (e.g., mass dose of medication per patient body weight per day) |
mg/(kg.hr) |
(Milligram / Kilogram) / Hour = milligram/ (kilogram × hour) (e.g., mass dose of medication per patient body weight per hour) |
mg/(8.hr.kg) |
(Milligram / Kilogram) /8 Hour Shift = milligram / (kilogram × 8 hour shift) (e.g., mass dose of medication per patient body weight per 8 hour shift) |
mg/(kg.min) |
(Milligram / Kilogram) / Minute = milligram / (kilogram × minute) (e.g., mass dose of medication per patient body weight per hour) |
mg/L |
Milligram / Liter |
mg/m2 |
Milligram / Meter2 (e.g., mass dose of medication per patient body surface area) |
mg/min |
Milligram / Minute |
mL |
Milliliter |
mL/cm_h20 |
Milliliter / Centimeters of Water (H20) (e.g., dynamic lung compliance) |
mL/d |
*Milliliter / Day |
mL/(hb) |
Milliliter / Heart Beat (e.g., stroke volume) |
mL/((hb).m2) |
(Milliliter / Heart Beat) / Meter2 = Milliliter / (Heart Beat × Meter2) (e.g., ventricular stroke volume index) |
mL/hr |
*Milliliter / Hour |
mL/(8.hr) |
*Milliliter / 8 Hour Shift |
mL/kg |
Milliliter / Kilogram (e.g., volume dose of medication or treatment per patient body weight) |
mL/(kg.d) |
(Milliliter / Kilogram) / Day = milliliter / (kilogram × day) (e.g., volume dose of medication or treatment per patient body weight per day) |
mL/(kg.hr) |
(Milliliter / Kilogram) / Hour = milliliter / (kilogram × hour) (e.g., volume dose of medication or treatment per patient body weight per hour) |
mL/(8.hr.kg) |
(Milliliter / Kilogram) / 8 Hour Shift = milliliter / (kilogram × 8 hour shift) (e.g., volume dose of medication or treatment per body weight per 8 hour shift) |
mL/(kg.min) |
(Milliliter / Kilogram) / Minute = milliliter / (kilogram × minute) (e.g., volume dose of medication or treatment per patient body weight per minute) |
mL/m2 |
Milliliter / Meter2 (e.g., volume of medication or other treatment per patient body surface area) |
mL/mbar |
Milliliter / Millibar (e.g., dynamic lung compliance) |
mL/min |
Milliliter / Minute |
mL/(min.m2) |
(Milliliter / Minute) / Meter2 = milliliter / (minute × meter2) (e.g., milliliters of prescribed infusion per body surface area; oxygen consumption index) |
mL/s |
Milliliter / Second |
mm |
Millimeter |
mm(hg) |
*Millimeter (HG) (1 mm Hg = 133.322 kilopascals) |
mm/hr |
Millimeter/ Hour |
mmol/kg |
Millimole / Kilogram (e.g., molar dose of medication per patient body weight) |
mmol/(kg.d) |
(Millimole / Kilogram) / Day = millimole / (kilogram × day) (e.g., molar dose of medication per patient body weight per day) |
mmol/(kg.hr) |
(Millimole / Kilogram) / Hour = millimole / (kilogram × hour) (e.g., molar dose of medication per patient body weight per hour) |
mmol/(8.hr.kg) |
(Millimole / Kilogram) / 8 Hour Shift = millimole / (kilogram × 8 hour shift) (e.g., molar dose of medication per patient body weight per 8 hour shift) |
mmol/(kg.min) |
(Millimole / Kilogram) / Minute = millimole / (kilogram × minute) (e.g., molar dose of medication per patient body weight per minute) |
mmol/L |
Millimole / Liter |
mmol/hr |
Millimole / Hour |
mmol/(8hr) |
Millimole / 8 Hour Shift |
mmol/min |
Millimole / Minute |
mmol/m2 |
Millimole / Meter2 (e.g., molar dose of medication per patient body surface area) |
mosm/L |
*Milliosmole / Liter |
ms |
Milliseconds |
mv |
Millivolts |
miu/mL |
*Milliunit / Milliliter |
mol/m3 |
Mole per cubic meter |
mol/kg |
Mole / Kilogram |
mol/(kg.s) |
(Mole / Kilogram) / Second = mole / (kilogram × second) |
mol/L |
Mole / Liter |
mol/s |
Mole / Second |
ng |
Nanogram |
ng/d |
Nanogram / Day |
ng/hr |
*Nanogram / Hour |
ng/(8.hr) |
Nanogram / 8 Hour shift |
ng/L |
Nanogram / Liter |
ng/kg |
Nanogram / Kilogram (e.g., mass dose of medication per patient body weight) |
ng/(kg.d) |
(Nanogram / Kilogram) / Day = nanogram / (kilogram × day) (e.g., mass dose of medication per patient body weight per day) |
ng/(kg.hr) |
(Nanogram / Kilogram) / Hour = nanogram / (kilogram × hour) (e.g., mass dose of medication per patient body weight per hour) |
ng/(8.hr.kg) |
(Nanogram / Kilogram) / 8 Hour Shift = nanogram / (kilogram × 8 hour shift) (e.g., mass dose of medication per patient body weight per 8 hour shift) |
ng/(kg.min) |
(Nanogram / Kilogram) / Minute = nanogram / (kilogram × minute) (e.g., mass dose of medication per patient body weight per minute) |
ng/m2 |
Nanogram / Meter2 (e.g., mass dose of medication per patient body surface area) |
ng/mL |
Nanogram / Milliliter |
ng/min |
*Nanogram / Minute |
ng/s |
*Nanogram / Second |
nkat |
*Nanokatel |
nm |
Nanometer |
nmol/s |
Nanomole / Second |
ns |
Nanosecond |
n |
Newton (force) |
n.s |
Newton second |
(od) |
*O.D. (optical density) |
ohm |
Ohm (electrical resistance) |
ohm.m |
Ohm meter |
osmol |
Osmole |
osmol/kg |
Osmole per kilogram |
osmol/L |
Osmole per liter |
/m3 |
*Particles / Meter3 |
/L |
*Particles / Liter |
/(tot) |
*Particles / Total Count |
(ppb) |
*Parts Per Billion |
(ppm) |
*Parts Per Million |
(ppth) |
Parts per thousand |
(ppt) |
Parts per trillion (10^12) |
pal |
Pascal (pressure) |
/(hpf) |
*Per High Power Field |
(ph) |
*pH |
pa |
Picoampere |
pg |
Picogram |
pg/L |
Picogram / Liter |
pg/mL |
Picogram / Milliliter |
pkat |
*Picokatel |
pm |
Picometer |
pmol |
*Picomole |
ps |
Picosecond |
pt |
Picotesla |
(pu) |
*P.U. |
% |
Percent |
dm2/s2 |
Rem (roentgen equivalent man) = 10-2 meter2 / second2 = decimeter2 / second2 Dose of ionizing radiation equivalent to 1 rad of x-ray or gamma ray) [From Dorland's Medical Dictionary] |
sec |
Seconds of arc |
sie |
Siemens (electrical conductance) |
sv |
Sievert |
m2/s |
Square meter / second |
cm2/s |
Square centimeter / second |
t |
Tesla (magnetic flux density) |
(td_u) |
Todd Unit |
v |
Volt (electric potential difference) |
1 |
Volume Fraction |
wb |
Weber (magnetic flux) |
*Starred
items are not genuine ISO, but do not conflict. |
None.
The length of the observation field is
variable, depending upon value type. See OBX-2 value type.[2] May repeat for multipart, single answer results with
appropriate data types, e.g., CE, TX, and FT data types.
[3] LOINC® Committee. Logical Observation
Identifier Names and Codes. Indianapolis: Regenstrief Institute and LOINC®
Committee, 1995. Regenstrief Institute c/o LOINC, 1050 Wishard Blvd., RG-5,
Indianapolis, IN 46202. 317/630-7433. Available at
http://www:regenstrief.org/loinc/loinc.html. The LOINC® Code System is
described in Forrey AW, McDonald CJ, DeMoor G, Huff SM, Leavelle D, Leland D,
et.al. Logical Observation Identifier Names and Codes (LOINC®) database: a
public use set of codes and names for electronic reporting of clinical
laboratory test results. Clinical Chemistry 1996;42:81-90[4] The HCPCS code is divided into three "levels." Level I
includes the entire CPT-4 code by reference. Level II includes the American
Dental Association's Current Dental Terminology (CDT-2) code by reference.
Level II also includes the genuine HCPCS codes, approved and maintained jointly
by the Alpha-Numeric Editorial Panel, consisting of HCFA, the Health Insurance
Association of America, and the Blue Cross and Blue Shield Association. Level
III are codes developed locally by Medicare carriers. The HCPCS modifiers are
divided into the same three levels, I being CPT-4 modifiers, II CDT-2 and
genuine HCPCS modifiers, and III being locally agreed modifiers.
The
genuine HCPCS codes and modifiers of level II can be found at [. HCFA distributes the HCPCS codes via the National Technical
Information Service (NTIS, ) and NTIS distribution includes the CDT-2 part of
HCPCS Level II, but does not include the CPT-4 part (Level I). HCFA may
distribute the CPT-4 part to its contractors.