visit the hl7 website The Demo site for our new HL7 Version 2+ (plus) Standard

24.8.1 Patient Referral (99.1.10)

25 .Patient Referral (11)

11

Stephen Chu

Michelle Miller Cerner Corporation

Michael Padula Children’s Hospital of Philadelphia

Patient Care

patientcare@lists.hl7.org

Chapter Chair:

Chapter Chair:

Laura Heermann Langford Intermountain Healthcare

Chapter Chair:

Emma Jones Allscripts

Chapter Chair:

Jay Lyle

Chapter Chair:

Chapter Chair:

Chapter Chair:

Michael Tan NICTIZ

Chapter Editor:

Amit Popat Epic

Assisstant Editor:

Daniel Rutz Epic

Sponsoring Work Group

List Server

25.1 CHAPTER 11 CONTENTS (11.1)

25.2 PURPOSE (11.2)

The Patient Referral chapter defines the message set used in patient referral communications between mutually exclusive healthcare entities. These referral transactions frequently occur between entities with different methods and systems of capturing and storing data. Such transactions frequently traverse a path connecting primary care providers, specialists, payors, government agencies, hospitals, labs, and other healthcare entities. The availability, completeness, and currency of information for a given patient will vary greatly across such a spectrum.

The referral in this specification is viewed from the perspective of the provider as an individual, irrespective of his/her affiliation with a specific institution or campus. Events triggering this kind of message are not restricted to a hospital environment, but have a community-wide area of impact in which more extensive identification of patients and healthcare providers is needed. Therefore, a referral must contain adequate identification information to meet the broadly varying requirements of the dissimilar systems within the community.

This chapter describes the various events and resulting transactions that make up the referral message set. Examples have been provided to demonstrate the use of this specification within the events described. Each event example centers on a primary care provider's encounter with a patient. All of the examples in this chapter have been constructed using the HL7 Encoding Rules.

25.2.1 Patient Referral and Responses (11.2.1)

When a patient is referred by one healthcare entity (e.g., a primary care provider) to another (e.g., a specialist or lab) or when a patient inquiry is made between two separate entities, little is known about the information each party requires to identify or codify the patient. The receiving entity may have no knowledge of the patient and may require a full set of demographics, subscriber and billing information, eligibility/coverage information, pre-authorization information, and/or clinical data to process the referral. If the receiving entity already has a record of the patient, the precise requirements for identifying that patient record will vary greatly from one entity to another. The existing record of a patient residing in the database of a specialist, a lab, or a hospital may require updating with more current information. In addition, providers receiving a referral often require detailed information about the provider making the referral, such as a physician's name and address.

For example, a primary care provider making a referral may need to obtain insurance information or pre-authorization from a payor prior to making a referral. Getting this information requires an inquiry and a response between the primary care provider and the payor. In addition, the primary care provider may request results from a lab to accompany the referral. Getting these results may require an inquiry and a response between the primary care provider and the lab. The information could then be incorporated into a referral sent from the primary care provider to the specialist. As the referral is processed, requested procedures are performed, the results are observed, and the relevant data must be returned to the primary care provider. Such a response may frequently take the form of multiple responses as results become available.

The message set that encompasses these transactions includes the referral (REF), requests for information (RQA, RQC, RQP, RQI) and the returned patient information (RCI, RCL, RPA, RPI, RPL, RRI). The referral message originates a transaction and a return patient information message concludes the transaction. At least one RPA/RPI is required to complete a patient referral or a patient request transaction, although multiple RPI messages may be returned in response to a single REF message. The segments used in the REF, RQA, RQI, RQP, RRI, RPH, RCI, RCL, RPA and RPI messages encompass information about patient, guarantor and next of kin demographics, eligibility/coverage information, accident, diagnosis, requested procedures, payor pre-authorization, notes, and referring and consulting provider data.

25.2.1.1 Patient referral (11.2.1.0)

There are clear distinctions between a referral and an order. An order is almost always an intra-enterprise transaction and represents a request from a patient's active provider to supporting providers for clearly defined services and/or results. While the supporting provider may exercise great discretion in the performance of an order, overall responsibility for the patient's plan of treatment remains with the ordering provider. As such, the ordering provider retains significant control authority for the order and can, after the fact, cause the order to be canceled, reinstated, etc. Additionally, detailed results produced by the supporting provider are always reported back to the ordering provider, who remains ultimately responsible for evaluating their value and relevance. A referral, on the other hand, can be either an intra- or an inter-enterprise transaction and represents not only a request for additional provider support but also a transfer of a portion or all of the responsibility for the patient's plan of treatment. Once the referral is made, the referring provider, during the transfer period, retains almost no control of any resulting actions. The referred-to provider becomes responsible for placing any additional orders and for evaluating the value and relevance of any results, which may or may not be automatically passed back to the referring provider. A referred-to provider may, in turn, also become a referring provider.

A referral message is used to support transactions related to the referral of a patient from one healthcare provider to another. This kind of message will be particularly useful from the perspective of a primary care provider referring a patient to a specialist. However, the application of the message should not be limited to this model. For example, a referral may be as simple as a physician sending a patient to another physician for a consultation or it may be as complex as a primary care provider sending a patient to a specialist for specific medical procedures to be performed and attaching the payor authorizations for those requested procedures as well as the relevant clinical information on the patient's case.

In a community model, stringent security requirements will need to be met when dealing with the release of clinical information. This message set facilitates the proper qualification of requests because the message packet will contain all the data required by any application in the community, including the necessary patient demographic information and the proper identification of the party requesting the information.

25.2.1.2 Responding to a patient referral (11.2.1.1)

When a patient is referred by one provider to another or is pre-admitted, there is a great likelihood that subsequent transactions will take place between the initiating entity (the referring or admitting physician) and the responding entity (the specialist or hospital). The subsequent transactions might include a variety of queries, orders, etc. Within those subsequent transactions, there must be a way for the initiating system to refer to the patient. The "generic" patient information included in the original referral or the pre-admit Patient Identification (PID) segment may not be detailed enough to locate the patient in the responding facility's database, unless the responding facility has assigned a unique identifier to the new patient. Similarly, the responding system may not have record retrieval capabilities based on any of the unambiguous, facility-neutral data elements (like the Social Security Number) included in the original referral or pre-admit PID segment. This problem could result in the responding system associating subsequent orders or requests with the wrong patient. One solution to this potential problem is for the responding system to utilize the RRI message and return to the initiating system the unique internal identifier it assigns to the patient, and with which it will primarily (or even exclusively) refer to that patient in all subsequent update operations. However, the intent of the RRI message is that it will supply the originator of the referral type message with sufficient patient demographic and/or clinical information to properly process continued transactions.

25.2.1.3 Communicating Collaborative Care of a Patient (11.2.1.2)

When providers collaborate in the sharing of patient care there can be many types of communications involved, and the expectations, roles and responsibilities may not always be clear and explicit; they may vary in different jurisdictions or work practice environments.

The use of HL7 Version 2.x in clinical messaging has involved the use of segments in ways for which they were not originally intended, as well as the development of the REL segment to express important relationships between clinical data components. Such use has also necessitated the introduction of mood codes to allow for the richer representation of intent, purpose, timing, and other event contingencies that such concepts required. When these extensions are applied to segments in messages which predate them there is the risk that a message generated by a system compliant with an earlier release could be misinterpreted by a system which interprets the segments in the wider context. The approach to this has been to constrain the use of the enhancements to these segments to new messages, or to newer versions of existing messages. The REF message has been in releases which pre-date the v2.6 clinical enhancements and its limitations in this regard, together with the need for a range of new Collaborative Care interactions, have led to the need for the Collaborative Care Message. Being developed to use the clinical v2.6 enhancements from the outset, the collaborative care messages do not need these versioning constraints around their use.

25.2.2 Application Roles and Data Process (11.2.2)

25.2.2.1 hiddentext (11.2.2.0)

25.2.2.2 Application roles (11.2.2.1)

This Standard assumes that there are four roles that an application can take on: a referring or referred-by provider application role, a referred-to provider application role, a querying application role, and an auxiliary application role. These application roles define the interactions an application will have with other applications in the messaging environment. In many environments, any single application may take on more than one application role.

This Standard's definition of application roles does not intend to define or limit the functionality of specific products developed by vendors of such applications. Instead, this information is provided to help define the model used to develop this Standard, and to provide an unambiguous way for applications to communicate with each other.

25.2.2.3 The referring provider application role (11.2.2.2)

A referring provider application requests the services of another healthcare provider (a referred-to provider) application. There may or may not be any association between the referring provider application and the receiving entity. Although in most cases a referral environment will be inter-enterprise in nature, it is not limited to that model and applies to intra-enterprise situations also. Because the referring provider application cannot exert any control over the referred-to provider application, it must send requests to modify the status of the referred-to provider application. The referring provider application will often assume an auxiliary application role once a patient has been accepted by another application. Once this happens, the referring provider application may receive unsolicited status updates from the referred-to provider application concerning the care of a patient.

The analog of a referring provider application in a non-automated environment might be a primary care provider diagnosing a patient with a problem that must in turn be referred to a specialist for a service. The primary care provider would contact the specialist and refer the patient into his care. Often, the specialist may not receive the patient into his care, preferring instead to refer the patient to another healthcare provider. The referring provider will indicate the diagnosis and any requested services, and the specialist to whom the patient is referred will indicate whether the referral will be accepted as specified. Once a patient referral has been accepted by the specialist, the specialist may send out updates to the primary care provider concerning the status of the patient as regards any tests performed, their outcomes, etc.

25.2.2.4 The referred-to provider application role (11.2.2.3)

A referred-to provider application, in the referral model, is one that performs one or more services requested by another healthcare provider (referring provider). In other words, a referred-to provider application exerts control over a certain set of services and defines the availability of those services. Because of this control, no other application has the ability to accept, reject, or otherwise modify a referral accepted by a particular referred-to provider application.

Other applications can, on the other hand, make requests to modify the status of an accepted referral "owned by" the referred-to provider application. The referred-to provider application either grants or denies requests for information, or otherwise modifies the referrals for the services over which it exerts control.

Finally, the referred-to provider application also provides information about the referral encounter to other applications. The reasons that an application may be interested in receiving such information are varied. An application may have previously requested the status of the referral encounter, or it may simply be interested in the information for its own clinical reporting or statistical purposes. There are two methods whereby the referred-to provider applications disseminate this information: by issuing unsolicited information messages to auxiliary applications, or by responding to queries made by querying applications.

The analog of a referred-to provider application in a non-automated environment might be a specialist such as a cardiologist. A patient does not generally go to a cardiologist for routine health care. Instead, a patient generally goes to a primary care provider, who may diagnose the patient with a heart ailment and refer that patient to a cardiologist. The cardiologist would review the information provided with the referral request and determine whether or not to accept the patient into his care. Once the cardiologist accepts the patient, anyone needing information on the status of the patient must then make requests to the cardiologist. In addition, the cardiologist may forward unsolicited information regarding the treatment of the patient back to the primary care provider. Once the cardiologist accepts the referred patient, he/she may determine that additional information regarding the patient is needed. It will often take the role of a querying application by sending a query message to the patient's primary care provider and requesting additional information on demographics, insurance information, laboratory test results, etc.

25.2.2.5 The querying application role (11.2.2.4)

