FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

8.26 Resource ResearchSubject - Content

Biomedical Research and Regulation icon Work GroupMaturity Level: 0 Trial UseSecurity Category: Patient Compartments: Device, Group, Patient

A ResearchSubject is a participant or object which is the recipient of investigative activities in a research study.



A research subject

  • is a participant or object which is the recipient of investigative activities in a research study.
  • is typically a human being or an animal, but can also be a device, drug product or biological product, substance, or a tissue or other sort of sample.
  • can also be a group or part of any of the above.

Human research subjects are traceable to a particular person but their identifying characteristics are usually hidden to protect study integrity and the subject's privacy. Note that in a human drug trial the human is the research subject even though the drug is what is being investigated.

In contemporary research contexts, where humans are involved, the term "Participant" is preferred over "Research Subject". "Participant" emphasizes the active and voluntary role of the individuals in the research process, reflecting a more ethical and respectful approach. However, some contexts still use "Research Subject" due to its broad use in regulatory documents.

The ResearchSubject Resource describes information about the subject in the context of a research study. It is the Resource, which links a patient to one or several studies, captures the business identifier for the research subject in a study, provides a reference to a Consent Resource and information on the assigned and actual study comparison group the subject is in. It also documents the research subject's individual movement through the study protocol.

The scope of ResearchSubject is intended to support the following use cases:

  • Humans and Animals for Clinical and Pre-clinical Trials
  • Drug Products for Stability Studies and other Tests
  • Devices - investigational medical devices including devices for non-clinical laboratory studies - in-vivo and in-vitro
  • Tissue Sample for bench science studies
  • Cases where subjects do not actively participate, but are still represented by their data contributions in retrospective studies

Known common use cases for this Resource are as:

  • a standard, basic, interface structure for linking healthcare systems with research systems.
  • an interface structure for reading off and for storing key status information to track a subject's progress in a trial, including the pre-screening phase.
  • an operational oversight source for sponsor systems.

A guiding goal in the development and maintenance of this Resource is to provide consistent definitions of states, state-change reasons, and milestones which can be used alone or in combination to document the progress of a research subject over the course of their participation in a study. Defining a permissible workflows for the course of a subject in a study is out of scope of this Resource, but the states, state-change reasons, milestones can be used as the basic elements in such a workflow - typically as a PlanDefinition.

The Subject State is the research subject's movement through the study protocol from the subject's point of view. In retrospective studies, subjects do not actively participate, but are still in scope of this Resource represented by their data contributions. The subjectState codes ‘on-study’ and ‘off-study’ track the periods during which their data is included, observed, or considered as part of the study analysis.

A Subject State can be assigned a State Change Reason (StateChangeReason) which indicates why the state of the subject changed.

The Subject Milestone is how the study activities relate to the subject's movement through the study protocol. The two are separate. State is driven by the subject and the Milestone is driven by the study protocol. The values in each element may be the same if necessary for study reasons.

While both states and milestones can be recorded, whether one, the other or both are recorded is dependent on the needs of the individual use cases.

Recurring questions emerging as a potential source of confusion in relation to participant management, are the topic of pre-screening, screening in relation to consent, timepoints of consent and enrollment:

Pre-Screening is the process of identifying eligible participants usually before consent is given. It could be requested by a sponsor or be part of a process at the study site. This implies that no more personal and/or sensitive data beyond what would be available during routine care can be used within that process.

Screening is the process of ensuring eligibility. This activity, which happens before enrollment, but must be consented (unless consent is implicit, waived. See below)

Enrollment is the process of officially entering the study. This is an activity following screening, and entering this phase must have been consented. Typically, screening and enrollment consent are identical but in some cases they may be separated or have different elements (see below).

Consent allows investigators to collect more personal and sensitive data as required by the study.

Establishing appropriate patient consent for any specific study is not a standardized process. Patient consent for their information to be used in support of a study may be explicit, previously obtained or implied. Explicit requirements for consent will usually be a part of the study protocol and/or procedures. Previously obtained consent may have been given under more general conditions such as willingness to allow personal data to be incorporated into registries (i.e. RWD/RWE).

