NEWFree ROI Calculators — quantify what prior auth and siloed data are costing your organization.Prior Auth ROI Siloed Data ROI
HL7 v2Segment7 min read

HL7 CSR Segment: Clinical Study Registration

The CSR (Clinical Study Registration) segment records the enrollment of an individual patient into a sponsored clinical study. It binds a patient to a study sponsor identifier, captures the registering institution, and timestamps the moment of registration along with consent, eligibility, randomization, and study-exit details. CSR is the anchor segment of a patient's clinical-study record and is typically the first of the clinical-study group followed by CSP and CSS.

Purpose

CSR exists to assert that a specific patient has been registered into a specific clinical study under a specific sponsor. It conveys the administrative and protocol identifiers needed to track a subject across the study lifecycle: the sponsor's study identifier, the sponsor's patient identifier, the registering and authorizing providers, consent and eligibility status, randomization arm and stratum, and the date and reason a patient ended the study. Downstream systems use CSR to reconcile subject enrollment against a study protocol and to drive evaluability reporting.

Used in

CSR carries patient clinical-study registration data inside CSU (Unsolicited Study Data) messages. Within a CSU message the clinical-study group normally appears after PID, with CSR establishing the registration, CSP describing the study phase, and CSS describing the data-collection schedule.

  • CSU — Unsolicited Study Data: see /academy/hl7/messages/csu

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (CSR.html). Length is shown as ; Required and Table # are taken from the HL7 v2.5.1 standard where well-established.

SeqNameData TypeLengthReqRepeatTable #Description
CSR-1Sponsor Study IDeiRSponsor's primary identifier for the study
CSR-2Alternate Study IDeiOSecondary or local identifier for the study
CSR-3Institution Registering the PatientceOFacility that registered the patient
CSR-4Sponsor Patient IDcxOSponsor's identifier for the study patient
CSR-5Alternate Patient ID - CSRcxOSecondary or local patient identifier
CSR-6Date/Time Of Patient Study RegistrationtsOWhen the patient was registered into study
CSR-7Person Performing Study RegistrationxcnOYIndividual who performed the registration
CSR-8Study Authorizing ProviderxcnOYProvider authorizing study participation
CSR-9Date/time Patient Study Consent SignedtsOWhen the patient signed study consent
CSR-10Patient Study Eligibility StatusceOEligibility determination for the study
CSR-11Study Randomization Date/timetsOYWhen the patient was randomized
CSR-12Randomized Study ArmceOYTreatment arm assigned at randomization
CSR-13Stratum for Study RandomizationceOYStratification group for randomization
CSR-14Patient Evaluability StatusceOWhether patient data is evaluable
CSR-15Date/time Ended StudytsOWhen the patient ended the study
CSR-16Reason Ended StudyceOCoded reason the patient ended study

Most-used fields

  • CSR-1 Sponsor Study ID: the required key that ties every clinical-study segment to one protocol.
  • CSR-4 Sponsor Patient ID: the sponsor-assigned subject identifier used for cross-system reconciliation.
  • CSR-6 Date/Time Of Patient Study Registration: the enrollment timestamp that opens the subject record.
  • CSR-10 Patient Study Eligibility Status: drives whether the subject contributes to analysis cohorts.
  • CSR-12 Randomized Study Arm: the assigned treatment arm for randomized trials.
  • CSR-15 / CSR-16 Date and Reason Ended Study: close out the subject and explain discontinuation.

Version differences (2.3 to 2.8.2)

  • The clinical-study segments (CSR, CSP, CSS) were introduced in HL7 v2.3 to support the CSU unsolicited study-data message.
  • Through 2.3.1 and 2.4 the field roster of CSR remained stable, with randomization and evaluability fields present from the outset.
  • In 2.5 and 2.5.1 the coded fields continued to use CE; this page reflects the 2.5.1 structure as published in the HAPI javadocs.
  • From 2.6 onward, many coded fields across the standard migrated toward CWE; implementers targeting 2.7 through 2.8.2 should confirm whether a partner expresses CSR coded fields as CE or CWE.
  • No fields have been removed from CSR across these releases; differences are primarily data-type normalization rather than field additions.

Common mistakes

  • Omitting CSR-1 Sponsor Study ID, which the standard requires; without it the segment cannot be tied to a protocol.
  • Confusing CSR-4 Sponsor Patient ID with the PID-3 patient identifier; they serve different identity domains.
  • Sending only one occurrence of CSR-7 or CSR-8 when multiple authorizing providers exist; both fields repeat.
  • Treating CSR-12 Randomized Study Arm as free text instead of a coded value.
  • Populating CSR-15 Date/time Ended Study without CSR-16 Reason Ended Study, leaving discontinuation unexplained.
  • Assuming CE components are interchangeable with CWE on partners running 2.7 or later.

Examples

Minimal CSR (required identifier and registration timestamp):

CSR|STUDY2024-ONC-17^^^SPONSOR^STUDY|||PT-90031^^^SPONSOR^MR||20260601103000

Fully populated CSR:

