HL7 CSU Messages: Unsolicited Study Data

HL7 CSU messages push clinical study data — trial enrollment records, phase transitions, and collected observations — from a clinical system to a study data management system without a prior query. A CSU message is sent whenever the source system has study data to report: an initial value, an updated value, a single data point, or a complete dataset. This page explains what a CSU message represents, the four trigger events that carry it, every segment the message can contain and what each one holds, and how a CSU message relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What a CSU message represents

A CSU message — CSU stands for Unsolicited Study Data — communicates that a clinical system has study-related data to transmit to a study data management system. The core of the message is the CSR segment, the Clinical Study Registration segment, which anchors the patient to a sponsor-defined study. Every piece of study data in a CSU message — phase records, scheduled time points, and collected observations — is subordinate to and organised around a CSR.

The sender is the clinical information system that records patient participation in a trial, and the receivers are the study data management systems, electronic data capture (EDC) platforms, and sponsor systems that must receive subject and observation data. CSU sits at the interface between the clinical care setting and the research data pipeline: the clinical system knows what happened to the patient; the study data management system needs a structured record of it as a trial observation.

When a CSU message is sent

A CSU message is sent whenever the clinical system has study data to push downstream, without waiting for a query. One patient in one study can generate a sequence of CSU messages over the life of a trial — from initial enrollment through each scheduled visit to final data lock — and the trigger event in MSH-9 communicates the nature of the data being pushed.

Trigger events

The CSU message type carries four trigger events:

• CSU^C09 – Unsolicited initial value for study. Sent when a patient is first enrolled in the study and an initial observation value is being reported.
• CSU^C10 – Unsolicited updated value for study. Sent when a previously transmitted value is being corrected or updated.
• CSU^C11 – Unsolicited data value for study. Sent to push a study data value that does not fit the initial or complete categories — typically a single observation collected at a scheduled time point.
• CSU^C12 – Unsolicited complete data value for study. Sent when a full, final dataset for the patient's participation in the study is being transmitted.

The trigger event tells the receiving study data management system whether it is seeing enrollment data, a correction, a routine observation push, or a complete final dataset, so that it can apply the appropriate processing and storage rules.

Integration topology

The diagram shows the clinical system emitting a study data event through the integration engine to the study data management system and sponsor platform.

{{diagram: clinical information system → CSU message → integration engine → study data management system / EDC platform / sponsor system}}

Typical senders: clinical information system (CIS), electronic health record, laboratory system, or other care-delivery platform that records trial activity.

Typical receivers: study data management system (SDMS), electronic data capture (EDC) platform, sponsor safety and regulatory database, and clinical trial management system (CTMS).

Direction: unidirectional notification from the clinical source to the research data pipeline; CSU carries no acknowledgement payload beyond the standard ACK.

Segments in a CSU message

The CSU message is organised into a mandatory PATIENT group (PID through optional VISIT subgroup) and one or more STUDY groups anchored by CSR. Within each STUDY group, an optional series of CSP phase segments precedes one or more STUDY_OBSERVATION subgroups, each opening with an optional CSS scheduled time point and containing optional order and result segments. 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.

[ ] = optional, { } = repeating

The STUDY group from CSR through the STUDY_OBSERVATION subgroups repeats once per study, and the STUDY_OBSERVATION subgroup repeats once per scheduled time point, so a single CSU message can carry a subject's complete multi-visit, multi-phase dataset in one transmission. The canonical segment pages carry the full field-by-field detail.

Sample CSU message

Note. Constructed for illustration. Patient identifiers, study identifiers, dates, and names are fictional.

MSH|^~&|CLINICALSYS|GENERALHOSP|SDMS|SPONSOR01|20260604083000||CSU^C09^CSU_C09|MSG00034|P|2.5.1
PID|1||SUB00142^^^GENERALHOSP^MR||SMITH^JANE^M||19750315|F
CSR|TRIAL-2024-007^SPONSOR01|ALT-NCT00000007|GENERALHOSP|SP-00142^^^SPONSOR01^SUBJ|20260601|20260604083000
CSP|PHASE1^Screening Phase^L|20260601000000
CSS|BASELINE^Baseline Visit^L|20260604000000
ORC|RE|ORD20260604-001^CLINICALSYS|FIL20260604-001^SDMS
OBR|1|ORD20260604-001^CLINICALSYS|FIL20260604-001^SDMS|VITALS^Vital Signs^L|||20260604083000
OBX|1|NM|8310-5^Body temperature^LN||37.1|Cel|36.1-37.2||||F|||20260604083000
OBX|2|NM|8867-4^Heart rate^LN||72|/min|60-100||||F|||20260604083000
OBX|3|NM|55284-4^Blood pressure^LN||120^80|mm[Hg]|<140/90||||F|||20260604083000

What this sample shows