Some jurisdictions have legal bases for using data without explicit consent, for instance for cancer registries. In some cases sharing data is mandatory (no opt out option), and in other cases opt out processes will be in place. Confirming that these types of consent are appropriately available to a study may also need to be considered.

In addition to the implied, previously obtained or explicit consents required for any particular study, these may need to be obtained and/or confirmed at various times during the conduct of the study.

Below is an overview, broadly explaining the consent requirements in relation to pre-screening and screening:

Pre-Screening vs. Screening and Consent Requirements
Condition Pre-Screening Screening Consent Requirement
Purpose Initial identification of potentially eligible participants using routine care data or minimal-risk activities. Formal confirmation of eligibility through study-specific assessments or procedures. - Pre-screening: Not required if routine care data is used within its original context.
Required if identifiable data or new activity.
Data/Procedure Source Routine care data, de-identified registries, or minimal-risk eligibility checks. New data or procedures collected specifically for the study. - Pre-screening: Consent required if accessing identifiable data outside of routine care.
Screening: Consent always required.
Participant Involvement Passive (e.g., record review) or minimal (e.g., routine surveys). Active involvement, including providing new biological samples or undergoing study-specific tests. - Pre-screening: Not needed for routine care data use at the same site.
Screening: Always needed for participant involvement.
Invasiveness of Procedures Non-invasive; limited to existing medical records, registries, or routine clinical data. Can include invasive or study-specific assessments (e.g., biopsies, advanced imaging). - Pre-screening: Consent required only for activities beyond routine care.
Screening: Consent always required.
Data Sensitivity Typically low sensitivity; often uses data already collected for other purposes. Higher sensitivity due to direct collection of study-specific data or new clinical tests. - Pre-screening: Consent required if accessing identifiable or sensitive data.
Screening: Consent always required for sensitive data.
Ethical Implications Minimal risk; often passive data review with no direct patient involvement. Greater risk; involves active engagement and possible physical, emotional, or privacy risks. - Pre-screening: Consent required only for non-routine activities.
Screening: Full consent required for active participant involvement.
Participant Decision Point No formal decision to join the study; simply identifies candidates for further steps. Participants formally decide to join the study and undergo detailed assessments. - Pre-screening: Consent depends on engagement or data usage.
Screening: Consent formalizes study enrollment.
Use of Archived Samples Use of previously collected and stored samples from routine care or biobanks. Collection of new samples specifically for study screening. - Pre-screening: Consent not required for de-identified archived samples.
Screening: Consent required for new sample collection.
Regulatory Requirements Governed by data protection laws (e.g., GDPR, HIPAA) for accessing routine care data or minimal-risk use cases. Governed by clinical trial regulations (e.g., GCP, ICH, FDA, EMA) for study-specific procedures. - Pre-screening: Consent may be waived for routine, de-identified data.
Screening: Always requires formal consent.
Timing Before formal participant engagement; passive evaluation stage. After pre-screening, focusing on active, detailed evaluations. - Pre-screening: Consent may be implied for routine data use.
Screening: Consent required for study-specific activities.

Is a person typically considered "on-study" before screening or after screening is completed and eligibility is confirmed? This question is a recurring source of confusion. The answer here is that this transition depends on the study:

#1 - Most Common Case: A person is typically considered "on-study" only after screening is completed and eligibility is confirmed.

Key reasons for this:

  1. Screening Completion:
      Screening is the process of evaluating a potential participant's eligibility against the protocol's inclusion and exclusion criteria.
      This phase includes activities like reviewing medical history, performing diagnostic tests, and assessing biomarkers.
      Until screening is completed and the participant is deemed eligible, they are not officially "on-study."
  2. Eligibility Confirmation:
      A participant transitions to the "on-study" state once eligibility is confirmed, and they formally enter the study by being enrolled.
      At this point, any study-specific interventions or activities outlined in the protocol begin.
  3. Protocol and Regulatory Alignment:
      In clinical research protocols, "on-study" often marks the formal initiation of study-related activities.
      Regulatory bodies (e.g., FDA, EMA) and ethical guidelines distinguish screening activities from the active phases of the study.

