FHIR to CDISC Joint Mapping Implementation Guide
1.0.0 - STU 1

FHIR to CDISC Joint Mapping Implementation Guide, published by HL7 International - BR&R Work Group. This is not an authorized publication; it is the continuous build for version 1.0.0). This version is based on the current content of https://github.com/HL7/fhir-cdisc-mapping/ and changes regularly. See the Directory of published versions

Demographics

Demographic information in FHIR is captured using the Patient resource. Even if an individual isn't directly receiving care, if they're a potential subject of care, they're represented using Patient. The ResearchSubject resource is used to tie patients to specific research studies and to capture metadata about the patient's involvement with that study. In theory the same patient could be involved in many studies, some even at the same time.

DM Mappings

Guidance on interpreting the tables can be found here.

CDISC FHIR map (or gap) Comment
Label CDASH SDTM Element FHIRPath
Study Identifier STUDYID
Core: HR
Type: Char
STUDYID
Core: Req
Type: Char
ResearchStudy.identifier
0..* Identifier

ResearchSubject.where(subject=Patient).study.resolve().partOf.resolve().identifier

Study Site Identifier SITEID
Core: HR
Type: Char
DM.SITEID
Core: Req
Type: Char
ResearchStudy.identifier
0..* Identifier

ResearchSubject.where(subject=Patient).study.resolve().identifier

Subject Identifier for the Study SUBJID
Core: HR
Type: Char
DM.SUBJID
Core: Req
Type: Char
ResearchSubject.identifier
0..* Identifier

ResearchSubject.where(individual=Patient).identifier.identifier

Birth Date BRTHDAT
Core: R/C
Type: Char
BRTHDTC
Core: Perm
Type: Char
values: ISO 8601
Patient.birthDate
0..1 date

Patient.birthDate

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
Birth Day BRTHDD
Core: R/C
Type: Char
BRTHDTC
Core: Perm
Type: Char
values: ISO 8601
Patient.birthDate
0..1 date

Patient.birthDate.substring(8,4)

Birth Month BRTHMO
Core: R/C
Type: Char
BRTHDTC
Core: Perm
Type: Char
values: ISO 8601
Patient.birthDate
0..1 date

Patient.birthDate.substring(5,2)

Birth Year BRTHYY
Core: R/C
Type: Char
BRTHDTC
Core: Perm
Type: Char
values: ISO 8601
Patient.birthDate
0..1 date

Patient.birthDate.substring(0,4)

Birth Time BRTHTIM
Core: O
Type: Char
BRTHDTC
Core: Perm
Type: Char
values: ISO 8601
Patient.extension
0..* Extension

Patient.extension(patient-birthTime).valueTime

Age AGE
Core: O
Type: Num
AGE
Core: Exp
Type: Num
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.
Age Units AGEU
Core: O
Type: Char
AGEU
Core: Exp
Type: Char
Age can be captured as an Observation as a point-in-time assessment, but generally this is simply calculated from birthDate.
Demographics Collection Date DMDAT
Core: R/C
Type: Char
DMDTC
Core: Perm
Type: Char
values: ISO 8601
Patient.meta
0..1 Meta

Patient.meta.lastUpdated

 

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 SEX
Core: R/C
Type: Char
SEX
Core: Req
Type: Char
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
Ethnicity ETHNIC
Core: O
Type: Char
ETHNIC
Core: Perm
Type: Char
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
Collected Ethnicity CETHNIC
Core: O
Type: Char
SUPPDM.QVAL 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
Race RACE
Core: R/C
Type: Char
RACE
Core: Exp
Type: Char
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
Collected Race CRACE
Core: R/C
Type: Char
SUPPDM.QVAL 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
Race Other RACEOTH
Core: O
Type: Char
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
FHIR map (or gap) CDISC Comment
Label Element FHIRPath CDASH SDTM
Study Identifier ResearchStudy.identifier
0..* Identifier

ResearchSubject.where(subject=Patient).study.resolve().partOf.resolve().identifier

STUDYID
Core: HR
Type: Char
STUDYID
Core: Req
Type: Char
Study Site Identifier ResearchStudy.identifier
0..* Identifier

ResearchSubject.where(subject=Patient).study.resolve().identifier

SITEID
Core: HR
Type: Char
DM.SITEID
Core: Req
Type: Char
Subject Identifier for the Study ResearchSubject.identifier
0..* Identifier

ResearchSubject.where(individual=Patient).identifier.identifier

SUBJID
Core: HR
Type: Char
DM.SUBJID
Core: Req
Type: Char
Birth Date Patient.birthDate
0..1 date

Patient.birthDate

BRTHDAT
Core: R/C
Type: Char
BRTHDTC
Core: Perm
Type: Char
values: ISO 8601
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
Birth Day Patient.birthDate
0..1 date

Patient.birthDate.substring(8,4)

BRTHDD
Core: R/C
Type: Char
BRTHDTC
Core: Perm
Type: Char
values: ISO 8601
Birth Month Patient.birthDate
0..1 date

Patient.birthDate.substring(5,2)

BRTHMO
Core: R/C
Type: Char
BRTHDTC
Core: Perm
Type: Char
values: ISO 8601
Birth Year Patient.birthDate
0..1 date

Patient.birthDate.substring(0,4)

BRTHYY
Core: R/C
Type: Char
BRTHDTC
Core: Perm
Type: Char
values: ISO 8601
Birth Time Patient.extension
0..* Extension

Patient.extension(patient-birthTime).valueTime

BRTHTIM
Core: O
Type: Char
BRTHDTC
Core: Perm
Type: Char
values: ISO 8601
Age 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.
AGE
Core: O
Type: Num
AGE
Core: Exp
Type: Num
Age Units Age can be captured as an Observation as a point-in-time assessment, but generally this is simply calculated from birthDate. AGEU
Core: O
Type: Char
AGEU
Core: Exp
Type: Char
Demographics Collection Date Patient.meta
0..1 Meta

Patient.meta.lastUpdated

DMDAT
Core: R/C
Type: Char
DMDTC
Core: Perm
Type: Char
values: ISO 8601
 

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 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
SEX
Core: R/C
Type: Char
SEX
Core: Req
Type: Char
Ethnicity 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 ETHNIC
Core: O
Type: Char
ETHNIC
Core: Perm
Type: Char
Collected Ethnicity 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 CETHNIC
Core: O
Type: Char
SUPPDM.QVAL
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
RACE
Core: R/C
Type: Char
RACE
Core: Exp
Type: Char
Collected 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.

Other countries use vastly different value sets or prohibit collection. If captured for clinical rather than administrative purposes, this would be an Observation
CRACE
Core: R/C
Type: Char
SUPPDM.QVAL
Race Other 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
RACEOTH
Core: O
Type: Char