CSR|STUDY2024-ONC-17^^^SPONSOR^STUDY|ALT-ONC-17^^^SITE^LOCAL|RH001^Riverside Research Hospital^L|PT-90031^^^SPONSOR^MR|LOC-5521^^^SITE^MR|20260601103000|72811^Reyes^Maria^^^Dr^^^SPONSOR^L|44102^Okafor^Daniel^^^Dr^^^SPONSOR^L|20260530090000|ELIG^Eligible^L|20260601110000|ARM-B^Treatment Arm B^L|STRAT2^Stratum 2 Age 50-65^L|EVAL^Evaluable^L|20260612160000|COMPLETED^Protocol Completed^L

Annotated breakdown:

CSR-1  Sponsor Study ID ............ STUDY2024-ONC-17 (sponsor study domain)
CSR-2  Alternate Study ID .......... ALT-ONC-17 (local site identifier)
CSR-3  Institution Registering ..... RH001 Riverside Research Hospital
CSR-4  Sponsor Patient ID .......... PT-90031 (sponsor MR domain)
CSR-5  Alternate Patient ID ........ LOC-5521 (site MR domain)
CSR-6  Date/Time Registration ...... 2026-06-01 10:30:00
CSR-7  Person Performing Reg ....... Dr Maria Reyes (id 72811)
CSR-8  Study Authorizing Provider .. Dr Daniel Okafor (id 44102)
CSR-9  Consent Signed .............. 2026-05-30 09:00:00
CSR-10 Eligibility Status .......... ELIG Eligible
CSR-11 Randomization Date/time ..... 2026-06-01 11:00:00
CSR-12 Randomized Study Arm ........ ARM-B Treatment Arm B
CSR-13 Stratum ..................... STRAT2 Stratum 2 Age 50-65
CSR-14 Evaluability Status ......... EVAL Evaluable
CSR-15 Date/time Ended Study ....... 2026-06-12 16:00:00
CSR-16 Reason Ended Study .......... COMPLETED Protocol Completed

In context, inside a CSU unsolicited study-data message after PID:

MSH|^~&|EDC|SPONSOR|REG|SITE|20260601103500||CSU^C09^CSU_C09|MSG00451|P|2.5.1
PID|1||PT-90031^^^SPONSOR^MR||Doe^Jane^A||19710204|F
CSR|STUDY2024-ONC-17^^^SPONSOR^STUDY|||PT-90031^^^SPONSOR^MR||20260601103000|72811^Reyes^Maria^^^Dr|||ELIG^Eligible^L

A second in-context excerpt showing a study-exit registration:

MSH|^~&|EDC|SPONSOR|REG|SITE|20260612160500||CSU^C09^CSU_C09|MSG00488|P|2.5.1
PID|1||PT-90031^^^SPONSOR^MR||Doe^Jane^A||19710204|F
CSR|STUDY2024-ONC-17^^^SPONSOR^STUDY|||PT-90031^^^SPONSOR^MR||20260601103000|||||||EVAL^Evaluable^L|20260612160000|COMPLETED^Protocol Completed^L

FHIR mapping

CSR is not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR IG for CSR. Conceptually, CSR aligns with the FHIR ResearchSubject resource (the patient's participation in a study) and references a ResearchStudy (the protocol identified by CSR-1). When normalizing to FHIR, implementers typically derive ResearchSubject.status from CSR-10 and CSR-14, ResearchSubject.period.start from CSR-6, and the study reference from CSR-1. These are implementer conventions, not a published normalized mapping.

Engine considerations

  • Most interface engines treat CSR as a Z-adjacent specialty segment; confirm the engine ships a CSU C09 structure or accept it as a generic segment.
  • Repeating fields CSR-7, CSR-8, CSR-11, CSR-12, and CSR-13 must be configured to preserve repetitions; flattening them loses authorizing providers and stratification data.
  • Validate that CSR-1 is non-empty before routing, since it is the protocol key.
  • When converting CE coded fields to CWE for a 2.7+ partner, map component 1 (identifier), 2 (text), and 3 (coding system) carefully.
  • Preserve timezone offsets in TS fields (CSR-6, CSR-9, CSR-11, CSR-15) so registration and randomization times remain unambiguous.

How Vorro parses and produces CSR

  • On inbound CSU messages, Vorro reads CSR positionally per the HAPI v2.5.1 structure and normalizes each repeating field into a list, preserving order.
  • CSR-1 Sponsor Study ID is required on parse; a missing value raises a validation event rather than silently dropping the segment.
  • TS fields are normalized to a primary internal timestamp form with timezone retained, and re-rendered to HL7 TS on output.
  • On production, Vorro emits CE coded fields by default and can transform them to CWE for partners on 2.7 or later via a configurable rule.
  • Repeating provider and randomization fields are round-tripped without collapsing, so an inbound multi-arm or multi-provider CSR is reproduced faithfully.
  • /academy/hl7/segments/csp
  • /academy/hl7/segments/css
  • /academy/hl7/messages/csu

Sources

← Back to HL7 v2 Guide

Ready to Integrate This Into Your Workflow?

Talk to a Vorro expert about implementing HL7 v2 in your specific environment.

Browse HL7 v2 Guides
HL7 CSR Segment: Clinical Study Registration | Vorro Academy | Vorro