Subject states for this case:

  • Before Screening Completion:
    • Subject is typically classified as:
      • Candidate: Identified for possible participation.
      • In-prescreening: Undergoing preliminary assessment.
      • In-screening: Undergoing detailed eligibility evaluation.
  • After Screening Completion:
    • Subject is classified as:
      • Eligible: Screening completed successfully.
      • On-study: Formally enrolled and participating in study activities.

#2 - Special Case: In some studies, particularly those with multi-step processes (e.g., run-in phases, conditional randomization):

  • A participant might be labeled "on-study" during initial phases before full screening is complete, if the protocol explicitly includes such activities as part of the formal study.
  • For example, a screening phase with study-specific interventions (e.g., collecting baseline biomarkers as part of the protocol) could place participants in an "on-study" status earlier.

In general, the distinction between screening and on-study hinges on the completion of eligibility assessment and enrollment.

#3 - Special Case: If eligibility criteria selection is based entirely on routine care data and no special interventions or study-specific procedures are needed, the potential participant can be set to "on-study" directly after eligibility criteria are fulfilled.

Key Factors Supporting "On-Study" Status Directly After Eligibility Fulfillment:

  1. No Additional Screening Activities:
    • If the eligibility criteria are fully met using routine care data (e.g., lab results, imaging, or clinical notes already collected during standard care), no further screening is necessary.
    • In such cases, the transition from "candidate" to "on-study" can occur immediately after eligibility is confirmed.
  2. No Study-Specific Interventions:
    • Without the need for new tests, procedures, or other activities beyond routine care, the participant effectively bypasses the traditional "in-screening" phase.
    • The "on-study" state is appropriate since the participant meets all inclusion criteria and no additional assessments are pending.
  3. Regulatory Compliance:
    • This approach aligns with ethical and regulatory principles, provided:
      • The participant has given consent (if required) for their routine care data to be used for research.
      • Data privacy and confidentiality are maintained.
  4. Protocol Definition:
    • The study protocol must clearly state that eligibility determination is based solely on routine care data and that participants move to the "on-study" phase immediately upon meeting criteria.

Example Workflow:

  • Pre-Screening:
    • Routine care data (e.g., pathology reports, biomarker results) is analyzed to identify potential participants.
    • If criteria are fulfilled, eligibility is confirmed without additional testing.
  • Eligibility Confirmation:
    • The participant transitions directly to "on-study."
    • Example transition:
      • Candidate → In-prescreening → Eligible → On-study
  • On-Study Activities:
    • Study-specific interventions (e.g., administering a drug, initiating monitoring) begin immediately after the participant is classified as "on-study."

Considerations

Protocol Clarity: The study protocol must explicitly outline this streamlined workflow to avoid confusion during implementation or audits.

Below is an overview, broadly explaining the different scenarios and their characteristics for Transition to "On-Study":

Table: Scenarios for Transition to "On-Study"
Case When "On-Study" Occurs Key Characteristics Example Workflow
#1 - Most Common Case After screening is completed and eligibility is confirmed. - Screening involves detailed eligibility evaluation (e.g., medical history, diagnostic tests, biomarker assessments).
- Transition occurs only after eligibility confirmation.
Candidate → In-prescreening → In-screening → Eligible → On-study
#2 - Special Case: Multi-Step Screening During screening if the protocol explicitly includes study-specific interventions or activities. - Participants engage in study-specific procedures during screening (e.g., baseline biomarker collection).
- Screening itself is part of the formal study phase.
Candidate → In-screening (study-specific tests) → On-study (within screening).
#3 - Special Case: Routine Care Eligibility Directly after eligibility criteria are fulfilled using routine care data. - Eligibility is determined entirely from routine care data (e.g., lab results, imaging, clinical notes).
- No new tests or study-specific interventions are required.
Candidate → In-prescreening → Eligible → On-study.

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. ResearchSubject TU DomainResource Participant or object which is the recipient of investigative activities in a study

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ 0..* Identifier Business Identifier for research subject in a study

... status ?!Σ 1..1 code draft | active | retired | unknown
Binding: PublicationStatus (Required)
... period Σ 0..1 Period Start and end of participation
... subject Σ 1..1 Reference(Patient | Group | Specimen | Device | Medication | Substance | BiologicallyDerivedProduct) Who or what is part of study
... subjectState 0..* BackboneElement A duration in the lifecycle of the ResearchSubject within a ResearchStudy

