HL7 RCI messages return clinical information about a patient — observations, results, and diagnoses — in response to an earlier request. An RCI message is sent as the reply to an RQI-style request for clinical information in a referral workflow, carrying back the clinical data the requesting system asked for and acknowledging the original request. This page explains what an RCI message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an RCI return relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an RCI message represents
An RCI message — RCI stands for Return Clinical Information — supplies the clinical information that another system requested about a patient in a referral. Where the request asked the holding system for a patient's clinical record, the RCI carries the answer: the observations and results in the OBR and OBX segments, and the diagnoses in the DG1 segment. The MSA segment acknowledges the request the RCI is answering, so the requester can correlate the returned data to the query it issued.
The core clinical content sits in a repeating OBSERVATION group built from OBR and OBX: the OBR names the service or panel and the observation date and time, and each OBX carries one observation value. 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 clinical information belongs to. The RCI is therefore both an acknowledgement of the request and a container for the clinical result set.
When an RCI message is sent
An RCI message is sent when a system that holds a patient's clinical record returns that record in answer to a request for clinical information. 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 data, and the holding system replies with an RCI carrying the requested observations and diagnoses, with MSA acknowledging the request.
Trigger event
The RCI message type carries a single trigger event:
RCI^I05— Request for patient clinical information (return). The RCI is the response to an RQI^I05request, returning the requested clinical data — observations, results, and diagnoses — for the patient named in the referral.
Because RCI has one trigger event, the receiver's handling turns on the contents of the message — the observations in OBX, the diagnoses in DG1, 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 RCI response through the integration engine to the requesting referral system.
{{diagram: clinical record system → RCI 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 RCI message returns the clinical data that an earlier RQI request solicited, and acknowledges that request through MSA.
Segments in an RCI message
The RCI message opens with MSH and optional acknowledgement, error, and query segments, then carries a repeating PROVIDER group that holds the patient, diagnoses, 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 result. 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 RCI message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (RCI^I05), 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 RCI 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 data 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 information 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 data 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 record being returned. |
[{DG1}] | Diagnosis. Carries the patient's diagnoses returned with the clinical information — the diagnosis code and description in DG1-3, the diagnosis type in DG1-6, and the diagnosis date/time in DG1-5. Optional and repeating, so a patient with several diagnoses produces several DG1 segments. |
{OBR} | Observation Request. Opens the OBSERVATION group and names the service or panel for the returned results — the universal service identifier in OBR-4 and the observation date and time in OBR-7. Required and repeating; the OBSERVATION group repeats once per result set returned. |
[{NTE}] | Notes and Comments. Notes that apply to the preceding OBR as a whole. Optional and repeating. |
[{OBX}] | Observation/Result. Carries a single returned observation — the value type in OBX-2, the observation identifier in OBX-3, the value in OBX-5, the units in OBX-6, 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 result, following the observation. Optional and repeating. |
[{NTE}] | Notes and Comments. Trailing notes that apply to the PROVIDER group as a whole, after the observation results. Optional and repeating. |
[ ] = optional, { } = repeating
The PROVIDER group from PRD through its trailing NTE repeats once per provider involved in the referral, and the OBSERVATION group from OBR through its OBX entries repeats once per returned result set. The canonical segment pages carry the full field-by-field detail.
Sample RCI message
Note. Constructed for illustration. Patient identifiers, provider identifiers, observation values, dates, and names are fictional.
MSH|^~&|CLINREPO|SPECIALTYMED|REFAPP|CITYMED|20260604091500||RCI^I05^RCI_I05|MSG00091|P|2.5.1
MSA|AA|MSG00047
QRD|20260604083000|R|I|QRY00047|||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
DG1|1||E11.9^Type 2 diabetes mellitus without complications^I10|Type 2 diabetes mellitus|20260520|F
OBR|1|||4548-4^Hemoglobin A1c^LN|||20260601080000
OBX|1|NM|4548-4^Hemoglobin A1c^LN||7.2|%|4.0-5.6|H|||F
OBX|2|NM|2345-7^Glucose^LN||142|mg/dL|70-99|H|||F
What this sample shows
The RCI^I05 in MSH-9 marks a return of clinical information, and MSA acknowledges request MSG00047 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. DG1 returns a diagnosis of type 2 diabetes (E11.9). The OBR names the Hemoglobin A1c service observed on 20260601, and the two OBX segments return the results: an A1c of 7.2 % and a glucose of 142 mg/dL, both flagged high (H) and final (F).
Working with RCI 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 RCI 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 clinical payload.
Read the clinical data from OBR/OBX and DG1
The returned results live in the OBSERVATION group: the OBR names the service and observation time, and each OBX carries one value with its units in OBX-6 and its result status in OBX-11. The diagnoses live in DG1. Parse the full repeating OBSERVATION group and all DG1 segments rather than reading only the first result, because a single RCI commonly returns a panel of observations and several diagnoses.
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 RCI to arrive more than once. Treating a repeated control id as a duplicate prevents the requesting system from posting the same clinical results or diagnoses twice.
Honour the OBX result status
OBX-11 records whether each observation is final (F), preliminary (P), or corrected (C). Surface this status rather than treating every returned value as final — a preliminary or corrected result 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 clinical information conceptually corresponds to a FHIR Bundle of DiagnosticReport and Observation resources — the OBR mapping to a DiagnosticReport, each OBX to an Observation, and each DG1 to a Condition — 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 RCI_I05 and no ConceptMap for the PRD provider data segment. A FHIR DiagnosticReport and Observation set produced from an RCI message is therefore mapped manually, deriving the report and observations from the OBR/OBX group, the conditions from DG1, the patient from PID, and the providers from the RP- and RT-role PRD segments.
Common pitfalls
Pitfall. Processing the clinical payload without checking
MSA-1. An RCI may acknowledge a request that could not be satisfied —ARorAEinMSA-1with anERRsegment explaining why. Reading the observations without first checking the acknowledgement code posts results for a request the sender actually rejected.
Pitfall. Reading only the first
OBXand ignoring the rest. The OBSERVATION group repeats, so a returned panel carries severalOBXsegments; processing only the first loses the remaining results. Parse the full repeating group.
Pitfall. Assuming every returned observation 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 RCI messages
Vorro receives RCI 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 the returned observations from the repeating OBR/OBX group and the diagnoses from DG1. Where a FHIR destination is configured, Vorro maps the return to a Bundle of DiagnosticReport and Observation resources — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- RQI — the request for patient information that an RCI message answers in the referral workflow.
- REF — the patient referral message that initiates a clinical referral, within which clinical information is requested and returned.
- RCL — the request for clinical information list, a related referral query in the same message family.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for RCI_I05
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for PRD
- HL7 Messaging Standard Version 2.5.1 product brief