A querying application neither exerts control over, nor requests changes to a referral. Rather than accepting unsolicited information about referrals, as does an auxiliary application, the querying application actively solicits this information using a query mechanism. It will, in general, be driven by an entity seeking information about a referral such as a referring provider application or an entity seeking information about a referred patient such as a referred-to provider application. The information that the querying application receives is valid only at the exact time that the query results are generated by the provider applications. Changes made to the referral or the referred patient's status after the query results have been returned are not communicated to the querying application until it issues another query transaction.

The analog of a querying application in a non-automated environment might be a primary care provider seeking information about a specific patient who has been referred to a specialist. For example, a patient may have been referred to a specialist in order that a specific test be performed, following which, the patient would return to the primary care provider. If the specialist has not forwarded information regarding the testing procedures for the patient to the primary care provider, the primary care provider would then query the specialist for the outcome of those procedures. Likewise, if a specialist received a referred patient without the preliminary diagnoses of test results, he/she might in turn query the primary care provider for the information leading to the diagnoses and subsequent referral.

25.2.2.6 The auxiliary application role (11.2.2.5)

Like querying applications, an auxiliary application neither exerts control over nor requests changes to a referral or a referred patient. They, too, are only concerned with gathering information about a particular referral. An auxiliary application is considered an "interested third-party," in that it is interested in any changes to a particular referral or referred patient, but has no interest in changing it or controlling it in any way. An auxiliary application passively collects information by receiving unsolicited updates from a provider application.

The analog of an auxiliary application in a non-automated environment might be any person receiving reports containing referral information. For example, an insurance company may need information about the activities a patient experiences during specific referral encounters. Primary care providers may need to forward information regarding all referred patients to a payor organization.

In turn, a primary care provider may have the ability to track electronically a patient's medical record. The provider would then be very interested in receiving any information regarding a patient referred to a specialist.

25.2.2.7 Application roles in a messaging environment (11.2.2.6)

In a messaging environment, these four application roles communicate using specific kinds of messages and trigger events. The following figure illustrates the relationships between these application roles in a messaging environment:

Figure 11-1. Application role messaging relationships

25.2.3 Acknowledgment Choreography (11.2.3)

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.

25.2.4 Glossary (11.2.4)

25.2.4.1 Benefits: (11.2.4.0)

The services payable under a specific payor plan. They are also referred to as an insurance product, such as professional services, prescription drugs, etc.

25.2.4.2 Clinical information: (11.2.4.1)

Refers to the data contained in the patient record. The data may include such things as problem lists, lab results, current medications, family history, etc. For the purposes of this chapter, clinical information is limited to diagnoses (DG1& DRG), results reported (OBX/OBR), and allergies (AL1).

25.2.4.3 Dependent: (11.2.4.2)

Refers to a person who is affiliated with a subscriber, such as spouse or child.

25.2.4.4 Eligibility/coverage: (11.2.4.3)

Refers to the period of time a subscriber or dependent is entitled to benefits.

25.2.4.5 Encounter: (11.2.4.4)

Refers to a meeting between a covered person and a healthcare provider whose services are provided.

25.2.4.6 Guarantor: (11.2.4.5)

Refers to a person who has financial responsibility for the payment of a patient account.

25.2.4.7 Healthcare provider: (11.2.4.6)

Refers to a person licensed, certified or otherwise authorized or permitted by law to administer health care in the ordinary course of business or practice of a profession, including a healthcare facility.

25.2.4.8 Payor: (11.2.4.7)

Indicates a third-party entity that pays for or underwrites coverage for healthcare expenses. A payor may be an insurance company, a health maintenance organization (HMO), a preferred provider organization (PPO), a government agency or an agency such as a third-party administrator (TPA).

25.2.4.9 Pre-authorization: (11.2.4.8)

Refers to the process of obtaining prior approval as to the appropriateness of a service. Pre-authorization does not guarantee coverage.

25.2.4.10 Primary care provider: (11.2.4.9)

Indicates the provider responsible for delivering care as well as authorizing and channeling care to specialists and other providers in a gatekeeper system. The provider is also referred to as a case manager or a gatekeeper.

25.2.4.11 Referral: (11.2.4.10)

Means a provider's recommendation that a covered person receive care from a different provider.

25.2.4.12 Referring provider: (11.2.4.11)

Indicates the provider who requests services from a specialist or another primary care provider. A referring provider may, in fact, be a specialist who is referring a patient to another specialist.

25.2.4.13 Referred-to-provider: (11.2.4.12)

Typically indicates a specialty care provider who provides services at the request of a primary care provider or another specialty care provider.

25.2.4.14 Specialist: (11.2.4.13)

Means a provider of services which are beyond the capabilities or resources of the primary care provider. A specialist is also known as a specialty care provider who provides services at the request of a primary care provider or another specialty care provider.

25.2.4.15 Subscriber: (11.2.4.14)

Refers to a person who elects benefits and is affiliated with an employer or insurer.

25.3 PATIENT INFORMATION REQUEST MESSAGES AND TRIGGER EVENTS (11.3)

Patient information may need to be retrieved from various enterprises. The definition of these enterprises often varies greatly. Some enterprises may be providers or reference laboratories, while others may be payors providing insurance information. In the first case, the message definitions will focus on patient and provider information, while in the latter case, the message definition will deal primarily with patient and subscriber identification.

25.3.1 RQI/RPI - Request for Insurance Information (Event I01) (11.3.1)

This event triggers a message to be sent from one healthcare provider to another to request insurance information for a specified patient.