.... code 1..1 CodeableConcept candidate | in-prescreening | in-screening | eligible | ineligible | on-study | on-study-intervention | in-follow-up | off-study
Binding: Research Subject State (Example)
.... startDate 1..1 dateTime The date a research subject entered the given state
.... endDate 0..1 dateTime The date a research subject exited or left the given state
.... reason 0..1 CodeableConcept State change reason
Binding: StateChangeReason icon (Example)
... subjectMilestone 0..* BackboneElement A significant event in the progress of a ResearchSubject

.... milestone 1..* CodeableConcept SignedUp | Screened | Randomized
Binding: Research Subject Milestone (Example)

.... date 0..1 dateTime The date/time when this milestone event was completed
.... reason 0..1 CodeableConcept
... assignedComparisonGroup 0..1 id What path should be followed
... actualComparisonGroup 0..1 id What path was followed
... consent 0..* Reference(Consent) Agreement to participate in study


doco Documentation for this format icon

See the Extensions for this resource

UML Diagram (Legend)

ResearchSubject (DomainResource)Identifiers assigned to this research subject for a studyidentifier : Identifier [0..*]The publication state of the resource (not of the subject) (this element modifies the meaning of other elements)status : code [1..1] « null (Strength=Required)PublicationStatus! »The dates the subject began and ended their participation in the studyperiod : Period [0..1]Reference to the study the subject is participating instudy : Reference [1..1] « ResearchStudy »The record of the person, animal or other entity involved in the studysubject : Reference [1..1] « Patient|Group|Specimen|Device| Medication|Substance|BiologicallyDerivedProduct »The name of the arm in the study the subject is expected to follow as part of this studyassignedComparisonGroup : id [0..1]The name of the arm in the study the subject actually followed as part of this studyactualComparisonGroup : id [0..1]A record of the patient's informed agreement to participate in the studyconsent : Reference [0..*] « Consent »SubjectStateIdentifies the aspect of the subject's journey that the state refers tocode : CodeableConcept [1..1] « null (Strength=Example)ResearchSubjectState?? »The date a research subject entered the given statestartDate : dateTime [1..1]The date a research subject exited or left the given stateendDate : dateTime [0..1]The reason for the state change. If coded it should follow the formal subject state modelreason : CodeableConcept [0..1] « null (Strength=Example)StateChangeReason?? »SubjectMilestoneA specific event in the research subjects journey through a research studymilestone : CodeableConcept [1..*] « null (Strength=Example)ResearchSubjectMilestone?? »The date/time when this milestone event was completeddate : dateTime [0..1]A rationale that provides additional clarification for the milestone that was captured or documentedreason : CodeableConcept [0..1]A duration in the lifecycle of the ResearchSubject within a ResearchStudysubjectState[0..*]A significant event in the progress of a ResearchSubjectsubjectMilestone[0..*]

XML Template

<ResearchSubject xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Business Identifier for research subject in a study --></identifier>
 <status value="[code]"/><!-- 1..1 draft | active | retired | unknown -->
 <period><!-- 0..1 Period Start and end of participation --></period>
 <study><!-- 1..1 Reference(ResearchStudy) Study subject is part of --></study>
 <subject><!-- 1..1 Reference(BiologicallyDerivedProduct|Device|Group|Medication|
   Patient|Specimen|Substance) Who or what is part of study --></subject>
 <subjectState>  <!-- 0..* A duration in the lifecycle of the ResearchSubject within a ResearchStudy -->
  <code><!-- 1..1 CodeableConcept candidate | in-prescreening | in-screening | eligible | ineligible | on-study | on-study-intervention | in-follow-up | off-study --></code>
  <startDate value="[dateTime]"/><!-- 1..1 The date a research subject entered the given state -->
  <endDate value="[dateTime]"/><!-- 0..1 The date a research subject exited or left the given state -->
  <reason><!-- 0..1 CodeableConcept State change reason icon --></reason>
 </subjectState>
 <subjectMilestone>  <!-- 0..* A significant event in the progress of a ResearchSubject -->
  <milestone><!-- 1..* CodeableConcept SignedUp | Screened | Randomized --></milestone>
  <date value="[dateTime]"/><!-- 0..1 The date/time when this milestone event was completed -->
  <reason><!-- 0..1 CodeableConcept  --></reason>
 </subjectMilestone>
 <assignedComparisonGroup value="[id]"/><!-- 0..1 What path should be followed -->
 <actualComparisonGroup value="[id]"/><!-- 0..1 What path was followed -->
 <consent><!-- 0..* Reference(Consent) Agreement to participate in study --></consent>
