Chapter Chair/Editor: |
John
Lynch, CHREF |
Editor: |
David
C. Means |
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.
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.
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.
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.
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.
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.
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.
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.
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. She or he would then be very interested in receiving
any information regarding the patient (s)he has referred to a specialist.
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:
The services payable under a specific payor plan. They are also referred to as an insurance product, such as professional services, prescription drugs, etc.
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).
Refers to a person who is affiliated with a subscriber, such as spouse or child.
Refers to the period of time a subscriber or dependent is entitled to benefits.
Refers to a meeting between a covered person and a healthcare provider whose services are provided.
Refers to a person who has financial responsibility for the payment of a patient account.
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.
Indicates a third-party entity who 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).
Refers to the process of obtaining prior approval as to the appropriateness of a service. Pre-authorization does not guarantee coverage.
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.
Means a provider's recommendation that a covered person receive care from a different provider.
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.
Typically indicates a specialty care provider who provides services at the request of a primary care provider or another specialty care provider.
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.
Refers to a person who elects benefits and is affiliated with an employer or insurer.
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.
This
event triggers a message to be sent from one healthcare provider to another to
request insurance information for a specified patient.
RQI^I01 |
Request Patient Information |
Chapter |
MSH |
Message Header |
2 |
{ |
||
PRD |
Provider Data |
11 |
[{CTD}] |
Contact Data |
11 |
} |
||
PID |
Patient Identification |
3 |
[{NK1}] |
Next of Kin/Associated Parties |
6 |
[[{GT1}] |
Guarantor |
6 |
{ |
||
IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert |
6 |
} |
||
] |
||
[{NTE}] |
Notes and Comments |
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.
RQI^I02 |
Request Patient Information |
Chapter |
MSH |
Message Header |
2 |
{ |
||
PRD |
Provider Data |
11 |
[{CTD}] |
Contact Data |
11 |
} |
||
PID |
Patient Identification |
3 |
[{NK1}] |
Next of Kin/Associated Parties |
6 |
[[{GT1}] |
Guarantor |
6 |
{ |
||
IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert |
6 |
} |
||
] |
||
[{NTE}] |
Notes and Comments |
2 |
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.
RQI^I03 |
Request Patient Information |
Chapter |
MSH |
Message Header |
2 |
{ |
||
PRD |
Provider Data |
11 |
[{CTD}] |
Contact Data |
11 |
} |
||
PID |
Patient Identification |
3 |
[{NK1}] |
Next of Kin/Associated Parties |
6 |
[[{GT1}] |
Guarantor |
6 |
{ |
||
IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert |
6 |
} |
||
] |
||
[{NTE}] |
Notes and Comments |
2 |
RPR^I03 |
Return Patient List |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
3 |
{ |
||
PRD |
Provider Data |
11 |
[{CTD}] |
Contact Data |
11 |
} |
||
[{PID}] |
Patient Identification |
3 |
[{NTE}] |
Notes and Comments |
2 |
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.
RQP^I04 |
Request Patient Demographics |
Chapter |
MSH |
Message Header |
2 |
{ |
||
PRD |
Provider Data |
11 |
[{CTD}] |
Contact Data |
11 |
} |
||
PID |
Patient Identification |
3 |
[{NK1}] |
Next of Kin/Associated Parties |
6 |
[{GT1}] |
Guarantor |
6 |
[{NTE}] |
Notes and Comments |
2 |
This
event is used to request clinical information for a specific patient.
Generally, this transaction occurs between one provider and another (typically
a laboratory or radiology, etc.). However, it may also be very useful for a
payor-to-provider request for clinical observation information to be used in
considering a request for treatment authorization.
RQC^I05 |
Request Clinical Information |
Chapter |
MSH |
Message Header |
2 |
QRD |
Query Definition |
5 |
[QRF] |
Query Filter |
5 |
{ |
||
PRD |
Provider Data |
11 |
[{CTD}] |
Contact Data |
11 |
} |
||
PID |
Patient Identification |
3 |
[{NK1}] |
Next of Kin/Associated Parties |
6 |
[{GT1}] |
Guarantor |
6 |
[{NTE}] |
Notes and Comments |
2 |
This
event code is sent from one healthcare provider to another (typically a
laboratory or radiology, etc.) to request a list of available clinical
observation information. When the provider is dealing with a community model
in which remote requests make transmission of large amounts of data
impractical, this event code will provide for interactive lists of transactions
from which more specific selections can be made.
RQC^I06 |
Request Clinical Information |
Chapter |
MSH |
Message Header |
2 |
QRD |
Query Definition |
5 |
[QRF] |
Query Filter |
5 |
{ |
||
PRD |
Provider Data |
11 |
[{CTD}] |
Contact Data |
11 |
} |
||
PID |
Patient Identification3 |
|
[{NK1}] |
Next of Kin/Associated parties |
6 |
[ GT1 ] |
Guarantor |
6 |
[{NTE}] |
Notes and Comments |
2 |
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.
PIN^I07 |
Patient Insurance Information |
Chapter |
MSH |
Message Header |
2 |
{ |
||
PRD |
Provider Data |
11 |
[{CTD}] |
Contact Data |
11 |
} |
||
PID |
Patient Identification |
3 |
[{NK1}] |
Next of Kin/Associated Parties |
6 |
[[{GT1}] |
Guarantor |
6 |
{ |
||
IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info -Cert |
6 |
} |
||
] |
||
[{NTE}] |
Notes and Comments |
2 |
ACK^I07 |
General Acknowledgment |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error Information |
2 |
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.
All
trigger events in this group use the following message definition.
RQA^I08,I09,I10,I11 |
Request Patient Authorization |
Chapter |
MSH |
Message Header |
2 |
[RF1] |
Referral Information |
11 |
[ |
||
AUT |
Authorization Information |
11 |
[CTD] |
Contact Data |
11 |
] |
||
{ |
||
PRD |
Provider Data |
11 |
[{CTD}] |
Contact Data |
11 |
} |
||
PID |
Patient Identification |
3 |
[{NK1}] |
Next of Kin/Associated Parties |
6 |
[[{GT1}] |
Guarantor |
6 |
{ |
||
IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert |
6 |
} |
||
] |
||
[ ACC ] |
Accident Information |
6 |
[{DG1}] |
Diagnosis |
6 |
[{DRG}] |
Diagnosis Related Group |
6 |
[{AL1}] |
Allergy Information |
3 |
[ |
||
{ |
||
PR1 |
Procedure |
6 |
[ |
||
AUT |
Authorization Information |
11 |
[CTD] |
Contact Data |
11 |
] |
||
} |
||
] |
||
[ |
||
{ |
||
OBR |
Observation Request |
4 |
[{NTE}] |
Notes and Comments |
2 |
[ |
||
{ |
||
OBX |
Observation/Result |
7 |
[{NTE}] |
Notes and Comments |
2 |
} |
||
] |
||
} |
||
] |
||
[ |
||
PV1 |
Patient Visit |
3 |
[PV2] |
Patient Visit Additional Info |
3 |
] |
||
[{NTE}] |
Notes and Comments |
2 |
RPA^I08,I09,I10,I11 |
Return Patient Authorization |
Chapter |
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
3 |
[RF1] |
Referral Information |
11 |
[ |
||
AUT |
Authorization Information |
11 |
[CTD] |
Contact Data |
11 |
] |
||
{ |
||
PRD |
Provider Data |
11 |
[{CTD}] |
Contact Data |
11 |
} |
||
PID |
Patient Identification |
3 |
[{NK1}] |
Next of Kin/Associated Parties |
6 |
[{GT1}] |
Guarantor |
6 |
[ |
||
{ |
||
IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info - Cert |
6 |
} |
||
] |
||
[ ACC ] |
Accident Information |
6 |
[{DG1}] |
Diagnosis |
6 |
[{DRG}] |
Diagnosis Related Group |
6 |
[{AL1}] |
Allergy Information |
3 |
{ |
||
PR1 |
Procedure |
6 |
[ |
||
AUT |
Authorization Information |
11 |
[CTD] |
Contact Data |
11 |
] |
||
} |
||
[ |
||
{ |
||
OBR |
Observation Request |
4 |
[{NTE}] |
Notes and Comments |
2 |
[ |
||
{ |
||
OBX |
Observation/Result |
7 |
[{NTE}] |
Notes and Comments |
2 |
} |
||
] |
||
} |
||
] |
||
[ |
||
PV1 |
Patient Visit |
3 |
[PV2] |
Patient Visit Additional Info |
3 |
] |
||
[{NTE}] |
Notes and Comments |
2 |
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.3.2, "RQA/RPA - request for treatment authorization information (event
I08)," through 11.3.5, "RQA/RPA - request for cancellation of an authorization
(event I11)."
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.
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.
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.
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.
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.
The
trigger events that use this message definition are described in Sections
11.4.2, "REF/RRI - patient referral (event I12)," through 11.4.5, "REF/RRI -
request patient referral status (event I15)."
REF^I12,I13,I14,I15 |
Patient Referral |
Chapter |
MSH |
Message Header |
2 |
[RF1] |
Referral Information |
11 |
[ |
||
AUT |
Authorization Information |
11 |
[CTD] |
Contact Data |
11 |
] |
||
{ |
||
PRD |
Provider Data |
11 |
[{CTD}] |
Contact Data |
11 |
} |
||
PID |
Patient Identification |
3 |
[{NK1}] |
Next of Kin/Associated Parties |
6 |
[{GT1}] |
Guarantor |
6 |
[ |
||
{ |
||
IN1 |
Insurance |
6 |
[IN2] |
Insurance Additional Info |
6 |
[IN3] |
Insurance Add'l Info -Cert |
6 |
} |
||
] |
||
[ACC] |
Accident Information |
6 |
[{DG1}] |
Diagnosis |
6 |
[{DRG}] |
Diagnosis Related Group |
6 |
[{AL1}] |
Allergy Information |
3 |
[ |
||
{ |
||
PR1 |
Procedure |
6 |
[ |
||
AUT |
Authorization Information |
11 |
[CTD] |
Contact Data |
11 |
] |
||
} |
||
] |
||
[ |
||
{ |
||
OBR |
Observation Request |
4 |
[{NTE}] |
Notes and Comments |
2 |
[ |
||
{ |
||
OBX |
Observation/Result |
7 |
[{NTE}] |
Notes and Comments |
2 |
} |
||
] |
||
} |
||
] |
||
[ |
||
PV1 |
Patient Visit |
3 |
[PV2] |
Patient Visit Additional Info |
3 |
] |
||
[ |
||
PV1 |
Patient Visit |
3 |
[PV2] |
Patient Visit Additional Info |
3 |
] |
||
[{NTE}] |
Notes and Comments |
2 |
RRI^I12,I13,I14,I15 |
Return Referral Information |
Chapter |
MSH |
Message Header |
2 |
[MSA] |
Message Acknowledgment |
3 |
[RF1] |
Referral Information |
11 |
[ |
||
AUT |
Authorization Information |
11 |
[CTD] |
Contact Data |
11 |
] |
||
{ PRD |
Provider Data |
11 |
[{CTD}] |
Contact Data |
11 |
} |
||
PID |
Patient Identification |
3 |
[ACC] |
Accident Information |
6 |
[{DG1}] |
Diagnosis |
6 |
[{DRG}] |
Diagnosis Related Group |
6 |
[{AL1}] |
Allergy Information |
3 |
[ |
||
{ |
||
PR1 |
Procedure |
6 |
[ |
||
AUT |
Authorization Information |
11 |
[CTD] |
Contact Data |
11 |
] |
||
} |
||
] |
||
[ |
||
{ |
||
OBR |
Observation Request |
4 |
[{NTE}] |
Notes and Comments |
2 |
[ |
||
{ |
||
OBX |
Observation/Result |
7 |
[{NTE}] |
Notes and Comments |
2 |
} |
||
] |
||
} |
||
] |
||
[ |
||
PV1 |
Patient Visit |
3 |
[PV2] |
Patient Visit Additional Info |
3 |
] |
||
[{NTE}] |
Notes and Comments |
2 |
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.
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.
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.
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.
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.
This
segment represents information that may be useful when sending referrals from
the referring provider to the referred-to provider.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
200 |
CE |
O |
0283 |
01137 |
Referral Status | |
2 |
200 |
CE |
O |
0280 |
01138 |
Referral Priority | |
3 |
200 |
CE |
O |
0281 |
01139 |
Referral Type | |
4 |
200 |
CE |
O |
Y |
0282 |
01140 |
Referral Disposition |
5 |
200 |
CE |
O |
0284 |
01141 |
Referral Category | |
6 |
30 |
EI |
R |
01142 |
Originating Referral Identifier | ||
7 |
26 |
TS |
O |
01143 |
Effective Date | ||
8 |
26 |
TS |
O |
01144 |
Expiration Date | ||
9 |
26 |
TS |
O |
01145 |
Process Date | ||
10 |
200 |
CE |
O |
Y |
0336 |
01228 |
Referral Reason |
11 |
30 |
EI |
O |
Y |
01300 |
External Referral Identifier |
Components:
<identifier (ID)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ID)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the status of the referral as defined by
either the referred-to or the referred-by provider. Refer to user-defined
table 0283 - Referral status for suggested values.
Value |
Description |
A |
Accepted |
P |
Pending |
R |
Rejected |
E |
Expired |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the urgency of the referral. Refer to
user-defined table 0280 - Referral priority for suggested
values.
Value |
Description |
S |
STAT |
A |
ASAP |
R |
Routine |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the type of referral. It is loosely
associated with a clinical specialty or type of resource. Refer to
user-defined table 0281 - Referral type for suggested values.
Value |
Description |
|---|---|
Lab |
Laboratory |
Rad |
Radiology |
Med |
Medical |
Skn |
Skilled Nursing |
Psy |
Psychiatric |
Hom |
Home Care |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the type of response or action that the
referring provider would like from the referred-to provider. Refer to
user-defined table 0282 - Referral disposition for suggested values.
Value |
Description |
WR |
Send Written Report |
RP |
Return Patient After Evaluation |
AM |
Assume Management |
SO |
Second Opinion |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the location at which the referral will take
place. Refer to user-defined table 0284 - Referral category for
suggested values.
Value |
Description |
I |
Inpatient |
O |
Outpatient |
A |
Ambulatory |
E |
Emergency |
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains the originating application's permanent
identifier for the referral. This is a composite field.
The first component is a string of up to 15 characters that identifies an
individual referral. It is assigned by the originating application, and it
identifies a referral, and the subsequent referral transactions, uniquely among
all such referrals from a particular processing application.
The second component is optional because this field, itself, is already defined
as a referral identifier.
The third component is optional. If used, it should contain the application
identifier for the referred-to or external applications (i.e., not the
originating application). The application identifier is a string of up to 15
characters that is uniquely associated with an application. A given healthcare
provider facility, or group of intercommunicating healthcare provider
facilities, should establish a unique list of applications that may be
potential originators and recipients, and then assign unique application
identifiers to each of those applications. This list of application
identifiers becomes one of the healthcare provider facility's master dictionary
lists. Since applications fulfilling different application roles can send and
receive referral messages, the assigning authority application identifier may
not identify the application sending or receiving a particular message. Data
elements on the Message Header (MSH) segment are available to identify the
actual sending and receiving applications.
Definition: This field contains the date on which the referral is effective.
Definition: This field contains the date on which the referral expires.
Definition: This field contains the date on which the referral originated. It is used in cases of retroactive approval.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the reason for which the referral will take
place. Refer to user-defined table 0336 - Referral reason for suggested
values.
Value |
Description |
S |
Second Opinion |
P |
Patient Preference |
O |
Provider Ordered |
W |
Work Load |
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains an external application's permanent identifier
for the referral. That is, this referral identifier does not belong to the
application which originated the referral and assigned the originating referral
identifier.
The first component is a string of up to 15 characters that identifies an
individual referral. It is typically assigned by the referred-to provider
application responding to a referral originating from a referring provider
application, and it identifies a referral, and the subsequent referral
transactions, uniquely among all such referrals for a particular referred-to
provider processing application. For example, when a primary care provider
(referring provider) sends a referral to a specialist (referred-to provider),
the specialist's application system may accept the referral and assign it a new
referral identifier which uniquely identifies that particular referral within
the specialist's application system. This new referral identifier would be
placed in the external referral identifier field when the specialist responds
to the primary care physician.
The second component is optional because this field, itself, is already defined
as a referral identifier.
The third component is optional. If used, it should contain the application
identifier for the referred-to or external application (i.e., not the
originating application. The application identifier is a string of up to 15
characters that is uniquely associated with an application. A given healthcare
provider facility, or group of intercommunicating healthcare provider
facilities, should establish a unique list of applications that may be
potential originators and recipients, and then assign unique application
identifiers to each of those applications. This list of application
identifiers becomes one of the healthcare provider facility's master dictionary
lists. Since applications fulfilling different application roles can send and
receive referral messages, the assigning authority application identifier may
not identify the application sending or receiving a particular message. Data
elements on the Message Header (MSH) segment are available to identify the
actual sending and receiving applications.
This
segment represents an authorization or a pre-authorization for a referred
procedure or requested service by the payor covering the patient's health
care.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the ID of the coverage plan authorizing
treatment. Values should be entries in a locally-defined table of plan codes.
User defined table 0072- Insurance Plan ID is used as the HL7
identifier for the user-defined table of values for this field. .
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the ID of the insurance company or other
entity that administers the authorizing coverage plan. Values may be entries
in a locally-defined table of payor codes. User defined Table 0285 -
Insurance company ID codes, is used as the HL7 identifier for the
user-defined table of values for this field.
Definition: This field contains the name of the insurance company or other entity that administers the authorizing coverage plan.
Definition: This field contains the effective date of the authorization.
Definition: This field contains the expiration date after which the authorization to treat will no longer be in effect from the perspective of the coverage plan.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains the coverage application's permanent
identifier assigned to track the authorization and all related billing
documents. This field is conditionally required. It is not required when
authorization information is being requested. However, it is required when
this segment is contained in a message which is responding to a request and
contains the authorization information. This is a composite field.
The first component of this field is a string of up to 15 characters that
identifies an individual authorization. It is assigned by the coverage
application, and it identifies an authorization, and the subsequent billing
transactions resulting from the given authorization, uniquely among all such
authorizations granted from a particular processing application.
The second component is optional because this field, itself, is already defined
as an authorization identifier.
The third component is optional. If used it should contain the application
identifier for the coverage application. The application identifier is a string
of up to six characters that is uniquely associated with an application. A
given healthcare provider facility, or group of intercommunicating healthcare
provider facilities, should establish a unique list of applications that may be
potential originators and recipients, and then assign unique application
identifiers to each of those applications. This list of application
identifiers becomes one of the healthcare provider facility's master dictionary
lists. Since applications fulfilling different application roles can send and
receive referral messages containing authorizations, the coverage application
identifier may not identify the application sending or receiving a particular
message. Data elements on the Message Header (MSH) segment are available to
identify the actual sending and receiving applications.
Components:
<price (CP)> ^ <price type (ID)> ^ <from value (NM)> ^
<to value (NM)> ^ <range units (CE)> ^ <range type
(ID)>
Definition: This field contains the dollar limit for reimbursement specified
by the coverage plan for the authorized treatment.
Definition: This field contains the requested number of times that the treatment may be administered to the patient without obtaining additional authorization.
Definition: This field contains the number of times that the authorized treatment may be administered to the patient without obtaining additional authorization.
Definition: This field contains the date that the authorization originated with the authorizing party.
This
segment will be employed as part of a patient referral message and its related
transactions. The PRD segment contains data specifically focused on a
referral, and it is inter-enterprise in nature. The justification for this new
segment comes from the fact that we are dealing with referrals that are
external to the facilities that received them. Therefore, using a segment such
as the current PV1 would be inadequate for all the return information that may
be required by the receiving facility or application. In addition, the PV1
does not always provide information sufficient to enable the external facility
to make a complete identification of the referring entity. The information
contained in the PRD segment will include the referring provider, the
referred-to provider, the referred-to location or service, and the referring
provider clinic address.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
1 |
200 |
CE |
R |
Y |
0286 |
01155 |
Provider Role |
2 |
106 |
XPN |
O |
Y |
01156 |
Provider Name | |
3 |
60 |
XAD |
O |
Y |
01157 |
Provider Address | |
4 |
60 |
PL |
O |
01158 |
Provider Location | ||
5 |
100 |
XTN |
O |
Y |
01159 |
Provider Communication Information | |
6 |
200 |
CE |
O |
0185 |
00684 |
Preferred Method of Contact | |
7 |
100 |
CM |
O |
Y |
01162 |
Provider Identifiers | |
8 |
26 |
TS |
O |
01163 |
Effective Start Date of Provider Role | ||
9 |
26 |
TS |
O |
01164 |
Effective End Date of Provider Role |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the contact role that defines the relationship
of the person described in this segment to the patient being referred. When a
referral is inter-enterprise in nature, there are several important
relationships that must be identified. For example, the proper identification
of both the referring and the referred-to provider is critical for proper
processing of a referral. In addition, some enterprises may want information
regarding a consulting provider or the identity of the person who actually
prepared the referral. This contact role may also expand to represent
affiliated persons to whom information regarding this referral must be
forwarded or copied. Refer to user-defined table 0286 - Provider role
for suggested values.
Value |
Description |
RP |
Referring Provider |
PP |
Primary Care Provider |
CP |
Consulting Provider |
RT |
Referred to Provider |
Components:
<family name (IS)> ^ <given name (IS)> & <last name prefix
(IS)> ^ <middle initial or name (IS)> ^ <suffix (e.g., JR or III)
(IS)> ^ <prefix (e.g., DR) (IS)> ^ <degree (e.g., MD) (IS)> ^
<name type code (ID)> ^ <name representation code (ID)>
Definition: This field contains the name of the provider identified in this
segment. Generally, this field will describe a physician associated with the
referral. However, it is not limited to physicians. This field may contain
the name of any valid healthcare provider associated with this referral. If
this Provider Name is a physician's name, you may refer to PRD-7-provider
identifiers for the physician identifier.
Components:
<street address (ST)> ^ <other designation (ST)> ^ <city
(ST)> ^ <state or province (ST)> ^ <zip or postal code(ST)> ^
<country (ID)> ^ < address type (ID)> ^ <other geographic
designation (ST)> ^ <county/parish code (IS)> ^ <census
tract (IS)> ^ <address representation code (ID)>
Definition: This field contains the mailing address of the provider identified
in this segment. One of the key components to completing the "circle of care"
and provider/institution bonding is the issuance of follow-up correspondence to
the referring provider.
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location type
(IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS) & <universal ID
(ST)> & <universal ID type (ID)>
Definition: This field contains the location of the provider as needed when a
provider that may be external to a given enterprise must be referenced. For
example, if this provider represented the referred-to physician, the
PRD-4-provider location should identify the clinic of the physician or
provider to whom this referral has been sent. The identification of the
provider's location is specified by an application and facility identifier
carried in the facility field. The application ID and facility ID would be
used in the same manner as their corresponding fields in the MSH segment
(MSH-3-sending application, MSH-5-receiving application MSH-4-sending
facility, MSH-6-receiving facility). That is, the facility field will
contain an application identifier and facility identifier which describe the
location of this provider. However, it should be noted that they may describe
a different location because the provider location being referenced in this
field may not be the location from which the message originated, which
is being described by the MSH.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication
use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email
address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^
<phone number (NM)> ^ <extension (NM)> ^ <any text
(ST)>
Definition: This field contains information, such as the phone number or
electronic mail address, used to communicate with the provider or organization.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the preferred method to use when communicating
with the provider. Refer to user-defined table 0185 - Preferred method of
contact for suggested values.
Components:
<ID number (ST)> ^ <type of ID number (IS)> ^ <other qualifying
info (ST)>
Definition: This repeating field contains the provider's unique identifiers
such as UPIN, Medicare and Medicaid numbers. Refer to PRA-6-practitioner ID
numbers in Chapter 8 (Section 8.6.3.6, "Practitioner ID numbers") for
suggested values.
Definition: This field contains the date that the role of the provider effectively began. For example, this date may represent the date on which a physician was assigned as a patient's primary care provider.
Definition:
This field contains the date that the role of the provider effectively ended.
For example, this date may represent the date that a physician was removed as a
patient's primary care provider.
Note: The PRD-8-effective start date of role and
PRD-9-effective end date of role fields should not be used as
trigger events. For example, they should not be used to trigger a change in
role. These two dates are for informational purposes only.
The
CTD segment may identify any contact personnel associated with a patient
referral message and its related transactions. The CTD segment will be paired
with a PRD segment. The PRD segment contains data specifically focused on
provider information in a referral. While it is important in an
inter-enterprise transaction to transmit specific information regarding the
providers involved (referring and referred-to), it may also be important to
identify the contact personnel associated with the given provider. For
example, a provider receiving a referral may need to know the office manager or
the billing person at the institution of the provider who sent the referral.
This segment allows for multiple contact personnel to be associated with a
single provider.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
200 |
CE |
R |
Y |
0131 |
00196 |
Contact Role |
2 |
106 |
XPN |
O |
Y |
01165 |
Contact Name | |
3 |
200 |
XAD |
O |
Y |
01166 |
Contact Address | |
4 |
60 |
PL |
O |
01167 |
Contact Location | ||
5 |
100 |
XTN |
O |
Y |
01168 |
Contact Communication Information | |
6 |
200 |
CE |
O |
0185 |
00684 |
Preferred Method of Contact | |
7 |
100 |
CM |
O |
Y |
01171 |
Contact Identifiers |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the contact role that defines the relationship
of the person described in this segment to the patient being referred. When a
referral is inter-enterprise in nature, there are some important relationships
that must be identified. For example, it may be necessary to identify the
contact representative at the clinic that sent the referral. User defined
table 0131 - Contact role is used as the HL7 identifier for the
user-defined table of values for this field.
Components:
<family name (IS)> ^ <given name (IS)> & <last name prefix
(IS)> ^ <middle initial or name (IS)> ^ <suffix (e.g., JR or III)
(IS)> ^ <prefix (e.g., DR) (IS)> ^ <degree (e.g., MD) (IS)> ^
<name type code (ID)> ^ <name representation code (ID)>
Definition: This field contains the name of the contact person identified in
this segment. Generally, this field will describe a person or provider
associated with the referral. If this contact name is a physician, you may
refer to the CTD-7-contact identifiers (Section 11.5.4.7) for the
physician identifier.
Components:
<street address (ST)> ^ <other designation (ST)> ^ <city
(ST)> ^ <state or province (ST)> ^ <zip or postal code(ST)> ^
<country (ID)> ^ < address type (ID)> ^ <other geographic
designation (ST)> ^ <county/parish code (IS)> ^ <census
tract (IS)> ^ <address representation code (ID)>
Definition: This field contains the mailing address of the contact person
identified in this segment. One of the key components for completing the
"circle of care" and provider/institution bonding is the issuance of follow-up
correspondence to the referring provider.
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location type
(IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS) & <universal ID
(ST)> & <universal ID type (ID)>
Definition: This field contains the location of the contact, which is required
when a contact that may be external to a given enterprise must be referenced.
For example, if this contact represents the office manager of the referred-to
physician, then the contact location should identify the clinic of the
physician or provider to whom this referral has been sent. The identification
of the contact's location is specified by an application and facility
identifier carried in the facility field. The application identifier and the
facility identifier would be used in the same manner as their corresponding
fields in the MSH segment (MSH-3-sending application, MSH-5-receiving
application, MSH-4-sending facility, MSH-6-receiving facility). That is,
the facility field will contain an application identifier and facility
identifier which describe the location of this contact. However, it should be
noted that they may describe a different location because the contact location
being referenced in this field may not be the location from which the
message originated, which is being described by the MSH.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication
use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email
address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^
<phone number (NM)> ^ <extension (NM)> ^ <any text
(ST)>
Definition: This field contains the information, such as the phone number or
electronic mail address, used to communicate with the contact person or
organization.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the preferred method to use when communicating
with the contact person. Refer to user-defined table 0185 - Preferred
method of contact for suggested values.
Components:
<ID number (ST)> ^ <type of ID number (IS)> ^ <other qualifying
info (ST)>
Definition: This repeating field contains the contact's unique identifiers
such as UPIN, Medicare and Medicaid numbers. Refer to Chapter 8 (Section
8.6.3.6, "Practitioner ID numbers") for suggested values.
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.
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. Blake is sending an insurance information request to the
Washington State Insurance Company for her patient, Cary Joe Brown. 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|^~\&|BLAKEMD|EWHIN|MSC|EWHIN|19940107155043||RQI^I01|BLAKEM7888|P|2.3.1|||NE|AL<cr>
PRD|RP|BLAKE^BEVERLY^^^DR^MD|N. 12828 NEWPORT HIGHWAY^^MEAD^WA^99021|
^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL CENTER|BLAKEM7899<cr>
PRD|RT|WSIC||^^^MSC&EWHIN^^^^^WASHINGTON STATE INSURANCE
COMPANY<cr>
PID|||402941703^9^M10||BROWN^CARY^JOE||19600309||||||||||||402941703<cr>
IN1|1|PPO|WA02|WSIC (WA State Code)|<cr>
MSH|^~\&|MSC|EWHIN|BLAKEMD|EWHIN|19940107155212||RPI^I01|MSC2112|P|2.3.1|||ER|ER<cr>
MSA|AA|BLAKEM7888|ELIGIBILITY INFORMATION FOUND<cr>
PRD|RP|BLAKE^BEVERLY^^^DR^MD|N. 12828 NEWPORT HIGHWAY^^MEAD^WA^99021|
^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL CENTER|BLAKEM7899<cr>
PRD|RT|WSIC||^^^MSC&EWHIN^^^^^WASHINGTON STATE INSURANCE
COMPANY<cr>
PID|||402941703^9^M10||BROWN^CARY^JOE||19600301||||||||||||402941703,CR>
IN1|1|PPO|WA02|WSIC (WA State Code)|11223 FOURTH STREET^^MEAD^WA^99021^USA|ANN
MILLER|509)333-1234|987654321||||19901101||||BROWN^CARY^JOE|1|19600309|N. 12345
SOME STREET^^MEAD^WA^99021^USA|||||||||||||||||402941703||||||01|M<cr>
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 Washington State Insurance Company for a colonoscopy on
Cary Joe Brown. 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|^~\&|BLAKEMD|EWHIN|MSC|EWHIN|19940110105307||RQA^I08|BLAKEM7898|P|2.3.1|||NE|AL<cr>
PRD|RP|BLAKE^BEVERLY^^^DR^MD|N. 12828 NEWPORT HIGHWAY^^MEAD^WA^99021|
^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL CENTER|BLAKEM7899<cr>
PRD|RT|WSIC||^^^MSC&EWHIN^^^^^WASHINGTON STATE INSURANCE
COMPANY<cr>
PID|||402941703^9^M10||BROWN^CARY^JOE||19600309||||||||||||402941703<cr>
IN1|1|PPO|WA02|WSIC (WA State Code)|11223 FOURTH STREET^^MEAD^WA^99021^USA|ANN
MILLER|509)333-1234|987654321||||19901101||||BROWN^CARY^JOE|1|19600309|N. 12345
SOME STREET^^MEAD^WA^99021^USA|||||||||||||||||402941703||||||01|M<cr>
DG1|1|I9|569.0|RECTAL POLYP|19940106103500|0<cr>
PR1|1|C4|45378|Colonoscopy|19940110105309|00<cr>
MSH|^~\&|MSC|EWHIN|BLAKEMD|EWHIN|19940110154812||RPA^I08|MSC2112|P|2.3.1|||ER|ER<cr>
MSA|AA|BLAKEM7888<cr>
PRD|RP|BLAKE^BEVERLY^^^DR^MD|N. 12828 NEWPORT HIGHWAY^^MEAD^WA^99021|
^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL CENTER|BLAKEM7899<cr>
PRD|RT|WSIC||^^^MSC&EWHIN^^^^^WASHINGTON STATE INSURANCE
COMPANY<cr>
PID|||402941703^9^M10||BROWN^CARY^JOE||19600301||||||||||||402941703<cr>
IN1|1|PPO|WA02|WSIC (WA State Code)|11223 FOURTH STREET^^MEAD^WA^99021^USA|ANN
MILLER|(509)333-1234|987654321||||19901101||||BROWN^CARY^JOE|1|19600309|N.
12345 SOME
STREET^^MEAD^WA^99021^USA|||||||||||||||||402941703||||||01|M<cr>
DG1|1|I9|569.0|RECTAL POLYP|19940106103500|0<cr>
PR1|1|C4|45378|Colonoscopy|19940110105309|00<cr>
AUT|PPO|WA02|WSIC (WA State Code)|19940110|19940510|123456789|175|1<cr>
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|^~\&|BLAKEMD|EWHIN|MSC|EWHIN|19940110105307||RQA^I08|BLAKEM7898|P|2.3.1|||AL|AL<cr>
PRD|RP|BLAKE^BEVERLY^^^DR^MD|N. 12828 NEWPORT HIGHWAY^^MEAD^WA^99021|
^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL CENTER|BLAKEM7899<cr>
PRD|RT|WSIC||^^^MSC&EWHIN^^^^^WASHINGTON STATE INSURANCE
COMPANY<cr>
PID|||402941703^9^M10||BROWN^CARY^JOE||19600301||||||||||||402941703<cr>
IN1|1|PPO|WA02|WSIC (WA State Code)|11223 FOURTH STREET^^MEAD^WA^99021^USA|ANN
MILLER|(509)333-1234|987654321||||19901101||||BROWN^CARY^JOE|1|19600309|N.
12345 SOME
STREET^^MEAD^WA^99021^USA|||||||||||||||||402941703||||||01|M<cr>
PR1|1|C4|45378|Colonoscopy|19940110105309|00<cr>
MSH|^~\&|MSC|EWHIN|BLAKEMD|EWHIN|1994011015315||MCF|MSC2112|P|2.3.1|||ER|ER<cr>
MSA|AA|BLAKEM7888<cr>
MSH|^~\&|MSC|EWHIN|BLAKEMD|EWHIN|19940111102304||RPA^I08|MSC2113|P|2.3.1|||ER|ER<cr>
MSA|AA|BLAKEM7888<cr>
PRD|RP|BLAKE^BEVERLY^^^DR^MD|N. 12828 NEWPORT HIGHWAY^^MEAD^WA^99021|
^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL CENTER|BLAKEM7899<cr>
PRD|RT|WSIC||^^^MSC&EWHIN^^^^^WASHINGTON STATE INSURANCE
COMPANY<cr>
PID|||402941703^9^M10||BROWN^CARY^JOE||19600301||||||||||||402941703<cr>
IN1|1|PPO|WA02|WSIC (WA State Code)|11223 FOURTH STREET^^MEAD^WA^99021^USA|ANN
MILLER|509)333-1234|987654321||||19901101||||BROWN^CARY^JOE|1|19600309|N. 12345
SOME STREET^^MEAD^WA^99021^USA|||||||||||||||||402941703||||||01|M<cr>
PR1|1|C4|45378|Colonoscopy|19940110105309|00<cr>
AUT|PPO|WA02|WSIC (WA State Code)|19940110|19940510|123456789|175|1<cr>
Once
pre-authorization has been received, the patient is referred to the referral
provider. In the following example, Dr. Blake is referring Cary Joe Brown to
Dr. Jose Jimenez 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|^~\&|BLAKEMD|EWHIN|JIME|EWHIN|19940111113142||REF^I11|BLAKEM7899|P|2.3.1|||NE|AL<cr>
RF1||R|MED|RP|O|REF4502|19940111|19940510|19940111<cr>
PRD|RP|BLAKE^BEVERLY^^^DR^MD|N. 12828 NEWPORT HIGHWAY^^MEAD^WA^99021|
^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL CENTER|BLAKEM7899<cr>
CTD|PR|JONES^BUCK|N. 12828 NEWPORT
HIGHWAY^^MEAD^WA^99021|^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL
CENTER<cr>
PRD|RT|JIMENEZ^JOSE^^^DR||^^^JIME&EWHIN^^^^^JIMENEZ AND
SMITH||||531886<cr>
PID|||1234567891^1^M10||BROWN^CARY^JOE||19600309|M||C|N. 12345 SOME
STREET^^MEAD^WA^99021^USA|SPO|(509)466-6801|(509)466-0396|ENGL|M|M||402941703|
BROWN*CJ4298^WA<cr>
NK1|1|BROWN^KATHARINA^LOU|2|N. 12345 SOME
STREET^^MEAD^WA^99021^USA|(509)466-6801<cr>
GT1|1||BROWN^CARY^JOE||N. 12345 SOME
STREET^^MEAD^WA^99021^USA|(509)466-6801|(509)466-0396|19600309|M||1|402941703||||
WISMER*MARTIN|||456789|01<cr>
IN1|1|PPO|WA02|WSIC (WA State Code)|11223 FOURTH STREET^^MEAD^WA^99021^USA|ANN
MILLER|509)333-1234|987654321||||19901101||||BROWN^CARY^JOE|1|19600309|N. 12345
SOME STREET^^MEAD^WA^99021^USA|||||||||||||||||402941703||||||01|M<cr>
ACC|19940105125700|WR|WISMER*MARTIN<cr>
DG1|1|I9|569.0|RECTAL POLYP|19940106103500|0<cr>
PR1|1|C4|45378|Colonoscopy|19940110105309|00<cr>
AUT|PPO|WA02|WSIC (WA State
Code)|19940110|19940510|123456789|175|1<cr>
MSH|^~\&|JIME|EWHIN|BLAKEMD|EWHIN|19940111152401||RRI^I11|JIME1123|P|2.3.1|||ER|ER<cr>
MSA|AA|BLAKEM7899<cr>
RF1|A|R|MED|RP|O|REF4502|19940111|19940510|19940111<cr>
PRD|RP|BLAKE^BEVERLY^^^DR^MD|N. 12828 NEWPORT HIGHWAY^^MEAD^WA^99021|
^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL CENTER|BLAKEM7899<cr>
CTD|PR|JONES^BUCK|N. 12828 NEWPORT
HIGHWAY^^MEAD^WA^99021|^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL
CENTER<cr>
PRD|RT|JIMENEZ^JOSE^^^DR||^^^JIME&EWHIN^^^^^JIMENEZ AND
SMITH||||531886<cr>
PID|||1234567891^1^M10||BROWN^CARY^JOE||19600309|M||C|N. 12345 SOME
STREET^^MEAD^WA^99021^USA|SPO|(509)466-6801|(509)466-0396|ENGL|M|M||402941703|
BROWN*CJ4298^WA<cr>
DG1|1|I9|569.0|RECTAL POLYP|19940106103500|0<cr>
PR1|1|C4|45378|Colonoscopy|19940111141509|00<cr>
NTE|||Patient is doing well.~Full recovery expected.<cr>
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|^~\&|BLAKEMD|EWHIN|JIME|EWHIN|19940111113142||REF^I11|BLAKEM7899|P|2.3.1|||AL|AL<cr>
RF1||R|MED|RP|O|REF4502|19940111|19940510|19940111<cr>
PRD|RP|BLAKE^BEVERLY^^^DR^MD|N. 12828 NEWPORT HIGHWAY^^MEAD^WA^99021|
^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL CENTER|BLAKEM7899<cr>
CTD|PR|JONES^BUCK|N. 12828 NEWPORT
HIGHWAY^^MEAD^WA^99021|^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL
CENTER<cr>
PRD|RT|JIMENEZ^JOSE^^^DR||^^^JIME&EWHIN^^^^^JIMENEZ AND
SMITH||||531886<cr>
PID|||1234567891^1^M10||BROWN^CARY^JOE||19600309|M||C|N. 12345 SOME
STREET^^MEAD^WA
^99021^USA|SPO|(509)466-6801|(509)466-0396|ENGL|M|M||402941703|BROWN*CJ4298^WA<cr>
NK1|1|BROWN^KATHARINA^LOU|2|N. 12345 SOME
STREET^^MEAD^WA^99021^USA|(509)466-6801<cr>
GT1|1||BROWN^CARY^JOE||N. 12345 SOME STREET^^MEAD^WA^99021^USA|(509)466-6801
|(509)466-0396|19600309|M||1|402941703||||WISMER*MARTIN|||456789|01<cr>
IN1|1|PPO|WA02|WSIC (WA State Code)|11223 FOURTH STREET^^MEAD^WA^99021^USA|ANN
MILLER|(509)333-1234|987654321||||19901101||||BROWN^CARY^JOE|1|19600309|N.
12345 SOME
STREET^^MEAD^WA^99021^USA|||||||||||||||||402941703||||||01|M<cr>
ACC|19940105125700|WR|WISMER*MARTIN<cr>
DG1|1|I9|569.0|RECTAL POLYP|19940106103500|0<cr>
PR1|1|C4|45378|Colonoscopy|19940110105309|00<cr>
AUT|PPO|WA02|WSIC (WA State
Code)|19940110|19940510|123456789|175|1<cr>
MSH|^~\&|JIME|EWHIN|BLAKEMD|EWHIN|19940111154812||MCF|JIME1123|P|2.3.1|||ER|ER<cr>
MSA|AA|BLAKEM7899<cr>
MSH|^~\&|JIME|EWHIN|BLAKEMD|EWHIN|19940112152401||RRI^I11|JIME1124|P|2.3.1|||ER|ER<cr>
MSA|AA|BLAKEM7899<cr>
RF1|A|R|MED|RP|O|REF4502|19940111|19940510|19940111<cr>
PRD|RP|BLAKE^BEVERLY^^^DR^MD|N. 12828 NEWPORT
HIGHWAY^^MEAD^WA^99021|^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL
CENTER|BLAKEM7899<cr>
CTD|PR|JONES^BUCK|N. 12828 NEWPORT
HIGHWAY^^MEAD^WA^99021|^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL
CENTER<cr>
PRD|RT|JIMENEZ^JOSE^^^DR||^^^JIME&EWHIN^^^^^JIMENEZ AND
SMITH||||531886<cr>
PID|||1234567891^1^M10||BROWN^CARY^JOE||19600309|M||C|N. 12345 SOME
STREET^^MEAD^WA^
99021^USA|SPO|(509)466-6801|(509)466-0396|ENGL|M|M||402941703|BROWN*CJ4298^WA<cr>
DG1|1|I9|569.0|RECTAL POLYP|19940106103500|0<cr>
PR1|1|C4|45378|Colonoscopy|19940111141509|00<cr>
NTE|||Patient is doing well.~Full recovery expected.<cr>
In
this example, Dr. Blake is querying a reference laboratory for the results of
all lab work performed on Cary Joe Brown between the dates of 03/20/94 and
03/22/94 and requests that the data be returned in a record or data elemented
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|^~\&|BLAKEMD|EWHIN|EHS_LAB|EWHIN|19940410113142||RQC^I05|BLAKEM7899|P|2.3.1|||NE|AL<cr>
QRD|19940504144501|R|I|BLAKEM7899|||5^RD|PATIENT|RES|ALL<cr>
QRF|EHS_LAB^EWHIN|19940320000000|19940322235959<cr>
PRD|RP|BLAKE^BEVERLY^^^DR^MD|N.12828NEWPORT
HIGHWAY^^MEAD^WA^99021|^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL
CENTER|BLAKEM7899<cr>
CTD|PR|JONES^BUCK|N. 12828 NEWPORT
HIGHWAY^^MEAD^WA^99021|^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL
CENTER<cr>
PRD|RT|EMPLAB^EMPIRE LAB||^^^EHS_LAB&EWHIN^^^^^EIMPIRE
LABORATORIES<cr>
PID|||1234567891^1^M10||BROWN^CARY^JOE||19600309|M||C|N.12345SOME
STREET^^MEAD^WA^
99021^USA|SPO|(509)466-6801|(509)466-0396|ENGL|M|M||402941703|BROWN*CJ4298^WA<cr>
MSH|^~\&|EHS_LAB|EWHIN|BLAKEMD|EWHIN|19940411152401||RPI^I05|EHSLAB4250|P|2.3.1|||ER|ER<cr>
MSA|AA|BLAKEM7899<cr>
QRD|19940504144501|R|I|BLAKEM7899|||5^RD|PATIENT|RES|ALL<cr>
QRF|EHS_LAB^EWHIN|19940320000000|19940322235959<cr>
PRD|RP|BLAKE^BEVERLY^^^DR^MD|N. 12828 NEWPORT
HIGHWAY^^MEAD^WA^99021|^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL
CENTER|BLAKEM7899<cr>
CTD|PR|JONES^BUCK|N. 12828 NEWPORT
HIGHWAY^^MEAD^WA^99021|^^^BLAKEMD&EWHIN^^^^^BLAKE MEDICAL
CENTER<cr>
PRD|RT|EMPLAB^EMPIRE LAB||^^^EHS_LAB&EWHIN^^^^^EIMPIRE
LABORATORIES<cr>
PID|||1234567891^1^M10||BROWN^CARY^JOE||19600309|M||C|N. 12345 SOME
STREET^^MEAD^WA^
99021^USA|SPO|(509)466-6801|(509)466-0396|ENGL|M|M||402941703|BROWN*CJ4298^WA<cr>
OBR|1||1045813^LAB|L1505.003^COMPLETE BLOOD COUNT
(D)|||19940320104700|""|1^EA||||
|19940320112400||CARMI||||||19940320104955|||F<cr>
OBX|1|ST|L1550.000^HEMOGLOBIN, AUTO
HEME||11.6|g/dl|12.0-16.0|L|||F<cr>
OBX|2|ST|L1551.003^HEMATOCRIT (D)||36.4|%|36-45||||F<cr>
OBX|3|ST|L1552.000^RBC, AUTO HEME||3.94|mil/ul|4.1-5.1|L|||F<cr>
OBX|4|ST|L1553.000^MCV, AUTO HEME||92.3.1|fl|80-100||||F<cr>
OBX|5|ST|L1554.000^MCH, AUTO HEME||29.3|pg|26-34||||F<cr>
OBX|6|ST|L1555.000^MCHC, AUTO HEME||31.8|g/dl|31-37||||F<cr>
OBX|7|ST|L1557.000^RBC DISTRIBUTION WIDTH||15.3|%|0-14.8|H|||F<cr>
OBX|8|ST|L1558.003^PLATELET COUNT (D)||279|th/ul|140-440||||F<cr>
OBX|9|ST|L1559.000^WBC, AUTO HEME||7.9|th/ul|4.5-11.0||||F<cr>
OBX|10|ST|L1561.100^NEUTROPHILS, % AUTO||73.8|%|||||F<cr>
OBX|11|ST|L1561.510^LYMPHOCYTES, % AUTO||16.6|%|||||F<cr>
OBX|12|ST|L1562.010^MONOCYTES, % AUTO||7.3|%|||||F<cr>
OBX|13|ST|L1563.010^EOSINOPHILS, % AUTO||1.7|%|||||F<cr>
OBX|14|ST|L1564.010^BASOPHILS, % AUTO||0.7|%|||||F<cr>
OBX|15|ST|L1565.010^NEUTROPHILS, ABS AUTO||5.8|th/ul|1.8-7.7||||F<cr>
OBX|16|ST|L1566.010^LYMPHOCYTES, ABS AUTO||1.3|th/ul|1.0-4.8||||F<cr>
OBX|17|ST|L1567.010^MONOYCYTES, ABS AUTO||0.6|th/ul|0.1-0.8||||F<cr>
OBX|18|ST|L1568.010^EOSINOPHILS, ABS AUTO||0.1|th/ul|0-0.7||||F<cr>
OBX|19|ST|L1569.000^BASOPHILS, ABS AUTO||0.1|th/ul|0-0.2||||F<cr>
OBX|20|ST|L2110.003^PROTHROMBIN TIME
(D)||30.7|sec|11.1-14.0|HH|||F<cr>
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)<cr>
OBX|21|ST|L2110.500^INR||5.95||||||F<cr>
NTE|1|L|Therapeutic Range (oral anticoagulant):~ Most clinical situations:
2.0 - 3.0~ Mech heart valve, recurrent embolism: 3.0 - 4.0<cr>
OBX|22|ST|L3110.003^SODIUM (D)||141|mmol/l|135-146||||F<cr>
OBX|23|ST|L3111.003^POTASSIUM (D)||3.8|mmol/l|3.5-5.1||||F<cr>
OBX|24|ST|L3112.003^CHLORIDE (D)||111|mmol/l|98-108|H|||F<cr>
OBX|25|ST|L3113.003^CO2 (TOTAL) (D)||23.7|mmol/l|23-30||||F<cr>
OBX|26|ST|L3114.000^ANION GAP||6||7-17|L|||F<cr>
OBX|27|ST|L3120.003^CREATININE (D)||1.4|mg/dl|0.5-1.2|H|||F<cr>
OBX|28|ST|L3121.003^UREA NITROGEN (D)||24|mg/dl|7-25||||F<cr>
OBX|29|ST|L3123.003^GLUCOSE (D)||123|mg/dl|65-115|H|||F<cr>
OBX|30|ST|L3126.003^CALCIUM (D)||8.7|mg/dl|8.4-10.2||||F<cr>
OBR|2||1045825^LAB|L2560.000^BLOOD GAS, ARTERIAL (R)|||19940320105800|""|
1^EA|||||19940320105800||CARMI||||||19940320105844|||F<cr>
OBX|1|ST|L2565.000^PH, ARTERIAL BLD GAS (R)||7.46||7.35-7.45|H|||F<cr>
OBX|2|ST|L2566.000^PCO2, ARTERIAL BLOOD GAS||28|mm/Hg|35-45|LL|||F<cr>
NTE|1|L|BLOOD GAS ANALYSIS CRITICAL VALUE(S) CALLED TO~DR.
CARLSON.<cr>
OBX|3|ST|L2567.000^PO2, ARTERIAL BLOOD GAS||83|mm/Hg|80-100||||F<cr>
OBX|4|ST|L2568.000^O2 SAT, ART BLD GAS (R)||96|%|95-99||||F<cr>
OBX|5|ST|L2569.000^BASE EX, ARTERIAL BLD
GAS||-2.1|mEq/l|-2.0-2.0|L|||F<cr>
OBX|6|ST|L2570.000^HCO3, ARTERIAL BLD GAS||19.4|mEq/l|22-26|L|||F<cr>
OBX|7|ST|L2571.000^PATIENT TEMP, ABG||96.2|deg F|||||F<cr>
OBX|8|ST|L2572.000^MODE, ABG||ROOM AIR||||||F<cr>
OBR|3||1045812^LAB|L2310.003^URINALYSISD)|||19940320121800|""|1^EA|||||19940320121800||CARMI||||||19940320104953|||F<cr>
OBX|1|ST|L2320.303^SPECIFIC GRAVITY, UR
(D)||1.015||1.002-1.030||||F<cr>
OBX|2|ST|L2320.403^PH, UR (D)||7.0||5.0-7.5||||F<cr>
OBX|3|ST|L2320.503^PROTEIN, QUAL, UR (D)||NEG|mg/dl|||||F<cr>
OBX|4|ST|L2320.703^GLUCOSE, QUAL, UR (D)||0|mg/dl|0-30||||F<cr>
OBX|5|ST|L2320.803^KETONES, UR (D)||NEG|mg/dl|||||F<cr>
OBX|6|ST|L2320.903^OCCULT BLOOD, UR (D)||SMALL|||A|||F<cr>
OBX|7|ST|L2321.003^BILIRUBIN, UR (D)||NEG||||||F<cr>
OBX|8|ST|L2321.100^LEUKOCYTES, UR||MOD|||A|||F<cr>
OBX|9|ST|L2321.200^NITRITES, UR||NEG||||||F<cr>
OBX|10|ST|L2321.300^UROBILINOGEN, UR||NEG||||||F<cr>
OBX|11|ST|L2342.000^MICRO SPUN VOLUME, UR||8|ml|8-8||||F<cr>
OBX|12|ST|L2350.003^RBC, UR (D)||5-10|/hpf|||||F<cr>
OBX|13|ST|L2350.100^WBC, UR||>100|/hpf|||||F<cr>
OBX|14|ST|L2350.200^EPITHELIAL CELLS, UR||2+||||||F<cr>
OBX|15|ST|L2350.300^BACTERIA, UR||2+|||A|||F<cr>
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.3.
The HL7 Patient Referral Chapter addresses business needs that the X12
transaction does not (e.g., transmission of codified clinical data).