12
Chapter Chair: |
Stephen Chu |
Laura Heermann Langford Intermountain Healthcare |
|
Chapter Chair: |
|
Chapter Chair: |
|
Chapter Chair: |
Michael Tan NICTIZ |
Assisstant Editor: |
|
Sponsoring Work Group |
|
List Server |
patientcare@lists.hl7.org |
The Patient Care Work Group 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.
This chapter describes a Clinical Relationship segment which enables the run-time expression of relationships between information elements both inside and, where identifiable, by the application, outside the message.
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" or update patient medical information 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.
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 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.
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.
Figure 12-1. Table of allowable trigger event types and action codes
Trigger Event Types |
Allowable Action Codes |
||
---|---|---|---|
xxx-Add |
Top level action code must be ADDDependent segment action code must be ADD (or NW for Order segments) |
||
xxx-Update |
Top level action code must be CORRECT, UPDATE, or UNCHANGEDDependent segment action codes - Any are allowed at the lower hierarchical levels |
||
xxx-Delete |
Top level action code must be DELETEDependent segments' action codes 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 Codes.
As of Version 2.9 Infrastructure and Messaging requires that Acknowledgment Choreography be explicitly specified in MSH-15 and MSH-16. Because of the nature of the Query and Response Messaging pattern, the Response message is always an Application Acknowledgment. To specify this, the value in MSH-16 SHALL always be “AL” for those messages that are Queries, to indicate that there will always be an Application Acknowledgment to the Query Message. See Chapter 2 for more details on this subject.
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 (Participation)." 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.
Segment | Cardinality | Implement | Status |
---|---|---|---|
PGL^PC6-PC8^PGL_PC6 | |||
MSH Message Header |
[1..1] | SHALL | |
ARV Access Restriction |
v2.9 | ||
SFT Software Segment |
|||
UAC User Authentication Credential Segment |
[0..1] | ||
PID Patient Identification |
[1..1] | SHALL | |
PROVIDER | [1..*] | SHALL | |
PRD Provider Data |
[1..1] | SHALL | |
CTD Contact Data |
|||
PATIENT_VISIT | [0..1] | ||
PV1 Patient Visit |
[1..1] | SHALL | |
PV2 Patient Visit - Additional Information |
[0..1] | ||
GOAL | [1..*] | SHALL | |
GOL Goal Detail |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
GOAL_PARTICIPATION | |||
ROL Role |
[1..1] | SHALL | B |
PRT Participation Information |
[1..1] | SHALL | |
VAR Variance |
|||
PATHWAY | |||
PTH Pathway |
[1..1] | SHALL | |
VAR Variance |
|||
OBSERVATION | |||
OBX Observation/Result |
[1..1] | SHALL | |
PRT Participation Information |
|||
NTE Notes and Comments |
|||
PROBLEM | |||
PRB Problem Details |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
PROBLEM_PARTICIPATION | |||
ROL Role |
[1..1] | SHALL | B |
PRT Participation Information |
[1..1] | SHALL | |
VAR Variance |
|||
PROBLEM_OBSERVATION | |||
OBX Observation/Result |
[1..1] | SHALL | |
PRT Participation Information |
|||
NTE Notes and Comments |
|||
ORDER | |||
ORC Common Order |
[1..1] | SHALL | |
ORDER_DETAIL | [0..1] | ||
CHOICE | [1..1] | SHALL | |
OBR Observation Request |
[1..1] | SHALL | |
Hxx any HL7 segment |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
ORDER_OBSERVATION | |||
OBX Observation/Result |
[1..1] | SHALL | |
PRT Participation Information |
|||
NTE Notes and Comments |
|||
VAR Variance |
MSH-15 | MSH-16 | Immediate ACK | Application Ack |
---|---|---|---|
Blank | Blank | - | ACK^PC6-PC8^ACK |
NE | NE | - | - |
AL, SU, ER | NE | ACK^PC6-PC8^ACK | - |
NE | AL, SU, ER | - | ACK^PC6-PC8^ACK |
AL, SU, ER | AL, SU, ER | ACK^PC6-PC8^ACK | ACK^PC6-PC8^ACK |
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.
Segment | Cardinality | Implement | Status |
---|---|---|---|
PPR^PC1-PC3^PPR_PC1 | |||
MSH Message Header |
[1..1] | SHALL | |
ARV Access Restriction |
v2.9 | ||
SFT Software Segment |
|||
UAC User Authentication Credential Segment |
[0..1] | ||
PID Patient Identification |
[1..1] | SHALL | |
PROVIDER | [1..*] | SHALL | |
PRD Provider Data |
[1..1] | SHALL | |
CTD Contact Data |
|||
PATIENT_VISIT | [0..1] | ||
PV1 Patient Visit |
[1..1] | SHALL | |
PV2 Patient Visit - Additional Information |
[0..1] | ||
PROBLEM | [1..*] | SHALL | |
PRB Problem Details |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
PROBLEM_PARTICIPATION | |||
ROL Role |
[1..1] | SHALL | B |
PRT Participation Information |
[1..1] | SHALL | |
VAR Variance |
|||
PATHWAY | |||
PTH Pathway |
[1..1] | SHALL | |
VAR Variance |
|||
PROBLEM_OBSERVATION | |||
OBX Observation/Result |
[1..1] | SHALL | |
PRT Participation Information |
|||
NTE Notes and Comments |
|||
GOAL | |||
GOL Goal Detail |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
GOAL_PARTICIPATION | |||
ROL Role |
[1..1] | SHALL | B |
PRT Participation Information |
[1..1] | SHALL | |
VAR Variance |
|||
GOAL_OBSERVATION | |||
OBX Observation/Result |
[1..1] | SHALL | |
PRT Participation Information |
|||
NTE Notes and Comments |
|||
ORDER | |||
ORC Common Order |
[1..1] | SHALL | |
ORDER_DETAIL | [0..1] | ||
CHOICE | [1..1] | SHALL | |
OBR Observation Request |
[1..1] | SHALL | |
Hxx any HL7 segment |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
ORDER_OBSERVATION | |||
OBX Observation/Result |
[1..1] | SHALL | |
PRT Participation Information |
|||
NTE Notes and Comments |
|||
VAR Variance |
MSH-15 | MSH-16 | Immediate ACK | Application Ack |
---|---|---|---|
Blank | Blank | - | ACK^PC1-PC3^ACK |
NE | NE | - | - |
AL, SU, ER | NE | ACK^PC1-PC3^ACK | - |
NE | AL, SU, ER | - | ACK^PC1-PC3^ACK |
AL, SU, ER | AL, SU, ER | ACK^PC1-PC3^ACK | ACK^PC1-PC3^ACK |
This error segment indicates the fields that caused a transaction to be rejected.
Segment | Cardinality | Implement | Status |
---|---|---|---|
PPP^PCB-PCD^PPP_PCB | |||
MSH Message Header |
[1..1] | SHALL | |
ARV Access Restriction |
v2.9 | ||
SFT Software Segment |
|||
UAC User Authentication Credential Segment |
[0..1] | ||
PID Patient Identification |
[1..1] | SHALL | |
PROVIDER | [1..*] | SHALL | |
PRD Provider Data |
[1..1] | SHALL | |
CTD Contact Data |
|||
PATIENT_VISIT | [0..1] | ||
PV1 Patient Visit |
[1..1] | SHALL | |
PV2 Patient Visit - Additional Information |
[0..1] | ||
PATHWAY | [1..*] | SHALL | |
PTH Pathway |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
PATHWAY_PARTICIPATION | |||
ROL Role |
[1..1] | SHALL | B |
PRT Participation Information |
[1..1] | SHALL | |
VAR Variance |
|||
PROBLEM | |||
PRB Problem Details |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
PROBLEM_PARTICIPATION | |||
ROL Role |
[1..1] | SHALL | B |
PRT Participation Information |
[1..1] | SHALL | |
VAR Variance |
|||
PROBLEM_OBSERVATION | |||
OBX Observation/Result |
[1..1] | SHALL | |
PRT Participation Information |
|||
NTE Notes and Comments |
|||
GOAL | |||
GOL Goal Detail |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
GOAL_PARTICIPATION | |||
ROL Role |
[1..1] | SHALL | B |
PRT Participation Information |
[1..1] | SHALL | |
VAR Variance |
|||
GOAL_OBSERVATION | |||
OBX Observation/Result |
[1..1] | SHALL | |
PRT Participation Information |
|||
NTE Notes and Comments |
|||
ORDER | |||
ORC Common Order |
[1..1] | SHALL | |
ORDER_DETAIL | [0..1] | ||
CHOICE | [1..1] | SHALL | |
OBR Observation Request |
[1..1] | SHALL | |
Hxx any HL7 segment |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
ORDER_OBSERVATION | |||
OBX Observation/Result |
[1..1] | SHALL | |
PRT Participation Information |
|||
NTE Notes and Comments |
|||
VAR Variance |
MSH-15 | MSH-16 | Immediate ACK | Application Ack |
---|---|---|---|
Blank | Blank | - | ACK^PCB-PCD^ACK |
NE | NE | - | - |
AL, SU, ER | NE | ACK^PCB-PCD^ACK | - |
NE | AL, SU, ER | - | ACK^PCB-PCD^ACK |
AL, SU, ER | AL, SU, ER | ACK^PCB-PCD^ACK | ACK^PCB-PCD^ACK |
Segment | Cardinality | Implement | Status |
---|---|---|---|
PPG^PCG,PCH,PCJ^PPG_PCG | |||
MSH Message Header |
[1..1] | SHALL | |
ARV Access Restriction |
v2.9 | ||
SFT Software Segment |
|||
UAC User Authentication Credential Segment |
[0..1] | ||
PID Patient Identification |
[1..1] | SHALL | |
PROVIDER | [1..*] | SHALL | |
PRD Provider Data |
[1..1] | SHALL | |
CTD Contact Data |
|||
PATIENT_VISIT | [0..1] | ||
PV1 Patient Visit |
[1..1] | SHALL | |
PV2 Patient Visit - Additional Information |
[0..1] | ||
PATHWAY | [1..*] | SHALL | |
PTH Pathway |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
PATHWAY_PARTICIPATION | |||
ROL Role |
[1..1] | SHALL | B |
PRT Participation Information |
[1..1] | SHALL | |
VAR Variance |
|||
GOAL | |||
GOL Goal Detail |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
GOAL_PARTICIPATION | |||
ROL Role |
[1..1] | SHALL | B |
PRT Participation Information |
[1..1] | SHALL | |
VAR Variance |
|||
GOAL_OBSERVATION | |||
OBX Observation/Result |
[1..1] | SHALL | |
PRT Participation Information |
|||
NTE Notes and Comments |
|||
PROBLEM | |||
PRB Problem Details |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
PROBLEM_PARTICIPATION | |||
ROL Role |
[1..1] | SHALL | B |
PRT Participation Information |
[1..1] | SHALL | |
VAR Variance |
|||
PROBLEM_OBSERVATION | |||
OBX Observation/Result |
[1..1] | SHALL | |
PRT Participation Information |
|||
NTE Notes and Comments |
|||
ORDER | |||
ORC Common Order |
[1..1] | SHALL | |
ORDER_DETAIL | [0..1] | ||
CHOICE | [1..1] | SHALL | |
OBR Observation Request |
[1..1] | SHALL | |
Hxx any HL7 segment |
[1..1] | SHALL | |
NTE Notes and Comments |
|||
VAR Variance |
|||
ORDER_OBSERVATION | |||
OBX Observation/Result |
[1..1] | SHALL | |
PRT Participation Information |
|||
NTE Notes and Comments |
|||
VAR Variance |
MSH-15 | MSH-16 | Immediate ACK | Application Ack |
---|---|---|---|
Blank | Blank | - | ACK^PCG,PCH,PCJ^ACK |
NE | NE | - | - |
AL, SU, ER | NE | ACK^PCG,PCH,PCJ^ACK | - |
NE | AL, SU, ER | - | ACK^PCG,PCH,PCJ^ACK |
AL, SU, ER | AL, SU, ER | ACK^PCG,PCH,PCJ^ACK | ACK^PCG,PCH,PCJ^ACK |
Retained for backwards compatibility only as of version 2.4 and removed from the standard as of v2.8; refer to Chapter 5, section 5.4. The original mode query and the QRD/QRF segments have been replaced.
Retained for backwards compatibility only as of version 2.4 and removed from the standard as of v2.8; refer to Chapter 5, section 5.4. The original mode query and the QRD/QRF segments have been replaced.
Retained for backwards compatibility only as of version 2.4 and removed from the standard as of v2.8; refer to Chapter 5, section 5.4. The original mode query and the QRD/QRF segments have been replaced.
Retained for backwards compatibility only in version 2.4 and removed from the standard as of v2.8; refer to Chapter 5, section 5.4. The original mode query and the QRD/QRF segments have been replaced.
Retained for backwards compatibility only in version 2.4 and removed from the standard as of v2.8; refer to Chapter 5, section 5.4. The original mode query and the QRD/QRF segments have been replaced.
Retained for backwards compatibility only in version 2.4 and removed from the standard as of v2.8; refer to Chapter 5, section 5.4. The original mode query and the QRD/QRF segments have been replaced.
Retained for backwards compatibility only in version 2.4 and removed from the standard as of v2.8; refer to Chapter 5, section 5.4. The original mode query and the QRD/QRF segments have been replaced.
Retained for backwards compatibility only in version 2.4 and removed from the standard as of v2.8; refer to Chapter 5, section 5.4. The original mode query and the QRD/QRF segments have been replaced.
The following is an example of a patient goal message.
MSH|^~\&|SENDAP|SENDFAC|RECAP|RECFAC|||PGL^PC4|
PID||0123456-1||EVERYMAN^ADAM^A|||||||9821111|
PV1|1|I|2000^2012^01||||004777^ATTEND^AARON^A.|||SUR||||ADM|A0|
GOL|AD|199505011200|00312^Improve Peripheral Circulation^Goal Master List||||199505011200|199505101200|Due^Review Due^Next Review List|||199505021200||QAM|||ACT^Active^Level Seven Healthcare, Inc. Internal|199505011200| P^Patient^Level Seven Healthcare, Inc. Internal||
PRT||AD||AT^Attending Provider^HL70912|^Admit^Alan^A^^RN||||||199505011200
PRT||AD||EP^Entering Provider^HL70912|^Admit^Alan^A^^RN||||||199505011200
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||||
PRT||AD||AT^Attending Provider^HL70912|^Admit^Alan^A^^RN||||||199505011200
OBX|001|TX|^Peripheral Dependent Edema|1|Increasing Edema in lower limbs|
The following is an example of a patient problem message.
MSH|^~\&|SENDAP|SENDFAC|RECAP|RECFAC|||PPR^PC1|
PID||0123456-1||EVERYMAN^ADAM^A|||||||9821111|
PV1|1|I|2000^2012^01||||004777^ATTEND^AARON^A.|||SUR||||ADM|A0|
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||||
PRT||AD||AT^Attending Provider^HL70912|^Admit^Alan^A^^RN||||||199505011200
PRT||AD||EP^Entering Provider^HL70912|^Admit^Alan^A^^RN||||||199505011200
OBX|001|TX|^Peripheral Dependent Edema|1|Increasing Edema in lower limbs|
GOL|AD|199505011200|00312^Improve Peripheral Circulation^Goal Master List||||199505011200|199505101200|Due^Review Due^Next Review List|| 199505021200||QAM|||ACT^Active^ Level Seven Healthcare, Inc. Internal|199505011200| P^Patient^Level Seven Healthcare, Inc.||
PRT||AD||AT^Attending Provider^HL70912|^Admit^Alan^A^^RN||||||199505011200
The following is an example of a patient pathway problem-oriented message.
MSH|^~\&|SENDAP|SENDFAC|RECAP|RECFAC|||PPP^PCB|
PID||0123456-1||EVERYMAN^ADAM^A|||||||9821111|
PV1|1|I|2000^2012^01||||004777^ATTEND^AARON^A.|||SUR||||ADM|A0|
PTH|AD^^HL70287|OH457^Open Heart Pathway^AHCPR|0018329078785^PCIS1|199505011200|A1^Active^Pathway Life Cycle Status List|199505011200|
VAR|84032847876^LOCK|199505011200||^Verify^Virgil^V^^RN|23^Coincident^Variance Class List|Exceeds APACHE III threshold score.|
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||||
PRT||AD||AT^Attending Provider^HL70912|^Admit^Alan^A^^RN||||||199505011200
PRT||AD||EP^Entering Provider^HL70912|^Admit^Alan^A^^RN||||||199505011200
ORC|NW|2045^OE||||E|^C^199505011200^199505011200^^TM30^^^^|
RXO|||3|L|IV|D5W WITH 1/2 NS WITH 20 MEQ KCL EVERY THIRD BOTTLE STARTING WITH
FIRST||W8&825&A^|N||||||||H30
ORC|NW|1000^OE|9999999^RX|||E|^Q6H^D10^^^R|||||||
RXA|1|199505011200|||0047-0402-30^Ampicillin 250 MG TAB^NDC|2|TAB||
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 allows 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 Infrastructure & Messaging committee for further debate.