</ResearchSubject>

JSON Template

{doco
  "resourceType" : "ResearchSubject",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Business Identifier for research subject in a study
  "status" : "<code>", // R!  draft | active | retired | unknown
  "period" : { Period }, // Start and end of participation
  "study" : { Reference(ResearchStudy) }, // R!  Study subject is part of
  "subject" : { Reference(BiologicallyDerivedProduct|Device|Group|Medication|
   Patient|Specimen|Substance) }, // R!  Who or what is part of study
  "subjectState" : [{ // A duration in the lifecycle of the ResearchSubject within a ResearchStudy
    "code" : { CodeableConcept }, // R!  candidate | in-prescreening | in-screening | eligible | ineligible | on-study | on-study-intervention | in-follow-up | off-study
    "startDate" : "<dateTime>", // R!  The date a research subject entered the given state
    "endDate" : "<dateTime>", // The date a research subject exited or left the given state
    "reason" : { CodeableConcept } // State change reason icon
  }],
  "subjectMilestone" : [{ // A significant event in the progress of a ResearchSubject
    "milestone" : [{ CodeableConcept }], // R!  SignedUp | Screened | Randomized
    "date" : "<dateTime>", // The date/time when this milestone event was completed
    "reason" : { CodeableConcept } // 
  }],
  "assignedComparisonGroup" : "<id>", // What path should be followed
  "actualComparisonGroup" : "<id>", // What path was followed
  "consent" : [{ Reference(Consent) }] // Agreement to participate in study
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:ResearchSubject;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:identifier  ( [ Identifier ] ... ) ; # 0..* Business Identifier for research subject in a study
  fhir:status [ code ] ; # 1..1 draft | active | retired | unknown
  fhir:period [ Period ] ; # 0..1 Start and end of participation
  fhir:study [ Reference(ResearchStudy) ] ; # 1..1 Study subject is part of
  fhir:subject [ Reference(BiologicallyDerivedProduct|Device|Group|Medication|Patient|Specimen|Substance) ] ; # 1..1 Who or what is part of study
  fhir:subjectState ( [ # 0..* A duration in the lifecycle of the ResearchSubject within a ResearchStudy
    fhir:code [ CodeableConcept ] ; # 1..1 candidate | in-prescreening | in-screening | eligible | ineligible | on-study | on-study-intervention | in-follow-up | off-study
    fhir:startDate [ dateTime ] ; # 1..1 The date a research subject entered the given state
    fhir:endDate [ dateTime ] ; # 0..1 The date a research subject exited or left the given state
    fhir:reason [ CodeableConcept ] ; # 0..1 State change reason
  ] ... ) ;
  fhir:subjectMilestone ( [ # 0..* A significant event in the progress of a ResearchSubject
    fhir:milestone  ( [ CodeableConcept ] ... ) ; # 1..* SignedUp | Screened | Randomized
    fhir:date [ dateTime ] ; # 0..1 The date/time when this milestone event was completed
    fhir:reason [ CodeableConcept ] ; # 0..1 
  ] ... ) ;
  fhir:assignedComparisonGroup [ id ] ; # 0..1 What path should be followed
  fhir:actualComparisonGroup [ id ] ; # 0..1 What path was followed
  fhir:consent  ( [ Reference(Consent) ] ... ) ; # 0..* Agreement to participate in study
]

Changes from both R4 and R4B

ResearchSubject
ResearchSubject.status
  • Change value set from http://hl7.org/fhir/ValueSet/research-subject-status|4.0.0 to PublicationStatus
  • Remove codes candidate, eligible, follow-up, ineligible, not-registered, off-study, on-study, on-study-intervention, on-study-observation, pending-on-study, potential-candidate, screening, withdrawn
  • Add codes draft, active, retired, unknown
