HL7 RCL messages return a structured list of clinical items about a patient — problems, allergies, medications, and observations — in response to an earlier request. An RCL message is sent as the reply to an RQI-style request for a clinical-information list in a referral workflow, carrying back the list of clinical items the requesting system asked for and acknowledging the original request. This page explains what an RCL message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an RCL return relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an RCL message represents
An RCL message — RCL stands for Return Clinical List — supplies the clinical list that another system requested about a patient in a referral. Where the request asked the holding system for the patient's list of problems, allergies, medications, or observations, the RCL carries the answer: each list item is delivered through the OBR and OBX segments of a repeating OBSERVATION group. The MSA segment acknowledges the request the RCL is answering, so the requester can correlate the returned list to the query it issued.
The core clinical content sits in a repeating OBSERVATION group built from OBR and OBX: the OBR names the kind of list — problem list, allergy list, medication list, observation list — and the observation date and time, and each OBX carries one item from the list. Surrounding that, the PRD segment identifies the providers in the referral — PRD-1 carries the role code RP for the referring provider and RT for the referred-to provider — and the PID segment identifies the patient the list belongs to. The RCL is therefore both an acknowledgement of the request and a container for the returned clinical list.
When an RCL message is sent
An RCL message is sent when a system that holds a patient's clinical record returns a list of clinical items from that record in answer to a request for a clinical-information list. It is the response leg of a request/response exchange within a referral: the requesting system issues an RQI-style request for the patient's clinical list, and the holding system replies with an RCL carrying the requested list items, with MSA acknowledging the request.
Trigger event
The RCL message type carries a single trigger event:
RCL^I06— Request/receipt of clinical data listing (return). The RCL is the response to an RQI^I06request, returning the requested clinical list — problems, allergies, medications, or observations — for the patient named in the referral.
Because RCL has one trigger event, the receiver's handling turns on the contents of the message — the list items in OBX and the acknowledgement code in MSA — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the system holding the clinical record returning an RCL response through the integration engine to the requesting referral system.
{{diagram: clinical record system → RCL message → integration engine → referring provider system / referral management application}}
Typical senders: the referred-to provider's EHR, a clinical data repository, or another provider system holding the patient's record.
Typical receivers: the referring provider's EHR, practice management system, or referral management application that issued the request.
Direction: request/response — the RCL message returns the clinical list that an earlier RQI request solicited, and acknowledges that request through MSA.
Segments in an RCL message
The RCL message opens with MSH and optional acknowledgement, error, and query segments, then carries a repeating PROVIDER group that holds the patient and a nested OBSERVATION group. The PROVIDER group — opening with PRD and optionally followed by CTD — repeats once per provider involved in the referral, and within it the OBSERVATION group from OBR through its OBX entries repeats once per list item returned. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every RCL message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (RCL^I06), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
[{MSA}] | Message Acknowledgement. Acknowledges the RQI request the RCL is answering — the acknowledgement code in MSA-1 and the control id of the request being acknowledged in MSA-2. Optional and repeating; lets the requester correlate the returned clinical list to its original query. |
[{ERR}] | Error. Carries any error detected in processing the request — the location and code of the problem. Optional and repeating; present when the request could not be fully satisfied. |
[{QRD}] | Query Definition. Echoes the query parameters from the original request — the query date/time, format, priority, and subject. Optional and repeating; the optional QRF filter follows it within the same group. |
[QRF] | Query Filter. Refines the QRD query with filter criteria such as a date range or status. Optional; present only when the QUERY group is present and the request carried a filter. |
{PRD} | Provider Data. The key segment of the PROVIDER group and the most important segment in the message. Identifies a provider involved in the referral: the provider role in PRD-1 (RP = referring provider, RT = referred-to provider), the provider name in PRD-2, the provider address in PRD-4 through PRD-6, and the provider identifier (NPI or other) in PRD-7. The PROVIDER group repeats once per provider, so a referral with a referring and a referred-to provider carries two PRD segments. |
[{CTD}] | Contact Data. Contact information for the provider identified in the preceding PRD — name, address, and telecommunication details for the contact person at that provider. Optional and repeating within each PROVIDER group. |
PID | Patient Identification. Identifies the patient the clinical list belongs to — the identifier list in PID-3, the patient name in PID-5, date of birth in PID-7, and sex in PID-8. Required; lets the requesting system match the returned list to the correct patient record. |
[{NK1}] | Next of Kin/Associated Parties. The patient's next of kin or associated persons. Optional and repeating; included when relevant to the clinical list being returned. |
[{NTE}] | Notes and Comments. Notes that apply to the PROVIDER group as a whole, before the observation results. Optional and repeating. |
{OBR} | Observation Request. Opens the OBSERVATION group and names the kind of list being returned — the universal service identifier in OBR-4 (problem list, allergy list, medication list, observation list) and the observation date and time in OBR-7. Required and repeating; the OBSERVATION group repeats once per list returned. |
[{NTE}] | Notes and Comments. Notes that apply to the preceding OBR as a whole. Optional and repeating. |
[{OBX}] | Observation/Result. Carries a single item from the returned clinical list — the value type in OBX-2, the item identifier in OBX-3, the value in OBX-5, the units in OBX-6 where applicable, and the result status in OBX-11. Optional and repeating within each OBSERVATION group; each OBX may itself be followed by its own repeating NTE notes. |
[{NTE}] | Notes and Comments. Notes relative to a specific OBX item, following the observation. Optional and repeating. |
[ ] = optional, { } = repeating
The PROVIDER group from PRD through its trailing OBSERVATION entries repeats once per provider involved in the referral, and the OBSERVATION group from OBR through its OBX entries repeats once per returned clinical list. The canonical segment pages carry the full field-by-field detail.
Sample RCL message
Note. Constructed for illustration. Patient identifiers, provider identifiers, list values, dates, and names are fictional.
MSH|^~&|CLINREPO|SPECIALTYMED|REFAPP|CITYMED|20260604091500||RCL^I06^RCL_I06|MSG00092|P|2.5.1
MSA|AA|MSG00048
QRD|20260604083000|R|I|QRY00048|||1^RD|PAT98765^^^CITYMED^MR|RES|ALL
PRD|RP|SMITH^CAROL^A^^^DR|123 MAIN ST^^CHICAGO^IL^60601^USA|||1234567890^NPI
PRD|RT|JONES^ROBERT^B^^^DR|456 OAK AVE^^CHICAGO^IL^60602^USA|||0987654321^NPI
PID|1||PAT98765^^^CITYMED^MR||JOHNSON^MARY^E||19750315|F
OBR|1|||PROBLIST^Problem List^L|||20260604080000
OBX|1|CE|E11.9^Type 2 diabetes mellitus without complications^I10||||||||F
OBX|2|CE|I10^Essential hypertension^I10||||||||F
OBR|2|||ALGYLIST^Allergy List^L|||20260604080000
OBX|1|CE|7980^Penicillin^RXNORM||Hives^Hives^L|||||F
OBR|3|||MEDLIST^Medication List^L|||20260604080000
OBX|1|CE|860975^Metformin 500 MG Oral Tablet^RXNORM||500 mg BID|||||F
What this sample shows
The RCL^I06 in MSH-9 marks a return of a clinical list, and MSA acknowledges request MSG00048 with code AA, tying the response back to the originating RQI. The first PRD carries role code RP (referring provider) and identifies Dr. Carol Smith with NPI 1234567890; the second PRD carries role code RT (referred-to provider) and identifies Dr. Robert Jones with NPI 0987654321. PID identifies the patient as Mary Johnson with medical record number PAT98765. Three OBSERVATION groups follow: the first OBR names the Problem List and carries two OBX items — type 2 diabetes (E11.9) and essential hypertension (I10); the second OBR names the Allergy List and carries one OBX item — a penicillin allergy with a hives reaction; the third OBR names the Medication List and carries one OBX item — metformin 500 mg BID. Every item is flagged final (F).
Working with RCL messages
Correlate the response through MSA
The MSA segment carries the acknowledgement code in MSA-1 and the control id of the request being answered in MSA-2. Use MSA-2 to correlate the RCL back to the RQI request that solicited it, and read MSA-1 to know whether the request was satisfied (AA), rejected (AR), or errored (AE) before processing the list payload.
Read each list from its own OBR/OBX group
The returned list lives in the OBSERVATION group: the OBR names the kind of list — problem, allergy, medication, observation — and the observation time, and each OBX carries one item from that list. A single RCL commonly returns several lists in several OBSERVATION groups, so parse the full repeating structure and dispatch each OBX according to the OBR-4 list identifier that introduced it; treating every OBX the same way loses the distinction between a problem, an allergy, and a medication.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key. Referral workflows frequently involve retries — a network timeout or an acknowledgement failure can cause the same RCL to arrive more than once. Treating a repeated control id as a duplicate prevents the requesting system from posting the same problem, allergy, or medication twice.
Honour the OBX result status
OBX-11 records whether each list item is final (F), preliminary (P), or corrected (C). Surface this status rather than treating every returned item as final — a preliminary or corrected medication or problem must be presented and reconciled differently from a final one, and discarding the status loses clinically significant context.
Vendor variance. The
QRD/QRFquery segments are optional and their population varies widely between senders. Some systems echo the original query parameters back inQRD; others omit the QUERY group entirely and rely onMSA-2alone to correlate the response. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A return of a clinical list conceptually corresponds to a FHIR Bundle of resources — each problem on the list mapping to a Condition, each allergy to an AllergyIntolerance, each medication to a MedicationStatement, and each observation to an Observation — with the patient as a Patient resource and, for a messaging exchange, a MessageHeader at the head of the Bundle.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for RCL_I06 and no ConceptMap for the PRD provider data segment. A FHIR Bundle produced from an RCL message is therefore mapped manually, deriving the Condition, AllergyIntolerance, MedicationStatement, and Observation resources from the OBR/OBX groups according to the list kind named in OBR-4, the patient from PID, and the providers from the RP- and RT-role PRD segments.
Common pitfalls
Pitfall. Processing the list payload without checking
MSA-1. An RCL may acknowledge a request that could not be satisfied —ARorAEinMSA-1with anERRsegment explaining why. Reading the list items without first checking the acknowledgement code posts data for a request the sender actually rejected.
Pitfall. Treating every
OBXas the same kind of clinical item. The OBSERVATION group repeats once per list, and the kind of list — problem, allergy, medication, observation — is named inOBR-4. Reading theOBXsegments without first reading theOBRthat introduces them collapses distinct clinical lists into an undifferentiated stream.
Pitfall. Assuming every returned item is final.
OBX-11may beP(preliminary) orC(corrected) as well asF(final); treating a preliminary or corrected value as final misrepresents the clinical record.
How Vorro handles RCL messages
Vorro receives RCL messages over MLLP or another transport, deduplicates on MSH-10, and correlates each response back to its originating RQI request through MSA-2. Vorro reads the acknowledgement code in MSA before processing the payload, parses the RP- and RT-role PRD segments to identify the referring and referred-to providers, extracts the patient from PID, and reads each returned list from its own repeating OBR/OBX group, dispatching items by the list kind named in OBR-4. Where a FHIR destination is configured, Vorro maps the return to a Bundle of Condition, AllergyIntolerance, MedicationStatement, and Observation resources — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- RCI — the return of clinical information that answers a request for the patient's clinical record, the sibling response message in the same referral query family.
- RQI — the request for patient information that an RCL message answers in the referral workflow.
- REF — the patient referral message that initiates a clinical referral, within which clinical lists are requested and returned.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for RCL_I06
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for PRD
- HL7 Messaging Standard Version 2.5.1 product brief
