Chapter Chair/Editor: |
Charles
Mead, M.D. |
Chapter Chair/Editor: |
Daniel
Russler, M.D. |
Chapter Chair/Editor: |
Heather
Von Allmen |
The
Patient Care[1] Technical Committee has designed
the following messages to support the communication of problem-oriented
records, including clinical problems, goals, and pathway information between
computer systems. The purpose of this chapter is to describe healthcare
messages that need to be communicated between clinical applications for a given
individual. These message transactions can be sent in either batch or online
mode. As described in Chapter 2, multiple communication transactions may be
grouped and sent between applications using a file transfer media or direct
networked connection.
This chapter defines the transactions that occur at the seventh OSI level, that
is, abstract messages. The examples of messages included in this chapter were
constructed using the HL7 Encoding Rules.
The following definitions of key terms are used throughout this chapter:
A goal refers to an objective to be achieved as a consequence of healthcare interventions applied to an individual. Goals are set in many areas of the healthcare system, and include educational, behavior modification, and clinical goals such as reduced discomfort, improved circulation. Goals are documented by a variety of healthcare professionals including physicians, nurses, and respiratory and other therapists. Goals are defined during patient visits and they may span one or multiple visits, encounters, or episodes of care.
A problem of a given individual can be described by formal diagnosis coding systems (such as DRGs, NANDA Nursing Diagnosis, ICD9, DSM, etc.) or by other professional descriptions of healthcare issues affecting an individual. Problems can be short- or long-term in nature, chronic or acute, and have a status. In a longitudinal record, all problems may be of importance in the overall long-term care of an individual, and may undergo changes in status repeatedly. Problems are identified during patient visits, and may span multiple visits, encounters, or episodes of care.
A role refers to the function or responsibility assumed by a person in the context of a healthcare event. Role information documents a person's association with an identified healthcare activity. Examples include primary care provider, transcriptionist, reviewer, and consulting physician.
A clinical pathway is a standardized plan of care against which progress towards health is measured. A clinical pathway is applied based upon the results of a patient assessment. A clinical pathway shows exact timing of all key patient care activities intended to achieve expected standard outcomes within designated time frames. A clinical pathway includes documentation of problems, expected outcomes/goals, and clinical interventions/orders.
Variances are documented deviations, either positive or negative, from a pre-defined standard. Variances are documented against expected outcomes, orders, or the patient's progress in general.
A physician's office is scheduling a patient for admission to the hospital. The admitting diagnosis/problem list and admission information is sent by the physician's electronic information system to the hospital's Patient Administration system and longitudinal medical record. The trigger event identifies the message as an "add problem" to the Patient Administration and medical record system.
A consultation is requested for an individual. The information system generating the consultation triggers an unsolicited message containing the problem/diagnosis list that is transmitted to the consulting organization. Goals and various kinds of role information are included with the transmission. The trigger event identifies the message as an unchanged record.
Information from point of care, clinical practice management or ancillary systems regarding the creation or update of pathways, problems, diagnoses, or goals are communicated to the clinical repository. Message triggers from the departmental systems may indicate adding, correcting, deleting, or updating records maintained in the clinical data repository.
The pathway is communicated between Quality Assurance, Point of Care Systems, Research Databases, and Clinical Order Entry Systems. A point of care information system triggers a linkage between a problem and a set of ordered interventions initiated by the clinical order entry system.
The
trigger events originate goal, problem and pathway messages. Each trigger
event is documented below, along with the appropriate form of the message
exchange. These are message-level event triggers, which are augmented by the
action code fields contained in the pathway, problem and goal segments
described below. Action codes are required fields in patient care message
segments (see Chapter 2 for further information regarding implementation
issues). Implementors need to apply the appropriate logic as part of their
message construction (for example, logic would state that an "add" trigger
event should not include segments with a "delete" action code).
In order to accommodate these high-level events, the following patient care
events are included in HL7 table 0003 - Event type. The
added events are instantiated in MSH-9-message type and are used by the
pathway, problem, and goal messages. MSH-9-message type contains the
message type and trigger event for the message.
Patient Care Trigger Events:
Value |
Description |
|---|---|
PC1 |
PPR - PC/ Problem Add |
PC2 |
PPR - PC/ Problem Update |
PC3 |
PPR - PC/ Problem Delete |
PC4 |
QRY - PC/ Problem Query |
PC5 |
PRR - PC/ Problem Response |
PC6 |
PGL - PC/ Goal Add |
PC7 |
PGL - PC/ Goal Update |
PC8 |
PGL - PC/ Goal Delete |
PC9 |
QRY - PC/ Goal Query |
PCA |
PPV - PC/ Goal Response |
PCB |
PPP - PC/ Pathway (Problem-Oriented) Add |
PCC |
PPP - PC/ Pathway (Problem-Oriented) Update |
PCD |
PPP - PC/ Pathway (Problem-Oriented) Delete |
PCE |
QRY - PC/ Pathway (Problem-Oriented) Query |
PCF |
PTR - PC/ Pathway (Problem-Oriented) Query Response |
PCG |
PPG - PC/ Pathway (Goal-Oriented) Add |
PCH |
PPG - PC/ Pathway (Goal-Oriented) Update |
PCJ |
PPG - PC/ Pathway (Goal-Oriented) Delete |
PCK |
QRY - PC/ Pathway (Goal-Oriented) Query |
PCL |
PPT - PC/ Pathway (Goal-Oriented) Query Response |
Prior
to Version 2.3 of the Standard, all repeating segments had to be sent in an
update message, because there was no way to indicate which ones changed and
which ones did not. In this snapshot mode, all repeating segments must
be sent with every subsequent message in the series of messages.
To reduce the number of repeating segments, action codes may be employed.
Action codes (e.g., order control codes and result status codes) may be
embedded within repeating segments and used by sophisticated application
parsers to reduce the number of repetitions required for a complete record.
In either event, for systems implementing Version 2.3 or higher, if a
particular repeating segment can be updated by either of these two modes, the
parties concerned determine by agreement on a site-specific basis whether an
interface uses the snapshot mode or the action code/unique
identifier mode.
A description of valid action codes used in message segments originating in
this chapter is given immediately below:
a. AD (ADD) - The object defined within the segment should be
added to the set of objects that is linked to the previous object in the
hierarchical structure of the message. (i.e., a goal under a problem is
implicitly linked to the problem. If the goals already exist, the segment
placement indicates the addition of a new linkage between the goal and that
problem.)
b. CO (CORRECT) - The object attributes contained within the
segment have been corrected. This is not updated information, but information
originally sent and later found to be in error. The previous attributes should
be replaced.
c. UP (UPDATE) - The object attributes contained within the
segment are an update of previously sent information. The previous information
was correct for the period of time in which it was sent.
d. DE (DELETE) - This object should be deleted from the set of
objects which are linked to the previous object in the message hierarchy. An
example might be a role deleted from the set of roles contained by the Goal
object. Delete presumes the original linkage was in error.
e. LI (LINK) - This action code denotes that the object contained in the
segment should be linked in a dependency relationship to the previous object in
the hierarchy. It is used to denote relationships and should not contain
additional information other than those attributes necessary for specific
identification.
f. UN (UNLINK) - This is a request that the object be removed
from the set of linked objects. An example might be the dissolution of a
relationship between a problem and a goal. Unlink presumes the original
linkage was correct, but due to life cycle changes the active linkage is no
longer appropriate.
g. UC (UNCHANGED) - This code signifies that the segment is being
included for the purposes of hierarchical set identification. It does not
contain any changed or additional data. Its purpose is to allow the
identification of the collection set to which subsequent segments belong in the
message structure. An example might be the modification of role information
requiring the previous goal segment to be appropriately identified.
A
problem list and associated goals are generated in a Point of Care system.
This transaction is broadcast through an interface engine that determines which
systems in the organization require the event information and then forwards the
messages appropriately. Each segment included in the original message contains
the Action Code for ADD to signify an original message instance.
a) Upon subsequent review, it is determined that a role segment designates the
wrong person as the transcribing clerk for a problem. After the information is
changed in the originating system, a new message is sent to provide
synchronization. The message includes the original PRB segment with the
PRB-1-action code for UNCHANGED (to identify the problem for
which the role is being changed). This code signifies that the segment is
included for the purposes of hierarchical linkage identification and that none
of the information contained in it has been changed. The accompanying role
segment sent would include the role transcriber in ROL-3-role,
the correct person in ROL-4-role person, and the value for
CORRECT in ROL-2-action code.
b) It is later decided that an additional goal must be added to a specific
problem, and that an already existing goal that is currently supporting another
problem should also be linked with this specific problem. The message would be
constructed with the problem (PRB) segment for identification (the value for
PRB-1-action code is UNCHANGED). The goal segment (GOL) for the
additional goal would include GOL-1-action code for ADD. The
goals already included with the problem list that need to be linked to this
problem would have to be included on additional GOL segments with the
GOL-1-action code for LINK.
Once data regarding a
Diagnosis/Problem or a Goal have been communicated to other systems, there are
occasions on which the data may have to be amended.
c) New diagnoses/problems must be added to an individual's list. The Problem
message is sent with the appropriate Problem Instance ID. All PRB segment(s)
included in the message that contain the value for ADD in
PRB-1-action code are processed as additions to the individual's problem
list.
d) New goals are added to the individual's record. The Goal message is sent
with the GOL segments indicating the value for ADD as GOL-1-action
code in each segment occurrence.
e) Changes are made to the attributes of a goal. Examples include a change in
the expected resolution date, a change in the life cycle status to reflect its
successful conclusion, etc. The Goal message is sent with the appropriate
GOL-4-goal instance ID. The GOL segments of the Goal message would
include the value for UPDATE in GOL-1-action code.
f) A new goal is attached to a problem already in the repository (e.g., the
goal of "education on diabetes" for an individual diagnosed with
"insulin-dependent diabetes"). A problem message would be sent with the PRB
segment including the PRB-4-problem instance ID for the diabetes
problem, and with the value UNCHANGED in PRB-1-action code. The
attached GOL segment for the education goal would accompany the message and
contain the value ADD in its GOL-1-action code field.
g) A new diagnosis/problem is attached to a goal (e.g., a Goal is to
"discharge an individual with intact skin." While the initial problem was
"skin breakdown related to immobility," a new problem is "potential for skin
breakdown related to draining wounds.") A Goal message would be sent with the
GOL segment, including the GOL-4-goal instance ID for the discharge
goal, and contain the value UNCHANGED in GOL-1-action code. The
attached PRB segment identifying the new problem, "potential for skin breakdown
related to draining wounds," would accompany this message and contain the value
for ADD in PRB-1-action code.
Note: If there is a requirement to modify information contained on a
segment and unlink that same problem/goal, two segments must be transmitted
(one for the modification and one for the unlink request).
The semantic meaning of a message is contained in the message through the use of the trigger events, the implicit hierarchical linkages of the segments, and the segment action codes. Each of these has a scope within the message. The message event as included in the MSH-9-message type has a scope which is global to the message. The segment hierarchical linkage has a scope which includes both the segment itself and its relationship to its parent. The segment action code's scope is to the segment itself. It may further define link and unlink actions in the hierarchical structure.
The
trigger event defines the action at the first level of the hierarchy, and
should not be contradicted by either hierarchical linkages or segment action
codes. Thus, a PC1 (problem add) event should only contain problem, goal, and
role segments that have action codes ADD.
Trigger Event Types |
Allowable Action Codes |
xxx-Add |
Top
level action code must be ADD |
xxx-Update |
Top
level action code must be CORRECT, UPDATE, or UNCHANGED |
xxx-Delete |
Top
level action code must be DELETE |
When using the segment action codes LINK and UNLINK, only those fields which are used to define a unique instance of the object are used. This action cannot be used to send changes and updates to the other fields of that segment.
In
dependent segments ADD is the action code to use to establish the
initial relationship between parent-child objects. The receiving system must
be ready to handle multiple adds of the same object. An example is a Problem
List of three (3) problems which is being sent. Attached to these problems are
three (3) goals. Problem A has Goals 1 and 2 attached to it. Problem B has
the same Goal 2 and a new Goal 3 attached to it. All of these will have the
ADD action code in the segment, and when Problem B is transmitted with
Goals 2 and 3, Goal 2 will have been previously transmitted with Problem A.
The message construct would look like this:
MSH...
PID...
PRB (Problem A)
GOL (Goal 1)
GOL (Goal 2)
PRB (Problem B)
GOL (Goal 2)
GOL (Goal 3)
PRB (Problem C) (No attached goals)
When two (or more) instances of the same problem or goal segment are present in
a message both such segments must have identical values for all fields.
Remember that HL7 only provides for error messages at the message level. Thus, if the receiving system cannot process one segment, the entire message is going to be treated as an error (See Chapter 2).
The
Problem, Goal, and Pathway messages integrate order segments as a method for
establishing causal linkages. Linkages or relationships between orders,
problems, goals, and pathways can therefore be presented in the Patient Care
messages.
Orders referenced in Patient Care messages are used for linkage purposes only.
Initiation and status changes to orders are accomplished by using dedicated
messages defined in the Order Entry Chapter.
Order segments are sent with Problem and Goal segments in order to establish a linkage between them, NOT to communicate new orders or changes to those orders. For purposes of these messages, an LI (Link) and a UL (Unlink) code have been added to HL7 table 0119 - Order control.
Applications
can have differing orientations for representing problem and goal hierarchies.
For example, parent/child relationships may map problem(s) to goal(s), or
goal(s) to problem(s). To accommodate these different orientations, the
Problem message allows representation of goals that are functionally dependent
upon a problem, and the Goal message allows representation of problems that are
functionally dependent on a goal.
Due to the multiple occurrences of common segments such as Variance (VAR) and
Notes (NTE), we have chosen to expand the segment definitions on the message
diagrams to explicitly identify the hierarchical relationships. Examples of
this would be "Variance (Goal)" and "Variance (Role)." This does not imply
unique segments, but indicates in the first case that the variance is related
to its parent Goal, and in the second case that the variance is related to its
parent Role.
The notation used to describe the sequence, the optionality, and the repetition
of segments is described in Chapter 2, under "Format for defining abstract
message."
Note: For all message definitions, the "OBR etc." notation represents all
possible combinations of pharmacy and other order detail segments, as outlined
in Chapter 4 conventions (See Section 4.2.2.4, "Order detail segment").
This
message is used to send goals from one application to another (e.g., a point of
care system to a clinical repository). Many of the segments associated with
this event are optional. This optionality allows systems in need of this
information to set up transactions that fulfill their requirements.
PGL^PC6-PC8^PGL_PC6 |
Patient Goal Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
PID |
Patient Identification |
3 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit - Additional Info |
3 |
{ |
||
GOL |
Detail Goal |
12 |
[{NTE}] |
Notes & Comments & Comments (Goal Comments) |
2 |
[{VAR}] |
Variance (Goal) |
12 |
[{ROL |
Role (Goal) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{PTH |
Detail Pathway |
12 |
[{VAR}] |
Variance (Pathway) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation/Result Comments) |
2 |
}] |
||
[{PRB |
Detail Problem |
12 |
[{NTE}] |
Notes & Comments (Problem Comments) |
2 |
[{VAR}] |
Variance (Problem) |
12 |
[{ROL |
Role (Problem) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation/Result Comments) |
|
}] |
||
}] |
||
[{ORC |
Common Order |
4 |
[OBR, etc... |
Order Detail Segment, etc. |
4 |
[{NTE}] |
Notes (Order Detail Comments) |
2 |
[{VAR}] |
Variance (Order) |
12 |
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation Comments) |
2 |
[{VAR}]} |
Variance (Observation/Result) |
12 |
}] |
||
] |
||
}] |
||
} |
ACK^PC6-PC8^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
This error segment indicates the fields that caused a transaction to be rejected.
The
patient problem message is used to send problems from one application to
another (e.g., a point of care system to a clinical repository). Many of the
segments associated with this event are optional. This optionality allows
systems in need of this information to set up transactions that fulfill their
requirements.
PPR^PC1-PC3^PPR_PC1 |
Patient Problem Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
PID |
Patient Identification |
3 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit |
3 |
{ |
||
PRB |
Detail Problem |
12 |
[{NTE}] |
Notes & Comments (Problem Comments) |
2 |
[{VAR}] |
Variance (Problem) |
12 |
[{ROL |
Role (Problem) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{PTH |
Detail Pathway |
12 |
[{VAR}] |
Variance (Pathway) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation/Result Comments) |
2 |
}] |
||
[{GOL |
Detail Goal |
12 |
[{NTE}] |
Notes & Comments (Goal Comments) |
2 |
[{VAR}] |
Variance (Goal) |
12 |
[{ROL |
Role (Goal) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation/Result Comments) |
2 |
}] |
||
}] |
||
[{ORC |
Common Order |
4 |
[OBR, etc |
Order Detail Segment, etc. |
4 |
[{NTE}] |
Notes & Comments (Order Detail Comments) |
2 |
[{VAR}] |
Variance (Order) |
12 |
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation Comments) |
2 |
[{VAR}] |
Variance (Observation/Result) |
12 |
}] |
||
] |
||
}] |
||
} |
ACK^PC1-PC3^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
This error segment indicates the fields that caused a transaction to be rejected.
PPP^PCB-PCD^PPP_PCB |
Patient Pathway Problem-Oriented Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
PID |
Patient Identification |
3 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit |
3 |
{ |
||
PTH |
Pathway Detail |
12 |
[{NTE}] |
Notes & Comments(Pathway Comments) |
2 |
[{VAR}] |
Variance (Pathway) |
12 |
[{ROL |
Role (Pathway) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{PRB |
Detail Problem |
12 |
[{NTE}] |
Notes & Comments(Problem Comments) |
2 |
[{VAR}] |
Variance (Problem) |
12 |
[{ROL |
Role (Problem) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments(Observation/Result Comments) |
2 |
}] |
||
[{GOL |
Detail Goal |
12 |
[{NTE}] |
Notes & Comments(Goal Comments) |
2 |
[{VAR}] |
Variance (Goal) |
12 |
[{ROL |
Role (Goal) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation/Result Comments) |
2 |
}] |
||
}] |
||
[{ORC |
Common Order |
4 |
[OBR, etc |
Order Detail Segment, etc. |
4 |
[{NTE}] |
Notes & Comments(Order Detail Comments) |
2 |
[{VAR}] |
Variance (Order) |
12 |
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments(Observation Comments) |
2 |
[{VAR}] |
Variance (Observation/Result) |
12 |
}] |
||
] |
||
}] |
||
}] |
||
} |
ACK^PCB-PCD^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
PPG^PCG,PCH,PCJ^PPG_PCG |
Patient Pathway Goal-Oriented Message |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
PID |
Patient Identification |
3 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit |
3 |
{ |
||
PTH |
Pathway Detail |
12 |
[{NTE}] |
Notes & Comments(Pathway Comments) |
2 |
[{VAR}] |
Variance (Pathway) |
12 |
[{ROL |
Role (Pathway) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{GOL |
Detail Goal |
12 |
[{NTE}] |
Notes & Comments(Goal Comments) |
2 |
[{VAR}] |
Variance (Goal) |
12 |
[{ROL |
Role (Goal) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments(Observation/Result Comments) |
2 |
}] |
||
[{PRB |
Detail Problem |
12 |
[{NTE}] |
Notes & Comments (Problem Comments) |
2 |
[{VAR}] |
Variance (Problem) |
12 |
[{ROL |
Role (Problem) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments(Observation/Result Comments) |
2 |
}] |
||
}] |
||
[{ORC |
Common Order |
4 |
[OBR, etc... |
Order Detail Segment, etc. |
4 |
[{NTE}] |
Notes & Comments (Order Detail Comments) |
2 |
[{VAR}] |
Variance (Order) |
12 |
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments(Observation Comments) |
2 |
[{VAR}] |
Variance (Observation/Result) |
12 |
}] |
||
] |
||
}] |
||
}] |
||
} |
ACK^PCG,PCH,PCJ^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
The
following trigger/message event is served by QRY (a query from another system).
The QRD-8-who filter identifies the patient or account number upon which
the query is defined and can contain a Format Code of R
(record-oriented). If the query is based on the Patient ID and there are data
associated with multiple accounts, the problem of which account data should be
returned becomes an implementation issue.
QRY^PC4^QRY_PC4 |
Query |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
QRD |
Query Definition |
2 |
[ QRF ] |
Query Filter |
2 |
The
following trigger/message event is served by PRR (a response from the system
responsible for maintaining the problem information).
PRR^PC5^PRR_PC5 |
Problem Query Response |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
[QAK] |
Query Acknowledgement |
5 |
QRD |
Query Definition |
2 |
{ |
||
PID |
Patient Identification |
3 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit |
3 |
{ |
||
PRB |
Detail Problem |
12 |
[{NTE}] |
Notes & Comments (Problem Comments) |
2 |
[{VAR}] |
Variance (Problem) |
12 |
[{ROL |
Role (Problem) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{PTH |
Detail Pathway |
12 |
[{VAR}] |
Variance (Pathway) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation/Result Comments) |
2 |
}] |
||
[{GOL |
Detail Goal |
12 |
[{NTE}] |
Notes & Comments (Goal Comments) |
2 |
[{VAR}] |
Variance (Goal) |
12 |
[{ROL |
Role (Goal) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation/Result Comments) |
2 |
}] |
||
}] |
||
[{ORC |
Common Order |
4 |
[OBR, etc. |
Order Detail Segment, etc. |
4 |
[{NTE}] |
Notes & Comments (Order Detail Comments) |
2 |
[{VAR}] |
Variance (Order) |
12 |
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation Comments) |
2 |
[{VAR}] |
Variance (Observation/Result) |
12 |
}] |
||
] |
||
}] |
||
} |
||
} |
The
following trigger/message event is served by QRY (a query from another system).
The QRD-8-who filter identifies the patient or account number upon which
the query is defined and can contain a Format Code of R
(record-oriented). If the query is based on the Patient ID and there are data
associated with multiple accounts, the problem of which account data should be
returned becomes an implementation issue.
QRY^PC9^QRY_PC4 |
Query |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
QRD |
Query Definition |
2 |
[ QRF ] |
Query Filter |
2 |
The
following trigger/message event is served by PPV (a response from the system
responsible for maintaining the goal information).
PPV^PCA^PPV_PCA |
Goal Query Response |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
[QAK] |
Query Acknowledgement |
5 |
QRD |
Query Definition |
2 |
{ |
||
PID |
Patient Identification |
3 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit |
3 |
{ |
||
GOL |
Detail Goal |
12 |
[{NTE}] |
Notes & Comments (Goal Comments) |
2 |
[{VAR}] |
Variance (Goal) |
12 |
[{ROL |
Role (Goal) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{PTH |
Detail Pathway |
12 |
[{VAR}] |
Variance (Pathway) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation/Result Comments) |
2 |
}] |
||
[{PRB |
Detail Problem |
12 |
[{NTE}] |
Notes & Comments (Problem Comments) |
2 |
[{VAR}] |
Variance (Problem) |
12 |
[{ROL |
Role (Problem) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation/Result Comments) |
2 |
}] |
||
}] |
||
[{ORC |
Common Order |
4 |
[OBR, etc. |
Order Detail Segment, etc. |
4 |
[{NTE]} |
Notes & Comments (Order Detail Comments) |
2 |
[{VAR}] |
Variance (Order) |
12 |
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation Comments) |
2 |
[{VAR}] |
Variance (Observation/Result) |
12 |
}] |
||
] |
||
}] |
||
} |
||
} |
The
following trigger/message event is served by QRY (a query from another system).
The QRD-8-who filter identifies the patient or account number upon which
the query is defined and can contain a Format Code of R
(record-oriented). If the query is based on the Patient ID and there are data
associated with multiple accounts, the problem of which account data should be
returned becomes an implementation issue.
QRY^PCE^QRY_PC4 |
Query |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
QRD |
Query Definition |
2 |
[ QRF ] |
Query Filter |
2 |
The
following trigger/message event is served by PTR (a response from the system
responsible for maintaining the problem-oriented pathway information).
PTR^PCF^PTR_PCF |
Patient Pathway Problem-Oriented Response |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
[QAK] |
Query Acknowledgement |
5 |
QRD |
Query Definition |
2 |
{ |
||
PID |
Patient Identification |
3 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit |
3 |
{ |
||
PTH |
Pathway Detail |
12 |
[{NTE}] |
Notes & Comments (Pathway Comments) |
2 |
[{VAR}] |
Variance (Pathway) |
12 |
[{ROL |
Role (Pathway) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}]0 |
||
[{PRB |
Detail Problem |
12 |
[{NTE}] |
Notes & Comments (Problem Comments) |
2 |
[{VAR}] |
Variance (Problem) |
12 |
[{ROL |
Role (Problem) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
{NTE}] |
Notes & Comments (Observation/Result Comments) |
2 |
}] |
||
[{GOL |
Detail Goal |
12 |
[{NTE}] |
Notes & Comments (Goal Comments) |
2 |
[{VAR}] |
Variance (Goal) |
12 |
[{ROL |
Role (Goal) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation/Result Comments) |
2 |
}] |
||
}] |
||
[{ORC |
Common Order |
4 |
[OBR, etc. |
Order Detail Segment, etc. |
4 |
[{NTE}] |
Notes & Comments (Order Detail Comments) |
2 |
[{VAR}] |
Variance (Order) |
12 |
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation Comments) |
2 |
[{VAR}] |
Variance (Observation/Result) |
12 |
}] |
||
] |
||
}] |
||
}] |
||
} |
||
} |
The
following trigger/message event is served by QRY (a query from another system).
The QRD-8-who filter identifies the patient or account number upon which
the query is defined and can contain a Format Code of R
(record-oriented). If the query is based on the Patient ID and there are data
associated with multiple accounts, the problem of which account data should be
returned becomes an implementation issue.
QRY^PCK^QRY_PC4 |
Query |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
QRD |
Query Definition |
2 |
[ QRF ] |
Query Filter |
2 |
The
following trigger/message event is served by PPT (a response from the system
responsible for maintaining the goal-oriented pathway information).
PPT^PCL^PPT_PCL |
Patient Pathway Goal-Oriented Response |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
[QAK] |
Query Acknowledgement |
5 |
QRD |
Query Definition |
2 |
{ |
||
PID |
Patient Identification |
3 |
[PV1 |
Patient Visit |
3 |
[PV2]] |
Patient Visit |
3 |
{ |
||
PTH |
Pathway Detail |
12 |
[{NTE}] |
Notes & Comments (Pathway Comments) |
2 |
[{VAR}] |
Variance (Pathway) |
12 |
[{ROL |
Role (Pathway) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{GOL |
Detail Goal |
12 |
[{NTE}] |
Notes & Comments (Goal Comments) |
2 |
[{VAR}] |
Variance (Goal) |
12 |
[{ROL |
Role (Goal) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation/Result Comments) |
2 |
}] |
||
[{PRB |
Detail Problem |
12 |
[{NTE}] |
Notes & Comments (Problem Comments) |
2 |
[{VAR}] |
Variance (Problem) |
12 |
[{ROL |
Role (Problem) |
12 |
[{VAR}] |
Variance (Role) |
12 |
}] |
||
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation/Result Comments) |
2 |
}] |
||
}] |
||
[{ORC |
Common Order |
4 |
[OBR, etc. |
Order Detail Segment, etc. |
4 |
[{NTE}] |
Notes & Comments (Order Detail Comments) |
2 |
[{VAR}] |
Variance (Order) |
12 |
[{OBX |
Observation/Result |
7 |
[{NTE}] |
Notes & Comments (Observation Comments) |
2 |
[{VAR}] |
Variance (Observation/Result) |
12 |
}] |
||
] |
||
}] |
||
}] |
||
} |
||
} |
The
goal detail segment contains the data necessary to add, update, correct, and
delete the goals for an individual.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
2 |
ID |
R |
0287 |
00816 |
Action Code |
|
2 |
26 |
TS |
R |
00817 |
Action Date/Time |
||
3 |
250 |
CE |
R |
00818 |
Goal ID |
||
4 |
60 |
EI |
R |
00819 |
Goal Instance ID |
||
5 |
60 |
EI |
O |
00820 |
Episode of Care ID |
||
6 |
60 |
NM |
O |
00821 |
Goal List Priority |
||
7 |
26 |
TS |
O |
00822 |
Goal Established Date/Time |
||
8 |
26 |
TS |
O |
00824 |
Expected Goal Achieve Date/Time |
||
9 |
250 |
CE |
O |
00825 |
Goal Classification |
||
10 |
250 |
CE |
O |
00826 |
Goal Management Discipline |
||
11 |
250 |
CE |
O |
00827 |
Current Goal Review Status |
||
12 |
26 |
TS |
O |
00828 |
Current Goal Review Date/Time |
||
13 |
26 |
TS |
O |
00829 |
Next Goal Review Date/Time |
||
14 |
26 |
TS |
O |
00830 |
Previous Goal Review Date/Time |
||
15 |
200 |
TQ |
O |
00831 |
Goal Review Interval |
||
16 |
250 |
CE |
O |
00832 |
Goal Evaluation |
||
17 |
300 |
ST |
O |
Y |
00833 |
Goal Evaluation Comment |
|
18 |
250 |
CE |
O |
00834 |
Goal Life Cycle Status |
||
19 |
26 |
TS |
O |
00835 |
Goal Life Cycle Status Date/Time |
||
20 |
250 |
CE |
O |
Y |
00836 |
Goal Target Type |
|
21 |
250 |
XPN |
O |
Y |
00837 |
Goal Target Name |
The business and/or application must assume responsibility for maintaining knowledge about data ownership, versioning, and/or audit trail control (for purposes of data integrity). It is also their responsibility to represent the appropriate version of that data.
Definition:
The action code field gives the intent of the problem or goal. Refer to
HL7 table 0287 - Problem/goal action co
de
for valid values.
Value |
Description |
|---|---|
AD |
ADD |
CO |
CORRECT |
DE |
DELETE |
LI |
LINK |
UC |
UNCHANGED * |
UN |
UNLINK |
UP |
UPDATE |
* The UNCHANGED action code is used to signify to the applications programs that this particular segment includes no information to be modified. It is supplied in order to identify the correct record for which the following modification is intended.
Definition: This field contains the date/time that the operation represented by the action code 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 identifies the goal. This is the identifier from an
institution's master list of goals.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains the unique identifier assigned by an
initiating system to this instance of the goal.
Note: It is required that the value in this field be unique over time.
This instance ID identifies a specific instance for a specific patient and is
unique across all patients. See entity ID data type description in Chapter 2.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field uniquely identifies the episode of care to which this
goal applies. See note under "Ongoing issues."
Note: Based on application use, this field is required to be unique over
time.
Definition: This field prioritizes this goal on a list that is maintained for an individual.
Definition: This field identifies the date/time when the stated goal was initially created.
Definition: This field contains the projected date/time for achieving the stated goal.
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 kind of goal. This field can be used to
categorize goals so that they may be managed and viewed independently within
different applications (e.g., admission, final, post-operative, pre-operative,
outpatient, discharge, etc.).
Note: This field can be used to differentiate separate goal lists that
may be managed independently within applications.
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 category of caregiver with responsibility
for managing this specific goal (e.g., care team, nursing, medicine,
respiratory therapy, occupational therapy, dietary etc.). This is a repeating
field to allow identification of all disciplines who may have the
responsibility for this goal.
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 current point in the continuum of a goal
review cycle (e.g., due, initiated, reviewed, overdue, verified, etc.).
Definition: This field contains the date/time of the current review of the goal.
Definition: This field contains the date/time of the next scheduled goal review.
Definition: This field contains the date/time that the goal was reviewed prior to the current review.
Components:
<quantity (CQ)> ^ <interval (CM)> ^ <duration (CM)> ^
<start date/time (TS)> ^ <end date/time (TS)> ^ <priority
(ID)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction
(ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^
<total occurrences(NM)>
Definition: This field contains the interval used to calculate the next goal
review date. (See Chapter 4, Section 4.3.2, "Interval component (CM)").
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 provides an indicator of progress towards achievement
of the goal (e.g., achieved, ahead of schedule, delayed, failed to achieve,
etc.).
Definition: This field contains the comments associated with the goal evaluation. Examples of comments that might be entered in this field include: a reason for delay in achieving goal, or a clinical footnote about progress made towards the goal, etc.
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 an indication of the state of the goal (e.g.,
Active, Canceled, Inactive, Suspended, etc.).
Definition: This field contains the effective date/time of the current goal life cycle status.
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 individual/group for whom the goal has
been established (e.g., family group, family member, patient, etc.).
Note: This field is focused on a specific person/group that is directly
patient-related.
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 contains the identification of the person(s) on whom
the goal is focused. This is a repeating field which allows for the
identification of a group of individuals.
The
problem detail segment contains the data necessary to add, update, correct, and
delete the problems of a given individual.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
2 |
ID |
R |
0287 |
00816 |
Action Code |
|
2 |
26 |
TS |
R |
00817 |
Action Date/Time |
||
3 |
250 |
CE |
R |
00838 |
Problem ID |
||
4 |
60 |
EI |
R |
00839 |
Problem Instance ID |
||
5 |
60 |
EI |
O |
00820 |
Episode of Care ID |
||
6 |
60 |
NM |
O |
00841 |
Problem List Priority |
||
7 |
26 |
TS |
O |
00842 |
Problem Established Date/Time |
||
8 |
26 |
TS |
O |
00843 |
Anticipated Problem Resolution Date/Time |
||
9 |
26 |
TS |
O |
00844 |
Actual Problem Resolution Date/Time |
||
10 |
250 |
CE |
O |
00845 |
Problem Classification |
||
11 |
250 |
CE |
O |
Y |
00846 |
Problem Management Discipline |
|
12 |
250 |
CE |
O |
00847 |
Problem Persistence |
||
13 |
250 |
CE |
O |
00848 |
Problem Confirmation Status |
||
14 |
250 |
CE |
O |
00849 |
Problem Life Cycle Status |
||
15 |
26 |
TS |
O |
00850 |
Problem Life Cycle Status Date/Time |
||
16 |
26 |
TS |
O |
00851 |
Problem Date of Onset |
||
17 |
80 |
ST |
O |
00852 |
Problem Onset Text |
||
18 |
250 |
CE |
O |
00853 |
Problem Ranking |
||
19 |
250 |
CE |
O |
00854 |
Certainty of Problem |
||
20 |
5 |
NM |
O |
|
00855 |
Probability of Problem (0-1) |
|
21 |
250 |
CE |
O |
00856 |
Individual Awareness of Problem |
||
22 |
250 |
CE |
O |
00857 |
Problem Prognosis |
||
23 |
250 |
CE |
O |
00858 |
Individual Awareness of Prognosis |
||
24 |
200 |
ST |
O |
00859 |
Family/Significant Other Awareness of Problem/Prognosis |
||
25 |
250 |
CE |
O |
00823 |
Security/Sensitivity |
The business and/or application must assume the responsibility for maintaining knowledge about data ownership, versioning, and/or audit trail control (for purposes of data integrity). It is also their responsibility to represent the appropriate version of that data.
Definition: This field contains the intent of the message. Refer to HL7 table 0287 - Problem/goal action code for valid values.
Definition: This field contains the date/time that the operation represented by the action code 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 identifies the problem. This is the identifier from an
institution's master list of problems.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains the identifier assigned by an initiating
system to an instance of a problem.
Note: It is required that this value remain unique over time. This
instance ID identifies a specific instance for a specific patient and is unique
across all patients. See entity ID data type description in Chapter 2.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field uniquely identifies the episode of care to which this
problem applies. (See note under "Ongoing issues.")
Note: It is required that this field be unique over time.
Definition: This field prioritizes this problem on a list that is maintained for the individual.
Definition: This field contains the date/time when the corresponding problem was initially identified by the caregiver.
Definition: This field contains the estimated date/time for resolving the stated problem.
Definition: This field contains the date/time that the problem was actually resolved.
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 kind of problem. This field can be used
to categorize problems so that they may be managed and viewed independently
within different applications (e.g., admission, final, post-operative,
pre-operative, outpatient, discharge, etc.).
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 category of caregiver with responsibility
for managing this specific problem (e.g., care team, nursing, medicine,
respiratory therapy, occupational therapy, dietary etc.). This is a repeating
field to allow identification of all disciplines who may have the
responsibility for this problem.
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 perseverance of a problem (e.g., acute,
chronic, etc.).
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 verification status of a problem (e.g.,
confirmed, differential, provisional, rule-out, etc.).
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 current status of the problem at this
particular date/time (e.g., active, active-improving, active-stable,
active-worsening, inactive, resolved, etc.).
Definition: This field indicates the effective date/time of the current problem life cycle status.
Definition: This field contains the date/time when the problem began.
Definition: This field allows for a textual representation of the time when the problem began.
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 user-defined prioritization of a problem
(e.g., numeric ranking, or the use of words such as "primary," "secondary,"
etc.).
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 qualitative representation of the certainty
of a problem (e.g., HI - high, LO - low, ME - medium, etc.).
Definition:
This field contains a quantitative or numeric representation of the certainty
that the problem exists for this patient. This field has a valid range of 0 to
1. For example, a healthcare provider may be 75% (.75) sure that the problem
has been correctly identified.
Note: We have provided for two different representations of the
certainty of the problem due to varying representations in applications.
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 individual's comprehension of the problem
(e.g., full, marginal, partial, etc.).
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 prognosis for the individual's problem
(e.g., good, poor, etc.).
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 individual's comprehension of the
prognosis for the problem (e.g., full, marginal, partial, etc.).
Definition: This field indicates the individual's family or significant other's comprehension of the actual problem/prognosis.
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 information about the level of security and/or
sensitivity surrounding the problem (e.g., highly sensitive, not sensitive,
sensitive, etc.).
The
role segment contains the data necessary to add, update, correct, and delete
from the record persons involved, as well as their functional involvement with
the activity being transmitted.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
60 |
EI |
C |
01206 |
Role Instance ID |
||
2 |
2 |
ID |
R |
0287 |
00816 |
Action Code |
|
3 |
250 |
CE |
R |
0443 |
01197 |
Role-ROL |
|
4 |
250 |
XCN |
R |
Y |
01198 |
Role Person |
|
5 |
26 |
TS |
O |
01199 |
Role Begin Date/Time |
||
6 |
26 |
TS |
O |
01200 |
Role End Date/Time |
||
7 |
250 |
CE |
O |
01201 |
Role Duration |
||
8 |
250 |
CE |
O |
01205 |
Role Action Reason |
||
9 |
250 |
CE |
O |
Y |
* |
01510 |
Provider Type |
10 |
250 |
CE |
O |
0406 |
01461 |
Organization Unit Type |
|
11 |
250 |
XAD |
O |
Y |
00679 |
Office/Home Address |
|
12 |
250 |
XTN |
O |
Y |
00678 |
Phone |
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains a unique identifier of the specific role
record.
Conditionality Rule: This field is required when used in Patient Care
messages. The field is optional when used in ADT and Finance messages.
Definition: This field reveals the intent of the message. Refer to HL7 table 0287 - Problem/goal action code for valid values.
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 functional involvement with the activity
being transmitted (e.g., Case Manager, Evaluator, Transcriber, Nurse Care
Practitioner, Midwife, Physician Assistant, etc.). Refer to HL7 table 0443
- Provider role for valid values. When the ROL segment is used in
conjunction with the Attending, Referring, or Admitting physician in the PV1
segment, the HL7 specified table values must be used. Additional site
negotiated values are allowed.
Note: Table 0443 is intended to have the same use and values as Table
0286. The plan is to coordinate the numbering of these two tables across
chapters in the next ballot cycle.
Value |
Description |
Used with |
|---|---|---|
AD |
Admitting |
PV1-17 Admitting doctor |
AT |
Attending |
PV1-7 Attending doctor |
CP |
Consulting Provider |
|
FHCP |
Family Health Care Professional |
|
PP |
Primary Care Provider |
|
RP |
Referring Provider |
PV1-8 Referring doctor |
RT |
Referred to Provider |
*The positional location of the ROL segment in ADT and Finance messages indicates the relationship. When the segment is used following the IN3 segment, and the role-ROL value is PP or FHCP, the PP or FHCP is related to the health plan. When the segment is used following the PID segment, and the role-ROL value is PP or FHCP, the PP or FHCP is related to the person. When the segment is used following the PV2 segment, and the role-ROL value is PCP or FHCP, the PP or FHCP is related to the patient visit.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <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)>
^ <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: <namespace ID(IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the identity of the person who is assuming the
role that is being transmitted. This field correlates to STF-2 Staff ID Code
and STF-3 Staff Name.
Definition: This field contains the date/time when the role began.
Definition: This field contains the date/time when the role ended.
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 qualitative length of time for performance
of a role (e.g., until the next assessment, four days, until discharge, etc.).
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 reason why the person is assuming (or
changing) the role (e.g., shift change, new primary nurse, etc.).
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 code identifying the provider type. This
attribute correlates to one of the following master file attributes: STF-4
Staff Type, ORG-? Health Care Provider Type, or ORG-? Health Care Provider
Classification. Coded values from the correlated master file table are
used; the user defined master file table is used as the coding system for this
attribute. For example, if you are using values from STF-2 Staff Type
the coding system would be HL70182 which is the table number for the user
defined Staff Type table. This field is included in this segment to support
international requirements, and is not intended as a master file update.
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 environment in which the provider acts
in the role specified in ROL-3. The provider environment is not the specialty
for the provider. The specialty information for the provider is defined in the
PRA segment. This attribute is included in the ROL segment to allow
communication of this data when the provider information may not have been
communicated previously in a master file. This attribute correlates to the
master file attribute ORG-3 Organization unit type and references the
same table. Refer to User-defined table 0406 - Organization unit
type. This field is included in this segment to support international
requirements, and is not intended as a master file update.
Value |
Description |
|---|---|
H |
Home |
O |
Office |
1 |
Hospital |
2 |
Physician Clinic |
3 |
Long Term Care |
4 |
Acute Care |
5 |
Other |
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)>
Subcomponents of street address: <street address (ST> &
<street name (ST)> & <dwelling number (ST)>
Definition: This field contains the office address and home address of the
provider. This is a repeating field. This attribute is included in the ROL
segment to allow communication of this data when the provider information may
not have been communicated previously in a master file. This field is included
in this segment to support international requirements, and is not intended as a
master file update. This field correlates to STF-11 Office/Home Address.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^
<telecommunication use code (ID)> ^ <telecommunication equipment type
(ID)> ^ <email address (ST)> ^ <county code (NM)> ^
<area/city code (NM)> ^ <phone number (NM) ^ <extension (NM)> ^
<any text (ST)>
Definition: This field contains the provider's phone number. This attribute
is included in the ROL segment to allow communication of this data when the
provider information may not have been communicated previously in a master
file. This field is included in this segment to support international
requirements, and is not intended as a master file update. This field
correlates to STF-10 Phone.
The
pathway segment contains the data necessary to add, update, correct, and delete
from the record pathways that are utilized to address an individual's health
care.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
2 |
ID |
R |
0287 |
00816 |
Action Code |
|
2 |
250 |
CE |
R |
01207 |
Pathway ID |
||
3 |
60 |
EI |
R |
01208 |
Pathway Instance ID |
||
4 |
26 |
TS |
R |
01209 |
Pathway Established Date/Time |
||
5 |
250 |
CE |
O |
01210 |
Pathway Life Cycle Status |
||
6 |
26 |
TS |
C |
01211 |
Change Pathway Life Cycle Status Date/Time |
Definition: This field reveals the intent of the message. Refer to HL7 table 0287 - Problem/goal action code for valid values.
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 pathway master data identifier associated
with the referenced problem or goal. Examples; open heart pathway, new
diabetic, total hip replace.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains a value generated by the originating
application that represents an associated order placer group number, or other
unique identifier assigned to the grouping of pathway directives.
Note: It is required that this value remain unique over time. This
instance ID identifies a specific instance for a specific patient and is unique
across all patients. See entity ID data type description in Chapter 2.
Definition: This field contains the identification of the event time for the current pathway record.
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 an application-specific set of state
identifiers (e.g., Active, Suspended, Complete, Canceled, Delayed, Scheduled).
Definition: This field contains the date/time when pathway has been modified or deactivated. (Marked as conditional - must be filled in if trigger event is update or terminate pathway)
The
variance segment contains the data necessary to describe differences that may
have occurred at the time when a healthcare event was documented.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
60 |
EI |
R |
01212 |
Variance Instance ID |
||
2 |
26 |
TS |
R |
01213 |
Documented Date/Time |
||
3 |
26 |
TS |
O |
01214 |
Stated Variance Date/Time |
||
4 |
250 |
XCN |
O |
Y |
01215 |
Variance Originator |
|
5 |
250 |
CE |
O |
01216 |
Variance Classification |
||
6 |
512 |
ST |
O |
Y |
01217 |
Variance Description |
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains the unique identifier of the specific variance
record.
Definition: This field contains the time stamp that identifies the timed occurrence of the variance documentation.
Definition: This field contains the time stamp that identifies a stated time of the variance which may be different than the time it was documented.
Components:
In Version 2.3 and later, use instead of the CN data type. <ID number
(ST)> ^ <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)>
^ <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: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the originator (person or system) documenting
the variance.
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 categorical set of variances.
Classification may be used by applications for presentation and processing
functions.
Definition: This field specifies the details of a variance. The content of the field is a string with optional formatting.
The
following is an example of a patient goal message.
MSH|^~\&|PCIS|MEDCENTER|REPOSITORY|MEDCENTER|||PGL^PC4| <cr>
PID||0123456-1||ROBERTSON^JOHN^H|||||||9821111|<cr>
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||||ADM|A0|<cr>
GOL|AD|199505011200|00312^Improve Peripheral Circulation^Goal Master
List||||199505011200|199505101200|Due^Review Due^Next Review List||
199505021200||QAM|||ACT^Active^Kaiser Internal|199505011200| P^Patient^Kaiser
Internal||<cr>
ROL|12^Primary Nurse^Role Master List|AD|^Wilson^Jane^L^^RN|
199505011200||||<cr>
ROL|45^Recorder^Role Master
List|AD|^Smith^Ellen^^^^|199505011201||||<cr>
PRB|AD|199505011200|04411^Restricted Circulation^Nursing Problem List||
||199505011200|||IP^Inpatient^Problem Classification List|
NU^Nursing^Management Discipline List|Acute^Acute^Persistence List|
C^Confirmed^Confirmation Status List|A1^Active^Life Cycle Status List|
199505011200|199504250000||2^Secondary^Ranking List|HI^High^Certainty Coding
List||1^Fully^Awareness Coding List|2^Good^Prognosis Coding List||||
<cr>
ROL|1^Diagnosing Provider^Role Master List|AD|^Edwards^John^H^^MD|
199505011200||||<cr>
OBX|001|TX|^Peripheral Dependent Edema|1|Increasing Edema in lower
limbs|<cr>
The following is an example of a patient problem message.
MSH|^~\&|PCIS|MEDCENTER|REPOSITORY|MEDCENTER|||PPR^PC1| <cr>
PID||0123456-1||ROBERTSON^JOHN^H|||||||9821111|<cr>
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||||ADM|A0|<cr>
PRB|AD|199505011200|04411^Restricted Circulation^Nursing Problem List||
||199505011200|||IP^Inpatient^Problem Classification List|
NU^Nursing^Management Discipline List|Acute^Acute^Persistence List|
C^Confirmed^Confirmation Status List|A1^Active^Life Cycle Status List|
199505011200|199504250000||2^Secondary^Ranking List|HI^High^Certainty Coding
List||1^Fully^Awareness Coding List|2^Good^Prognosis Coding List||||
<cr>
ROL|1^Diagnosing Provider^Role Master List|AD|^Edwards^John^H^^MD|
199505011200||||<cr>
ROL|45^Recorder^Role Master
List|AD|^Smith^Ellen^^^^|199505011201||||<cr>
OBX|001|TX|^Peripheral Dependent Edema|1|Increasing Edema in lower
limbs|<cr>
GOL|AD|199505011200|00312^Improve Peripheral Circulation^Goal Master
List||||199505011200|199505101200|Due^Review Due^Next Review List||
199505021200||QAM|||ACT^Active^Kaiser Internal|199505011200| P^Patient^Kaiser
Internal||<cr>
ROL|12^Primary Nurse^Role Master List|AD|^Wilson^Jane^L^^RN|
199505011200||||<cr>
The following is an example of a patient pathway problem-oriented message.
MSH|^~\&|PCIS|MEDCENTER|REPOSITORY|MEDCENTER|||PPP^PCB| <cr>
PID||0123456-1||ROBERTSON^JOHN^H|||||||9821111|<cr>
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||||ADM|A0|<cr>
PTH|AD^^HL70287|OH457^Open Heart
Pathway^AHCPR|0018329078785^PCIS1|199505011200|A1^Active^Pathway Life Cycle
Status List|199505011200|<cr>
VAR|84032847876^PCIS1|199505011200||^Wilson^Jane^L^^RN|23^Coincident^Variance
Class List|Exceeds APACHE III threshold score.|<cr>
PRB|AD|199505011200|04411^Restricted Circulation^Nursing Problem List||
||199505011200|||IP^Inpatient^Problem Classification List|
NU^Nursing^Management Discipline List|Acute^Acute^Persistence List|
C^Confirmed^Confirmation Status List|A1^Active^Life Cycle Status List|
199505011200|199504250000||2^Secondary^Ranking List|HI^High^Certainty Coding
List||1^Fully^Awareness Coding List|2^Good^Prognosis Coding List||||
<cr>
ROL|1^Diagnosing Provider^Role Master List|AD|^Edwards^John^H^^MD|
199505011200||||<cr>
ROL|45^Recorder^Role Master
List|AD|^Smith^Ellen^^^^|199505011201||||<cr>
ORC|NW|2045^OE||||E|^C^199505011200^199505011200^^TM30^^^^|<cr>
RXO|||3|L|IV|D5W WITH 1/2 NS WITH 20 MEQ KCL EVERY THIRD BOTTLE STARTING
WITH
FIRST||W8&825&A^|N||||||||H30<cr>
ORC|NW|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|||||||<cr>
RXA|1|199505011200|||0047-0402-30^Ampicillin 250 MG
TAB^NDC|2|TAB||<cr>
The
Patient Care Technical Committee recognizes that this document contains a great
deal of information for computer systems that are currently under development.
The participating institutions/vendors will be responsible for defining the
necessary tables that have been previously discussed. As these tables are
defined and clarified, they will be included in this document for
distribution.
Applications can have differing orientations for representing problem and goal
hierarchies. For example, parent:child relationships may map problem(s) to
goal(s), or goal(s) to problem(s). To accommodate these different
orientations, the Problem message allows representation of goals that are
functionally dependent upon a problem, and the Goal message allow
representation of problems that are functionally dependent on a goal. We
recognize that institutions will decide on one or the other of the
methodologies based on practice preferences.
In
both the Problem and Goal segments a field named "Episode of Care" has been
included. This field is intended to accommodate an entity defined by consensus
business rules that defines an episode of care.
Individual businesses/applications must be cognizant of and able to handle data
integrity issues that may arise from the fact that problem lists and goal lists
may not have a single owner of record. This chapter does not address the need
for joint data ownership (of problem and goal data) between two or more
front-end clinical applications concurrently supporting patient care in
real-time. From a data integrity perspective, problem/goal data must be
sourced/originated (and thus owned) by a single application only - for example,
a front-end clinical application (source) transmitting to a back-end repository
application. This is not recognized to be within the current scope of the
Patient Care Committee; therefore, this concern will be submitted to the
Control/Query group for further debate.
The Patient Care Technical Committee will be addressing the following issues in
the future:
1. The relationship between one problem and another problem.
2. The relationships between problems, goals and related patient care events.
While not an ideal term, the word "patient" is used here to represent the entire spectrum of individuals who receive healthcare in a variety of settings including, but not limited to, acute care, clinic care, long-term care, residential care, home health care, office practices, school-based care and community settings.