FHIR to CDISC Joint Mapping Implementation Guide
1.0.0 - STU 1

This page is part of the CDISC Mapping FHIR IG (v1.0.0: STU 1) based on FHIR R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, 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