ResearchSubject.subject
  • Added Mandatory Element
ResearchSubject.subjectState
  • Added Element
ResearchSubject.subjectState.code
  • Added Mandatory Element
ResearchSubject.subjectState.startDate
  • Added Mandatory Element
ResearchSubject.subjectState.endDate
  • Added Element
ResearchSubject.subjectState.reason
  • Added Element
ResearchSubject.subjectMilestone
  • Added Element
ResearchSubject.subjectMilestone.milestone
  • Added Mandatory Element
ResearchSubject.subjectMilestone.date
  • Added Element
ResearchSubject.subjectMilestone.reason
  • Added Element
ResearchSubject.assignedComparisonGroup
  • Added Element
ResearchSubject.actualComparisonGroup
  • Added Element
ResearchSubject.consent
  • Max Cardinality changed from 1 to *
ResearchSubject.individual
  • Deleted
ResearchSubject.assignedArm
  • Deleted
ResearchSubject.actualArm
  • Deleted

See the Full Difference for further information

This analysis is available for R4 as XML or JSON and for R4B as XML or JSON.

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. ResearchSubject TU DomainResource Participant or object which is the recipient of investigative activities in a study

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ 0..* Identifier Business Identifier for research subject in a study

... status ?!Σ 1..1 code draft | active | retired | unknown
Binding: PublicationStatus (Required)
... period Σ 0..1 Period Start and end of participation
... subject Σ 1..1 Reference(Patient | Group | Specimen | Device | Medication | Substance | BiologicallyDerivedProduct) Who or what is part of study
... subjectState 0..* BackboneElement A duration in the lifecycle of the ResearchSubject within a ResearchStudy

.... code 1..1 CodeableConcept candidate | in-prescreening | in-screening | eligible | ineligible | on-study | on-study-intervention | in-follow-up | off-study
Binding: Research Subject State (Example)
.... startDate 1..1 dateTime The date a research subject entered the given state
.... endDate 0..1 dateTime The date a research subject exited or left the given state
.... reason 0..1 CodeableConcept State change reason
Binding: StateChangeReason icon (Example)
... subjectMilestone 0..* BackboneElement A significant event in the progress of a ResearchSubject

.... milestone 1..* CodeableConcept SignedUp | Screened | Randomized
Binding: Research Subject Milestone (Example)

.... date 0..1 dateTime The date/time when this milestone event was completed
.... reason 0..1 CodeableConcept
... assignedComparisonGroup 0..1 id What path should be followed
... actualComparisonGroup 0..1 id What path was followed
... consent 0..* Reference(Consent) Agreement to participate in study


doco Documentation for this format icon

See the Extensions for this resource

UML Diagram (Legend)

ResearchSubject (DomainResource)Identifiers assigned to this research subject for a studyidentifier : Identifier [0..*]The publication state of the resource (not of the subject) (this element modifies the meaning of other elements)status : code [1..1] « null (Strength=Required)PublicationStatus! »The dates the subject began and ended their participation in the studyperiod : Period [0..1]Reference to the study the subject is participating instudy : Reference [1..1] « ResearchStudy »The record of the person, animal or other entity involved in the studysubject : Reference [1..1] « Patient|Group|Specimen|Device| Medication|Substance|BiologicallyDerivedProduct »The name of the arm in the study the subject is expected to follow as part of this studyassignedComparisonGroup : id [0..1]The name of the arm in the study the subject actually followed as part of this studyactualComparisonGroup : id [0..1]A record of the patient's informed agreement to participate in the studyconsent : Reference [0..*] « Consent »SubjectStateIdentifies the aspect of the subject's journey that the state refers tocode : CodeableConcept [1..1] « null (Strength=Example)ResearchSubjectState?? »The date a research subject entered the given statestartDate : dateTime [1..1]The date a research subject exited or left the given stateendDate : dateTime [0..1]The reason for the state change. If coded it should follow the formal subject state modelreason : CodeableConcept [0..1] « null (Strength=Example)StateChangeReason?? »SubjectMilestoneA specific event in the research subjects journey through a research studymilestone : CodeableConcept [1..*] « null (Strength=Example)ResearchSubjectMilestone?? »The date/time when this milestone event was completeddate : dateTime [0..1]A rationale that provides additional clarification for the milestone that was captured or documentedreason : CodeableConcept [0..1]A duration in the lifecycle of the ResearchSubject within a ResearchStudysubjectState[0..*]A significant event in the progress of a ResearchSubjectsubjectMilestone[0..*]