The CSU^C09 in MSH-9 marks an unsolicited initial value push — the patient's first study data transmission. PID identifies the subject with medical record number SUB00142. The CSR anchors the subject to sponsor study TRIAL-2024-007 (alternate ID ALT-NCT00000007), registered at GENERALHOSP, with sponsor subject ID SP-00142 and registration date 20260601. The CSP places the subject in PHASE1 (Screening Phase), which began on 20260601. The CSS identifies the BASELINE scheduled time point, scheduled for 20260604. The ORC carries the order linking the observations to the clinical order record, and the OBR names the Vital Signs battery collected at 20260604083000. Three OBX segments carry body temperature (37.1 °C), heart rate (72 /min), and blood pressure (120/80 mm[Hg]), each with result status F (final).

Working with CSU messages

CSR is the anchor — validate it first

The CSR segment is the prerequisite for every observation in the message. Before processing any CSP, CSS, or OBX data, confirm that CSR-1 (sponsor study ID) and CSR-4 (sponsor patient ID) resolve to known records in the receiving study data management system. A CSR that cannot be matched should cause the entire message to be rejected and queued for investigation rather than partially processed.

Use the trigger event to drive processing rules

The four trigger events carry distinct semantics that should drive different processing paths. A C09 initial value should create a new subject record if one does not exist; a C10 updated value should update an existing record and log the change; a C11 data value should append the observation to the existing dataset; a C12 complete value should mark the subject's dataset as final and lock it against further amendment. Routing all four to the same processing path silently conflates enrollments, corrections, and final lock events.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key. Clinical trial feeds are replayed after outages, and treating a repeated control id as a duplicate prevents a replayed enrollment or observation from creating duplicate records in the study database. The natural business key for a subject observation is the combination of CSR-1 (study), CSR-4 (sponsor patient ID), CSS-1 (scheduled time point), and OBX-3 (observation identifier) together with the observation date-time in OBX-14.

Nested group structure requires careful parsing

The CSU message is more deeply nested than most HL7 v2 messages: observations in OBX are children of a battery in OBR, which is a child of a scheduled time point in CSS, which is a child of a phase in CSP, which is a child of a study registration in CSR. A parser that flattens the segment stream without tracking group boundaries will mis-assign observations to the wrong time point or phase when a single message carries multiple phases or time points.

Vendor variance. The CSP phase segment and the CSS time-point segment are both optional, and some clinical systems omit them even when the protocol defines phases and time points. Confirm a partner's field and group usage against their interface specification; do not assume that CSP will always be present in a multi-phase trial.

FHIR equivalent

A clinical study registration and its associated observations correspond conceptually to the FHIR ResearchSubject resource (for the enrollment record in CSR) and Observation resources (for the data values in OBX), with the patient as a Patient resource, the study as a ResearchStudy resource, and, for a messaging exchange, a MessageHeader at the head of a Bundle.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for CSU and no ConceptMap for the CSR clinical study registration segment — the clinical trial messaging group (C-series) is not covered in the current published maps. A FHIR ResearchSubject produced from a CSU message is therefore mapped manually, taking the study identifier and subject identifier from CSR and deriving the ResearchSubject status from the trigger event; OBX observations map to FHIR Observation resources following the same pattern used for ORU results.

Common pitfalls

Pitfall. Processing all four trigger events identically. A C10 updated value must overwrite and audit-trail a prior value; treating it as a new C09 initial value creates a duplicate subject record rather than correcting the existing one.

Pitfall. Parsing the segment stream without tracking group boundaries. OBX segments belong to the OBR immediately above them, which belongs to the CSS time point above that, which belongs to the CSR study registration. A flat parse that ignores nesting assigns observations to the wrong phase or time point when a message carries multiple CSR or CSS repetitions.

Pitfall. Assuming CSP is always present in a phased trial. Some senders omit CSP for studies that define phases but do not report them via HL7; accepting a message without CSP does not mean the trial has no phases.

How Vorro handles CSU messages

Vorro ingests the CSU feed over MLLP or another transport, deduplicates on MSH-10, and routes each study data message to every subscribed destination in the format that system expects — the SDMS, EDC platform, or sponsor database. Vorro reads the study registration from CSR, the phase from CSP, the scheduled time point from CSS, and the observations from OBX, preserving the nested group structure so that each observation is correctly attributed to its time point, phase, and study. The trigger event in MSH-9 drives the processing rule applied at each destination — create, update, append, or lock — and, where a FHIR destination is configured, Vorro maps the enrollment to a ResearchSubject resource and each observation to an Observation resource, composed manually since the v2-to-FHIR Implementation Guide publishes no map for this message.

Related messages

• CRM — the clinical study registration message used to explicitly register or update a patient's study enrollment.
• CQU — the unsolicited notification of a clinical trial event, complementary to the data push in CSU.
• ORU — the unsolicited observation result message, which shares the OBR/OBX observation structure used inside a CSU STUDY_OBSERVATION subgroup.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for CSU
• HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for CSR
• HL7 Messaging Standard Version 2.5.1 product brief