Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study.
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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?)
Will need to decide which id to expose or may need to map to one recognized by the sponsor. If you want the PI for the overall study rather than just for the site associated with the Observation, you'll need to traverse the partOf.resolve() from the study-specific ResearchStudy.
The path using the extension will only exist if the system maintaining the Observation is aware of its relevance to the Study.
Will need to decide which name to expose if there are multiples. Can also extract the prefix, given and family names if text isn't specified.
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?)
Study subject is found by finding the StudySubject that corresponds to the same Patient and ResearchStudy as the Observation. Use the identifier.type to differentiate subject identifiers.
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.
Study subject is found by finding the StudySubject that corresponds to the same Patient and ResearchStudy as the Observation. Use the identifier.type to differentiate subject identifiers.
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.
Study subject is found by finding the StudySubject that corresponds to the same Patient and ResearchStudy as the Observation. Use the identifier.type to differentiate subject identifiers.
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.
Consider whether patient personal information is required for sponsor to perform patient reconciliation. If not, do not send this data element. The US-core birth-sex extension (if it is present) may be more consistently populated than Patient.gender.
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.
Note that name.text will typically contain the full name, but *can* contain initials only. If the full name is present, initials can be extracted by looking at the given and family name components and converting to initials
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.
Note that precision can vary (YYYY, YYYY-MM or YYYY-MM-DD)
Consider whether patient personal information is required for the sponsor to perform patient reconciliation. If not, do not send this data element.
No standard way to decide which identifier to use if multiples are present
In practice, visit name would be the ActivityDefinition.title for the activity in the protocol associated with the encounter. There is no standard extension for this link (though one will be defined). Most clinical systems won't actually capture this, so the determination will need to be made at time of data extraction based on the protocol
See LB mapping comment
This is essentially whether the visit is tied to a particular activity within the PlanDefinition (study protocol) or not. Given that in non-study-specific systems, there won't typically be a linkage even when the encounter *is* driven by the study, this will generally need to be populated algorithmically on extension
This could theoretically be distinguished by whether there was a link to a CarePlan activity or ActivityDefinition. Alternatively, you could use an extension or tag. (What's 'planned' for one study might be unplanned for another)
This would be Encounter.reasonCode
This would be Encounter.reasonCode
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?)
FHIR allows capture meta.lastUpdated which reflects when the data last changed on the server in question, but would need to look at Provenance to see when data last changed on a particular system. This typically won't be available.
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?)
Will need to look at identifier.type or identifier.system to know which identifier to use. In some cases, performer might be PractitionerRole, in which case, will need to map through PractitionerRole.organization. If there are multiple performers that link to multiple organizations, converter will need to look at Organization.type or have other rules to decide amongst the candidates.
If there are multiple performers that link to multiple organizations, converter will need to look at Organization.type or have other rules to decide amongst the candidates.
If there are multiple identifiers, need to look at identifier.system or identifier.type to determine
Most of the time there'll only be a single dateTime. If collected over a period of time (e.g. urine), use the end.
Will need to convert value + units into an ISO duration
The event would be in extension('target').valueReference.display and the time would be in extension('offset').valueDuration value and unit.
Will need to choose which coding to extract the code for
Note that practitioners can have multiple identifiers - use type or system to decide which identifier to expose
Note that organizations can have multiple identifiers - use type or system to decide which identifier to expose
If multiple codes are present, filter based on system
If multiple codes are present, filter based on system. Translation may be required
If multiple codings are present, will need to decide which to use
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. 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.
FHIR to CDISC mapping as follows:
F -> Y; NF -> N; FNA -> N/A; NG -> Not Applicable (blank)
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.
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?)
Multiple fields are required to populate this value per the standard.
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.
The normal transmission of data, via FHIR, is for study tests. If non-study test results are required (e.g., AdverseEvent follow-up), these would be obtained via a special request from the data provider. Alternatively, if the system requires this field to be populated, derive whether the test was for the study or not, use the ServiceRequest resource.
Differentiation would be whether the Observation was basedOn a particular activity in the CarePlan (scheduled) or tied to a particular ActivityDefinition (Study test)
Use "Organization/type" to pick the type of Organization that represents "Performing Lab"
Since this is a codeable concept, there may be multiple codes for a test. The sponsor will have to determine which is the "lab's" code vs. "receiver's" code vs. others.
Not all notes will necessarily be appropriate to map here. Would need to decide whether to also bring across authors and dates and would need to combined multiple repetitions into a single string.
Observation/code/coding/system/@value ("system" element used to designate the type of code that is being represented (in this case the "ReceiverTest") by the "code" element)
This will always be 'LOINC'
Will need to determine whether to also incude date and author.
This has two possible values: P for Preliminary and F for Final.
The alert flag generated by the reference ranges applied and tied to the reported result. There are 9 alert flag values:
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.
The delta flag generated by the reference ranges applied and tied to the reported result. There are three delta flags:
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.
The exclusion flag generated by the reference ranges applied and tied to the reported result. There are four exclusion flag values:
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
A new code would likely be needed to specifically designate 'blinded'.
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?)
If there are multiple possible systems, the sponsor will have to determine which interpretation corresponds to toxicity grade
May need to translate the URI to a CDISC Code List id
Determine from the field in which the result resides. valueCodeableConcept vs. valueQuantity vs. valueString Greater than and less than can be determined by valueQuantity.qualifier
May need to convert from URI to CDISC-recognized 'ID'
If the reported result isn't in conventional units, can use the PQ-translation extension to convey a translation.
If the reported result isn't in SI units, can use the PQ-translation extension to convey a translation.
Determine the precision from the value.
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.
Determine the precision from the value.
Precision is implicitly determined from the attribute
Observation/valueQuantity/value/@value
Determine the precision from the 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.
Will need to combine value and unit into a string. If the reported units aren't 'conventional, can use the PQ-translation extension on Quantity to convey a translation.
Will need to combine value and unit into a string.
Will need to combine value and unit into a string. If the reported units aren't SI, can use the PQ-translation extension on Quantity to convey a translation.
Will need to combine value and unit into a string. If the reported units aren't 'conventional, can use the PQ-translation extension on Quantity to convey a translation.
Will need to combine value and unit into a string.
Will need to combine value and unit into a string. If the reported units aren't SI, can use the PQ-translation extension on Quantity to convey a translation.
If the reported units are not the same as conventional, can convey with the translation extension. Translation to CDISC terminology may be required.
This may require translation to CDISC terminology
If the reported units are not SI units, can convey with the translation extension. Translation to CDISC terminology may be required.
Populate with a default value, depending on the type of data being transmitted.
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.
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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.
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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.
Will need to decide which id to expose. If you want the PI for the overall study rather than just for the site associated with the Observation, you'll need to traverse the partOf.resolve() from the study-specific ResearchStudy.
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.
Study subject is found by finding the StudySubject that corresponds to the same Patient and ResearchStudy as the Observation.
No standard way to decide which subject identifier to use
1. Clinical encounter number. 2. Numeric version of VISIT, used for sorting.
This won't necessarily correlate with the protocol-defined visit number. Correspondance to a protocol-defined visit will typically require rules-based analysis based on time, encounter type and other factors.
The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.
1. Protocol-defined description of clinical encounter 2. May be used in addition to VISITNUM and/or VISITDY
In most cases, real world data won't have a direct association to a study protocol activity and the link would need to be inferred. However, if it exists, it would map as follows:
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.
As reported from the Site
NOTE: no mapping included for CDASH LBDAT and LBTIM
To map directly, the data must be formatted in ISO 8601 date/time format (e.g., 2015-02-07T13:28:17-05:00)
NOTE: No mapping included for CDASH LBENDAT and LBENTIM)
To map directly, the data must be formatted in ISO 8601 date/time format (e.g., 2015-02-07T13:28:17-05:00)
Will need to convert value and unit to ISO syntax. E.g. 90 min would convert to PT1H30M
1. Text Description of time when specimen 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 LBTPTNUM and LBTPTREF. Examples: Start, 5 min post.
Typically named timepoints won't exist in real-world data and the timing point name will need to be assigned by the sponsor. However, this shows where the data would be expressed in FHIR if it was present there.
Planned Elapsed time (in ISO 8601) relative to a planned fixed reference (LBTPTREF). This variable is useful where there are repetitive measures. Not a clock time or a date time variable. Represented as an ISO 8601 duration. Examples: "-PT15M" to represent the period of 15 minutes prior to the reference point indicated by LBTPTREF, or "PT8H" to represent the period of 8 hours after the reference point indicated by LBTPTREF.
Typically named timepoints won't exist in real-world data and the timing point offset will need to be calculated by the sponsor. However, this shows where the data would be expressed in FHIR if it was present there. If present, would need to translate to ISO-8601
Free or standardized text describing the condition of the specimen e.g. HEMOLYZED, ICTERIC, LIPEMIC etc.
Recommend submitting change proposals to extend the FHIR vocabulary to include CDISC values. Sponsor will need to decide how to map when FHIR terminology contains codes not present in CDISC.
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.
NOTE: In some cases, this may be inferred from the LOINC.
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.
FHIR to CDISC mapping as follows:
F -> Y; NF -> N; FNA -> N/A; NG -> Not Applicable.
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
As reported from the lab. Will need to map to CDISC controlled terminology
Need to translate to blank or N if not received as blank or N
May not be applicable for safety labs.
Used to define a category of related records across subjects. Examples: such as HEMATOLOGY, URINALYSIS, CHEMISTRY.
NOTE: In some cases, this may be inferred from the LOINC. It might also be found by looking for the 'panel' Obsesrvation this Observation is a part of. In most cases, translation will be required to sponsor-defined codes. It may work best for the sponsor to categorize based on TESTCD values and ignore lab-reported and EHR-determined categories entirely.
Used to indicate exam not done. Should be null if a result exists in LBORRES.
Sponsor may choose to map a situation in which the entire panel is cancelled as one summary record compliant with SDTM IG examples.
Some sponsor may decline to accept cancelled records under specific circumstances (e.g., unscheduled)
Sponsor may also choose to populate LBREASND as CANCELLED
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.
see notes on LBSTAT
Short name of the measurement, test, or examination described in LBTEST. It can be used as a column name when converting a dataset from a vertical to a horizontal format. The value in LBTESTCD cannot be longer than 8 characters, nor can it start with a number (e.g."1TEST"). LBTESTCD cannot contain characters other than letters, numbers, or underscores. Examples: ALT, LDH.
Translate to compliant terminology (if needed)
Verbatim name of the test or examination used to obtain the measurement or finding. Note any test normally performed by a clinical laboratory is considered a lab test. The value in LBTEST cannot be longer than 40 characters. Examples: Alanine Aminotransferase, Lactate Dehydrogenase.
Translate to compliant terminology (if needed)
1. Dictionary-derived LOINC Code for LBTEST. 2. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the define.xml external codelist attributes
The name or identifier of the vendor (e.g., laboratory) that provided the test results.
The name or identifier of the laboratory that performed the test.
1. Indicates where the value falls with respect to reference range defined by LBORNRLO and LBORNRHI, LBSTNRLO and LBSTNRHI, or by LBSTNRC. Examples: NORMAL, ABNORMAL, HIGH, LOW. 2. Sponsors should specify in the study metadata (Comments column in the define.xml) whether LBNRIND refers to the original or standard reference ranges and results. 3. Should not be used to indicate clinical significance.
Must map to CDISC controlled terminology
Records toxicity grade value using a standard toxicity scale (such as the NCI CTCAE). If value is from a numeric scale, represent only the number (e.g., "2" and not "Grade 2"). The sponsor is expected to provide the name of the scale and version used to map the terms, utilizing the define.xml external codelist attributes.
Must map to sponsor-determind terminology
Description of toxicity quantified by LBTOXGR. The sponsor is expected to provide the name of the scale and version used to map the terms, utilizing the define.xml external codelist attributes.
Typically FHIR systems will only populate Coding.version where the terminology is ill-behaved and code meanings change over time. The code system version doesn't convey what value set the user was choosing from (which could be a subset of the codes from the code system or could draw from multiple code systems).
Description of toxicity quantified by LBTOXGR. The sponsor is expected to provide the name of the scale and version used to map the terms, utilizing the define.xml external codelist attributes.
Note that the system doesn't define the value set nor does it specify value set version or code system version(s)
The lower end of normal range or reference range for continuous results stored in LBORRES.
Lower end of reference range for continuous measurements in original units. Should be populated only for continuous results.
As reported from the lab.
The upper end of normal range or reference range for continuous results stored in LBORRES.
Upper end of reference range for continuous measurements in original units. Should be populated only for continuous results.
As reported from the lab.
For normal range values that are character in ordinal scale or if categorical ranges were supplied (e.g., "-1 to +1", "NEGATIVE TO TRACE").
Sponsor would normalize this.
Result of the measurement or finding as originally received or collected.
Result of the measurement or finding as originally received or collected.
Might also include valueQuantity.comparator
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.
Needs to be translated to match the controlled terminology, if not already compliant
An indication whether lab test results were clinically significant.
As determined by the lab, not the sponsor
Method of the test or examination. Examples: EIA (Enzyme Immunoassay), ELECTROPHORESIS, DIPSTICK
Method can cover collection and many other features. In some cases, collection method may be inferred from the Observation.code. Would need to map to CDISC controlled terminology
In some cases, the anatomical location can be inferred from the Observation.code. Would need to map to CDISC controlled terminology.
Would need to introduce an extension
May not be applicable for safety labs.
Identifier used to uniquely identify a subject across all studies for all applications or submissions involving the product.
To find an identifier that was consistent for the subject across studies would typically mean looking to the Patient identifier. However, this may not be appropriate to be exposed directly, so some degree of mapping, obfuscation or anonymization may be required.
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.
This wouldn't come from the lab. It *could* be added after the fact. If so, this would be the mapping
Not differentiated from LBLOC. Not for basic safety labs
This can sort of be inferred from the absence of a link to a PlanDefinition or ActivityDefinition, however there are lots of other reasons these links could be missing, so that's not totally reliable. Could look at using an extension or a tag
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.
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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.
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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.
Study subject is found by finding the StudySubject that corresponds to the same Patient and ResearchStudy as the Observation.
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
Linked via Observation.encounter
An indication whether or not a planned vital signs measurement, series of vital signs measurements, tests, or observations was performed.
This field is not an SDTM variable.
May be used to derive a value into the SDTM variable VSSTAT. If VSPERF="N", the value of VSSSTAT will be "NOT DONE". If VSPErF="Y", VSSTAT should be NULLUsed to indicate that a vital sign measurement was not done. Should be null if a result exists in VSORRES.
The date of the vital signs measurement, 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 VSDTC in ISO 8601 format.
The time of measurement, represented in an unambiguous time format (e.g., hh:mm:ss).
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 VSDTC in ISO 8601 format.
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.
FHIR allows multiple categorizations at various levels of granularity.
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.
FHIR allows multiple categorizations at various levels of granularity.
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
TimePoints will be represented in FHIR as PlanDefinition.activities. Referencing a PlanDefinition is supported in R5. Can use a standard extension to pre-adopt.
The variable used to indicate that data are not available by having the site recording the value as "Not Done".
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Used to indicate that a vital sign measurement was not done. Should be null if a result exists in VSORRES.
In some instances, VSSTAT="NOT DONE" records will come from FHIR Observation resources where Observation.status="cancelled". This is not an exact match and there could be observations which have been scheduled and did not happen so an observation may not exist.
Result of the vital signs measurement as originally received or collected.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Result of the vital signs measurement as originally received or collected.
Ensure the value provided from the EHR is considered an actual value (result), an interpretation or range.
The unit of the result as originally received or collected.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Original units in which the data were collected. The unit for VSORRES. Examples: IN, LB, BEATS/MIN.
An indication whether the vital sign result was clinically significant.
If clinical significance is a boolean, then the mapping is different from the existing http://hl7.org/fhir/ValueSet/observation-interpretation ValueSet. Meaning, the values of "normal", "high", :low", etc. can reside in the --NRIND variable. There are also cases where clinical significant outcome details can exist with corresponding details that don't fit into either of those mentioned buckets.
The position of the subject during a measurement or examination.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Position of the subject during a measurement or examination. Examples: SUPINE, STANDING, SITTING.
This is often pre-coordinated into the Observation.code, but can also be expressed in the method
A description of the anatomical location of the subject relevant to the collection of Vital Signs measurement.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Location relevant to the collection of Vital Signs measurement. Example: ARM for blood pressure.
Requires knowledge or review of data to ensure location, laterality and directionality are included in the code and can be parsed.
Qualifier for anatomical location further detailing the side of the body.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Qualifier for anatomical location or specimen further detailing laterality. Examples: RIGHT, LEFT, BILATERAL
Requires knowledge or review of data to ensure location, laterality and directionality are included in the code and can be parsed.
Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).
Requires knowledge or review of data to ensure location, laterality and directionality are included in the code and can be parsed.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). The SDTMIG variable VSTESTCD may be determined from the value collected in VSTESTCD and VSTEST. Both VSTESTCD and VSTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.Short name of the measurement, test, or examination described in VSTEST. It can be used as a column name when converting a dataset from a vertical to a horizontal format. The value in VSTESTCD cannot be longer than 8 characters, nor can it start with a number (e.g."1TEST"). VSTESTCD cannot contain characters other than letters, numbers, or underscores. Examples: SYSBP, DIABP, BMI.
May use one of the following:coding.display and coding.code (plus coding.system)
Descriptive name of the test or examination used to obtain the measurement or finding.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). The SDTMIG variable VSTESTCD may be determined from the value collected in VSTESTCD and VSTEST. Both VSTESTCD and VSTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.Verbatim name of the test or examination used to obtain the measurement or finding. The value in VSTEST cannot be longer than 40 characters. Examples: Systolic Blood Pressure, Diastolic Blood Pressure, Body Mass Index.
May use one of the following:coding.display and coding.code (plus coding.system)
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. Perhaps pre-printed on the CRF as an explicit line identifier or defined in the sponsor's operational database.
The assigner of the identifier can be explicit or inferred by the Identifier.system. Example: "assigner=sponsor", the value of assigner can either be a simple name using "display" (e.g. "assigner.display=MyPharma" or a reference to an "Organization"
The instance number of a test that is repeated within a given timeframe for the same test. The level of granularity can vary (e.g., within a time point, within a visit).
The repetition number of test/measurement within the time point ma be preprinted on the CRF (e.g.. multiple measurements of blood pressure, multiple analyses of a sample).
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.
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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.
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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.
Research subject points to patient, adverse event points to patient. Adverse event points to study. Check to see if they are the same in order to establish linkage. When extracting real world evidence either the extraction will be performed in a fully identified mode and de-identification will happen as a subsequent process or the de-identification will already have occurred. Any identify info in the resources will already have real world identification randomized or otherwise made nonsensitive. The mapping is referring to subject.reference not to the identifier element on the clinical resources.
An indication whether or not any AEs were experienced during the study.
Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that the field is NOT SUBMITTED.
In FHIR, this would be determined by searching for AdverseEvents with a given subject (possibly also filtered by research study) and excluding those that were entered in error. If a flag were necessary, it would be an extension on Study, not sent on AdverseEvent. It might also be necessary to search for Condition instances, Observation instances, Encounters with particular reasons and other resources if the desire is to have the full set of potential adverse reactions.
A grouping of topic-variable values based on user-defined characteristics.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). I the column with the heading SDTMIG Target.Used to define a category of related records. Example: BLEEDING, NEUROPSYCHIATRIC.
This is typically sponsor-specific and we would not expect this to come from the site.
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.
This is typically sponsor-specific and we would not expect this to come from the site.
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.
The assigner of the identifier can be explicit or inferred by the Identifier.system.
The reported or prespecified name of the adverse event.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Verbatim name of the event.
An indication whether a prespecified adverse event or a group of adverse events occurred when information about the occurrence of a specific event is solicited.
This does not map directly to an SDTMIG variable. Because the SDTM AE domain is intended to hold only AdverseEvents that actually happen, all values collected in AEOCCUR for prespecified AEs should be submitted in a Findings About AdverseEvents data set (FAAE) where FAORRES=the value of AEOCCUR where FATESTCD="OCCUR" in addition, where AEOCCUR=Y, there should be a corresponding record in the AE domain.
FHIR only captures AdverseEvents that have actually occurred. A flag about whether a particular potential adverse reaction has been detected or not could be captured using Questionnaire Response
An indication that a specific event, or group of events, are prespecified on a CRF.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).A value of "Y" indicates that this adverse event was pre-specified on the CRF. Values are null for spontaneously reported events (i.e., those collected as free-text verbatim terms)
If captured within an EHR, this would be an extension on the existing extension that references the ResearchStudy. (An AdverseEvent might be pre-specified for one study and not for another.)
The start date of the adverse event, 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 START DATE and TIME components and populate the SDTMIG variable AESTDTC in ISO 8601 format.
The start time of the adverse event, represented in an unambiguous time format (e.g., hh:mm:ss)
This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable AESTDTC in ISO 8601 format.
A description of the anatomical location relevant for the adverse event.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Describes anatomical location relevant for the event (e.g., ARM for skin rash).
Requires knowledge or review of data to ensure location, laterality and directionality are included in the code and can be parsed.
Qualifier for anatomical location further detailing the side of the body relevant for the event.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).
Requires knowledge or review of data to ensure location, laterality and directionality are included in the code and can be parsed.
Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).
Requires knowledge or review of data to ensure location, laterality and directionality are included in the code and can be parsed.
Qualifier for anatomical location further detailing the distribution (i.e., arrangement of, apportioning of).
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).
Review of data to ensure location, laterality and directionality are included in the code and can be parsed.
Indication that an adverse event is ongoing when no End Date is provided.
Identifies the end of the event as being before or after the reference time point defined by variable AEENTPT.
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 (RFSTDTC) and a discrete ending point (RFENDTC) of the trial.
Note that the assertion of 'ongoing' is made at the time the adverse event is recorded, which may or may not be what's needed for submission purposes.
The date when the adverse event resolved/ended, represented in an unambiguous date format (e.g., DD-MON-YYYY).
Need to use a standard extension to pre-adopt the type allowed in R5. Element contains both date and time (if specified).
The time when the adverse event ended/resolved, represented in an unambiguous time format (e.g., hh:mm:ss).
Need to use a standard extension to pre-adopt the type allowed in R5. Element contains both date and time (if specified).
The severity or intensity of the event.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).The severity or intensity of the event. Examples: MILD, MODERATE, SEVERE.
The grade of the severity of the event using a standard "toxicity" scale (e.g., NCI CTCAE).
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). The sponsor is expected to provide the toxicity scale name and version used to map the terms utilizing the Define-XML external code list attributes.Toxicity grade according to a standard toxicity scale such as Common Terminology Criteria for Adverse Events v3.0 (CTCAE). Sponsor should specify name of the scale and version used in the metadata (see Assumption 6d). If value is from a numeric scale, represent only the number (e.g., "2" and not "Grade 2").
Recommendation is to add extension for oncology or other studies requiring toxicity grades.
An indication whether or not the adverse event is determined to be "serious" based on what is defined in the protocol.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Is this a serious event?
Access if an adverse event should be classified as serious based on the serious criteria defined in the protocol.
An indication the serious adverse event resulted in death.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Did the serious event result in death?
Date of death for any subject who died.
This field does not map directly to an SDTMIG variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable DTHDTC in ISO 8601 format.Date/time of death for any subject who died, in ISO 8601 format. Should represent the date/time that is captured in the clinical-trial database.
An indication the serious adverse event was life threatening.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Was the serious event life threatening?
These would typically be flagged by seriousness or outcome codes. Will need to propose change request to support capturing more than one
An indication the serious adverse event resulted in an initial or prolonged hospitalization.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Did the serious event require or prolong hospitalization?
Note: there is Encounter.hospitalization.[x], but its relevance to AESHOSP may not be explicit and would require additional analysis.
An indication the serious adverse event was associated with a persistent or significant disability or incapacity.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Did the serious event result in persistent or significant disability/incapacity?
These would typically be flagged by seriousness or outcome codes. Will need to propose change request to support capturing more than one
An indication the serious adverse event was associated with a congenital anomaly or birth defect.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Was the serious event associated with congenital anomaly or birth defect?
These would typically be flagged by seriousness or outcome codes. Will need to propose change request to support capturing more than one
An indication an adverse event required medical or surgical intervention to preclude permanent impairment of a body function, or prevent permanent damage to a body structure, due to the use of a medical product.
If the details regarding Serious As are collected I the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type.
These would typically be flagged by seriousness or outcome codes. Will need to propose change request to support capturing more than one
An indication additional categories for seriousness apply.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Do additional categories for seriousness apply?
Additional outcomes or seriousness codes would be specified
An indication the serious event was associated with the development of cancer.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Was the serious event associated with the development of cancer?
Additional outcomes or seriousness codes would be specified
An indication the serious event occurred with an overdose.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Did the serious event occur with an overdose?
Product Relatedness implies that the product is involved in the AE, but it doesn't indicate overdose. After looking through other fields, it does not look like there is a field that would cover this situation. In studies, OD would be a reason why the AE was marked as an SAE.
An indication the study treatment had a causal effect on the adverse event, as determined by the clinician/investigator.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Records the investigator's opinion as to the causality of the event to the treatment. ICH E2A and E2B examples include NOT RELATED, UNLIKELY RELATED, POSSIBLY RELATED, RELATED. Controlled Terminology may be defined in the future. Check with regulatory authority for population of this variable.
Reasonable to map to both. Information could be useful in either of these fields.
A description of the action taken with study treatment as a result of the event.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Describes changes to the study treatment as a result of the event. AEACN is specifically for the relationship to study treatment. AEACNOTH is for actions unrelated to dose adjustments of study treatment. Examples of AEACN values include ICH E2B values: DRUG WITHDRAWN, DOSE REDUCED, DOSE INCREASED, DOSE NOT CHANGED, UNKNOWN or NOT APPLICABLE.
Pre-adopting R5 capability via a standard extension. Note that the extension captures all actions taken, so filtration would be needed to select only those related to study treatment
A description of the action taken, with respect to a device used in a study (which may or may not be the device under study), as a result of the event.
This does not map directly an SDTMIG variable. The sponsor may submit this data in a SUPPAE-dataset where SUPPAE.QNAM = "AEACNDEV" and SUPPAE.QLABEL = "Actions Taken with Device". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.
Pre-adopting R5 capability via a standard extension. Note that the extension captures all actions taken, so filtration would be needed to select only those related to devices
A description of other action taken as a result of the event that is unrelated to dose adjustments of the study treatment.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Describes other actions taken as a result of the event that are unrelated to dose adjustments of study treatment. Usually reported as free text. Example: "TREATMENT UNBLINDED. PRIMARY CARE PHYSICIAN NOTIFIED."
Pre-adopting R5 capability via a standard extension. Note that the extension captures all actions taken, so filtration would be needed to exclude actions related to study treatment or device
A description of the outcome of an event.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Description of the outcome of an event.
The coded equivalents matching up the CDISC controlled terminology. Meaning, in the EHR we may not have value-based coordination from FHIR-to-CDISC
An indication whether the event caused the subject to discontinue from the study.
This does not map directly an SDTMIG variable. May be used to create a RELREC to link the AdverseEvent to the Disposition record (see SDTMIG v3.2 Section (8.2). The sponsor may also submit this data in a SUPPAE dataset where SUPPAE.QNAM = "AEDIS" and SUPPAE.QLABEL = "Cased Study Discontinuation ". if appropriate. Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.
An extension would be added that would be study specific as the relationship might vary study to study.
An indication whether in the investigator's opinion the event may have been due to a treatment other than study treatment.
This does not map directly an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is not SUBMITTED.
An extension would be added that would be study specific as the relationship might vary study to study.
Description of the investigator's opinion as to whether the adverse event may have been due to a treatment other than study treatment.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Records the investigator's opinion as to whether the event may have been due to a treatment other than study drug. May be reported as free text. Example: "MORE LIKELY RELATED TO ASPIRIN USE.".
An extension would be added that would be study specific as the relationship might vary study to study.
An adverse event of special interest (serious or non-serious) is one of scientific and medical concern specific to the sponsor's product or program, for which ongoing monitoring and rapid communication by the investigator to the sponsor can be appropriate. Such an event might warrant further investigation in order to characterize and understand it. Depending on the nature of the event, rapid communication by the trial sponsor to other parties (e.g., regulators) might also be warranted.
Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that the field is NOT SUBMITTED.
Add extension, probably on a study-specific link. (Adverse events of interst to one study wouldn't necessarily be of interest to others.)
Used to indicate the pattern of the event over time.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Used to indicate the pattern of the event over time. Examples: INTERMITTENT, CONTINUOUS, SINGLE EVENT.
An extension would be added that would be study specific as the relationship might vary study to study.
An indication whether a concomitant or additional treatment given because of the occurrence of the event.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Was another treatment given because of the occurrence of the event?
R5 pre-adoption extension. Note that mitigatingActions aren't necessarily treatments, so codes would need to be examined to only map those that were treatments
If the value for AETERM is modified to facilitate coding, then AEMODIFY will contain the modified text.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).If AETERM is modified to facilitate coding, then AEMODIFY will contain the modified text.
The fact one of the codings was modified would be captured as an extension
The dictionary or standardized text description of AETERM or the modified topic variable (AEMODIFY), if applicable.
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 map the terms.Dictionary-derived text description of AETERM or AEMODIFY. Equivalent to the Preferred Term (PT in MedDRA). The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the define.xml external codelist attributes.
Sponsors will populate this through the coding process and is applicable to items using MedDRA coding.
MedDRA text description of the Lowest Level Term.
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 map the terms.Dictionary-derived text description of the Lowest Level Term.
Sponsors will populate this through the coding process and is applicable to items using MedDRA coding.
MedDRA Lowest Level Term code.
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 map the terms.Dictionary-derived code for the Lowest Level Term.
Sponsors will populate this through the coding process and is applicable to items using MedDRA coding.
MedDRA code for the Preferred Term.
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 map the terms.Dictionary-derived code for the Preferred Term.
Sponsors will populate this through the coding process and is applicable to items using MedDRA coding.
MedDRA text description of the High Level Term from the primary path.
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 map the terms.Dictionary-derived text description of the High Level Term for the primary System Organ Class.
Sponsors will populate this through the coding process and is applicable to items using MedDRA coding.
MedDRA High Level Term code from the primary path.
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 map the terms.Dictionary-derived code for the High Level Term for the primary System Organ Class.
Sponsors will populate this through the coding process and is applicable to items using MedDRA coding.
MedDRA text description of the High Level Group Term from the primary path.
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 map the terms.Dictionary-derived text description of the High Level Group Term for the primary System Organ Class.
Sponsors will populate this through the coding process and is applicable to items using MedDRA coding.
MedDRA High Level Group Term code from the primary path.
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 map the terms.Dictionary-derived code for the High Level Group Term for the primary System Organ Class.
Sponsors will populate this through the coding process and is applicable to items using MedDRA coding.
MedDRA Primary System Organ Class text description associated with the event.
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 map the terms.Dictionary-derived text description of the primary System Organ Class. Will be the same as AEBODSYS if the primary SOC was used for analysis.
Sponsors will populate this through the coding process and is applicable to items using MedDRA coding.
MedDRA code for the primary System Organ Class.
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 map the terms.Dictionary-derived code for the primary System Organ Class. Will be the same as AEBDSYCD if the primary SOC was used for analysis.
Sponsors will populate this through the coding process and is applicable to items using MedDRA coding.
An indication whether any other actions were taken in response to the adverse event that were unrelated to study treatment dose changes or other non-study treatments given because of this adverse event.
Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that the field is NOT SUBMITTED.
R5 pre-adoption extension. Note that mitigatingActions also include treatments, so codes would need to be examined to only map those that were NOT treatments
A unique identifier for a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Unique identifier for a study.
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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.
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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.
Study subject is found by finding the StudySubject that corresponds to the same Patient and ResearchStudy as the focal resource.
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
The sponsors does not typically require this information from the sites.
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.
The sponsors does not typically require this information from the sites.
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
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. Perhaps pre-printed on the CRF as an explicit line identifier or defined in the sponsor's operational database. Example: Line number on a Medical History page.
If FHIR IDs are used for RELREC, then the sponsor should evaluate its use case as necessary prior to mapping.
Specifies the aspect of the medical condition or event by which MHSTDTC and/or the MHENDTC is defined.
If MHSTDTC and/or the MHENDTC are extracted from FHIR, their meaning is fixed, and thus so will be the value of this element.
This will generally be set to SYMPTOM ONSET for all resources, as both the onsetDateTime and effectiveDateTime are expected to represent when the symptoms first appeared, not when the diagnosis occurred. However, there are no strict rules in FHIR about when a condition flare-up is considered to be a continuation of a prior condition and when it's a new condition. Thus in some cases, new condition instances could spawn from net new episodes or relapes. Spronsors may need to check for prior condition instances and based on their rules, adjust the value for this field to be EPISODE or something else in some cases.
The reported or prespecified name of the medical condition or event.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Verbatim or preprinted CRF term for the medical condition or event.
An indication whether a prespecified medical condition/event or a group of medical conditions/events occurred when information about the occurrence of a specific event is solicited.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). Used when the occurrence of specific medical history conditions is solicited to indicate whether or not (Y/N) a medical condition (MHTERM) had ever occurred. Values are null for spontaneously reported events.
In general in FHIR, records of the absence of Conditions are not normally captured. If the information revolves around "has the patient had X", that would be accomplished through a Questionnaire.Response
An indication that a specific event, or group of events, are prespecified on a CRF.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).A value of "Y" indicates that this medical history event was pre-specified on the CRF. Values are null for spontaneously reported events (i.e., those collected as free-text verbatim terms)
Not expect to receive these from the site. How this is populated in the sponsor's database would be up to the sponsor. If available, this would need to be an extension. The notion of pre-specified is part of the questionnaire
An indication whether the event occurred prior to study start.
This does not map directly to an SDTMIG variable. May be used to populate a value into an SDTMIG relative timing variable such as MHSTRF or MHSTRTPT. When populating MHSTRF, or MHSTRTPT if the value of the CDASH field MHPRIOR is "Y" a value from the CDISC CT (STENRF) may be used. When MHPRIOR refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTMIG variable MHSTRF should be populated. When MHPRIOR is compared to another time point, the SDTMIG variables MHSTRTPT and MHSTTPT should be used.
This does not map directly to an SDTMIG variable. May be used to populate a value into an SDTMIG relative timing variable such as MHSTRF or MHSTRTPT. When populating MHSTRF, or MHSTRTPT if the value of the CDASH field MHPRIOR is "Y" a value from the CDISC CT (STENRF) may be used. When MHPRIOR refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTMIG variable MHSTRF should be populated. When MHPRIOR is compared to another time point, the SDTMIG variables MHSTRTPT and MHSTTPT should be used.
This can be determined from either the onsetDateTime and/or the abatementDateTime. If it were to be flagged on the record, it would need to be an extension on the extension that links to the study.
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.
Indication whether the medical condition or event is under control at the time of data collection.
For all of these, the evaluation of resolution is tied to the date the record was last updated, not necessarily the start of the study, so lack of resolution in the record doesn't necessarily mean that the item will be unresolved at study time.
The start date of medical history event or condition 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 START DATE and TIME components and populate the SDTMIG variable MHSTDTC in ISO 8601 format.
The end date of medical history event or condition 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 MHENDTC in ISO 8601 format.
A description of the anatomical location relevant for the medical condition or event.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).
AllergyIntolerances are generally not associated with body sites.
Qualifier for anatomical location further detailing the side of the body relevant for the event.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).
There should be a standard extension defined that allows Condition, AdverseEvent, Observation and Specimen to point to a BodyStructure. Laterality is not relevant for allergies. Differentiation of laterality, directionality and other location qualifiers will require knowledge of the qualifier codes and code-by-code mapping
Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).
There should be a standard extension defined that allows Condition, AdverseEvent, Observation and Specimen to point to a BodyStructure. Directionality is not relevant for allergies. Differentiation of laterality, directionality and other location qualifiers will require knowledge of the qualifier codes and code-by-code mapping
Qualifier for anatomical location further detailing the distribution, which means arrangement of, apportioning of.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).
This would likely be an extension on Condition. It is not relevant for the other resources
If the value for MHTERM is modified to facilitate coding, then MHMODIFY will contain the modified text.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).If MHTERM is modified to facilitate coding, then MHMODIFY will contain the modified text.
This would need to be captured as an extension on AdverseEvent.event.text. A new standard extesnsion should be proposed
In most cases, no MedDRA codes will be present in source data and all coding levels and displays will be added by the sponsor. However, FHIR allows multiple codings and therefore all of these codes *can* be conveyed in FHIR if the data source chooses to capture them. Standard code system URLs should be defined for each of the MedDRA levels. If MedDRA is considered a single code system, then the consumer will be responsible for distinguishing which codes represent which levels by looking up the received code.
The dictionary text description of MHTERM or the modified topic variable (MH MODIFY), if applicable.
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".Dictionary-derived text description of MHTERM or MHMODIFY. Equivalent to the Preferred Term (PT in MedDRA). The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the define.xml external codelist attributes.
In most cases, no MedDRA codes will be present in source data and all coding levels and displays will be added by the sponsor. However, FHIR allows multiple codings and therefore all of these codes *can* be conveyed in FHIR if the data source chooses to capture them. Standard code system URLs should be defined for each of the MedDRA levels. If MedDRA is considered a single code system, then the consumer will be responsible for distinguishing which codes represent which levels by looking up the received code.
MedDRA Dictionary text description of the Lowest Level Term.
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".
In most cases, no MedDRA codes will be present in source data and all coding levels and displays will be added by the sponsor. However, FHIR allows multiple codings and therefore all of these codes *can* be conveyed in FHIR if the data source chooses to capture them. Standard code system URLs should be defined for each of the MedDRA levels. If MedDRA is considered a single code system, then the consumer will be responsible for distinguishing which codes represent which levels by looking up the received code.
MedDRA Lowest Level Term code.
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".
In most cases, no MedDRA codes will be present in source data and all coding levels and displays will be added by the sponsor. However, FHIR allows multiple codings and therefore all of these codes *can* be conveyed in FHIR if the data source chooses to capture them. Standard code system URLs should be defined for each of the MedDRA levels. If MedDRA is considered a single code system, then the consumer will be responsible for distinguishing which codes represent which levels by looking up the received code.
MedDRA code for the Preferred Term.
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".
In most cases, no MedDRA codes will be present in source data and all coding levels and displays will be added by the sponsor. However, FHIR allows multiple codings and therefore all of these codes *can* be conveyed in FHIR if the data source chooses to capture them. Standard code system URLs should be defined for each of the MedDRA levels. If MedDRA is considered a single code system, then the consumer will be responsible for distinguishing which codes represent which levels by looking up the received code.
MedDRA text description of the High Level Term from the primary path.
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".
In most cases, no MedDRA codes will be present in source data and all coding levels and displays will be added by the sponsor. However, FHIR allows multiple codings and therefore all of these codes *can* be conveyed in FHIR if the data source chooses to capture them. Standard code system URLs should be defined for each of the MedDRA levels. If MedDRA is considered a single code system, then the consumer will be responsible for distinguishing which codes represent which levels by looking up the received code.
MedDRA High Level Term code from the primary path.
The field does not typically appear on the CRF. Sponsor's will populate this through the coding process. This is applicable to items using MedDRA coding
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".
In most cases, no MedDRA codes will be present in source data and all coding levels and displays will be added by the sponsor. However, FHIR allows multiple codings and therefore all of these codes *can* be conveyed in FHIR if the data source chooses to capture them. Standard code system URLs should be defined for each of the MedDRA levels. If MedDRA is considered a single code system, then the consumer will be responsible for distinguishing which codes represent which levels by looking up the received code.
MedDRA text description of the High Level Group Term from the primary path.
The field does not typically appear on the CRF. Sponsor's will populate this through the coding process. This is applicable to items using MedDRA coding
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".
In most cases, no MedDRA codes will be present in source data and all coding levels and displays will be added by the sponsor. However, FHIR allows multiple codings and therefore all of these codes *can* be conveyed in FHIR if the data source chooses to capture them. Standard code system URLs should be defined for each of the MedDRA levels. If MedDRA is considered a single code system, then the consumer will be responsible for distinguishing which codes represent which levels by looking up the received code.
MedDRA High Level Group Term code from the primary path.
The field does not typically appear on the CRF. Sponsor's will populate this through the coding process. This is applicable to items using MedDRA coding
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".
In most cases, no MedDRA codes will be present in source data and all coding levels and displays will be added by the sponsor. However, FHIR allows multiple codings and therefore all of these codes *can* be conveyed in FHIR if the data source chooses to capture them. Standard code system URLs should be defined for each of the MedDRA levels. If MedDRA is considered a single code system, then the consumer will be responsible for distinguishing which codes represent which levels by looking up the received code.
The field does not typically appear on the CRF. Sponsor's will populate this through the coding process. This is applicable to items using MedDRA coding
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".
In most cases, no MedDRA codes will be present in source data and all coding levels and displays will be added by the sponsor. However, FHIR allows multiple codings and therefore all of these codes *can* be conveyed in FHIR if the data source chooses to capture them. Standard code system URLs should be defined for each of the MedDRA levels. If MedDRA is considered a single code system, then the consumer will be responsible for distinguishing which codes represent which levels by looking up the received code.
MedDRA code for the primary System Organ Class.
The field does not typically appear on the CRF. Sponsor's will populate this through the coding process. This is applicable to items using MedDRA coding
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".
In most cases, no MedDRA codes will be present in source data and all coding levels and displays will be added by the sponsor. However, FHIR allows multiple codings and therefore all of these codes *can* be conveyed in FHIR if the data source chooses to capture them. Standard code system URLs should be defined for each of the MedDRA levels. If MedDRA is considered a single code system, then the consumer will be responsible for distinguishing which codes represent which levels by looking up the received code.
A unique identifier for a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Unique identifier for a study.
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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.
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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.
Study subject is found by finding the StudySubject that corresponds to the same Patient and ResearchStudy as the focal resource.
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.
In FHIR, a medication can be categorized in multiple ways and to the granularity 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 CMCAT and CMSCAT based on the study-designed categories (unless they've pre-arranged with the EHR to ensure it captures the same codes).
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.
In FHIR, a medication can be categorized in multiple ways and to the granularity 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 CMCAT and CMSCAT based on the study-designed categories (unless they've pre-arranged with the EHR to ensure it captures the same codes).
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.
Verbatim medication name or treatments (include only treatments with data collection characteristics similar to medications).
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Verbatim medication name that is either pre-printed or collected on a CRF.
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 to indicate whether (Y/null) information about the use of a specific medication was solicited on the CRF.
Would not expect to receive from the site.
An indication whether the prespecified medication/treatment/therapy (CMTRT) or the group of medications/treatments/therapies was administered when information about the occurrence of a specific intervention is solicited.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).When the use of specific medications is solicited, CMOCCUR is used to indicate whether or not (Y/N) use of the medication occurred. Values are null for medications not specifically solicited.
In general, medication records won't exist unless the patient is taking the medication, though there is an ability to say a medication isn't currently being taken or shouldn't be taken
Medication Ingredients.
Does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.
The condition, disease, symptom, or disorder that the concomitant (non-study) medication/treatment/therapy was used to address or investigate (e.g., why the medication/treatment/therapy was taken or administered).
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Denotes why a medication was taken or administered. Examples: NAUSEA, HYPERTENSION.
Identifier for the adverse event that is the indication for this medication/treatment/therapy.
This does not map directly to an SDTMIG variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the AdverseEvent domain.
This could match on AdverseEvent by code. (Note that the AdverseEvent points to the medication record, not the reverse
Identifier for the medical history condition that is the indication for this medication/treatment/therapy.
This does not map directly to an SDTMIG variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the AdverseEvent domain.
The dose of medication/treatment (e.g., --TRT ) given at one time represented as a numeric value.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). in the column with the heading "SDTMIG Target".Amount of CMTRT taken. Not populated when CMDOSTXT is populated.
The dose of medication/treatment taken per administration.
This does not map directly to an SDTMIG variable. Numeric values map to CMDOSE in SDTM. Non-numeric values (e.g., 200 - 400) map to CMDOSTXT in SDTM.Dosing amounts or a range of dosing information collected in text form. Units may be stored in CMDOSU. Example: 200-400, 15-20. Not populated when CMDOSE is populated.
This does not map directly to an SDTMIG variable. Numeric values map to CMDOSE in SDTM. Non-numeric values (e.g., 200 - 400) map to CMDOSTXT in SDTM.Amount of CMTRT taken. Not populated when CMDOSTXT is populated.
Requires combining multiple repetitions together
The total amount of CMTRT taken over a day using the units in CMDOSU.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Total daily dose of CMTRT using the units in CMDOSU. Used when dosing is collected as Total Daily Dose. Total dose over a period other than day could be recorded in a separate Supplemental Qualifier variable.
If Total Daily Dose is required by the sponsor, it may require collection of the drug dose and frequency to derive the CM Total Daily Dose.
The unit associated with the concomitant medication/treatment/therapy taken (e.g., mg in "2 mg 3 times per day").
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Units for CMDOSE, CMDOSTOT, and CMDOSTXT. Examples: ng, mg, or mg/kg.
The pharmaceutical dosage form in which the CMTRT is physically presented.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Dose form for CMTRT. Examples: TABLET, LOTION.
The number of doses given/administered/taken during a specific interval.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Usually expressed as the number of repeated administrations of CMDOSE within a specific time period. Examples: BID (twice daily), Q12H (every 12 hours).
The route of administration of the (concomitant) [medication/treatment/therapy].
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Route of administration for CMTRT. Examples: ORAL, INTRAVENOUS.
The start date when the concomitant medication/treatment/therapy was first taken, represented in an unambiguous date format (e.g., DD-MON-YYYY).
This does not map directly to an SDTMIG variable. For the SDTM submission datasets, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable CDSTDTC in ISO 8601 format.
Start includes both date and time, though time commonly won't be specified. If string is specified, it will have to be parsed and converted to whatever precision is posisble
The time the concomitant medication/treatment/therapy was started, represented in an unambiguous time format (e.g., hh:mm:ss).
This does not map directly to an SDTMIG variable. For the SDTM submission datasets, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable CDSTDTC in ISO 8601 format.
Start includes both date and time, though time commonly won't be specified. If string is specified, it will have to be parsed and converted to whatever precision is posisble
The date that the subject ended/stopped taking the concomitant medication/treatment/therapy represented in an unambiguous date format (e.g., DD-MON-YYYY).
This does not map directly to an SDTMIG variable. For the SDTM submission datasets, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable CMSTDTC in ISO 8601 format.
End includes both date and time, though time commonly won't be specified. If string is specified, it will have to be parsed and converted to whatever precision is posisble
The time when the subject ended/stopped taking the concomitant medication/treatment/therapy represented in an unambiguous time format (e.g., hh:mm:ss).
This does not map directly to an SDTMIG variable. For the SDTM submission datasets, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable CMENDTC in ISO 8601 format.
End includes both date and time, though time commonly won't be specified. If string is specified, it will have to be parsed and converted to whatever precision is posisble
Indication the concomitant medication/treatment/therapy was given or taken prior to [CMSTTPT] or prior to the date in DM.RFSTDTC.
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= "CMATC1" and SUPPCM.QLABEL="ATC Level 1 Description". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED". Describes the start of the medication relative to 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). If information such as "PRIOR", ONGOING or "CONTINUING" was collected, this information may be translated into CMSTRF.
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= "CMATC1" and SUPPCM.QLABEL="ATC Level 1 Description". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED". Identifies the start of the medication as being before or after the reference time point defined by variable CMSTTPT.
This would need to be an extension added to the study extension on the medication resource - normally it is not captured except in the context of a study (and would be a study-specific assertion)
Indication the concomitant medication/treatment/therapy is ongoing when no end date is provided.
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= "CMATC1" and SUPPCM.QLABEL="ATC Level 1 Description". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED". Describes the end of the medication 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). If information such as "PRIOR", "ONGOING, or "CONTINUING" was collected, this information may be translated into CMENRF.
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= "CMATC1" and SUPPCM.QLABEL="ATC Level 1 Description". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED". Identifies the end of the medication as being before or after the reference time point defined by variable CMENTPT.
This would need to be an extension added to the study extension on the medication resource - normally it is not captured except in the context of a study (and would be a study-specific assertion)
The dictionary- or sponsor-defined standardized text description of the topic variable, CMTRT, or the modified topic variable (CMMODIFY), if applicable.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Standardized or dictionary-derived text description of CMTRT or CMMODIFY. Equivalent to the generic medication name in WHO Drug. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the define.xml external codelist attributes. If an intervention term does not have a decode value in the dictionary then CMDECOD will be left blank.
We would not expect to receive these from the site.
The class for the intervention, often obtained from a coding dictionary.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Drug class. May be obtained from coding. When coding to a single class, populate with class value. If using a dictionary and coding to multiple classes, then follow Section 4: 4.1.2.8.3, Multiple Values For A Non-Result Qualifier Variable or omit CMCLAS.
These *can* be provided as alternate codings, however typically encoding is performed by the sponsor and we would not expect to receive these from the site.
The assigned dictionary code for the class for the intervention.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Class code corresponding to CMCLAS. Drug class. May be obtained from coding. When coding to a single class, populate with class code. If using a dictionary and coding to multiple classes, then follow Section 4: 4.1.2.8.3, Multiple Values For A Non-Result Qualifier Variable or omit CMCLASCD.
These *can* be provided as alternate codings, however typically encoding is performed by the sponsor and we would not expect to receive these from the site.
Dictionary text description of the first level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the anatomical 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= "CMATC1" and SUPPCM.QLABEL="ATC Level 1 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 first level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the anatomical 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= "MATC1CD" and SUPPCM.QLABEL="ATC Level 1 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 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.
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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.
Mapping is based on presumption that research subject will be tied to site-specific ResearchStudy, which will then be part of overall ResearchStudy.
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.
Study subject is found by finding the StudySubject that corresponds to the same Patient and ResearchStudy as the Procedure.
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.
FHIR doesn't have 2 distinct category levels. The option exists to have as many categorizations with whatever axes and granularities needed or desired. When mapping data to a particular study, it would be necessary to decide what category values best correspond to CAT vs. SCAT. A standard extension will be needed to convey multiple repetitions in R4. (Procedure.category does repeat in the draft of R5) The SNOMED binding is an example, which means that any codes can be used. Even if the binding were stronger, alternate codes would be possible on other repetitions.
A sub-division of the PRCAT values based on user-defined characteristics.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Used to define a further categorization of PRCAT values.
FHIR doesn't have 2 distinct category levels. Instead, Procedure.category repeats. The option exists to have as many categorizations with whatever axes and granularities needed or desired. When mapping data to a particular study, it would be necessary to decide what category values best correspond to CAT vs. SCAT.
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).Sponsor-defined identifier. Example: pre-printed line identifier on a CRF or record identifier defined in the sponsor's operational database.
The verbatim surgical, therapeutic, or diagnostic procedure's name.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Name of procedure performed, either pre-printed or collected on a CRF.
The name as expressed by or displayed to the user goes in code.text. The name associated with the selected code goes in code.coding.display.
The dictionary- or sponsor-defined standardized text description of PRTRT, or the modified topic variable (PRMODIFY), if applicable.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Standardized or dictionary-derived name of PRTRT. The sponsor is expected to provide the dictionary name and version used to map the terms in the define.xml external codelist attributes. If an intervention term does not have a decode value in the dictionary then PRDECOD will be null.
Translation of the source-system-determined procedure code to the study-defined value set may need to be performed by the sponsor.
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.
Coding translations are left to the sponsor.
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.
Note that reasonReference would need to be turned into a code or string. Reason[x] indicates reason for doing the procedure; statusReason when status=not-done would be reason for non-occurrence
An explanation of why the data are not available.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).
Indication the procedure occurred prior to [PRSTTPT] or prior to the date in DM.RFSTDTC.
This does not map directly to an SDTMIG variable. May be used to populate a value into an SDTM relative timing variable such as PRSTRF or PRSTRTPT. When populating PRSTRF, or PRSTRTPT, if the value of the CDASH field PRPRIOR is "Y" a value from the CDISC CT (STENRF) may be used.
AFTER
BEFORE
COINCIDENT
U
Identifies the start of the observation as being before or after the sponsor-defined reference time point defined by variable PRSTTPT.
This does not map directly to an SDTMIG variable. May be used to populate a value into an SDTM relative timing variable such as PRSTRF or PRSTRTPT. When populating PRSTRF, or PRSTRTPT, if the value of the CDASH field PRPRIOR is "Y" a value from the CDISC CT (STENRF) may be used.
Typically, this extension won't exist, or won't be expressed relative to the subjects participation in the study. In such cases, the value for this element will need to be derived by the sponsor through comparision of procedure dates with study participation dates. If available, then the codes 'before-start' and 'before' map to 'true' and the rest map to false.
The date or start date of when the procedure started or was performed, 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 START DATE and TIME components and populate the SDTMIG variable PRSTDTC in ISO 8601 formatStart date/time of the procedure represented in ISO 8601 character format.
FHIR also allows performedString, but there is no way to map that to CDISC. The performedRange mapping is imprecise because it indicates imprecision around the performance rather than a specific start time.
Indication the procedure is ongoing when no end date is provided.
This does not map directly to an SDTM variable. May be used to populate a value into an SDTMIG relative timing variable such as PRENRF or PRENRTPT. When populating PRENRF, if the value of PRONGO is "Y", the value of "DURING", "AFTER" or "DURING/AFTER" may be used. When populating PRENRTPT, if the value of PRONGO is "Y", the value of "ONGOING" may be used. When PRONGO refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTM variable PRENRF should be populated. When PRONGO is used in conjunction with another time point, the SDTM variable PRENRRPT and PRENTPT should be used
AFTER
BEFORE
COINCIDENT
ONGOING
U
Identifies the end of the observation as being before or after the sponsor-defined reference time point defined by variable PRENTPT.
This does not map directly to an SDTM variable. May be used to populate a value into an SDTMIG relative timing variable such as PRENRF or PRENRTPT. When populating PRENRF, if the value of PRONGO is "Y", the value of "DURING", "AFTER" or "DURING/AFTER" may be used. When populating PRENRTPT, if the value of PRONGO is "Y", the value of "ONGOING" may be used. When PRONGO refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTM variable PRENRF should be populated. When PRONGO is used in conjunction with another time point, the SDTM variable PRENRRPT and PRENTPT should be used
This supports the necessity of separating procedures and medication.
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.
FHIR also allows performedString, but there is no way to map that to CDISC. The performedRange mapping is imprecise because it indicates imprecision around the performance rather than a specific end time.
The condition, disease, symptom, or disorder that the procedure was used to address or investigate (e.g., why the therapy was taken or administered, why the procedure was performed).
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Denotes the indication for the procedure (e.g., why the procedure was performed).
Note that reasonReference would need to be turned into a code or string.
Identifier for the adverse event that is the indication for this procedure.
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 format
Identifier for the medical history event that is the indication for this procedure.
This does not map directly to an SDTMIG variable. For SDTM submission datasets, may be used to create RELREC to link this record with a record in the eMedical History domain.
If FHIR IDs are used for RELREC, then the sponsor should evaluate its use case as necessary prior to mapping.
Dosing information collected in text form. Examples: <1, 200-400. Not populated when PRDOSE is populated.
If FHIR IDs are used for RELREC, then the sponsor should evaluate its use case as necessary prior to mapping.
The unit for intended dose/amount for PRDOSE, PRDOSTOT, or PRDOSTXT.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Units for PRDOSE, PRDOSTOT, or PRDOSTXT.
If FHIR IDs are used for RELREC, then the sponsor should evaluate its use case as necessary prior to mapping.
The number/amount of the procedure that was given/administered/taken during a specific interval.
The route of administration of the procedure.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Route of administration for PRTRT.
This is a known gap. Procedure Route of Administration interval does NOT exist for 'Procedure'.
A description of the anatomical location of an procedure, such as location of a biopsy.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Anatomical location of a procedure.
Qualifier for anatomical location further detailing side of the body for the procedure administration.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Qualifier for anatomical location or specimen further detailing laterality.
This is frequently pre-coordinated into Procedure.bodySite. Multiple qualifiers are possible. Laterality will need to be recognized by code and/or system
Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Qualifier for anatomical location or specimen further detailing directionality.
This is frequently pre-coordinated into Procedure.bodySite. Multiple qualifiers are possible. Directionality will need to be recognized by code and/or system
Qualifier for anatomical location further detailing the distribution (i.e., arrangement of, apportioning of).
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Qualifier for anatomical location or specimen further detailing the distribution, which means arrangement of, apportioning of.
Typically this would be pre-coordinated into Procedure.code and would be captured in dosage instructions text for medications. If captured as a separate element, if would need to be an extension.
An indication that the subject has abstained from food/water for the specified amount of time.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).
This would be handled as an extension. Could propose as standard extension.
The text description of the (intended) schedule or regimen for the procedure.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Text description of the intended schedule or regimen for the procedure.
An administration could be based on more than one thing (recommendation, plan, order) and in theory the intended dose would be different for each.
An indication whether or not the procedure dose/amount was adjusted.
When PRDOSADJ is collected, does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED> When PRADJ is to collected, the sponsor may suit this variable as a SUPPQ.
This would be handled as an extension. Would appear on Procedure/MedicationAdministration/MedicationStatement.basedOn.
Might consider proposing it as a standard extension.
Description or explanation of why a procedure dose/amount was adjusted.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).
This would be handled as an extension. Would appear on Procedure/MedicationAdministration/MedicationStatement.basedOn.
Might consider proposing it as a standard extension.
Indication whether the subject completed the intended regimen.
This does not map, directly to an SDTMIG variable. This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM = "PRTRTCMP" and SUPPPR.QLABEL = "Treatment Completed".
Not all potential mapping/FHIR resources/attributes will be addressed in this implementation guide. All data requires review and analysis to ensure the data is relevant and understood.
An indication whether the procedure was interrupted.
Does not map to an SDTMIG variable. The SDTM a CRF is annotated to indicate that this field is NOT SUBMITTED.
If something is currently interrupted, the status would either be on-hold or stopped. If there was a temporary interruption and the procedure has since resumed or completed, the only way to detect the interruption would be an extension or to review the history.
An indication of why the intervention was interrupted.
This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM = "PRITRPRS" and SUPPPR.QLABEL = "Reason intervention Interrupted". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variable.
If the status is on-hold or stopped, statusReason would convey the reason. If there was a temporary interruption and the procedure has since resumed or completed, the only way to detect the interruption would be an extension or to review the history.
The collected duration of the procedure interruption.
This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM = "PRCINTD" and SUPPPR.QLABEL = "Intervention Duration". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variable.
This would have to be an extension. Typically, you'd just look at history to see when something was suspended, then resumed.
The unit for the collected duration of the procedure interruption.
This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPPR dataset as the value of SPPPR.QVAL where SUPPPR.QNAM = "PRITRPD" and SUPPPR.QLABEL = "Interruption Duration". Concatenate the collected procedure interruption duration and the duration unit components and create PRITRPD using ISO 8601.
This would have to be part of the previous extension. Typically, reviewing the history of the procedure will indicate if it was suspended and then resumed.
MedDRA text description of the Lowest Level Term.
This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM = "PRLLT" and SUPPPR.QLABEL = "Lower Level Term". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variable.
Translation of Procedure.code to MeDRA will typically be performed by the sponsor and not provided in FHIR source data.
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.
Translation of Procedure.code to MeDRA will typically be performed by the sponsor and not provided in FHIR soure data.
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 is performed by the sponsor - not expected to receive this from the site or FHIR.
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 is performed by the sponsor - not expected to receive this from the site or FHIR.
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 is performed by the sponsor - not expected to receive this from the site or FHIR.
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 is performed by the sponsor - not expected to receive this from the site or FHIR.
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 is performed by the sponsor - not expected to receive this from the site or FHIR.
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 is performed by the sponsor - not expected to receive this from the site or FHIR.
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 is performed by the sponsor - not expected to receive this from the site or FHIR.
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.
A unique identifier for a site within 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 site within a study.
A unique subject identifier within a site and a study.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s). I the column with the heading SDTMIG Target.Subject identifier, which must be unique within the study. Often the ID of the subject as recorded on a CRF.
A subject's date of birth (with or without the time of birth). The complete Date of Birth is made from the temporal components of Birth Year, Birth Month, Birth Day and Birth Time.
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.
There is potential where the birth date can not be collected due to country regulations. In those cases an estimated age may be entered.
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.
Month of birth of the subject in an unambiguous date format (e.g., MMM).
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.
The year of birth of the subject in an unambiguous date format (e.g., 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 birth of the subject.
The time of birth of the subject in an unambiguous time format (e.g., hh:mm)
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.
The age of the subject expressed in AGEU.
The corresponding CDASH Variable(s) map directly to identified SDTM Variable(s).Age expressed in AGEU. May be derived from RFSTDTC and BRTHDTC, but BRTHDTC may not be available in all cases (due to subject privacy concerns).
There is potential where the birth date can not be collected due to country regulations.
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