HL7 CSR Clinical Study Registration
HL7 field reference CSR fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| CSR.1 | Sponsor Study ID | Yes | No | EI | |
| CSR.2 | Alternate Study ID | No | No | EI | |
| CSR.3 | Institution Registering the Patient | No | No | CE | |
| CSR.4 | Sponsor Patient ID | Yes | No | CX | |
| CSR.5 | Alternate Patient ID - CSR | No | No | CX | |
| CSR.6 | Date/Time Of Patient Study Registration | Yes | No | TS | |
| CSR.7 | Person Performing Study Registration | No | Yes | XCN | |
| CSR.8 | Study Authorizing Provider | Yes | Yes | XCN | |
| CSR.9 | Date/time Patient Study Consent Signed | No | No | TS | |
| CSR.10 | Patient Study Eligibility Status | No | No | CE | |
| CSR.11 | Study Randomization Date/time | No | Yes | TS | |
| CSR.12 | Randomized Study Arm | No | Yes | CE | |
| CSR.13 | Stratum for Study Randomization | No | Yes | CE | |
| CSR.14 | Patient Evaluability Status | No | No | CE | |
| CSR.15 | Date/time Ended Study | No | No | TS | |
| CSR.16 | Reason Ended Study | No | No | CE |
CSR records a subject's clinical-study registration and status, tying the patient or subject to a study and phase.
The standard describes CSR this way: The CSR segment will contain fundamental administrative and regulatory information required to document a patient's enrollment on a clinical trial. This segment is all that is required if one needs to message another system that an enrollment has taken place, i.e., from clinical trials to pharmacy, accounting, or order entry systems. The CSR segment may also be used to identify that OBR, OBX, RXA, and RXR segments that follow represent data applicable to the identified study.
Clinical-study segments tie a message back to a trial, phase, schedule, subject registration, and protocol-specific events. They are not general observation notes; they support trial governance and reporting.
The useful data is usually the combination of study identifiers, phase identifiers, schedule timing, and subject status. Keep protocol codes and local study IDs aligned with the system that is managing the trial.
The v2.5.1 structures show CSR in CRM_C01 - CRM - Register a patient on a clinical trial, CSU_C09 - CSU - Automated time intervals for reporting like monthly, and PEX_P07 - PEX - Unsolicited initial individual product experience report. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
CSR-1 identifies the Sponsor Study ID for this study workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
CSR-2 identifies the Alternate Study ID for this study workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
CSR-3 identifies an organization, clinic, facility, department, or company involved in this study workflow. Keep the organization identifier and display name separate when the datatype supports it.
CSR-4 identifies the Sponsor Patient ID for this study workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
CSR-5 identifies the Alternate Patient ID - CSR for this study workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
CSR-6 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
CSR-7 identifies a person, provider, staff member, or contact involved in this study workflow. Use the structured name or provider datatype instead of flattening everything into display text.
When more than one person is sent, repeats should carry role or identifier context so the receiver can tell who did what.
CSR-8 identifies a person, provider, staff member, or contact involved in this study workflow. Use the structured name or provider datatype instead of flattening everything into display text.
When more than one person is sent, repeats should carry role or identifier context so the receiver can tell who did what.
CSR-9 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
CSR-10 tells the receiver the state of this study workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
CSR-11 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
CSR-12 carries Randomized Study Arm for this study workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
CSR-13 carries Stratum for Study Randomization for this study workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
CSR-14 tells the receiver the state of this study workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
CSR-15 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
CSR-16 qualifies the study workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Related links
- CM0 - Clinical Study Master
- CM1 - Clinical Study Phase Master
- CM2 - Clinical Study Schedule Master
- CSP - Clinical Study Phase
- CSS - Clinical Study Data Schedule Segment
- CTI - Clinical Trial Identification
- OBX - Observation/Result
- CRM_C01 - CRM - Register a patient on a clinical trial
- CSU_C09 - CSU - Automated time intervals for reporting like monthly
- PEX_P07 - PEX - Unsolicited initial individual product experience report