XML Template

<ResearchSubject xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier Business Identifier for research subject in a study --></identifier>
 <status value="[code]"/><!-- 1..1 draft | active | retired | unknown -->
 <period><!-- 0..1 Period Start and end of participation --></period>
 <study><!-- 1..1 Reference(ResearchStudy) Study subject is part of --></study>
 <subject><!-- 1..1 Reference(BiologicallyDerivedProduct|Device|Group|Medication|
   Patient|Specimen|Substance) Who or what is part of study --></subject>
 <subjectState>  <!-- 0..* A duration in the lifecycle of the ResearchSubject within a ResearchStudy -->
  <code><!-- 1..1 CodeableConcept candidate | in-prescreening | in-screening | eligible | ineligible | on-study | on-study-intervention | in-follow-up | off-study --></code>
  <startDate value="[dateTime]"/><!-- 1..1 The date a research subject entered the given state -->
  <endDate value="[dateTime]"/><!-- 0..1 The date a research subject exited or left the given state -->
  <reason><!-- 0..1 CodeableConcept State change reason icon --></reason>
 </subjectState>
 <subjectMilestone>  <!-- 0..* A significant event in the progress of a ResearchSubject -->
  <milestone><!-- 1..* CodeableConcept SignedUp | Screened | Randomized --></milestone>
  <date value="[dateTime]"/><!-- 0..1 The date/time when this milestone event was completed -->
  <reason><!-- 0..1 CodeableConcept  --></reason>
 </subjectMilestone>
 <assignedComparisonGroup value="[id]"/><!-- 0..1 What path should be followed -->
 <actualComparisonGroup value="[id]"/><!-- 0..1 What path was followed -->
 <consent><!-- 0..* Reference(Consent) Agreement to participate in study --></consent>
</ResearchSubject>

JSON Template

{doco
  "resourceType" : "ResearchSubject",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // Business Identifier for research subject in a study
  "status" : "<code>", // R!  draft | active | retired | unknown
  "period" : { Period }, // Start and end of participation
  "study" : { Reference(ResearchStudy) }, // R!  Study subject is part of
  "subject" : { Reference(BiologicallyDerivedProduct|Device|Group|Medication|
   Patient|Specimen|Substance) }, // R!  Who or what is part of study
  "subjectState" : [{ // A duration in the lifecycle of the ResearchSubject within a ResearchStudy
    "code" : { CodeableConcept }, // R!  candidate | in-prescreening | in-screening | eligible | ineligible | on-study | on-study-intervention | in-follow-up | off-study
    "startDate" : "<dateTime>", // R!  The date a research subject entered the given state
    "endDate" : "<dateTime>", // The date a research subject exited or left the given state
    "reason" : { CodeableConcept } // State change reason icon
  }],
  "subjectMilestone" : [{ // A significant event in the progress of a ResearchSubject
    "milestone" : [{ CodeableConcept }], // R!  SignedUp | Screened | Randomized
    "date" : "<dateTime>", // The date/time when this milestone event was completed
    "reason" : { CodeableConcept } // 
  }],
  "assignedComparisonGroup" : "<id>", // What path should be followed
  "actualComparisonGroup" : "<id>", // What path was followed
  "consent" : [{ Reference(Consent) }] // Agreement to participate in study
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:ResearchSubject;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:identifier  ( [ Identifier ] ... ) ; # 0..* Business Identifier for research subject in a study
  fhir:status [ code ] ; # 1..1 draft | active | retired | unknown
  fhir:period [ Period ] ; # 0..1 Start and end of participation
  fhir:study [ Reference(ResearchStudy) ] ; # 1..1 Study subject is part of
  fhir:subject [ Reference(BiologicallyDerivedProduct|Device|Group|Medication|Patient|Specimen|Substance) ] ; # 1..1 Who or what is part of study
  fhir:subjectState ( [ # 0..* A duration in the lifecycle of the ResearchSubject within a ResearchStudy
    fhir:code [ CodeableConcept ] ; # 1..1 candidate | in-prescreening | in-screening | eligible | ineligible | on-study | on-study-intervention | in-follow-up | off-study
    fhir:startDate [ dateTime ] ; # 1..1 The date a research subject entered the given state
    fhir:endDate [ dateTime ] ; # 0..1 The date a research subject exited or left the given state
    fhir:reason [ CodeableConcept ] ; # 0..1 State change reason
  ] ... ) ;
  fhir:subjectMilestone ( [ # 0..* A significant event in the progress of a ResearchSubject
    fhir:milestone  ( [ CodeableConcept ] ... ) ; # 1..* SignedUp | Screened | Randomized
    fhir:date [ dateTime ] ; # 0..1 The date/time when this milestone event was completed
    fhir:reason [ CodeableConcept ] ; # 0..1 
  ] ... ) ;
  fhir:assignedComparisonGroup [ id ] ; # 0..1 What path should be followed
  fhir:actualComparisonGroup [ id ] ; # 0..1 What path was followed
  fhir:consent  ( [ Reference(Consent) ] ... ) ; # 0..* Agreement to participate in study
]

