The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study.
The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study.
Determine from type of call to service (requesting all data vs incremental data - e.g. filtering by _lastUpdated). NOTE: If data are not persisted between FHIR and LAB, cannot do incremental data processing (due to lack of delta detection).
If the data is being 'pushed' in a message, this could also be conveyed in the MessageHeader.event
Determining whether transactions are insert or update is a task for the data consumer. (NOTE: This requires persistent storage to compare current data with data in the incoming file)
This would be conveyed using a transaction Bundle - specifically the Bundle.entry.request.method
The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study.
Determining whether transactions are insert or update is a task for the data consumer. (NOTE: This requires persistent storage to compare current data with data in the incoming file)
As per study transaction type (not clear why it happens at both levels - what would it mean to 'delete' at the study level and 'update at the site level?)
The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study.
The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study.
Determining whether transactions are insert or update is a task for the data consumer. (NOTE: This requires persistent storage to compare current data with data in the incoming file)
As per study transaction type (not clear why it happens at both levels - what would it mean to 'delete' at the study level and 'update at the site level?)
No standard way to decide which subject identifier to use. Also no standard way to differentiate subject id from screening id from spare subject id.
No standard way to decide which subject identifier to use. Also no standard way to differentiate subject id from screening id from spare subject id.
No standard way to decide which subject identifier to use. Also no standard way to differentiate subject id from screening id from spare subject id.
If patient gender is sent, the values must be mapped from the FHIR vocabulary to the LAB standard:
male -> M
female -> F
other -> U
unknown -> U
For FHIR, the administrative gender code list is fixed, so no need to send it in the instance. If there's a need to convey alternate gender codes, then those would appear either as Observation values or as extension values on Patient (the former for clinical information, the latter for administrative purposes). In either event, the code would be in CodeableConcept.coding which allows identifying both the code system and (if relevant), the version
There's an US-core extension (us-core-race) for capturing this in the U.S. and the possibility that other countries will define their own extensions. Note that this is for administrative, not clinical purposes. Genetic heritage would typically be captured as an Observation
Consider whether patient personal information is required for the sponsor to perform patient reconciliation. If not, do not send this data element.
If patient race is sent, use the us-core-race extension in FHIR.
Race, whether captured as an extension or observation value is generally a CodeableConcept allowing capturing both code system and (if relevant) version. Race is highly variable from country to country (both whether it's allowed and how it's coded), so there's no standard element for this in the core spec.
Consider whether patient personal information is required for the sponsor to perform patient reconciliation. If not, do not send this data element. If required, be sure to send only the initials, derived from the name.
Consider whether patient personal information is required for the sponsor to perform patient reconciliation. If not, do not send this data element.
This would be Encounter.reasonCode
If the full birthdate cannot be shared, due to country restrictions, use the birth year to derive age information. Due to lost accuracy in having only the year of birth, 'years' would be the default unit. As an alternative use the cqf-relativeTime extension on Patient.birthDate and convey as a relative time to study enrollment
If captured as an Observation, this would be in the ValueQuantity.code derived from the patient.birthDate(Observation.subject (ref:Patient.birthDate).
If the full birthdate cannot be shared, due to country restrictions, use the birth year to derive age information. Due to lost accuracy in having only the year of birth, 'years' would be the default unit.
If fastingStatusDuration is present and non-zero, that would also map to 'Y'. There are times where this can be inferred from the Observation.code.
Use ServiceRequest.status and ServiceRequest.doNotPerform (doNotPerform will only be true if the test is not to be performed) to represent the test status. From these two fields, sponsors will need to translate to the CDISC test statuses:
D - Done
N - Not Performed
X - Cancelled.
LP - Low Panic
LT - Low Telephone
LN - Low Normal
N - Normal
HN - High Normal
HT - High Telephone
HP - High Panic
AB - Abnormal
and blank when not used. It may be necessary to translate from other interpretation codings.
D+ for an increase in value
D- for a decrease in value
and blank for no flag. It may be necessary to translate from other interpretation codings.
LX - Low Exclusion
HX - High Exclusion
EX - Excluded (for exclusions not falling under high or low)
and blank for no flag. It may be necessary to translate from other
Precision is implicitly determined from the attribute
Observation/valueQuantity/value/@value If the reported result isn't in conventional units, can use the PQ-translation extension to convey a translation.
Precision is implicitly determined from the attribute
Observation/valueQuantity/value/@value
Precision is implicitly determined from the attribute
Observation/valueQuantity/value/@value If the reported result isn't in SI units, can use the PQ-translation extension to convey a translation.
E.g., "BASE"
In FHIR, the value will always be 'reported', with the ability to convey translations in an extension. Nothing will differentiate whether a translation is considered 'conventional' or not, so if there are multiple translations present and the receiver can't figure it out by looking, an additional extension may be necessary to differentiate. This can sometimes also be inferred from the Observation.code.
Populate with a default value.
The version of FHIR in use is conveyed using Resource.meta.profile
Pull from the message wrapper. (file creation date)
Bundle.timestamp
No mitigation. If required, fill with a default value.
As per study.transaction
Pull from the message wrapper.
MessageHeader.source.endpoint if using messaging, otherwise determined out of band based on sender authentication process
Pull from the message wrapper.
MessageHeader.source.name if using messaging, otherwise determined out of band based on sender authentication process
A unique identifier for a study.
Unique identifier for a study.
The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study. ResearchStudy links to Patient. Observation links to Patient. If the patients are the same, that establishes the linkage. There's also an extension that allows direct linkage to a 'study' from any resource - if the source system has actually established such a linkage.
A unique identifier for a site within a study.
Unique identifier for a site within a study.
The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study.
An identifier to describe the Investigator for the study. May be used in addition to SITEID. Not needed if SITEID is equivalent to INVID.
The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study.
A unique subject identifier within a site and a study.
Subject identifier, which must be unique within the study. Often the ID of the subject as recorded on a CRF.
No standard way to decide which subject identifier to use
1. Clinical encounter number. 2. Numeric version of VISIT, used for sorting.
We could go through Encounter.basedOn-> ServiceRequest.instantiatesCanonical, you arrive at ActivityDefinition. Encounter should have a standard instantiatesCanonical extension that would allow pointing to the ActivityDefinition. This would be the ActivityDefinition.name. Submit a change request to add the extension
An internal or external identifier such as specimen identifier.
Internal or external specimen identifier. Example: Specimen ID.
To map directly, the data must be formatted in ISO 8601 date/time format (e.g., 2015-02-07T13:28:17-05:00)
NOTE: requires an extension to the FHIR vocabulary to include CDISC values (e.g., Refrigerated). An "as collected" version of the SDTM variable is recommended to allow the sponsor to make adjustments to ensure terminology compliance while mapping to SDTM.
Defines the type of specimen used for a measurement. Examples: SERUM, PLASMA, URINE.
FHIR terminology is not standardized. Sponsor will need to map to CDISC terminology if raw data does not use CDISC codes. An "as collected" version of the SDTM variable is recommended to allow the sponsor to make adjustments to ensure terminology compliance while mapping to SDTM.
Indicator used to identify fasting status such as Y, N, U, or null if not relevant.
If fastingStatusDuration is present and non-zero, that would also map to 'Y'. In some cases, this may be inferred from the LOINC term (Challenge). For example, Challenge=post CFst to signify a calorie fast.
Indication whether the testing condition defined in the protocol were met (e.g., Low fat diet).
This is an 'ask on entry' question. May be able to determine some conditions, such as fasting, by using other specimen.collection attributes (e.g., fasting status). Others might be captured as components or extensions. Alternatively, obtain this information from the case report form entries.
There are explicit elements for Specimen.collection.fastingStatus and collection.fastingDuration. May need extensions for other pre-conditions
May not be applicable for safety labs.
Used to define a category of related records across subjects. Examples: such as HEMATOLOGY, URINALYSIS, CHEMISTRY.
Needs to be translated from FHIR vocabulary to SDTM controlled terminology: FHIR -> CDISC:
Not performed = NOT DONE
Cancelled = NOT DONE
Completed = <blank>
Describes why a measurement or test was not performed such as BROKEN EQUIPMENT, SUBJECT REFUSED, or SPECIMEN LOST. Used in conjunction with LBSTAT when value is NOT DONE.
CDISC (and sponsors) may have different definitions about what constitutes an "original result". Sponsors will need to make a determination of whether the value found in the Observation.value meets those criteria and is appropriate to be mapped. (In some cases, what's in Observation.value could have been transformed from what was captured at the point of measurement.)
The unit of the result as originally received or collected.
Original units in which the data were collected. The unit for LBORRES. Example: g/L.
In theory, a sponsor specific study-independent identifier could be maintained on Patient alongside other patient identifiers, but this would be unusual in most clinical systems.
Not generally used for human clinical trials
Numerical version of LBTPT to aid in sorting.
Pull this information from the Clinical Plan (PlanDefinition)
Link to the clinical plan would be through the Observation.basedOn link to CarePlan or the instantiatesCanonical link to PlanDefinition or ActivityDefinition
This does not apply to safety labs.
The corresponding values need to be evaluated and aligned accordingly to the CDISC context of --METHOD.
Potentially could appear in Observation.method. An extension is required to distinguish.
Indicator used to identify a baseline value. The value should be "Y" or null.
Variable may be deprecated. This information would come from the Sponsor.
Could appear in Observation.reasonCode. In practice the notion of 'baseline' is more of a relationship. Any arbitrary Observation might be selected as the 'baseline' for a particular step in the study. As such, the real linkage is the tie to the CarePlan activity that's tied to the ActivityDefinition with a reason of 'baseline'.
Used to indicate a derived record. The value should be Y or null. Records that represent the average of other records, or do not come from the CRF, or are not as originally received or collected are examples of records that might be derived for the submission datasets. If LBDRVFL=Y, then LBORRES may be null, with LBSTRESC, and (if numeric) LBSTRESN having the derived value.
This information would come from the Sponsor.
FHIR doesn't use a flag. If an Observation is derived, it should point to the Observations it's derived from with the derivedFrom association. (If that relationship is present, then the Derived Flag is true)
A unique identifier for a study.
Unique identifier for a study.
The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study. ResearchStudy links to Patient. Observation links to Patient. If the patients are the same, that establishes the linkage. There's also an extension that allows direct linkage to a 'study' from any resource - if the source system has actually established such a linkage.
A unique identifier for a site within a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Unique identifier for a site within a study.
The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study.
A unique subject identifier within a site and a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Subject identifier, which must be unique within the study. Often the ID of the subject as recorded on a CRF.
No standard way to decide which subject identifier to use
The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).1. Protocol-defined description of clinical encounter. 2. May be used in addition to VISITNUM and/or VISITDY.
Encounter should have a standard instantiatesCanonical extension that would allow pointing to the ActivityDefinition. This would be the ActivityDefinition.name. Submit a change request to add the extension
Date the clinical encounter occurred (or started).
The field is not an SDTM variable. The date of a measurement, test observation can be determined from the date/time of visit (VISDAT/VISTM components
Observation.category.coding.system="http://terminology.hl7.org/CodeSystem/observation-category" + Observation.category.coding.code="vital-signs".
This combination can be used to extract vital sign data points from EHR system and correctly assign them to the VS domain.
A sub-division of the VSCAT values based on user-defined characteristics.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).A further categorization of a measurement or examination.
Observation.category.coding.system="http://terminology.hl7.org/CodeSystem/observation-category" + Observation.category.coding.code="vital-signs".
This combination can be used to extract vital sign data points from EHR system and correctly assign them to the VS domain.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Used to tie together a block of related records in a single domain for a subject.
This would typically be done by having the related Observations being 'membersOf' a common parent Observation.
A text description of planned time point when measurements should be taken as defined in the protocol.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).1. Text Description of time when measurement should be taken. 2. This may be represented as an elapsed time relative to a fixed reference point, such as time of last dose. See VSTPTNUM and VSTPTREF. Examples: Start, 5 min post
This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPVS dataset as the value of SUPPPVS.QVAL where SUPPVS.QNAM="VSREPNUM" and SUPVS.QLABEL="Repetition Number within time point:. Refer to current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.
This could be captured as a specific ActivityDefinition where you'd have a distinct ActivityDefinition for each occurrence. However, it is more likely to be a single ActivityDefinition for the test and an extension would be added on Observation.instantiates to indicate which occurrence is the Observation.
A unique identifier for a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). I the column with the heading SDTMIG Target.Unique identifier for a study.
The direct path using AdverseEvent.study will only exist if the system maintaining the AdverseEvent is aware of its relevance to the Study. ResearchStudy links to Patient. Observation links to Patient. If the patients are the same, that establishes the linkage. There's also an extension that allows direct linkage to a 'study' from any resource - if the source system has actually established such a linkage.
A unique identifier for a site within a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Unique identifier for a site within a study.
The direct path using AdverseEvent.study will only exist if the system maintaining the AdverseEvent is aware of its relevance to the Study.
A unique subject identifier within a site and a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Subject identifier, which must be unique within the study. Often the ID of the subject as recorded on a CRF.
In FHIR, an AdverseEvent can be categorized in as many ways as desired with whatever granularity is desired. When converting from FHIR to CDASH, systems will need to look at the FHIR categories (and potentially other information) to determine how best to populate AECAT and AESCAT based on the study-designed categories (unless they've pre-arranged with the EHR to ensure it captures the same codes)
A sub-division of the AECAT values based on user-defined characteristics.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).A further categorization of adverse event. Example: NEUROLOGIC.
In FHIR, an AdverseEvent can be categorized in as many ways as desired with whatever granularity is desired. When converting from FHIR to CDASH, systems will need to look at the FHIR categories (and potentially other information) to determine how best to populate AECAT and AESCAT based on the study-designed categories (unless they've pre-arranged with the EHR to ensure it captures the same codes)
A sponsor-defined identifier. In CDASH, This is typically used for preprinted or auto-generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). May be used to create RELREC to link this record with a record in another domain.Sponsor-defined identifier. It may be pre-printed on the CRF as an explicit line identifier or defined in the sponsor's operational database. Example: Line number on an Adverse Events page.
ResearchStudy links to Patient. Observation links to Patient. If the patients are the same, that establishes the linkage. There's also an extension that allows direct linkage to a 'study' from any resource - if the source system has actually established such a linkage.
A unique identifier for a site within a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Unique identifier for a site within a study.
The path using the extension will only exist if the system maintaining the AdverseEvent/Condition/AllergyIntolerance/Observation is aware of its relevance to the Study.
A unique subject identifier within a site and a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Subject identifier, which must be unique within the study. Often the ID of the subject as recorded on a CRF.
No standard way to decide which subject identifier to use
An indication whether or not there was any medical history to report.
Does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED
If captured, this would be a Questionnaire question. FHIR almost always has some type of history information. Will require review to determine if the history is relevant.
A grouping of topic-variable values based on user-defined characteristics.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Used to define a category of related records. Examples: CARDIAC or GENERAL
If needed there are several options to categorize this based on whether something is a Condition/AllergyIntolerance/Observation/etc. This could also include sub-categorize by diagnosis vs. problem, Allergy vs. intolerance or use Observation.category. But in general, the mapping to both CAT and SCAT is going to be driven by what types of categories the study requires or needs.
A sub-division of the MHCAT values based on user-defined characteristics.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). A further categorization of the condition or event.
If needed there are several options to categorize this based on whether something is a Condition/AllergyIntolerance/Observation/etc. This could also include sub-categorize by diagnosis vs. problem, Allergy vs. intolerance or use Observation.category. But in general, the mapping to both CAT and SCAT is going to be driven by what types of categories the study requires or needs.
The date on which the medical history was collected, represented in an unambiguous date format (e.g., DD-MON-YYYY).
This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MHDTC in ISO 8601 format
The sponsor may determine this, based on an anchor point in the protocol.
Indication the medical condition or event is ongoing when no end date is provided.
This does not map directly to an SDTMIG variable. May be used to populate a value into an SDTMIG relative timing variable such as MHENRF or MHENRTPT. When populating MHENRF, if the value of the MHONGO is "Y" a value of "DURING", "AFTER" or "DURING/AFTER" may be used. When populating MHENRTPT, if the value of MHONGO is "Y", the value of "ONGOING" may be used. When MHONGO refers to the Study Reference Period (defined in DM>RFSTDTC to DM>RFENDTC) the SDTMIG variable MHENRF should be populated.Describes the end of the event relative to the sponsor-defined reference period. The sponsor-defined reference period is a continuous period of time defined by a discrete starting point and a discrete ending point (represented by RFSTDTC and RFENDTC in Demographics)
This does not map directly to an SDTMIG variable. May be used to populate a value into an SDTMIG relative timing variable such as MHENRF or MHENRTPT. When populating MHENRF, if the value of the MHONGO is "Y" a value of "DURING", "AFTER" or "DURING/AFTER" may be used. When populating MHENRTPT, if the value of MHONGO is "Y", the value of "ONGOING" may be used. When MHONGO refers to the Study Reference Period (defined in DM>RFSTDTC to DM>RFENDTC) the SDTMIG variable MHENRF should be populated.
AFTER
BEFORE
COINCIDENT
ONGOING
U
Identifies the end of the event as being before or after the reference time point defined by variable MHENTPT.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external code list attributes. Sponsors should include an Origin in the defined metadata document to indicate that the data was "ASSIGNED".
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external code list attributes. Sponsors should include an Origin in the defined metadata document to indicate that the data was "ASSIGNED".
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external code list attributes. Sponsors should include an Origin in the defined metadata document to indicate that the data was "ASSIGNED".
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external code list attributes. Sponsors should include an Origin in the defined metadata document to indicate that the data was "ASSIGNED".
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external code list attributes. Sponsors should include an Origin in the defined metadata document to indicate that the data was "ASSIGNED".
The path using the extension will only exist if the system maintaining the MedicationStatement/Request/Dispense/Administration or Immunization is aware of its relevance to the Study. ResearchStudy links to Patient. Observation links to Patient. If the patients are the same, that establishes the linkage. There's also an extension that allows direct linkage to a 'study' from any resource - if the source system has actually established such a linkage.
A unique identifier for a site within a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Unique identifier for a site within a study.
The path using the extension will only exist if the system maintaining the MedicationStatement/Request/Dispense/Administration or Immunization is aware of its relevance to the Study.
A unique subject identifier within a site and a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Subject identifier, which must be unique within the study. Often the ID of the subject as recorded on a CRF.
No standard way to decide which subject identifier to use
A grouping of topic-variable values based on user-defined characteristics.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Used to define a category of medications/treatments. Examples: PRIOR, CONCOMITANT, ANTI-CANCER MEDICATION, or GENERAL CONMED.
A standard extension will need to be used if multiple categories are specified. There can be a wide variety of categories covering different axes of categorization. As well, the binding in the HL7 specifications 'example', which means that there are no constraints on what can be used.
A sub-division of the CMCAT values based on user-defined characteristics.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).A further categorization of medications/ treatment. Examples: CHEMOTHERAPY, HORMONAL THERAPY, ALTERNATIVE THERAPY.
A standard extension will need to be used if multiple categories are specified. There can be a wide variety of categories covering different axes of categorization. As well, the binding in the HL7 specifications 'example', which means that there are no constraints on what can be used.
An indication whether or not any (concomitant) medications/treatments/therapies were taken/given.
Does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.
This would be determined by dates within the protocol.
What constitutes a 'concomitant' drug is study-specific and would need to be evaluated on a study level. FHIR would not normally store that information. However an extension on ResearchSubject could be utilized or could be captured in a Questionnaire.
A sponsor-defined identifier. In CDASH, This is typically used for preprinted or auto-generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). May be used to create RELREC to link this record with a record in another domain.Sponsor-defined reference number. Examples: a number pre-printed on the CRF as an explicit line identifier or record identifier defined in the sponsor's operational database. Example: line number on a concomitant medication page.
All coding levels are found in the same attribute as distinct codings. The granularity is distinguished by the code system or knowledge of the code
Dictionary text description for the second level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the therapeutic main group.
This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "CMATC2" and SUPPCM.QLABEL="ATC Level 2 Description". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".
Encoding is performed by the sponsor and we would not expect to receive these from the site.
Dictionary code denoting the second level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the therapeutic main group.
This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "MATC2CD" and SUPPCM.QLABEL="ATC Level 2 Code". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".
Encoding is performed by the sponsor and we would not expect to receive these from the site.
All coding levels are found in the same attribute as distinct codings. The granularity is distinguished by the code system or knowledge of the code
Dictionary text description of the third level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the therapeutic/pharmacological subgroup.
This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "CMATC3" and SUPPCM.QLABEL="ATC Level 3 Description". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".
Encoding is performed by the sponsor and we would not expect to receive these from the site.
Dictionary code denoting the third level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the therapeutic/pharmacological subgroup.
This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "MATC3CD" and SUPPCM.QLABEL="ATC Level 3 Code". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".
Encoding is performed by the sponsor and we would not expect to receive these from the site.
All coding levels are found in the same attribute as distinct codings. The granularity is distinguished by the code system or knowledge of the code
Dictionary text description of the fourth level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the chemical/therapeutic/pharmacological subgroup.
This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "CMATC4" and SUPPCM.QLABEL="ATC Level 4 Description". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".
Encoding is performed by the sponsor and we would not expect to receive these from the site.
Dictionary code denoting the fourth level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the chemical/therapeutic/pharmacological subgroup.
This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "MATC4CD" and SUPPCM.QLABEL="ATC Level 4 Code". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".
Encoding is performed by the sponsor and we would not expect to receive these from the site.
All coding levels are found in the same attribute as distinct codings. The granularity is distinguished by the code system or knowledge of the code
Dictionary text description of the fifth level of hierarchy within the Anatomical Therapeutic Chemical Classification system. Indicates the chemical substance.
This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "CMATC5" and SUPPCM.QLABEL="ATC Level 5 Description". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".
Encoding is performed by the sponsor and we would not expect to receive these from the site.
Dictionary code denoting the fifth level of hierarchy within the Anatomical Therapeutic Chemical Classification system. Indicates the chemical substance.
This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "MATC5CD" and SUPPCM.QLABEL="ATC Level 5 Code". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".
Encoding is performed by the sponsor and we would not expect to receive these from the site.
All coding levels are found in the same attribute as distinct codings. The granularity is distinguished by the code system or knowledge of the code
A unique identifier for a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Unique identifier for a study.
The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study. ResearchStudy links to Patient. Observation links to Patient. If the patients are the same, that establishes the linkage. There's also an extension that allows direct linkage to a 'study' from any resource - if the source system has actually established such a linkage. ResearchStudy links to Patient. Observation links to Patient. If the patients are the same, that establishes the linkage. There's also an extension that allows direct linkage to a 'study' from any resource - if the source system has actually established such a linkage.
A unique identifier for a site within a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Unique identifier for a site within a study.
The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study.
A unique subject identifier within a site and a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Subject identifier, which must be unique within the study. Often the ID of the subject as recorded on a CRF.
No standard way to decide which subject identifier to use
An indication whether or not the subject had any procedures performed.
Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED
In FHIR, this would be determined by searching for Procedures with a given subject (possibly also filtered by research study) and excluding those that were entered in error. It might also be necessary to search for education, massage, cognitive therapy and various other data to determine all procedures.
A grouping of topic-variable values based on user-defined characteristics.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Used to define a category of procedure values.
PRDECOD is the dictionary or the sponsor-defined standardized text description of PRTRT, or the modified topic variable (PRMODIFY), if applicable. This means it is the standardized term for the procedure.
If the value for PRTERM is modified for coding purposes, then the modified text is placed here.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).
Coding translations are conducted by the sponsor.
In FHIR, there's no need to modify the PRTERM. The text which was actually saw/typed (errors and all) is present and the various codes encoding it and the display names for those codes. If there was a need to capture a corrected text that was submitted to a post-coding process, that would be an extension
An indication that a specific intervention or a group of interventions is prespecified on a CRF.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Used when a specific procedure is pre-specified on a CRF. Values should be "Y" or null.
This likely to be a Questionnaire question than something that would directly be captured in a record.
This could possibly be an extension on the Procedure/MedicationAdministration/MedicationStatement.
An indication whether a prespecified procedure (PRTRT) happened when information about the occurrence of a specific intervention is solicited.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). If the response was not asked or answered, populate the SDTMIG variable PRSTAT with "NOT DONE"Used to record whether a pre-specified procedure occurred when information about the occurrence of a specific procedure is solicited.
Status of 'not-done', 'entered-in-error' would indicate that it didn't happen, 'active', 'in-progress', 'on-hold', 'completed' would indicate that it did. 'stopped' would indicate that it started, but was abnormally terminated - where that should go depends on the study's definition of 'occur'.
An explanation of why a scheduled procedure did or did not occur.
This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM = "PRREASOC" and SUPPPR.QLABEL = "Reason for Occur Value". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variable I SDTM domains.
An example of ongoing procedure, "hemodialysis with frequency of three times a week". If the status is 'in-progress'/'active', then it's ongoing.
The end date of the procedure, represented in an unambiguous date format (e.g., DD-MON-YYYY).
This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable PRSTDTC in ISO 8601 formatEnd date/time of the procedure represented in ISO 8601 character format.
Procedure.code can contain many codings and at various levels of granularity. Granularity will be determined by reviewing the code system and/or having knowledge of the codes within the same code system (where one code system can express content at multiple granularities).
MedDRA Lowest Level Term code.
This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM = "PRLLTCD" and SUPPPR.QLABEL = "Lower Level Term Code". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variable.
Procedure.code can contain as many codings as you like at whatever granularity you like. You would distinguish what granularity it was by looking at the code system and/or having knowledge of the codes within the same code system (where one code system can express content at multiple granularities) Note: Not clear how many of these would be populated for a procedure.
MedDRA code for the Preferred Term.
This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM = "PRPTCD" and SUPPPR.QLABEL = "Preferred Term Code Lower Level Term Code". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variable.
Procedure.code can contain as many codings as you like at whatever granularity you like. You would distinguish what granularity it was by looking at the code system and/or having knowledge of the codes within the same code system (where one code system can express content at multiple granularities).
MedDRA text description of High Level Term from the primary path.
This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM = "PRHLT" and SUPPPR.QLABEL = "High Level Term". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variable.
Procedure.code can contain as many codings as you like at whatever granularity you like. You would distinguish what granularity it was by looking at the code system and/or having knowledge of the codes within the same code system (where one code system can express content at multiple granularities).
MedDRA High Level Term code from the primary path.
This is not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variable to CDASH is to provide a more complete data management package. This variable could be used in the PR domain for MedDRA coding. Other dictionaries can be used and the appropriate coding elements added. if appropriate, in the SUPPPR.QVAL dataset
Procedure.code can contain as many codings as you like at whatever granularity you like. You would distinguish what granularity it was by looking at the code system and/or having knowledge of the codes within the same code system (where one code system can express content at multiple granularities).
MedDRA text description of the High Level Group Term from the primary path.
This is not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variable to CDASH is to provide a more complete data management package. This variable could be used in the PR domain for MedDRA coding. Other dictionaries can be used and the appropriate coding elements added. if appropriate, in the SUPPPR.QVAL dataset
Procedure.code can contain as many codings as you like at whatever granularity you like. You would distinguish what granularity it was by looking at the code system and/or having knowledge of the codes within the same code system (where one code system can express content at multiple granularities).
MedDRA High Level Group Term code from the primary path.
This is not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variable to CDASH is to provide a more complete data management package. This variable could be used in the PR domain for MedDRA coding. Other dictionaries can be used and the appropriate coding elements added. if appropriate, in the SUPPPR.QVAL dataset
Procedure.code can contain as many codings as you like at whatever granularity you like. You would distinguish what granularity it was by looking at the code system and/or having knowledge of the codes within the same code system (where one code system can express content at multiple granularities).
MedDRA Primary System Organ Class description associated with the intervention.
This is not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variable to CDASH is to provide a more complete data management package. This variable could be used in the PR domain for MedDRA coding. Other dictionaries can be used and the appropriate coding elements added. if appropriate, in the SUPPPR.QVAL dataset
Procedure.code can contain as many codings as you like at whatever granularity you like. You would distinguish what granularity it was by looking at the code system and/or having knowledge of the codes within the same code system (where one code system can express content at multiple granularities).
MedDRA Primary System Organ Class code.
This is not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variable to CDASH is to provide a more complete data management package. This variable could be used in the PR domain for MedDRA coding. Other dictionaries can be used and the appropriate coding elements added. if appropriate, in the SUPPPR.QVAL dataset
Procedure.code can contain as many codings as you like at whatever granularity you like. You would distinguish what granularity it was by looking at the code system and/or having knowledge of the codes within the same code system (where one code system can express content at multiple granularities).
A unique identifier for a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). I the column with the heading SDTMIG Target.Unique identifier for a study.
Birth time is captured as a standard extension
Day of birth of the subject in an unambiguous date format (e.g., DD).
This does not map directly to an SDTMIG variable. For the SDTM submission data set, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable BRTHDTC in ISO 860 format.Date/time of birth of the subject.
Age can be captured either through additional filters, additional transformation, or occasionally looking for information in alternate locations such as an Observation as a point-in-time assessment, but generally this is simply calculated from birthDate. Specifically, relevant clinical trial documentation will have expectations around units, other code systems and data consistency that may not be met by RWD and conversion and mapping may be necessary.
Those units of time that are routinely used to express the age of a person.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Units associated with AGE.
Age can be captured as an Observation as a point-in-time assessment, but generally this is simply calculated from birthDate.
The date of collection represented in an unambiguous date format (e.g., DD-MON-YYYY)
This does not map directly to an SDTMIG variable. For the SDTM submission data set, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable BRTHDTC in ISO 860 format.Date/time of demographic data collection.
This indicates when the Patient resource was last changed, but in practice different pieces of demographics are collected at different times. Review will be required of the history of the patient resource to determine when any particular fact was first asserted.
Sex of the subject as determined by the investigator.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Sex of the subject.
Sex and gender are multi-faceted.concepts. Both FHIR and CDISC standards have a large degree of ambiguity in their definitions for their primary data elements describing a subject’s sex or gender (DM.SEX and Patient.gender). This ambiguity often exists in original source systems. Depending on the use case, the Various facets of sex and gender may be utilized or captured within clinical data.. - physiologic, social, chromosomal, etc. As such, it's not advisable to indicate a mapping where all the facets of sex and gender are ambiguous in both the source and study data standards. Study sponsors and regulators will need to establish policies and look into the quality and nature of the source data as well as the analysis that needs to be performed to determine appropriate mappings.
Extensions such as US core "birth sex" and FHIR core "gender identity" may give more semanticly consistent values, but may not be widely populated Some gender concepts such as physiologic and genetic characteristics may be captured as Observation values rather than as demographics elements on Patient
A social group characterized by a distinctive social and cultural tradition maintained from generation to generation, a common history and origin and a sense of identification with the group; members of the group have distinctive features in their way of life, shared experiences and often a common genetic heritage; these features may be reflected in their experience of health and disease.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).The ethnicity of the subject. Sponsors should refer to "Collection of Race and Ethnicity Data in Clinical Trials" (FDA, September 2005) for guidance regarding the collection of ethnicity (http://www.fda.gov/RegulatoryInformation/Guidances/ucm126340.htm).
There's a U.S. Core extension (https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-ethnicity.html) for this to capture ethnicity as required by U.S. legislation. It captures two distinct granularities as well as free text. Depending on the study, the higher or lower granularity might map to ETHNIC and the lower or free text could map to CETHNIC. Other countries use vastly different value sets or prohibit collection. If captured for clinical rather than administrative purposes, this would be an Observation
A social group characterized by a distinctive social and cultural tradition maintained from generation to generation, a common history and origin and a sense of identification with the group; members of the group have distinctive features in their way of life, shared experiences and often a common genetic heritage; these features may be reflected in their experience of health and disease.
This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPDM dataset as the value of SUPPDM.QVAL where SUPPDM.QNAM = "CETHIC" and SUPPDM.QLABEL = "Collected Ethnicity" See SDTMIG v3.2 Section 5, DM Domain. Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.
There's a U.S. Core extension (https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-ethnicity.html) for this to capture ethnicity as required by U.S. legislation. It captures two distinct granularities as well as free text. Depending on the study, the higher or lower granularity might map to ETHNIC and the lower or free text could map to CETHNIC. Other countries use vastly different value sets or prohibit collection. If captured for clinical rather than administrative purposes, this would be an Observation
An arbitrary classification based on physical characteristics; a group of persons related by common descent or heredity (U.S. Center for Disease Control).
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Race of the subject. Sponsors should refer to "Collection of Race and Ethnicity Data in Clinical Trials" (FDA, September 2005) for guidance regarding the collection of race (http://www.fda.gov/RegulatoryInformation/Guidances/ucm126340.htm) See Assumption below regarding RACE.
There's a U.S. Core extension (https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-race.html) for this to capture race as required by U.S. legislation. In theory, the OMBRace could map to RACE, 'detailed' could map to CRACE and 'text' could map to RACEOTH. However, how appropriate these mappings would be would depend on the study requirements.
Please note: the extension may or may not correspond to the sponsor's requirements and the extension can actually capture race information in 3 different ways, so further mapping would be needed. Other countries use vastly different value sets or prohibit collection. If captured for clinical rather than administrative purposes, this would be an Observation
An arbitrary classification based on physical characteristics; a group of persons related by common descent or heredity (US Centers for Disease Control).
This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPDM dataset as the value of SUPPDM.QVAL where SUPPDM.QNAM = "CRACE" and SUPPDM.QLABEL = "Collected Race" See SDTMIG v3.2 Section 5, DM Domain. Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.
There's a U.S. Core extension (https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-race.html) for this to capture race as required by U.S. legislation. In theory, the OMBRace could map to RACE, 'detailed' could map to CRACE and 'text' could map to RACEOTH. However, how appropriate these mappings would be would depend on the study requirements.
Other countries use vastly different value sets or prohibit collection. If captured for clinical rather than administrative purposes, this would be an Observation
A free-text field to be used when none of the preprinted values for RACE are applicable or if another, unprinted selection should be added to those preprinted values.
This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPDM dataset as the value of SUPPDM.QVAL where SUPPDM.QNAM = "RACEOTHER" and SUPPDM.QLABEL = "RACE OTHER" See SDTMIG v3.2 Section 5, DM Domain. Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.
There's a U.S. Core extension (https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-race.html) for this to capture race as required by U.S. legislation. In theory, the OMBRace could map to RACE, 'detailed' could map to CRACE and 'text' could map to RACEOTH. However, how appropriate these mappings would be would depend on the study requirements.
Other countries use vastly different value sets or prohibit collection. If captured for clinical rather than administrative purposes, this would be an Observation