Segment Cardinality Implement Status
RQI^I01^RQI_I01
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
PROVIDER [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PID

Patient Identification

[1..1] SHALL
NK1

Next of Kin / Associated Parties

 
GUARANTOR_INSURANCE [0..1]  
GT1

Guarantor

 
INSURANCE [1..*] SHALL
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
NTE

Notes and Comments

 

 

RQI_I01

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - ACK^I07^ACK
Blank Blank - RPR^I03^RPR_I03
Blank Blank - RPL^I02^RPL_I02
Blank Blank - RPI^I01^RPI_I01
NE NE - -
NE AL - RPR^I03^RPR_I03
NE AL - RPL^I02^RPL_I02
NE AL - RPI^I01^RPI_I01
AL NE ACK^I07^ACK -
AL, SU, ER AL ACK^I03^ACK RPR^I03^RPR_I03
AL, SU, ER AL ACK^I02^ACK RPL^I02^RPL_I02
AL, SU, ER AL ACK^I01^ACK RPI^I01^RPI_I01
We need some ER7 examples...
We need some XML examples...
Segment Cardinality Implement Status
RPI^I01^RPI_I01
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
MSA

Message Acknowledgment

[1..1] SHALL
PROVIDER [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PID

Patient Identification

[1..1] SHALL
NK1

Next of Kin / Associated Parties

 
GUARANTOR_INSURANCE [0..1]  
GT1

Guarantor

 
INSURANCE [1..*] SHALL
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
NTE

Notes and Comments

 

 

RPI_I01

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - -
NE NE - -
AL, SU, ER NE ACK^I02^ACK -
We need some ER7 examples...
We need some XML examples...

25.3.2 RQI/RPL - Request/Receipt of Patient Selection Display List (Event I02) (11.3.2)

This trigger event occurs when the inquirer specifies a request for a name lookup listing. Generally, this request is used by the responder when insufficient data is on hand for a positive match. In this case, the requester may ask for a list of possible candidates from which to make a selection. This event code is also used by the responder to signify that the return information contains a list of information rather than information specific to a single patient.

Segment Cardinality Implement Status
RQI^I02^RQI_I01
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
PROVIDER [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PID

Patient Identification

[1..1] SHALL
NK1

Next of Kin / Associated Parties

 
GUARANTOR_INSURANCE [0..1]  
GT1

Guarantor

 
INSURANCE [1..*] SHALL
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
NTE

Notes and Comments

 

 

RQI_I01

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - ACK^I07^ACK
Blank Blank - RPR^I03^RPR_I03
Blank Blank - RPL^I02^RPL_I02
Blank Blank - RPI^I01^RPI_I01
NE NE - -
NE AL - RPR^I03^RPR_I03
NE AL - RPL^I02^RPL_I02
NE AL - RPI^I01^RPI_I01
AL NE ACK^I07^ACK -
AL, SU, ER AL ACK^I03^ACK RPR^I03^RPR_I03
AL, SU, ER AL ACK^I02^ACK RPL^I02^RPL_I02
AL, SU, ER AL ACK^I01^ACK RPI^I01^RPI_I01
We need some ER7 examples...
We need some XML examples...
Segment Cardinality Implement Status
RPL^I02^RPL_I02
MSH

Message Header

[1..1] SHALL
SFT

Software Segment

 
MSA

Message Acknowledgment

[1..1] SHALL
PROVIDER [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
NTE

Notes and Comments

 
DSP

Display Data

 
DSC

Continuation Pointer

[0..1]  

 

RPL_I02

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - -
NE NE - -
AL, SU, ER NE ACK^I02^ACK -
We need some ER7 examples...
We need some XML examples...

25.3.3 RQI/RPR - Request/Receipt of Patient Selection List (Event I03) (11.3.3)

This trigger event occurs when the inquirer specifies a request for a listing of patient names. This event differs from event I02 (request/receipts of patient selection display list) in that it returns the patient list in repeating PID segments instead of repeating DSP segments.

Segment Cardinality Implement Status
RQI^I03^RQI_I01
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
PROVIDER [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PID

Patient Identification

[1..1] SHALL
NK1

Next of Kin / Associated Parties

 
GUARANTOR_INSURANCE [0..1]  
GT1

Guarantor

 
INSURANCE [1..*] SHALL
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
NTE

Notes and Comments

 

 

RQI_I01

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - ACK^I07^ACK
Blank Blank - RPR^I03^RPR_I03
Blank Blank - RPL^I02^RPL_I02
Blank Blank - RPI^I01^RPI_I01
NE NE - -
NE AL - RPR^I03^RPR_I03
NE AL - RPL^I02^RPL_I02
NE AL - RPI^I01^RPI_I01
AL NE ACK^I07^ACK -
AL, SU, ER AL ACK^I03^ACK RPR^I03^RPR_I03
AL, SU, ER AL ACK^I02^ACK RPL^I02^RPL_I02
AL, SU, ER AL ACK^I01^ACK RPI^I01^RPI_I01
We need some ER7 examples...
We need some XML examples...
Segment Cardinality Implement Status
RPR^I03^RPR_I03
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
MSA

Message Acknowledgment

[1..1] SHALL
PROVIDER [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PID

Patient Identification

 
NTE

Notes and Comments

 

 

RPR_I03

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - -
NE NE - -
AL, SU, ER NE ACK^I03^ACK -
We need some ER7 examples...
We need some XML examples...

25.3.4 RQP/RPI - request for patient demographic data (Event I04) (11.3.4)

This event triggers a request from one healthcare provider to another for patient demographic information, including insurance and billing information. Typically, this transaction would occur between one provider to another, but it could also be directed to a payor.

Segment Cardinality Implement Status
RQP^I04^RQP_I04
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
PROVIDER [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PID

Patient Identification

[1..1] SHALL
NK1

Next of Kin / Associated Parties

 
GT1

Guarantor

 
NTE

Notes and Comments

 

 

RQP_I04

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - RPI^I04^RPI_I04
NE AL - RPI^I04^RPI_I04
AL, SU, ER AL ACK^I04^ACK RPI^I04^RPI_I04
We need some ER7 examples...
We need some XML examples...
Segment Cardinality Implement Status
RPI^I04^RPI_I04
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
MSA

Message Acknowledgment

[1..1] SHALL
PROVIDER [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PID

Patient Identification

[1..1] SHALL
NK1

Next of Kin / Associated Parties

 
GUARANTOR_INSURANCE [0..1]  
GT1

Guarantor

 
INSURANCE [1..*] SHALL
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
NTE

Notes and Comments

 

 

RPI_I04

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - -
NE NE - -
AL, SU, ER NE ACK^I04^ACK -
We need some ER7 examples...
We need some XML examples...

25.3.5 RQC/RCI - Request for Patient Clinical Information (Event I05) (11.3.5)

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, "Query Response Message Pairs." The original mode query and the QRD/QRF segments have been replaced.

25.3.6 RQC/RCL - Request/Receipt of Clinical Data Listing (Event I06) (11.3.6)

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, "Query Response Message Pairs." The original mode query and the QRD/QRF segments have been replaced.

25.3.7 PIN/ACK - Unsolicited Insurance Information (Event I07) (11.3.7)

This trigger event is used by an entity or organization to transmit to a healthcare provider the insurance information on a specific patient. Typically, the healthcare provider will be a primary care provider.

Segment Cardinality Implement Status
PIN^I07^RQI_I01
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
PROVIDER [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PID

Patient Identification

[1..1] SHALL
NK1

Next of Kin / Associated Parties

 
GUARANTOR_INSURANCE [0..1]  
GT1

Guarantor

 
INSURANCE [1..*] SHALL
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
NTE

Notes and Comments

 

 

RQI_I01

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - ACK^I07^ACK
Blank Blank - RPR^I03^RPR_I03
Blank Blank - RPL^I02^RPL_I02
Blank Blank - RPI^I01^RPI_I01
NE NE - -
NE AL - RPR^I03^RPR_I03
NE AL - RPL^I02^RPL_I02
NE AL - RPI^I01^RPI_I01
AL NE ACK^I07^ACK -
AL, SU, ER AL ACK^I03^ACK RPR^I03^RPR_I03
AL, SU, ER AL ACK^I02^ACK RPL^I02^RPL_I02
AL, SU, ER AL ACK^I01^ACK RPI^I01^RPI_I01
We need some ER7 examples...
We need some XML examples...
Segment Cardinality Implement Status
ACK^I07^ACK
MSH

Message Header

[1..1] SHALL
SFT

Software Segment

 
MSA

Message Acknowledgment

[1..1] SHALL
ERR

Error

 

 

ACK

We need some ER7 examples...
We need some XML examples...

25.4 PATIENT TREATMENT AUTHORIZATION REQUESTS (11.4)

This functional definition applies to a request for treatment authorization. Although this message also pertains to the payor, it differs greatly from that of an insurance information request. This message is used to request an authorization for specific procedures. Just as patient identification was important in an insurance information request, the focus of this functional area is provider identification, requested treatments/procedures and, in many cases, clinical information on a patient needed to fulfill review or certification requirements.

25.4.1 RQA/RPA - Request Patient Authorization Message (Event I08) (11.4.1)

All trigger events in this group use the following message definition.

Segment Cardinality Implement Status
RQA^I08-I11^RQA_I08
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
RF1

Referral Information

[0..1]  
AUTHORIZATION [0..1]  
AUT

Authorization Information

[1..1] SHALL
CTD

Contact Data

[0..1]  
PROVIDER [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PID

Patient Identification

[1..1] SHALL
NK1

Next of Kin / Associated Parties

 
GUARANTOR_INSURANCE [0..1]  
GT1

Guarantor

 
INSURANCE [1..*] SHALL
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
ACC

Accident

[0..1]  
DG1

Diagnosis

 
DRG

Diagnosis Related Group

 
AL1

Patient Allergy Information

 
PROCEDURE  
PR1

Procedures

[1..1] SHALL
AUTHORIZATION [0..1]  
AUT

Authorization Information

[1..1] SHALL
CTD

Contact Data

[0..1]  
OBSERVATION  
OBR

Observation Request

[1..1] SHALL
PRT

Participation Information

 
NTE

Notes and Comments

 
RESULTS  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
NTE

Notes and Comments

 
VISIT [0..1]  
PV1

Patient Visit

[1..1] SHALL
PV2

Patient Visit - Additional Information

[0..1]  
NTE

Notes and Comments

 

 

RQA_I08

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - RPA^I08-I11^RPA_I08
NE AL - RPA^I08-I11^RPA_I08
AL, SU, ER AL ACK^I08-I11^ACK RPA^I08-I11^RPA_I08
We need some ER7 examples...
We need some XML examples...
Segment Cardinality Implement Status
RPA^I08-I11^RPA_I08
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
MSA

Message Acknowledgment

[1..1] SHALL
RF1

Referral Information

[0..1]  
AUTHORIZATION [0..1]  
AUT

Authorization Information

[1..1] SHALL
CTD

Contact Data

[0..1]  
PROVIDER [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PID

Patient Identification

[1..1] SHALL
NK1

Next of Kin / Associated Parties

 
GT1

Guarantor

 
INSURANCE  
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
ACC

Accident

[0..1]  
DG1

Diagnosis

 
DRG

Diagnosis Related Group

 
AL1

Patient Allergy Information

 
PROCEDURE [1..*] SHALL
PR1

Procedures

[1..1] SHALL
AUTHORIZATION [0..1]  
AUT

Authorization Information

[1..1] SHALL
CTD

Contact Data

[0..1]  
OBSERVATION  
OBR

Observation Request

[1..1] SHALL
PRT

Participation Information

 
NTE

Notes and Comments

 
RESULTS  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
NTE

Notes and Comments

 
VISIT [0..1]  
PV1

Patient Visit

[1..1] SHALL
PV2

Patient Visit - Additional Information

[0..1]  
NTE

Notes and Comments

 

 

RPA_I08

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - -
NE NE - -
AL, SU, ER NE ACK^I08-I11^ACK -
We need some ER7 examples...
We need some XML examples...
Note: The abstract message definitions for both the RPA and RQA include the patient visit segments (PV1 and PV2). The PV1 and PV2 segments appear in the RPA and RQA as an optional grouping to specify the visit or encounter that generated the referral authorization request. The PV1 and PV2 should not be used to provide suggested information for a future encounter or visit generated by the referral authorization request.

The trigger events that use this message definition are described in sections 11.4.2, "RQA/RPA - Request for Treatment Authorization Information (Event I08)," through 11.4.5, "RQA/RPA - Request for Cancellation of an Authorization (Event I11)."

25.4.2 RQA/RPA - Request for Treatment Authorization Information (Event I08) (11.4.2)

This event triggers a message to be sent from a healthcare provider to a payor requesting authorization to perform specific medical procedures or tests on a given patient. The specific medical procedures must be filled out in the PR1 segments. Each repeating PR1 segment may be paired with an AUT segment so that authorization information can be given regarding dollar amounts, number of treatments, and perhaps the estimated length of stay for treatment. The OBR and OBX segments should be used to include any relevant clinical information that may be required to support or process the authorization.

25.4.3 RQA/RPA - Request for Modification to an Authorization (Event I09) (11.4.3)

This event triggers a message sent from a healthcare provider to a payor requesting changes to a previously referenced authorization. For example, a provider may determine that a substitute testing or surgical procedure should be performed on a specified patient.

25.4.4 RQA/RPA - Request for Resubmission of an Authorization (Event I10) (11.4.4)

If a previously submitted request for treatment authorization is rejected or canceled, this event could trigger a resubmission message for a referenced authorization. For example, the payor may have rejected a request until additional clinical information is sent to support the authorization request.

25.4.5 RQA/RPA - Request for Cancellation of an Authorization (Event I11) (11.4.5)

This event may trigger the cancellation of an authorization. It may be used by the provider to indicate that an authorized service was not performed, or perhaps that the patient changed to another provider. A payor may use this request to reject a submitted authorization request from a provider.

25.5 PATIENT REFERRAL MESSAGES AND TRIGGER EVENTS (11.5)

These message definitions and event codes define the patient referral. Although only three trigger events are defined, the abstract message is very versatile and can provide for a wide variety of inter-enterprise transactions.

25.5.1 REF/RRI - Patient Referral Message (11.5.1)

The trigger events that use this message definition are described in Sections 11.5.2, "REF/RRI - Patient Referral (Event I12)," through 11.5.5, "REF/RRI - Request Patient Referral Status (Event I15)."

Segment Cardinality Implement Status
REF^I12-I15^REF_I12
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
RF1

Referral Information

[0..1]  
AUTHORIZATION_CONTACT2 [0..1]  
AUT

Authorization Information

[1..1] SHALL
CTD

Contact Data

[0..1]  
PROVIDER_CONTACT [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PID

Patient Identification

[1..1] SHALL
NK1

Next of Kin / Associated Parties

 
GT1

Guarantor

 
INSURANCE  
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
ACC

Accident

[0..1]  
DG1

Diagnosis

 
DRG

Diagnosis Related Group

 
AL1

Patient Allergy Information

 
PROCEDURE  
PR1

Procedures

[1..1] SHALL
AUTHORIZATION_CONTACT2 [0..1]  
AUT

Authorization Information

[1..1] SHALL
CTD

Contact Data

[0..1]  
OBSERVATION  
OBR

Observation Request

[1..1] SHALL
PRT

Participation Information

 
NTE

Notes and Comments

 
RESULTS_NOTES  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
NTE

Notes and Comments

 
PATIENT_VISIT [0..1]  
PV1

Patient Visit

[1..1] SHALL
PV2

Patient Visit - Additional Information

[0..1]  
NTE

Notes and Comments

 

 

REF_I12

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - RPI^I12-I15^RPI_I12
NE AL - RPI^I12-I15^RPI_I12
AL, SU, ER AL ACK^I12-I15^ACK RPI^I12-I15^RPI_I12
We need some ER7 examples...
We need some XML examples...
Segment Cardinality Implement Status
RRI^I12-I15^RRI_I12
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
MSA

Message Acknowledgment

[0..1]  
RF1

Referral Information

[0..1]  
AUTHORIZATION_CONTACT2 [0..1]  
AUT

Authorization Information

[1..1] SHALL
CTD

Contact Data

[0..1]  
PROVIDER_CONTACT [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PID

Patient Identification

[1..1] SHALL
ACC

Accident

[0..1]  
DG1

Diagnosis

 
DRG

Diagnosis Related Group

 
AL1

Patient Allergy Information

 
PROCEDURE  
PR1

Procedures

[1..1] SHALL
AUTHORIZATION_CONTACT2 [0..1]  
AUT

Authorization Information

[1..1] SHALL
CTD

Contact Data

[0..1]  
OBSERVATION  
OBR

Observation Request

[1..1] SHALL
PRT

Participation Information

 
NTE

Notes and Comments

 
RESULTS_NOTES  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
NTE

Notes and Comments

 
PATIENT_VISIT [0..1]  
PV1

Patient Visit

[1..1] SHALL
PV2

Patient Visit - Additional Information

[0..1]  
NTE

Notes and Comments

 

 

RRI_I12

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - -
NE NE - -
AL, SU, ER NE ACK^I12-I15^ACK -
We need some ER7 examples...
We need some XML examples...
Note: The abstract message definitions for both the REF and RRI include the patient visit segments (PV1 and PV2). The PV1 and PV2 segments appear in the REF as an optional grouping to specify the visit or encounter that generated the referral. The PV1 and PV2 should not be used to provide suggested information for a future encounter or visit generated by the referral.

The PV1 and PV2 are also included in the RRI message definition. It should be noted that these segments do not merely mirror the segments in the originating REF message. Rather, they may contain information regarding the visit or encounter that resulted from the referral.

25.5.2 REF/RRI - Patient Referral (Event I12) (11.5.2)

This event triggers a message to be sent from one healthcare provider to another regarding a specific patient. The referral message may contain patient demographic information, specific medical procedures to be performed (accompanied by previously obtained authorizations) and relevant clinical information pertinent to the patient's case.

25.5.3 REF/RRI - Modify Patient Referral (Event I13) (11.5.3)

This event triggers a message to be sent from one healthcare provider to another regarding changes to an existing referral. Changes in a referral may include additional instructions from the referring provider, additional clinical information, and even additional information on patient demographics.

25.5.4 REF/RRI - Cancel Patient Referral (Event I14) (11.5.4)

This event triggers a message to be sent from one healthcare provider to another canceling a referral. A previous referral may have been made in error, or perhaps the cancellation has come from the patient.

25.5.5 REF/RRI - Request Patient Referral Status (Event I15) (11.5.5)

This event triggers a message to be sent between healthcare providers regarding the status of a patient referral request. A previous referral has been made and acknowledged; however, no response has been received to indicate results and/or procedures performed.

25.6 COLLABORATIVE CARE MESSAGES AND TRIGGER EVENTS (11.6)

These message definitions and event codes define the collaborative care exchanges, including patient referral, discharge summary and infectious diseases notifications. Although only seven trigger events are defined, the abstract message is very versatile and can provide for a wide variety of exchanges of information between care entities.

25.6.1 CCM/ACK - Collaborative Care Message (Event I21) (11.6.1)

This event triggers a message to be sent from one healthcare provider to another healthcare provider, clinical repository or regulatory body regarding a specific patient. The collaborative care message may contain patient demographic information, a full history of appointments, specific medical procedures that have been performed, a full clinical history, an administrative history of patient visits, a full medication history, all relevant problems, pathways and goals. This message fulfills the role of a notification of a single patient's health status and history. It is usable for discharge summaries, disease notifications or just moving a patient's electronic medical record from one the place to another. This message uses the REL segment to express the relationships between clinical histories.

Segment Cardinality Implement Status
CCM^I21^CCM_I21
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
PID

Patient Identification

[1..1] SHALL
PD1

Patient Additional Demographic

[0..1]  
NK1

Next of Kin / Associated Parties

 
INSURANCE  
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
APPOINTMENT_HISTORY  
SCH

Scheduling Activity Information

[1..1] SHALL
RESOURCES  
RGS

Resource Group

[1..1] SHALL
RESOURCE_DETAIL  
RESOURCE_OBJECT [1..1] SHALL
AIS

Appointment Information

[1..1] SHALL
AIG

Appointment Information - General Resource

[1..1] SHALL
AIL

Appointment Information - Location Resource

[1..1] SHALL
AIP

Appointment Information - Personnel Resource

[1..1] SHALL
RESOURCE_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
CLINICAL_HISTORY  
ORC

Common Order

[1..1] SHALL
CLINICAL_HISTORY_DETAIL  
CLINICAL_HISTORY_OBJECT [1..1] SHALL
OBR

Observation Request

[1..1] SHALL
PRT

Participation Information

 
  
ODS

Dietary Orders, Supplements, and Preferences

[1..1] SHALL
PR1

Procedures

[1..1] SHALL
RF1

Referral Information

[1..1] SHALL
AL1

Patient Allergy Information

[1..1] SHALL
IAM

Patient Adverse Reaction Information

[1..1] SHALL
ACC

Accident

[1..1] SHALL
RMI

Risk Management Incident

[1..1] SHALL
DB1

Disability

[1..1] SHALL
DG1

Diagnosis

[1..1] SHALL
DRG

Diagnosis Related Group

[1..1] SHALL
PDA

Patient Death and Autopsy

[1..1] SHALL
CLINICAL_HISTORY_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
PARTICIPATION_CLINICAL_HISTORY  
PARTICIPATION_CLINICAL_HISTORY_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
CTI

Clinical Trial Identification

 
PATIENT_VISITS [1..*] SHALL
PV1

Patient Visit

[1..1] SHALL
PV2

Patient Visit - Additional Information

[0..1]  
MEDICATION_HISTORY  
ORC

Common Order

[1..1] SHALL
MEDICATION_ORDER_DETAIL [0..1]  
RXO

Pharmacy/Treatment Order

[1..1] SHALL
RXR

Pharmacy/Treatment Route

[1..*] SHALL
RXC

Pharmacy/Treatment Component Order

 
MEDICATION_ORDER_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
MEDICATION_ENCODING_DETAIL [0..1]  
RXE

Pharmacy/Treatment Encoded Order

[1..1] SHALL
RXR

Pharmacy/Treatment Route

[1..*] SHALL
RXC

Pharmacy/Treatment Component Order

 
MEDICATION_ENCODING_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
MEDICATION_ADMINISTRATION_DETAIL  
RXA

Pharmacy/Treatment Administration

[1..*] SHALL
RXR

Pharmacy/Treatment Route

[1..1] SHALL
MEDICATION_ADMINISTRATION_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
CTI

Clinical Trial Identification

 
PROBLEM  
PRB

Problem Details

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_PROBLEM  
PARTICIPATION_PROBLEM_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
PROBLEM_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
GOAL  
GOL

Goal Detail

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_GOAL  
PARTICIPATION_GOAL_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
GOAL_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
PATHWAY  
PTH

Pathway

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_PATHWAY  
PARTICIPATION_PATHWAY_OBJECT [1..1] SHALL
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
PATHWAY_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
REL

Clinical Relationship Segment

 

 

CCM_I21

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank -
NE NE - -
AL, SU, ER NE ACK^I21^ACK -
We need some ER7 examples...
We need some XML examples...

25.6.2 CCR/ACK - Collaborative Care Referral (Events I16, I17 and I18) (11.6.2)

The trigger events that use this message are described in the sections below. The Collaborate Care Referral message is sent from one healthcare provider to another regarding a specific patient or group of patients. The collaborative care referral may contain specific clinical orders, patient demographic information, a full history of appointments, specific medical procedures that have been performed, a full clinical history, an administrative history of patient visits, a full medication history, all relevant problems, pathways and goal. This message uses the REL segment to express the relationships between patients and clinical orders and/or clinical histories, patients and patient visits, patients and medical histories, patients and problems, goals and pathways, as well as patients and providers, and providers and patient problems, goals and patient pathways. The REL segments can also be used to express the relationships between providers. The collaborative care referral message definitely implies intent to share, or transfer some, or all, of the care of the patient to the referred to provider or providers.

Segment Cardinality Implement Status
CCR^I16-I18^CCR_I16
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
RF1

Referral Information

[1..*] SHALL
PROVIDER_CONTACT [1..*] SHALL
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
CLINICAL_ORDER  
ORC

Common Order

[1..1] SHALL
CLINICAL_ORDER_TIMING  
TQ1

Timing/Quantity

[1..1] SHALL
TQ2

Timing/Quantity Relationship

 
CLINICAL_ORDER_DETAIL [1..*] SHALL
CLINICAL_ORDER_OBJECT [1..1] SHALL
OBR

Observation Request

[1..1] SHALL
PRT

Participation Information

 
  
RXO

Pharmacy/Treatment Order

[1..1] SHALL
PRT

Participation Information

 
  
ODS

Dietary Orders, Supplements, and Preferences

[1..1] SHALL
PR1

Procedures

[1..1] SHALL
CLINICAL_ORDER_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
CTI

Clinical Trial Identification

 
PATIENT [1..*] SHALL
PID

Patient Identification

[1..1] SHALL
PD1

Patient Additional Demographic

[0..1]  
NK1

Next of Kin / Associated Parties

 
INSURANCE  
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
APPOINTMENT_HISTORY  
SCH

Scheduling Activity Information

[1..1] SHALL
RESOURCES  
RGS

Resource Group

[1..1] SHALL
RESOURCE_DETAIL  
RESOURCE_OBJECT [1..1] SHALL
AIS

Appointment Information

[1..1] SHALL
AIG

Appointment Information - General Resource

[1..1] SHALL
AIL

Appointment Information - Location Resource

[1..1] SHALL
AIP

Appointment Information - Personnel Resource

[1..1] SHALL
RESOURCE_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
CLINICAL_HISTORY  
ORC

Common Order

[1..1] SHALL
CLINICAL_HISTORY_DETAIL  
CLINICAL_HISTORY_OBJECT [1..1] SHALL
OBR

Observation Request

[1..1] SHALL
PRT

Participation Information

 
  
ODS

Dietary Orders, Supplements, and Preferences

[1..1] SHALL
PR1

Procedures

[1..1] SHALL
RF1

Referral Information

[1..1] SHALL
AL1

Patient Allergy Information

[1..1] SHALL
IAM

Patient Adverse Reaction Information

[1..1] SHALL
ACC

Accident

[1..1] SHALL
RMI

Risk Management Incident

[1..1] SHALL
DB1

Disability

[1..1] SHALL
DG1

Diagnosis

[1..1] SHALL
DRG

Diagnosis Related Group

[1..1] SHALL
CLINICAL_HISTORY_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
PARTICIPATION_CLINICAL_HISTORY  
PARTICIPATION_CLINICAL_HISTORY_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
CTI

Clinical Trial Identification

 
PATIENT_VISITS [1..*] SHALL
PV1

Patient Visit

[1..1] SHALL
PV2

Patient Visit - Additional Information

[0..1]  
MEDICATION_HISTORY  
ORC

Common Order

[1..1] SHALL
MEDICATION_ORDER_DETAIL [0..1]  
RXO

Pharmacy/Treatment Order

[1..1] SHALL
PRT

Participation Information

 
RXR

Pharmacy/Treatment Route

[1..*] SHALL
RXC

Pharmacy/Treatment Component Order

 
MEDICATION_ORDER_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
MEDICATION_ENCODING_DETAIL [0..1]  
RXE

Pharmacy/Treatment Encoded Order

[1..1] SHALL
PRT

Participation Information

 
RXR

Pharmacy/Treatment Route

[1..*] SHALL
RXC

Pharmacy/Treatment Component Order

 
MEDICATION_ENCODING_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
MEDICATION_ADMINISTRATION_DETAIL  
RXA

Pharmacy/Treatment Administration

[1..1] SHALL
PRT

Participation Information

 
RXR

Pharmacy/Treatment Route

[1..1] SHALL
MEDICATION_ADMINISTRATION_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
CTI

Clinical Trial Identification

 
PROBLEM  
PRB

Problem Details

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_PROBLEM  
PARTICIPATION_PROBLEM_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
GOAL  
GOL

Goal Detail

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_GOAL  
PARTICIPATION_GOAL_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
GOAL_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
PATHWAY  
PTH

Pathway

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_PATHWAY  
PARTICIPATION_PATHWAY_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
PATHWAY_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
REL

Clinical Relationship Segment

 

 

CCR_I16

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - -
NE NE - -
AL, SU, ER NE ACK^I16-I18^ACK -
We need some ER7 examples...
We need some XML examples...

25.6.3 CCR/ACK - Collaborative Care Referral (Event I16) (11.6.3)

This event triggers a message to be sent from one healthcare provider to another regarding a specific patient or group of patients. The intent is to create a collaborative relationship between the referring provider, the referred to provider or providers and the patient or patients, for the shared care of the patient or patients. Whilst the acknowledgment is a simple ACK message, the expectation is that the referred to provider(s) will send back a CCU - Asynchronous Collaborative Care Update at a later time to indicate acceptance or rejection of the referral.

25.6.4 CCR/ACK - Modify Collaborative Care Referral (Event I17) (11.6.4)

This event triggers a message to be sent from one healthcare provider to another regarding changes to an existing Collaborative Care Referral. Changes may include additional instructions from the referring provider, additional clinical orders, additional clinical history, additional patient visits, additional medication history, or modifications to the problems, goals and/or pathways. Whilst the acknowledgment is a simple ACK message, the expectation is that the referred to provider(s) will send back a CCU - Asynchronous Collaborative Care Update at a later time to indicate acceptance or rejection of the modifications.

25.6.5 CCR/ACK - Cancel Collaborative Care Referral (Event I18) (11.6.5)

This event triggers a message to be sent from one healthcare provider to another canceling an existing Collaborative Care Referral. A previous Collaborative Care Referral may have been made in error, or perhaps the cancellation has come from the patient. Whilst the acknowledgment is a simple ACK message, the expectation is that the referred to provider(s) will send back a CCU - Asynchronous Collaborative Care Update at a later time to indicate cancellation of the Collaborative Care Referral.

25.6.6 CCU/ACK - Asynchronous Collaborative Care Update (Event I20) (11.6.6)

This event triggers a message to be sent from a referred to healthcare provider to the referring health care provider, regarding a specific, previously received collaborative care referral. The collaborative care update may contain patient demographic information, additional appointments, additional clinical history, additional patient visits and additional medication history. It may also contain updates of patient problems, pathways and goal. The information is similar to that which may have been provided in the original Collaborate Care Referral message, but significantly different, as it is information from the perspective of the referred to provider. Patient visits will be those visits by the patient, to the referred to provider, relating to the referral. Appointments will be appointments made for the patient, by the referred to provider, during those visits. Clinical history will be observations made during those visits and medication history will be medications prescribed, observed or recommended during those visits. This message is used to update the referring provider as to the current status of the referral. The referrer would also use this message to update of the status of a referral, such as accepted, rejected, patient put on waiting list, treatment completed etc.

Segment Cardinality Implement Status
CCU^I20^CCU_I20
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
RF1

Referral Information

[1..1] SHALL
PROVIDER_CONTACT  
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PATIENT  
PID

Patient Identification

[1..1] SHALL
PD1

Patient Additional Demographic

[0..1]  
NK1

Next of Kin / Associated Parties

 
INSURANCE  
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
APPOINTMENT_HISTORY  
SCH

Scheduling Activity Information

[1..1] SHALL
RESOURCES  
RGS

Resource Group

[1..1] SHALL
RESOURCE_DETAIL  
RESOURCE_OBJECT [1..1] SHALL
AIS

Appointment Information

[1..1] SHALL
AIG

Appointment Information - General Resource

[1..1] SHALL
AIL

Appointment Information - Location Resource

[1..1] SHALL
AIP

Appointment Information - Personnel Resource

[1..1] SHALL
RESOURCE_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
CLINICAL_HISTORY  
ORC

Common Order

[1..1] SHALL
CLINICAL_HISTORY_DETAIL  
CLINICAL_HISTORY_OBJECT [1..1] SHALL
OBR

Observation Request

[1..1] SHALL
PRT

Participation Information

 
  
ODS

Dietary Orders, Supplements, and Preferences

[1..1] SHALL
PR1

Procedures

[1..1] SHALL
RF1

Referral Information

[1..1] SHALL
AL1

Patient Allergy Information

[1..1] SHALL
IAM

Patient Adverse Reaction Information

[1..1] SHALL
ACC

Accident

[1..1] SHALL
RMI

Risk Management Incident

[1..1] SHALL
DB1

Disability

[1..1] SHALL
DG1

Diagnosis

[1..1] SHALL
DRG

Diagnosis Related Group

[1..1] SHALL
PDA

Patient Death and Autopsy

[1..1] SHALL
CLINICAL_HISTORY_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
PARTICIPATION_CLINICAL_HISTORY  
PARTICIPATION_CLINICAL_HISTORY_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
CTI

Clinical Trial Identification

 
PATIENT_VISITS [1..*] SHALL
PV1

Patient Visit

[1..1] SHALL
PV2

Patient Visit - Additional Information

[0..1]  
MEDICATION_HISTORY  
ORC

Common Order

[1..1] SHALL
MEDICATION_ORDER_DETAIL [0..1]  
RXO

Pharmacy/Treatment Order

[1..1] SHALL
PRT

Participation Information

 
RXR

Pharmacy/Treatment Route

[1..*] SHALL
RXC

Pharmacy/Treatment Component Order

 
MEDICATION_ORDER_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
MEDICATION_ENCODING_DETAIL [0..1]  
RXE

Pharmacy/Treatment Encoded Order

[1..1] SHALL
PRT

Participation Information

 
RXR

Pharmacy/Treatment Route

[1..*] SHALL
RXC

Pharmacy/Treatment Component Order

 
MEDICATION_ENCODING_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
MEDICATION_ADMINISTRATION_DETAIL  
RXA

Pharmacy/Treatment Administration

[1..1] SHALL
PRT

Participation Information

 
RXR

Pharmacy/Treatment Route

[1..1] SHALL
MEDICATION_ADMINISTRATION_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
CTI

Clinical Trial Identification

 
PROBLEM  
PRB

Problem Details

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_PROBLEM  
PARTICIPATION_PROBLEM_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
PROBLEM_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
GOAL  
GOL

Goal Detail

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_GOAL  
PARTICIPATION_GOAL_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
GOAL_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
PATHWAY  
PTH

Pathway

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_PATHWAY  
PARTICIPATION_PATHWAY_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
PATHWAY_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
REL

Clinical Relationship Segment

 

 

CCU_I20

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank ACK^I20^ACK -
NE NE - -
AL, SU, ER NE ACK^I20^ACK -
We need some ER7 examples...
We need some XML examples...

25.7 COLLABORATIVE CARE INFORMATION REQUEST MESSAGES AND TRIGGER EVENTS (11.7)

Collaborative care information may need to be retrieved from various entities, such as healthcare providers, clinical repositories or regulatory bodies. The definition of these entities often varies greatly. Some times the query will relate to a previous referral. At other times it will relate to a specific patient.

25.7.1 CCQ/CQU - Collaborative Care Query/Collaborative Care Query Update (Event I19) (11.7.1)

This event triggers a query message to be sent from a referring healthcare provider to a referred to healthcare provider, regarding a specific, previously sent collaborative care referral. The Collaborative Care Query message must contain sufficient data for the referred to provider to be able to identify the specific referral being queried. The response to a Collaborative Care Query message is a CQU - Collaborative Care Query Update message. The meaning of the Collaborative Care Query Update message is identical to the meaning of the Asynchronous Collaborative Care Update message.

Segment Cardinality Implement Status
CCQ^I19^CCQ_I19
MSH

Message Header

[1..1] SHALL
SFT

Software Segment

 
RF1

Referral Information

[1..1] SHALL
PROVIDER_CONTACT  
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
REL

Clinical Relationship Segment

 

 

CCQ_I19

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - CQU^I19^CQU_I19
NE AL - CQU^I19^CQU_I19
AL, SU, ER AL ACK^I19^ACK CQU^I19^CQU_I19
We need some ER7 examples...
We need some XML examples...
Segment Cardinality Implement Status
CQU^I19^CQU_I19
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
MSA

Message Acknowledgment

[1..1] SHALL
ERR

Error

 
RF1

Referral Information

[1..1] SHALL
PROVIDER_CONTACT  
PRD

Provider Data

[1..1] SHALL
CTD

Contact Data

 
PATIENT  
PID

Patient Identification

[1..1] SHALL
PD1

Patient Additional Demographic

[0..1]  
NK1

Next of Kin / Associated Parties

 
INSURANCE  
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
APPOINTMENT_HISTORY  
SCH

Scheduling Activity Information

[1..1] SHALL
RESOURCES  
RGS

Resource Group

[1..1] SHALL
RESOURCE_DETAIL  
RESOURCE_OBJECT [1..1] SHALL
AIS

Appointment Information

[1..1] SHALL
AIG

Appointment Information - General Resource

[1..1] SHALL
AIL

Appointment Information - Location Resource

[1..1] SHALL
AIP

Appointment Information - Personnel Resource

[1..1] SHALL
RESOURCE_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
CLINICAL_HISTORY  
ORC

Common Order

[1..1] SHALL
CLINICAL_HISTORY_DETAIL  
CLINICAL_HISTORY_OBJECT [1..1] SHALL
OBR

Observation Request

[1..1] SHALL
PRT

Participation Information

 
  
ODS

Dietary Orders, Supplements, and Preferences

[1..1] SHALL
PR1

Procedures

[1..1] SHALL
RF1

Referral Information

[1..1] SHALL
AL1

Patient Allergy Information

[1..1] SHALL
IAM

Patient Adverse Reaction Information

[1..1] SHALL
ACC

Accident

[1..1] SHALL
RMI

Risk Management Incident

[1..1] SHALL
DB1

Disability

[1..1] SHALL
DG1

Diagnosis

[1..1] SHALL
DRG

Diagnosis Related Group

[1..1] SHALL
PDA

Patient Death and Autopsy

[1..1] SHALL
CLINICAL_HISTORY_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
PARTICIPATION_CLINICAL_HISTORY  
PARTICIPATION_CLINICAL_HISTORY_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
CTI

Clinical Trial Identification

 
PATIENT_VISITS [1..*] SHALL
PV1

Patient Visit

[1..1] SHALL
PV2

Patient Visit - Additional Information

[0..1]  
MEDICATION_HISTORY  
ORC

Common Order

[1..1] SHALL
MEDICATION_ORDER_DETAIL [0..1]  
RXO

Pharmacy/Treatment Order

[1..1] SHALL
PRT

Participation Information

 
RXR

Pharmacy/Treatment Route

[1..*] SHALL
RXC

Pharmacy/Treatment Component Order

 
MEDICATION_ORDER_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
MEDICATION_ENCODING_DETAIL [0..1]  
RXE

Pharmacy/Treatment Encoded Order

[1..1] SHALL
PRT

Participation Information

 
RXR

Pharmacy/Treatment Route

[1..*] SHALL
RXC

Pharmacy/Treatment Component Order

 
MEDICATION_ENCODING_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
MEDICATION_ADMINISTRATION_DETAIL  
RXA

Pharmacy/Treatment Administration

[1..*] SHALL
PRT

Participation Information

 
RXR

Pharmacy/Treatment Route

[1..1] SHALL
MEDICATION_ADMINISTRATION_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
CTI

Clinical Trial Identification

 
PROBLEM  
PRB

Problem Details

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_PROBLEM  
PARTICIPATION_PROBLEM_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
PROBLEM_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
GOAL  
GOL

Goal Detail

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_GOAL  
PARTICIPATION_GOAL_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
GOAL_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
PATHWAY  
PTH

Pathway

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_PATHWAY  
PARTICIPATION_PATHWAY_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
PATHWAY_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
REL

Clinical Relationship Segment

 

 

CQU_I19

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - -
NE NE - -
AL, SU, ER NE ACK^I19^ACK -
We need some ER7 examples...
We need some XML examples...

25.7.2 CCF/CCI - Collaborative Care Fetch / Collaborative Care Information (Event I22) (11.7.2)

This event triggers a query message to be sent from one healthcare provider to another healthcare provider, clinical repository or regulatory body regarding a specific patient. The Collaborative Care Fetch message must contain sufficient information for the healthcare provider, clinical repository or regulatory body to be able to identify the specific patient. The response to a Collaborative Care Fetch is a CCI - Collaborative Care Information message. The meaning of the Collaborative Care Query Information message is identical to the meaning of the Collaborative Care Message message.

Segment Cardinality Implement Status
CCF^I22^CCF_I22
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
PID

Patient Identification

[1..1] SHALL

 

CCF_I22

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - CCI^I22^CCI_I22
NE AL - CCI^I22^CCI_I22
AL, SU, ER AL ACK^I22^ACK CCI^I22^CCI_I22
We need some ER7 examples...
We need some XML examples...
Segment Cardinality Implement Status
CCI^I22^CCI_I22
MSH

Message Header

[1..1] SHALL
ARV

Access Restriction

  v2.9
UAC

User Authentication Credential Segment

[0..1]  
MSA

Message Acknowledgment

[1..1] SHALL
ERR

Error

 
PID

Patient Identification

[1..1] SHALL
PD1

Patient Additional Demographic

[0..1]  
NK1

Next of Kin / Associated Parties

 
INSURANCE  
IN1

Insurance

[1..1] SHALL
IN2

Insurance Additional Information

[0..1]  
IN3

Insurance Additional Information, Certification

[0..1]  
APPOINTMENT_HISTORY  
SCH

Scheduling Activity Information

[1..1] SHALL
RESOURCES  
RGS

Resource Group

[1..1] SHALL
RESOURCE_DETAIL  
RESOURCE_OBJECT [1..1] SHALL
AIS

Appointment Information

[1..1] SHALL
AIG

Appointment Information - General Resource

[1..1] SHALL
AIL

Appointment Information - Location Resource

[1..1] SHALL
AIP

Appointment Information - Personnel Resource

[1..1] SHALL
RESOURCE_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
CLINICAL_HISTORY  
ORC

Common Order

[1..1] SHALL
CLINICAL_HISTORY_DETAIL  
CLINICAL_HISTORY_OBJECT [1..1] SHALL
OBR

Observation Request

[1..1] SHALL
PRT

Participation Information

 
ODS

Dietary Orders, Supplements, and Preferences

[1..1] SHALL
PR1

Procedures

[1..1] SHALL
RF1

Referral Information

[1..1] SHALL
AL1

Patient Allergy Information

[1..1] SHALL
IAM

Patient Adverse Reaction Information

[1..1] SHALL
ACC

Accident

[1..1] SHALL
RMI

Risk Management Incident

[1..1] SHALL
DB1

Disability

[1..1] SHALL
DG1

Diagnosis

[1..1] SHALL
DRG

Diagnosis Related Group

[1..1] SHALL
PDA

Patient Death and Autopsy

[1..1] SHALL
CLINICAL_HISTORY_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
PARTICIPATION_CLINICAL_HISTORY  
PARTICIPATION_CLINICAL_HISTORY_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
CTI

Clinical Trial Identification

 
PATIENT_VISITS [1..*] SHALL
PV1

Patient Visit

[1..1] SHALL
PV2

Patient Visit - Additional Information

[0..1]  
MEDICATION_HISTORY  
ORC

Common Order

[1..1] SHALL
MEDICATION_ORDER_DETAIL [0..1]  
RXO

Pharmacy/Treatment Order

[1..1] SHALL
PRT

Participation Information

 
RXR

Pharmacy/Treatment Route

[1..*] SHALL
RXC

Pharmacy/Treatment Component Order

 
MEDICATION_ORDER_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
MEDICATION_ENCODING_DETAIL [0..1]  
RXE

Pharmacy/Treatment Encoded Order

[1..1] SHALL
PRT

Participation Information

 
RXR

Pharmacy/Treatment Route

[1..*] SHALL
RXC

Pharmacy/Treatment Component Order

 
MEDICATION_ENCODING_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
MEDICATION_ADMINISTRATION_DETAIL  
RXA

Pharmacy/Treatment Administration

[1..1] SHALL
PRT

Participation Information

 
RXR

Pharmacy/Treatment Route

[1..1] SHALL
MEDICATION_ADMINISTRATION_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
CTI

Clinical Trial Identification

 
PROBLEM  
PRB

Problem Details

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_PROBLEM  
PARTICIPATION_PROBLEM_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
PROBLEM_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
GOAL  
GOL

Goal Detail

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_GOAL  
PARTICIPATION_GOAL_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
GOAL_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
PATHWAY  
PTH

Pathway

[1..1] SHALL
VAR

Variance

 
PARTICIPATION_PATHWAY  
PARTICIPATION_PATHWAY_OBJECT [1..1] SHALL
ROL

Role

[1..1] SHALL B
PRT

Participation Information

[1..1] SHALL
PRD

Provider Data

[1..1] SHALL
VAR

Variance

 
PATHWAY_OBSERVATION  
OBX

Observation/Result

[1..1] SHALL
PRT

Participation Information

 
REL

Clinical Relationship Segment

 

 

CCI_I22

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - -
NE NE - -
AL, SU, ER NE ACK^I22^ACK -
We need some ER7 examples...
We need some XML examples...

25.8 EXAMPLES (11.9)

The following examples will demonstrate the proposed way in which the RQI, RQA and REF messages can be used with the I01 (request for insurance information), I08 (request for treatment authorization information), I15 (request patient referral status) and I06 (request/receipt of clinical data listing) event codes. The events are presented in the order in which they would occur in a typical patient encounter. The first event to occur when the patient visits the medical practice is the verification of eligibility/coverage information. Next, the patient will be diagnosed and may be referred to a specialist for further treatment. This procedure may require a request for pre-authorization from the payor, which will be forwarded to the referral provider. Once the referral provider begins treatment, messages regarding the status or outcome of the treatment will be sent to the referring provider. Queries may also be sent to the specialist and reference laboratories.

25.8.1 RQI Message Using an I01 Event with an Immediate Response (11.9.1)

When a patient arrives for an appointment, the office staff will frequently need to verify the patient's insurance information. In the following RQI message example, Dr. Hippocrates is sending an insurance information request to the H. C. Payor Insurance Company for his patient, Adam A. Everyman. The response from the payor is shown in a more complete IN1 segment. However, it should be noted that in addition to the IN1 segment, this return information could have been placed in the NTE segment to serve as display data. This strategy would serve a broader community of diverse application systems that might have different levels of ability to process the record-formatted data.

MSH|^~\&|HIPPOCRATESMD|EWHIN|MSC|EWHIN|19940107155043||RQI^I01|HIPPOCRATESMD7888|P|2.9|||NE|AL

PRD|RP|HIPPOCRATES^HAROLD^^^DR^MD|1001 HEALTHCARE^DRIVE^ANN ARBOR^MI^99999| ^^^HIPPOCRATESMD&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER|HIPPOCRATESMD7899

PRD|RT|HCIC||^^^MSC&EWHIN^^^^^H.C. PAYOR INSURANCE COMPANY

PID||| HL71001111111111^9^M10||EVERYMAN^ADAM^A||19600309||||||||||||444-33-3333

IN1|1|PPO|HC02|HCIC (MI State Code)|

MSH|^~\&|MSC|EWHIN|HIPPOCRATESMD|EWHIN|19940107155212||RPI^I01|MSC2112|P|2.9|||ER|ER

MSA|AA|HIPPOCRATESMD7888|ELIGIBILITY INFORMATION FOUND

PRD|RP|HIPPOCRATES^HAROLD^^^DR^MD|1001 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999| ^^^HIPPOCRATESMD&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER|HIPPOCRATESMD7899

PRD|RT|HCIC||^^^MSC&EWHIN^^^^^H.C. PAYOR INSURANCE COMPANY

PID|||HL71001111111111^9^M10||EVERYMAN^ADAM^A||19600301||||||||||||444-33-333CR>

IN1|1|PPO|HC02|HCIC (MI State Code)|5555 INSURERS CIRCLE ^^ANN ARBOR^MI^99999^USA|CHRISTOPHER CLERK|(855)555-1234|987654321||||19901101||||EVERYMAN^ADAM^A|1|19600309|N. 2222 HOME STREET^^ANN ARBOR^MI^99999^USA|||||||||||||||||444333555||||||01|M

25.8.2 RQA Message Using an I08 Event with an Immediate Response (11.9.2)

When the attending physician decides to refer the patient for treatment to another healthcare provider, pre-authorization may be required by the payor. In the following RQA example, Dr. Blake is requesting the appropriate pre-authorization from H.C Payor Insurance Company for a colonoscopy on Adam Everyman. The request includes the diagnosis, in case it is a factor in the approval decision. As shown below, the immediate response indicates approval of the request that was made on 01/10/94 and that expires on 05/10/94. In actuality, most payors require some human intervention in the pre-authorization process and would probably not respond immediately.

MSH|^~\&|HIPPOCRATESMD|EWHIN|MSC|EWHIN|19940110105307||RQA^I08|HIPPOCRATESMD7898|P|2.9|||NE|AL

PRD|RP|HIPPOCRATES^HAROLD^^^DR^MD|1001 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999| ^^^HIPPOCRATESMD&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER|HIPPOCRATESMD7899

PRD|RT|HIIC||^^^MSC&EWHIN^^^^^H.C.PAYOR INSURANCE COMPANY

PID|||HL71001111111111^9^M10||EVERYMAN^ADAM^A||19600309||||||||||||444-33-3333

IN1|1|PPO|HC02|HCIC (MI State Code)|5555 INSURERS CIRCLE^^ANN ARBOR^MI^99999^USA|CHRISTOPHER CLERK|(855)555-1234|(555)555-3002||||19901101||||EVERYMAN^ADAM^A|1|19600309|2222 HOME STREET^^ANN ARBOR^MI^99999^USA |||||||||||||||||444333555||||||01|M

DG1|1|I9|569.0|RECTAL POLYP|19940106103500|0

PR1|1|C4|45378|Colonoscopy|19940110105309|00

MSH|^~\&|MSC|EWHIN|HIPPOCRATESMD|EWHIN|19940110154812||RPA^I08|MSC2112|P|2.9|||ER|ER

MSA|AA|HIPPOCRATESMD7888

PRD|RP|HIPPOCRATES^HAROLD^^^DR^MD|1001 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999| ^^^ HIPPOCRATESMD &EWHIN^^^^^HIPPOCRATES MEDICAL CENTER| HIPPOCRATESMD7899

PRD|RT|HIIC||^^^MSC&EWHIN^^^^^H.C.PAYOR INSURANCE COMPANY

PID|||HL71001111111111^9^M10||EVERYMAN^ADAM^A||19600301|||||||||||| HL71001111111111

IN1|1|PPO|HC02|HCIC (MI State Code)|5555 INSURERS CIRCLE^^ANN ARBOR^MI^99999^USA|CHRISTOPHER CLERK|(855)555-1234|(555)555-3002||||19901101||||EVERYMAN^ADAM^A|1|19600309|2222 HOME STREET^^ANN ARBOR^MI^99999^USA|||||||||||||||||444555333||||||01|M

DG1|1|I9|569.0|RECTAL POLYP|19940106103500|0

PR1|1|C4|45378|Colonoscopy|19940110105309|00

AUT|PPO|HC02|HIIC (MI State Code)|19940110|19940510|HL71001111111111|175|1

25.8.3 RQA Message Using an I08 Event with a Deferred Response (11.9.3)

In the following example of a pre-authorization request, the payor indicates his receipt of the request (a standard acknowledgment message), but defers issuing a pre-authorization to a later time. This response represents a more typical payor transaction sequence. Note the use of the "Accept Acknowledgment Type," requiring the receiving system to respond in all cases to receipt of the message.

MSH|^~\&|HIPPOCRATESMD|EWHIN|MSC|EWHIN|19940110105307||RQA^I08|HIPPOCRATES7898|P|2.9|||AL|AL

PRD|RP| HIPPOCRATES^HAROLD ^^^DR^MD|1001 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999| ^^^HIPOOCRATES&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER|HIPPOCRATESM7899

PRD|RT|HIIC||^^^MSC&EWHIN^^^^^H.C.PAYOR INSURANCE COMPANY

PID||| HL71001111111111^9^M10||EVERYMAN^ADAM^A||19600301|||||||||||| HL71001111111111

IN1|1|PPO|HC02|HCIC (MI State Code)|5555 INSURERS CIRCLE^^ANN ARBOR^MI^99999^USA|CHRISTOPHER CLERK|(855)555-1234|(555)555-3002||||19901101||||EVERYMAN^ADAM^A|1|19600309|2222 HOME STREET^^ANN ARBOR^MI^99999^USA|||||||||||||||||444555333||||||01|M

PR1|1|C4|45378|Colonoscopy|19940110105309|00

MSH|^~\&|MSC|EWHIN|HIPPOCRATESMD|EWHIN|1994011015315||MCF|MSC2112|P|2.9|||ER|ER

MSA|AA|HIPPOCRATES7888

MSH|^~\&|MSC|EWHIN|HIPPOCRATESMD|EWHIN|19940111102304||RPA^I08|MSC2113|P|2.9|||ER|ER

MSA|AA|HIPPOCRATESM7888

PRD|RP| HIPPOCRATES^HAROLD ^^^DR^MD|1001 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999| ^^^HIPOOCRATES&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER|HIPPOCRATESM7899

PRD|RT|WSIC||^^^MSC&EWHIN^^^^^H.C.PAYOR INSURANCE COMPANY

PID|||HL71001111111111^9^M10||EVERYMAN^ADAM^A ||19600301|||||||||||| HL71001111111111

IN1|1|PPO|HC02|HCIC (MI State Code)|5555 INSURERS CIRCLE^^ANN ARBOR^MI^99999^USA|CHRISTOPHER CLERK|(855)555-1234|(555)555-3002||||19901101||||EVERYMAN^ADAM^A|1|19600309|2222 HOME STREET^^ANN ARBOR^MI^99999^USA|||||||||||||||||444555333||||||01|M

PR1|1|C4|45378|Colonoscopy|19940110105309|00

AUT|PPO|HC02|HIIC (MI State Code)|19940110|19940510|HL71001111111111|175|1

25.8.4 REF Message Using an I11 Event with an Immediate Response (11.9.4)

Once pre-authorization has been received, the patient is referred to the referral provider. In the following example, Dr. Hippocrates is referring Adam Everyman to Dr. Tony Tum for a colonoscopy. The referral message includes the patient's demographic information, diagnosis and the pre-authorization information retrieved during the previous transaction. The dates contained in the pre-authorization segment (e.g., authorization date and authorization expiration date) pertain to the authorization, given by a payor, for a specified procedure. They are not intended to imply any kind of schedule request. Scheduling will be handled by the referral provider and the patient in a separate transaction. Not all referrals will require a detailed chain of response messages, so in this case, a simple acknowledgment in the form of an RPI is returned with a note from the referred-to provider.

MSH|^~\&|HIPPOCRATESMD|EWHIN|TUM|EWHIN|19940111113142||REF^I11|HIPPOCRATESM7899|P|2.9|||NE|AL

RF1||R|MED|RP|O|REF4502|19940111|19940510|19940111

PRD|RP|HIPPOCRATES^HAROLD^^^DR^MD|1001 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999| ^^^HIPPOCRATESMD&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER|HIPPOCRATES7899

CTD|PR|ENTER^ELLEN|1001 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999^USA^|^^^HIPPOCRATESMD&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER

PRD|RT|TUM^TONY^^^DR||^^^JIME&EWHIN^^^^^TUM AND TUMOR||||531886

PID|||HL71001111111111^9^M10||EVERYMAN^ADAM^A ||19600309|M||C|2222 HOME STREET^^ANN ARBOR^MI^99999^USA|SPO|(555)555-2004|ENGL|M|M||HL71001111111111EVERYMAN*3-444-555^MI

NK1|1|EVERYMAN^BETTERHALF^W|2|2222 HOME STREET^^ANN ARBOR^MI^99999^USA|(555)555-2004

GT1|1||EVERYMAN^ADAM^A||2222 HOME STREET^^ANN ARBOR^MI^99999^USA|(555)4555-2004|(555)555-2004|19600309|M||1|402941703||||CONTACT*CARRIE|||456789|01

IN1|1|PPO|HC02|HCIC (MI State Code)|5555 INSURERS CIRCLE^^ANN ARBOR^MI^99999^USA|CHRISTOPHER CLERK|(855)555-1234|(555)555-3002||||19901101||||EVERYMAN^ADAM^A|1|19600309|2222 HOME STREET^^ANN ARBOR^MI^99999^USA|||||||||||||||||444555333||||||01|M

ACC|19940105125700|WR|ENTER*ELLEN<

DG1|1|I9|569.0|RECTAL POLYP|19940106103500|0

PR1|1|C4|45378|Colonoscopy|19940110105309|00

AUT|PPO|WA02|HCIC (MI State Code)|19940110|19940510|123456789|175|1

MSH|^~\&|TUM|EWHIN|HIPPOCRATESMD|EWHIN|19940111152401||RRI^I11|TUM1123|P|2.9|||ER|ER

MSA|AA|TUMM7900

RF1|A|R|MED|RP|O|REF4502|19940111|19940510|19940111

PRD|RP|TUM^TONY^^^DR^MD|1031 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999| ^^^TUMMD&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER|TUMMT7900

CTD|PR|ENTER^ELLEN|1021 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999|^^^TUMTMD&EWHIN^^^^^TUM MEDICAL CENTER

PRD|RT|TUM^TONY^^^DR||^^^TUM&EWHIN^^^^^TUM AND TUMOR||||531886

PID|||HL71001111111111^9^M10||EVERYMAN^ADAM^A ||19600309|M||C|2222 HOME STREET^^ANN ARBOR^MI^99999^USA|SPO|(555)555-2004|ENGL|M|M||HL71001111111111EVERYMAN*3-444-555^MI

DG1|1|I9|569.0|RECTAL POLYP|19940106103500|0

PR1|1|C4|45378|Colonoscopy|19940111141509|00

NTE|||Patient is doing well.~Full recovery expected.

25.8.5 REF Message Using an I11 Event with a Deferred Response (11.9.5)

The following example demonstrates the ability of the referral provider to return a series of responses. For most referrals, multiple responses will be returned because referrals may contain multiple requested procedures that may be performed over a period of time. The referral provider determines the completion of this chain of messages and indicates that designation in the following example by setting the "Processed" flag in the MSA segment. This procedure will probably vary from network to network.

MSH|^~\&|TUMMD|EWHIN|HIPPOCRATESMD|EWHIN|19940111113142||REF^I11|TUMMM7899|P|2.9|||AL|AL

RF1||R|MED|RP|O|REF4502|19940111|19940510|19940111

PRD|RP|TUM^TONY^^^DR^MD|1031 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999| ^^^TUMMD&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER|TUMMT7900

CTD|PR|ENTER^ELLEN|1021 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999|^^^TUMTMD&EWHIN^^^^^TUM MEDICAL CENTER

PRD|RT|TUM^TONY^^^DR||^^^TUM&EWHIN^^^^^TUM AND TUMOR||||531886

PID|||HL71001111111111^9^M10||EVERYMAN^ADAM^A ||19600309|M||C|2222 HOME STREET^^ANN ARBOR^MI^99999^USA|SPO|(555)555-2004|ENGL|M|M||HL71001111111111EVERYMAN*3-444-555^MI

NK1|1|EVERYMAN^BETTERHALF^W|2|2222 HOME STREET^^ANN ARBOR^MI^99999^USA|(555)555-2004

GT1|1||EVERYMAN^ADAM^A||2222 HOME STREET^^ANN ARBOR^MI^99999^USA|(555)4555-2004|(555)555-2004|19600309|M||1|402941703||||CONTACT*CARRIE|||456789|01

IN1|1|PPO|HC02|HCIC (MI State Code)|5555 INSURERS CIRCLE^^ANN ARBOR^MI^99999^USA|CHRISTOPHER CLERK|(855)555-1234|(555)555-3002||||19901101||||EVERYMAN^ADAM^A|1|19600309|2222 HOME STREET^^ANN ARBOR^MI^99999^USA|||||||||||||||||444555333||||||01|M

ACC|19940105125700|WR|ENTER*ELLEN

DG1|1|I9|569.0|RECTAL POLYP|19940106103500|0

PR1|1|C4|45378|Colonoscopy|19940110105309|00

AUT|PPO|HC02|HCIC (MI State Code)|19940110|19940510|123456789|175|1

MSH|^~\&|TUMMD|EWHIN|HIPPOCRATESMD|EWHIN|19940111154812||MCF|TUMT1123|P|2.9|||ER|ER

MSA|AA|TUMM7899

MSH|^~\&|TUM|EWHIN|HIPPOCRATESMD|EWHIN|19940112152401||RRI^I11|TUMTE1124|P|2.9|||ER|ER

MSA|AA|HIPPOCRATESM7899

RF1|A|R|MED|RP|O|REF4502|19940111|19940510|19940111

PRD|RP|HIPPOCRATES^HAROLD^^^DR^MD|1001 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999|^^^HIPPOCRATESMD&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER|HIPPOCRATESM7899

CTD|PR|ENTER^ELLEN|1001 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999|^^^HIPPOCRATESMD&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER

PRD|RP|TUM^TONY^^^DR^MD|1031 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999| ^^^TUMMD&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER|TUMMT7900

PID|||HL71001111111111^9^M10||EVERYMAN^ADAM^A ||19600309|M||C|2222 HOME STREET^^ANN ARBOR^MI^99999^USA|SPO|(555)555-2004|ENGL|M|M||HL71001111111111EVERYMAN*3-444-555^MI

DG1|1|I9|569.0|RECTAL POLYP|19940106103500|0

PR1|1|C4|45378|Colonoscopy|19940111141509|00

NTE|||Patient is doing well.~Full recovery expected.

25.8.6 RQC Inquiry Message Using an I05 Event with an Immediate Response (11.9.6)

Retained for backwards compatibility only in version 2.4 and later; refer to Chapter 5 section 5.4, "Query Response Message Pairs." The original mode query and the QRD/QRF segments have been replaced.

In this example, Dr. Hippocrates is querying a reference laboratory for the results of all lab work performed on Adam Everyman between the dates of 03/20/94 and 03/22/94 and requests that the data be returned in a record or data element format. The message request contains all of the patient identification, as well as the provider identification necessary for the responding facility to qualify the request.

MSH|^~\&|HIPPOCRATESMD|EWHIN|HL7_LAB|EWHIN|19940410113142||RQC^I05|HIPPOCRATES7899|P|2.9|||NE|AL

QRD|19940504144501|R|I|HIPPOCRATES7899|||5^RD|PATIENT|RES|ALL

QRF|HL7_LAB^EWHIN|19940320000000|19940322235959

PRD|RP|HIPPOCRATES^HAROLD^^^DR^MD|1001 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999| ^^^HIPPOCRATESMD&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER|HIPPOCRATES7899

CTD|PR|ENTER^ELLEN|1001 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999|^^^HIPPOCRATES&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER

PRD|RT|HL7AB^HEALTH LEVEL LAB||^^^HL7_LAB&EWHIN^^^^^HEALTH LEVEL LABORATORIES

PID|||HL71001111111111^9^M10||EVERYMAN^ADAM^A ||19600309|M||C|2222 HOME STREET^^ANN ARBOR^MI^99999^USA|SPO|(555)555-2004|ENGL|M|M||HL71001111111111EVERYMAN*3-444-555^MI

MSH|^~\&|HL7_LAB|EWHIN|HIPPOCRATESMD|EWHIN|19940411152401||RPI^I05|HL7LAB4250|P|2.9|||ER|ER

MSA|AA|HIPPOCARATES7899

QRD|19940504144501|R|I|HIPPOCRATES7899|||5^RD|PATIENT|RES|ALL

QRF|HL7_LAB^EWHIN|19940320000000|19940322235959

PRD|RP|HIPPOCRATES^HAROLD^^^DR^MD||1001 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999|^^^HIPPOCRATES&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER|HIPPOCRATES7899

CTD|PR|ENTER^ELLEN|1001 HEALTHCARE DRIVE^^ANN ARBOR^MI^99999|^^^HIPPOCRATES&EWHIN^^^^^HIPPOCRATES MEDICAL CENTER

PRD|RT|HL7LAB^HEALTH LEVEL LAB||^^^HL7_LAB&EWHIN^^^^^HEALTH LEVELLABORATORIES

PID|||HL71001111111111^9^M10||EVERYMAN^ADAM^A ||19600309|M||C|2222 HOME STREET^^ANN ARBOR^MI^99999^USA|SPO|(555)555-2004|ENGL|M|M||HL71001111111111EVERYMAN*3-444-555^MI

OBR|1||1045813^LAB|L1505.003^COMPLETE BLOOD COUNT (D)|||19940320104700|""|1^EA|||| |19940320112400||CARMI||||||19940320104955|||F

OBX|1|ST|L1550.000^HEMOGLOBIN, AUTO HEME||11.6|g/dl|12.0-16.0|L|||F

OBX|2|ST|L1551.003^HEMATOCRIT (D)||36.4|%|36-45||||F

OBX|3|ST|L1552.000^RBC, AUTO HEME||3.94|mil/ul|4.1-5.1|L|||F

OBX|4|ST|L1553.000^MCV, AUTO HEME||92.4|fl|80-100||||F

OBX|5|ST|L1554.000^MCH, AUTO HEME||29.3|pg|26-34||||F

OBX|6|ST|L1555.000^MCHC, AUTO HEME||31.8|g/dl|31-37||||F

OBX|7|ST|L1557.000^RBC DISTRIBUTION WIDTH||15.3|%|0-14.8|H|||F

OBX|8|ST|L1558.003^PLATELET COUNT (D)||279|th/ul|140-440||||F

OBX|9|ST|L1559.000^WBC, AUTO HEME||7.9|th/ul|4.5-11.0||||F

OBX|10|ST|L1561.100^NEUTROPHILS, % AUTO||73.8|%|||||F

OBX|11|ST|L1561.510^LYMPHOCYTES, % AUTO||16.6|%|||||F

OBX|12|ST|L1562.010^MONOCYTES, % AUTO||7.3|%|||||F

OBX|13|ST|L1563.010^EOSINOPHILS, % AUTO||1.7|%|||||F

OBX|14|ST|L1564.010^BASOPHILS, % AUTO||0.7|%|||||F

OBX|15|ST|L1565.010^NEUTROPHILS, ABS AUTO||5.8|th/ul|1.8-7.7||||F

OBX|16|ST|L1566.010^LYMPHOCYTES, ABS AUTO||1.3|th/ul|1.0-4.8||||F

OBX|17|ST|L1567.010^MONOYCYTES, ABS AUTO||0.6|th/ul|0.1-0.8||||F

OBX|18|ST|L1568.010^EOSINOPHILS, ABS AUTO||0.1|th/ul|0-0.7||||F

OBX|19|ST|L1569.000^BASOPHILS, ABS AUTO||0.1|th/ul|0-0.2||||F

OBX|20|ST|L2110.003^PROTHROMBIN TIME (D)||30.7|sec|11.1-14.0|HH|||F

NTE|1|L|COAGULATION CRITICAL VALUES CALLED TO VICKIE QUASCHNICK~AT 1130 BY VON~Therapeutic Ranges(oral anticoagulant):~Most clinical situations: 16.1 - 21.1 sec -~ (1.3 - 1.7 times the mean of the normal range)~Mech heart valve, recurrent embolism: 18.6 - 23.6 sec -~ (1.5 - 1.9 times the mean of the normal range)

OBX|21|ST|L2110.500^INR||5.95||||||F

NTE|1|L|Therapeutic Range (oral anticoagulant):~ Most clinical situations: 2.0 - 3.0~ Mech heart valve, recurrent embolism: 3.0 - 4.0

OBX|22|ST|L3110.003^SODIUM (D)||141|mmol/l|135-146||||F

OBX|23|ST|L3111.003^POTASSIUM (D)||3.8|mmol/l|3.5-5.1||||F

OBX|24|ST|L3112.003^CHLORIDE (D)||111|mmol/l|98-108|H|||F

OBX|25|ST|L3113.003^CO2 (TOTAL) (D)||23.7|mmol/l|23-30||||F

OBX|26|ST|L3114.000^ANION GAP||6||7-17|L|||F

OBX|27|ST|L3120.003^CREATININE (D)||1.4|mg/dl|0.5-1.2|H|||F

OBX|28|ST|L3121.003^UREA NITROGEN (D)||24|mg/dl|7-25||||F

OBX|29|ST|L3123.003^GLUCOSE (D)||123|mg/dl|65-115|H|||F

OBX|30|ST|L3126.003^CALCIUM (D)||8.7|mg/dl|8.4-10.2||||F

OBR|2||1045825^LAB|L2560.000^BLOOD GAS, ARTERIAL (R)|||19940320105800|""| 1^EA|||||19940320105800||CARMI||||||19940320105844|||F

OBX|1|ST|L2565.000^PH, ARTERIAL BLD GAS (R)||7.46||7.35-7.45|H|||F

OBX|2|ST|L2566.000^PCO2, ARTERIAL BLOOD GAS||28|mm/Hg|35-45|LL|||F

NTE|1|L|BLOOD GAS ANALYSIS CRITICAL VALUE(S) CALLED TO~DR. CARLSON.

OBX|3|ST|L2567.000^PO2, ARTERIAL BLOOD GAS||83|mm/Hg|80-100||||F

OBX|4|ST|L2568.000^O2 SAT, ART BLD GAS (R)||96|%|95-99||||F

OBX|5|ST|L2569.000^BASE EX, ARTERIAL BLD GAS||-2.1|mEq/l|-2.0-2.0|L|||F

OBX|6|ST|L2570.000^HCO3, ARTERIAL BLD GAS||19.4|mEq/l|22-26|L|||F

OBX|7|ST|L2571.000^PATIENT TEMP, ABG||96.2|deg F|||||F

OBX|8|ST|L2572.000^MODE, ABG||ROOM AIR||||||F

OBR|3||1045812^LAB|L2310.003^URINALYSISD)|||19940320121800|""|1^EA|||||19940320121800||CARMI||||||19940320104953|||F

OBX|1|ST|L2320.303^SPECIFIC GRAVITY, UR (D)||1.015||1.002-1.030||||F

OBX|2|ST|L2320.403^PH, UR (D)||7.0||5.0-7.5||||F

OBX|3|ST|L2320.503^PROTEIN, QUAL, UR (D)||NEG|mg/dl|||||F

OBX|4|ST|L2320.703^GLUCOSE, QUAL, UR (D)||0|mg/dl|0-30||||F

OBX|5|ST|L2320.803^KETONES, UR (D)||NEG|mg/dl|||||F

OBX|6|ST|L2320.903^OCCULT BLOOD, UR (D)||SMALL|||A|||F

OBX|7|ST|L2321.003^BILIRUBIN, UR (D)||NEG||||||F

OBX|8|ST|L2321.100^LEUKOCYTES, UR||MOD|||A|||F

OBX|9|ST|L2321.200^NITRITES, UR||NEG||||||F

OBX|10|ST|L2321.300^UROBILINOGEN, UR||NEG||||||F

OBX|11|ST|L2342.000^MICRO SPUN VOLUME, UR||8|ml|8-8||||F

OBX|12|ST|L2350.003^RBC, UR (D)||5-10|/hpf|||||F

OBX|13|ST|L2350.100^WBC, UR||>100|/hpf|||||F

OBX|14|ST|L2350.200^EPITHELIAL CELLS, UR||2+||||||F

OBX|15|ST|L2350.300^BACTERIA, UR||2+|||A|||F

25.9 OUTSTANDING ISSUES (11.10)

25.9.1 HL7 Overlapping With ASC X12N (11.10.1)

There have been discussions regarding overlap of the proposed Patient Referral Chapter with recent development efforts by a committee within the ASC X12N organization. In the Healthcare Task Group (Task Group 2) of the ASC X12N Insurance Subcommittee, the Services Review Working Group (Working Group 10) has been working on a referral transaction (Transaction 278). This transaction has been designed from a payor perspective by focusing on certification of a referral or notification that a referral took place. This focus deals primarily with the financial or reimbursement side of a referral. There are some similarities between the two messages. However, there are also some clear differences. For example, the ASC X12 transaction does not provide for provider-to-provider referrals containing clinical data. Referrals containing a patient's clinical record along with diagnoses and requested procedures are the major focus of the work being done by HL7. In an effort to alleviate some of the controversy that this issue has caused, sections of this HL7 Patient Referral chapter have been removed. These sections dealt primarily with eligibility and plan coverage information. That information will be specifically handled by ASC X12N transactions 271 and 272, and the new interactive transactions.

There are some convergence activities currently in progress. The HL7 - X12 Joint Coordinating Committee has been formed to facilitate efforts to unify these two standard development organizations as well as others. Work is in progress to harmonize HL7 trigger events within X12N transactions, as well as in joint data modeling. There has also been some work done at the working group level to harmonize the common data segments of the two respective referral messages. There is ongoing participation by both HL7 committees and X12N work groups to achieve a certain level of data compatibility.

The HL7 Board of Directors has directed HL7 to continue development of the Patient Referral Chapter for the following reasons:

The HL7 - X12 coordination is ongoing, but will not be complete in time for Standard Version 2.7.

The HL7 Patient Referral Chapter addresses business needs that the X12 transaction does not (e.g., transmission of codified clinical data).