Changes from both R4 and R4B

ResearchSubject
ResearchSubject.status
  • Change value set from http://hl7.org/fhir/ValueSet/research-subject-status|4.0.0 to PublicationStatus
  • Remove codes candidate, eligible, follow-up, ineligible, not-registered, off-study, on-study, on-study-intervention, on-study-observation, pending-on-study, potential-candidate, screening, withdrawn
  • Add codes draft, active, retired, unknown
ResearchSubject.subject
  • Added Mandatory Element
ResearchSubject.subjectState
  • Added Element
ResearchSubject.subjectState.code
  • Added Mandatory Element
ResearchSubject.subjectState.startDate
  • Added Mandatory Element
ResearchSubject.subjectState.endDate
  • Added Element
ResearchSubject.subjectState.reason
  • Added Element
ResearchSubject.subjectMilestone
  • Added Element
ResearchSubject.subjectMilestone.milestone
  • Added Mandatory Element
ResearchSubject.subjectMilestone.date
  • Added Element
ResearchSubject.subjectMilestone.reason
  • Added Element
ResearchSubject.assignedComparisonGroup
  • Added Element
ResearchSubject.actualComparisonGroup
  • Added Element
ResearchSubject.consent
  • Max Cardinality changed from 1 to *
ResearchSubject.individual
  • Deleted
ResearchSubject.assignedArm
  • Deleted
ResearchSubject.actualArm
  • Deleted

See the Full Difference for further information

This analysis is available for R4 as XML or JSON and for R4B as XML or JSON.

 

Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis

Path ValueSet Type Documentation
ResearchSubject.status PublicationStatus Required

The lifecycle status of an artifact.

ResearchSubject.subjectState.code ResearchSubjectState Example

Indicates the progression of a study subject through a study.

ResearchSubject.subjectState.reason StateChangeReason icon Example

Indicates why the state of the subject changed.

ResearchSubject.subjectMilestone.milestone ResearchSubjectMilestone Example

Indicates the progression of a study subject through the study milestones.



The following diagram reflects the "typical" state machine for ResearchSubject.

Diagram showing typical state machine for the ResearchSubject resource

Search parameters for this resource. See also the full list of search parameters for this resource, and check the Extensions registry for search parameters on extensions related to this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name Type Description Expression In Common
date date Start and end of participation ResearchSubject.period 26 Resources
identifier token Business Identifier for research subject in a study ResearchSubject.identifier 65 Resources
patient reference Who or what is part of study ResearchSubject.subject.where(resolve() is Patient)
(Patient)
65 Resources
status token draft | active | retired | unknown ResearchSubject.status
study reference Study subject is part of ResearchSubject.study
(ResearchStudy)
subject reference Who or what is part of study ResearchSubject.subject
(Group, Specimen, BiologicallyDerivedProduct, Device, Medication, Patient, Substance)
subject_state token candidate | in-prescreening | in-screening | eligible | ineligible | on-study | on-study-intervention | in-follow-up | off-study ResearchSubject.subjectState.code