HL7 CSU_C09 Scheduled Clinical Study Data Report

HL7 message structure CSU_C09 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

SegmentNameRequiredRepeatable
Message Header Yes No
Software Segment No Yes
CSU_C09.PATIENT
Patient group Yes Yes
Patient Identification Yes No
Patient Additional Demographic No No
Notes and Comments No Yes
CSU_C09.VISIT
Visit group No No
Patient Visit Yes No
Patient Visit - Additional Information No No
Clinical Study Registration Yes No
CSU_C09.STUDY_PHASE
Study Phase group Yes Yes
Clinical Study Phase No No
CSU_C09.STUDY_SCHEDULE
Study Schedule group Yes Yes
Clinical Study Data Schedule Segment No No
CSU_C09.STUDY_OBSERVATION
Study Observation group Yes Yes
Common Order No No
Observation Request Yes No
CSU_C09.TIMING_QTY
Timing Quantity group No Yes
Timing/Quantity Yes No
Timing/Quantity Relationship No Yes
Observation/Result Yes Yes
CSU_C09.ORCRXARXR_SUPPGRP
Orcrxarxr Suppgrp group Yes Yes
Common Order No No
CSU_C09.RXARXR_SUPPGRP
Rxarxr Suppgrp group Yes Yes
Pharmacy/Treatment Administration Yes No
Pharmacy/Treatment Route Yes No

CSU_C09 is a clinical study data update message for automated reporting intervals, such as monthly or protocol-defined submissions. You will see it in older clinical trial and sponsor-reporting interfaces more often than in ordinary hospital ADT/order/result traffic.

The practical idea is simple: identify the patient and study, identify the study phase and scheduled time point, then send the observations or administrations that satisfy that time point.

A small CSU C09 example

MSH|^~\&|TRIALS|CITYHOSP|SPONSOR|REMOTE|20260728110000||CSU^C09^CSU_C09|CSUC090001|P|2.5.1 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F CSR|STUDY-2026-07^SPONSOR|ALT-77^CITYHOSP|CITYHOSP^City Hospital^L|SUBJ-10045^^^SPONSOR^AN||20260718113000|7788^Trial^Tara|9911^Oncologist^Owen CSP|CYCLE1^Cycle 1^L|20260718113000 CSS|DAY-28^Day 28 assessment^L|20260728100000 OBR|1||STUDYLAB001^TRIALS|CBC^Complete blood count^L|||20260728100000 OBX|1|NM|WBC^White blood cells^L||6.2|10*9/L|||||F RXA|0|1|20260728103000|20260728103000|TRIALDRUG^Trial drug dose^L|1|TAB^tablet^UCUM RXR|PO^Oral^HL70162

What systems do with it

A trial or data-capture system sends CSU_C09 when a reporting interval is due. The receiver may be a sponsor gateway, research data warehouse, safety system, or internal monitoring application. Receivers usually key off the study ID, subject ID, phase, and schedule point before looking at the clinical data.

The data can look familiar because it uses segments also seen in ordinary clinical messages: OBR and OBX for observations, plus RXA and RXR for administrations. The trial wrapper is what changes the meaning.

How to read the structure

PID identifies the patient. Optional PD1, NTE, PV1, and PV2 can add demographic and visit context.

CSR identifies the study registration. CSP identifies the study phase. CSS identifies the scheduled time point. Then the repeating observation and administration groups carry the data that belongs to that schedule.

Implementation traps

The common mistake is validating the OBR/OBX or RXA/RXR content and ignoring the schedule. In clinical trial reporting, an otherwise good lab result can be rejected because it is attached to the wrong phase or scheduled time point.

Also be explicit about corrections. If a monthly report is resent with corrected observations, the receiver needs a clear replacement or correction rule. CSU_C09 itself does not magically solve study-data versioning.

Reference notes

HL7 v2 clinical study administration defines CSU_C09 for automated time-interval study reporting and uses CSR, CSP, CSS, observation, and administration groups to bind data to trial context. This page keeps the guidance intentionally short because CSU_C09 is a specialized legacy workflow.