This
page
is
part
of
the
Continuous
Integration
Build
of
FHIR
Specification
(v5.0.0:
R5
-
STU
).
This
is
the
current
published
version
in
it's
permanent
home
(it
will
always
(will
be
available
incorrect/inconsistent
at
this
URL).
For
a
full
list
of
available
versions,
see
times).
See
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
R3
Responsible
Owner:
Biomedical
Research
and
Regulation
Work
Group
|
|
Security 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
Human
research
subjects
are
traceable
to
a
particular
person
but
their
identifying
characteristics
are
usually
hidden
to
protect
study
integrity
and
to
protect
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:
Known common use cases for this Resource are as:
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.
When used in relation to patient care, the ResearchSubject.subject element references the Patient Resource and allows deidentified data sharing related to the ResearchSubject. In this context, it is the Patient and not the ResearchSubject that follows the Participant Pattern in FHIR.
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:
Subject states for this case:
#2 - Special Case: In some studies , particularly those with multi-step processes (e.g., run-in phases, conditional randomization):
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:
Example Workflow:
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
| Name | Flags | Card. | Type |
Description
&
Constraints
Filter:
|
|---|---|---|---|---|
|
|
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 |
|
|
Σ | 0..* | Identifier |
Business
Identifier
for
research
subject
in
a
study
|
|
?! Σ | 1..1 | code |
draft
|
active
|
retired
|
unknown
Binding: PublicationStatus ( Required ) |
|
Σ
|
0..1 |
|
Start
and
end
of
participation
|
|
|
1..1 |
|
Study
subject
is
part
of
|
|
|
1..1 |
|
Who
or
what
is
part
of
study
|
|
|
0..* |
|
A
duration
in
the
lifecycle
of
the
ResearchSubject
within
a
ResearchStudy
|
|
|
1..1 | CodeableConcept |
candidate
|
in-prescreening
|
in-screening
|
eligible
|
ineligible
|
on-study
|
on-study-intervention
|
in-follow-up
|
off-study
Binding:
(
Example
)
|
|
|
1..1 | dateTime |
The
date
a
research
subject
entered
the
given
state
|
|
0..1 | dateTime |
The
date
a
research
subject
exited
or
left
the
given
state
|
|
|
0..1 |
|
State
change
reason
Binding: StateChangeReason
(
Example
)
|
|
|
0..* |
|
A
significant
event
in
the
progress
of
|
|
|
1..1 |
|
Binding: ResearchSubjectMilestone
|
|
|
0..1 |
|
The
date/time
when
this
milestone
event
was
completed
|
|
|
|
0..* |
|
Binding: StateChangeReason
(
Example
)
|
|
|
0..* |
|
A
group
to
which
the
subject
is
assigned
Binding: Example Comparison Group ( Example ) |
|
0..* | Reference ( Consent ) |
Agreement
to
participate
in
study
|
|
Documentation
for
this
format
|
||||
See the Extensions for this resource
UML Diagram ( Legend )
XML Template
<ResearchSubject xmlns="http://hl7.org/fhir"><!-- 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 -->
< <</type> <</subjectState> <</milestone> <</reason> < < </progress><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|</subject> < < <</consent>Patient|Specimen|Substance|SubstanceDefinition) 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
--></reason> </subjectState> <subjectMilestone> <!-- 0..* A significant event in the progress of a ResearchSubject --> <milestone><!-- 1..1 CodeableConcept
--></milestone> <date value="[dateTime]"/><!-- 0..1 The date/time when this milestone event was completed --> <reason><!-- 0..* CodeableConcept
--></reason> </subjectMilestone> <comparisonGroup><!-- 0..* CodeableReference(Group) A group to which the subject is assigned --></comparisonGroup> <consent><!-- 0..* Reference(Consent) Agreement to participate in study --></consent> </ResearchSubject>
JSON Template
{
"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|SubstanceDefinition) }, // 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
}],
"subjectMilestone" : [{ // A significant event in the progress of a ResearchSubject
"milestone" : { CodeableConcept }, // R!
"date" : "<dateTime>", // The date/time when this milestone event was completed
"reason" : [{ CodeableConcept }] //
}],
"comparisonGroup" : [{ CodeableReference(Group) }], // A group to which the subject is assigned
"consent" : [{ Reference(Consent) }] // Agreement to participate in study
}
Turtle Template
@prefix fhir: <http://hl7.org/fhir/> .[ a fhir:ResearchSubject; fhir:nodeRole fhir:treeRoot; # if this is the parser root
# from # from# from Resource: fhir:id, fhir:meta, fhir:implicitRules, and fhir:language # from DomainResource: fhir:text, fhir:contained, fhir:extension, and fhir:modifierExtension fhir:identifier ( [ Identifier ] ... ) ; # 0..* Business Identifier for research subject in a study fhir:status [ code ] ; # 1..1 draft | active | retired | unknownfhir: fhir: fhir: fhir: fhir: fhir: fhir: ] ... ) ;fhir:period [ Period ] ; # 0..1 Start and end of participation fhir:study [ Reference(ResearchStudy) ] ; # 1..1 Study subject is part offhir: fhir: fhir: fhir:fhir:subject [ Reference(BiologicallyDerivedProduct|Device|Group|Medication|Patient|Specimen|Substance| SubstanceDefinition) ] ; # 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..1 fhir:date [ dateTime ] ; # 0..1 The date/time when this milestone event was completed fhir:reason ( [ CodeableConcept ] ... ) ; # 0..* ] ... ) ; fhir:comparisonGroup ( [ CodeableReference(Group) ] ... ) ; # 0..* A group to which the subject is assigned fhir:consent ( [ Reference(Consent) ] ... ) ; # 0..* Agreement to participate in study ]
Changes from both R4 and R4B
| ResearchSubject | |
| ResearchSubject.status |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ResearchSubject.comparisonGroup |
|
| ResearchSubject.consent |
|
| ResearchSubject.individual |
|
| ResearchSubject.assignedArm |
|
| ResearchSubject.actualArm |
|
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
| Name | Flags | Card. | Type |
Description
&
Constraints
Filter:
|
|---|---|---|---|---|
|
|
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 |
|
|
Σ | 0..* | Identifier |
Business
Identifier
for
research
subject
in
a
study
|
|
?! Σ | 1..1 | code |
draft
|
active
|
retired
|
unknown
Binding: PublicationStatus ( Required ) |
|
Σ
|
0..1 |
|
Start
and
end
of
participation
|
|
|
1..1 |
|
Study
subject
is
part
of
|
|
|
1..1 |
|
Who
or
what
is
part
of
study
|
|
|
0..* |
|
A
duration
in
the
lifecycle
of
the
ResearchSubject
within
a
ResearchStudy
|
|
|
1..1 | CodeableConcept |
candidate
|
in-prescreening
|
in-screening
|
eligible
|
ineligible
|
on-study
|
on-study-intervention
|
in-follow-up
|
off-study
Binding:
(
Example
)
|
|
|
1..1 | dateTime |
The
date
a
research
subject
entered
the
given
state
|
|
0..1 | dateTime |
The
date
a
research
subject
exited
or
left
the
given
state
|
|
|
0..1 |
|
State
change
reason
Binding: StateChangeReason
(
Example
)
|
|
|
|
0..* | BackboneElement |
A
significant
event
in
the
progress
of
|
|
1..1 |
|
Binding: ResearchSubjectMilestone
|
|
|
0..1 |
|
The
date/time
when
this
milestone
event
was
completed
|
|
|
|
0..* |
|
Binding: StateChangeReason
(
Example
)
|
|
|
0..* |
|
A
group
to
which
the
subject
is
assigned
Binding: Example Comparison Group ( Example ) |
|
0..* | Reference ( Consent ) |
Agreement
to
participate
in
study
|
|
Documentation
for
this
format
|
||||
See the Extensions for this resource
XML Template
<ResearchSubject xmlns="http://hl7.org/fhir"><!-- 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 -->
< <</type> <</subjectState> <</milestone> <</reason> < < </progress><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|</subject> < < <</consent>Patient|Specimen|Substance|SubstanceDefinition) 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
--></reason> </subjectState> <subjectMilestone> <!-- 0..* A significant event in the progress of a ResearchSubject --> <milestone><!-- 1..1 CodeableConcept
--></milestone> <date value="[dateTime]"/><!-- 0..1 The date/time when this milestone event was completed --> <reason><!-- 0..* CodeableConcept
--></reason> </subjectMilestone> <comparisonGroup><!-- 0..* CodeableReference(Group) A group to which the subject is assigned --></comparisonGroup> <consent><!-- 0..* Reference(Consent) Agreement to participate in study --></consent> </ResearchSubject>
JSON Template
{
"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|SubstanceDefinition) }, // 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
}],
"subjectMilestone" : [{ // A significant event in the progress of a ResearchSubject
"milestone" : { CodeableConcept }, // R!
"date" : "<dateTime>", // The date/time when this milestone event was completed
"reason" : [{ CodeableConcept }] //
}],
"comparisonGroup" : [{ CodeableReference(Group) }], // A group to which the subject is assigned
"consent" : [{ Reference(Consent) }] // Agreement to participate in study
}
Turtle Template
@prefix fhir: <http://hl7.org/fhir/> .[ a fhir:ResearchSubject; fhir:nodeRole fhir:treeRoot; # if this is the parser root
# from # from# from Resource: fhir:id, fhir:meta, fhir:implicitRules, and fhir:language # from DomainResource: fhir:text, fhir:contained, fhir:extension, and fhir:modifierExtension fhir:identifier ( [ Identifier ] ... ) ; # 0..* Business Identifier for research subject in a study fhir:status [ code ] ; # 1..1 draft | active | retired | unknownfhir: fhir: fhir: fhir: fhir: fhir: fhir: ] ... ) ;fhir:period [ Period ] ; # 0..1 Start and end of participation fhir:study [ Reference(ResearchStudy) ] ; # 1..1 Study subject is part offhir: fhir: fhir: fhir:fhir:subject [ Reference(BiologicallyDerivedProduct|Device|Group|Medication|Patient|Specimen|Substance| SubstanceDefinition) ] ; # 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..1 fhir:date [ dateTime ] ; # 0..1 The date/time when this milestone event was completed fhir:reason ( [ CodeableConcept ] ... ) ; # 0..* ] ... ) ; fhir:comparisonGroup ( [ CodeableReference(Group) ] ... ) ; # 0..* A group to which the subject is assigned fhir:consent ( [ Reference(Consent) ] ... ) ; # 0..* Agreement to participate in study ]
Changes from both R4 and R4B
| ResearchSubject | |
| ResearchSubject.status |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ResearchSubject.comparisonGroup |
|
| ResearchSubject.consent |
|
| ResearchSubject.individual |
|
| ResearchSubject.assignedArm |
|
| ResearchSubject.actualArm |
|
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 |
|
Example |
|
| ResearchSubject.subjectState.reason |
|
|
Indicates
why
the
|
| ResearchSubject.subjectMilestone.milestone |
ResearchSubjectMilestone
|
Example |
Indicates the progression of a study subject through the study milestones. |
|
|
StateChangeReason
|
Example |
Indicates why the state of the subject changed. |
| ResearchSubject.comparisonGroup | ExampleComparisonGroup | Example | Example values for defining comparison groups. |
The following diagram reflects the "typical" state machine for ResearchSubject.
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 |
|
| identifier | token | Business Identifier for research subject in a study | ResearchSubject.identifier |
|
| patient | reference | Who or what is part of study |
ResearchSubject.subject.where(resolve()
is
Patient)
( Patient ) |
|
| 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 , SubstanceDefinition , BiologicallyDerivedProduct , Device , Medication , Patient , Substance ) |
|
| subject_state | token |
candidate
|
|
|