There are multiple areas where different approaches between FHIR and CDISC create challenges for mapping between the standards. This section highlights some of those areas and lists considerations and guidance for how study sponsors and others might manage the mapping process.

NOTE: The determination of what data should be mapped and how it should be mapped must always be made in the context of the intended use of the information, including the nature of the study, the requirements of any regulatory agency, and the type(s) of analysis to be performed. As such, deviation from the guidance provided here may be appropriate or even essential in some situations. Some data elements may need to be converted, extrapolated or derived rather than mapped directly.

Mapping Conditions to MedDRA for Medical History, Clinical Events, and Adverse Events

This is a potential solution for terminologies and mapping Conditions in FHIR for the CDASH/SDTM domains of Medical History (MH), Clinical Events (CE), and Adverse Events (AE). Currently, CE is not mapped in this implementation guide, however, the concepts in MH and AE will likely apply mapping is required for this domain.

Typically in clinical research, the Medical Dictionary for Regulatory Activities (MedDRA) is used for clinical concepts for medical history and adverse events. In many countries and regions, the use of MedDRA is mandated for safety reporting. MedDRA is medical terminology for clinical research developed by the International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use (ICH) to facilitate the sharing of regulatory information. MedDRA is organized with a five-level hierarchy. The broadest term is the System Organ Class (SOC); this is further divided into High-Level Group Terms (HLGT), High-Level Terms (HLT), Preferred Terms (PT), and then granular Lowest Level Terms (LLT). In CDISC there are variables for the different levels of MedDRA terms. See the the Study Data Tabulation Model Implementation Guide (SDTMIG) v3.3, Section 4.3, Coding, and Controlled Terminology for more information and the SDTMIG v3.2, Section 4.1.3.5, Storing Controlled Terminology for Synonym Qualifier Variables (available at https://www.cdisc.org/standards/foundational/sdtmig).

Example:

Description	CDASH Variable	CDASH Mapping Instruction & Description
AE Lowest Level Term	AELLT	MedDRA text description of the Lowest Level Term
AE Lowest Level Term code	AELLTCD	MedDRA Lowest Level Term code

In the Medical History domain, the MHTERM variable is the verbatim or preprinted CRF term for the medical condition or event. The MHMODIFY variable is the MHTERM modified to facilitate coding and the MHDECOD variable is the dictionary-derived text description of MHTERM or MHMODIFY which is 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 external codelist element in the Define-XML document. MHMODIFY is used to store a term that has been modified to code against the dictionary (e.g., to correct typos or reorder words), when the original verbatim term is retained in MHTERM. It is a sponsor’s decision whether or not to use MHMODIFY - some sponsors go back to the investigator for corrections to allow coding and then just update the value in MHTERM. This applies similarly to AETERM, AEMODIFY, and AEDECOD. The focus of this page is geared towards the topic of adverse events. For medical history, adverse event, and clinical event, the Fast Healthcare Interoperability Resources (FHIR) Resources Condition, Observation will likely be where the events of interest will be identified.

Keep in mind that the Resource AdverseEvent in FHIR originates with the HL7 Patient Care Working Group (PCWG). FHIR defines AdverseEvent as "Actual or potential/avoided event causing unintended physical injury resulting from or contributed to by medical care, a research study or other healthcare setting factors that requires additional monitoring, treatment, or hospitalization, or that results in death."

There may be applications that are tailored for clinical research where this definition is aligned with the clinical research concepts. The best approach is to be cognizant of the data being mapped and realize the difference between the similar terms and different definitions due to the different healthcare focus and clinical research concepts. While it may appear the same, it may not be. At the time of this mapping, the values in AdverseEvent are likely related to hospital, health clinic, and health-related encounters.

In addition to variations in concepts, each coding system has varying degrees of specificity and overlap. In clinical research, MedDRA is used. However, in electronic health record systems, common terminologies include the International Classification of Disease (Version 10, ICD-10, or Version 11, ICD-11), LOINC, and SNOMED CT (see table).

Table. Terminologies

Terminology	Description	Web links
MedDRA	MeDRA is medical terminology for clinical research developed by the International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use (ICH).	https://tools.meddra.org/wbb/
NCI-EVS	The National Cancer Institute Enterprise Vocabulary Services, part of the US National Institutes of Health, creates, compiles, and cross-maps biomedical terminology needed by NCI and its community. EVS publishes the NCI Thesaurus (NCIt).	https://evs.nci.nih.gov
NCIt	The NCIt is a widely recognized standard for biomedical coding and reference, used by a broad variety of public and private partners both nationally and internationally including the Clinical Data Interchange Standards Consortium Terminology (CDISC), the US Food and Drug Administration (FDA), the Federal Medication Terminologies (FMT), and the National Council for Prescription Drug Programs (NCPDP).	https://ncit.nci.nih.gov/ncitbrowser/
ICD	The International Classification of Diseases provides the foundation for the identification of health trends and statistics globally and the international standard for reporting diseases and health conditions. There are differences in the implementations of the ICD codes by country to be aware of when mapping.	https://www.who.int/classifications/icd/en/
SNOMED CT	SNOMED (formerly the Systematized Nomenclature of Medicine) is a multilingual thesaurus with an ontological foundation that is owned and maintained by the International Health Terminology Standards Development Organization (IHTSDO). SNOMED has a class hierarchy and is a clinical terminology designed to capture and represent patient data for clinical purposes. The IHTSDO's SNOMED CT browser provides ways to browse and search for SNOMED CT.[6]	https://www.snomed.org https://browser.ihtsdotools.org/
LOINC	Logical Observation Identifiers Names and Code provides universal codes and names that provide a common language with identifiers, names, and codes for identifying health measurements, observations, and documents.	https://loinc.org/ https://loinc.org/downloads/loinc-table/

In FHIR, the context of a value would be captured in the code such as SNOMED. Requires a review of data to ensure the code meets the criteria for the data element.

RELREC

For RELREC, these have not been mapped as transformational-based relationship linking is out of scope for this mapping document. If FHIR identifiers (IDs) are used for RELREC, then the sponsor should evaluate the use case as necessary prior to mapping to CDISC. Often relationships are established by the investigator which would occur outside of the clinical healthcare data realm and in the clinical research data realm, thus this information is likely collected only in the sponsor's electronic data capture (EDC) system.

--PRESP AND --OCCUR

• This is noted as a "gap", however, in an EHR system, this variable is not applicable. The idea behind the --PRESP and --OCCUR variables is that the suggestion of the concept may impact the answer. For example, if the subject is asked if their arm hurts, they might consider it and think, yes, my arm does hurt. Whereas, if the subject is asked how they feel, they may not mention their arm hurting. In clinical research, this is tracked to see if the --PRESP/--OCCUR impacted the results.
• If a Case report form was designed to be sent to the EHR for completion as a part of the patient/subjects record, it is coded as a "Questionnaire" Resource with each concept then prespecified (--PRESP) as a StructuredDefinition.*element --> the element being in the procedure domain the types of procedures in question. Identifier.SNOMED.73761001.colonoscopy which would likely be translated to MedDRA term for the procedure (or CDISC code if available): "Colonoscopy"
• How this is populated in the sponsor's database would be up to the sponsor. If available, it would need to be an extension.
• In general, FHIR only captures concepts/records that have occurred and normally does not capture the absence of concepts. If the information around "has the patient had X" then this could be accomplished using a questionnaire.
• Would not expect to receive these from a site. These variables may be appropriate for mapping in a questionnaire.

MHEVDTYP

Not expect to receive this 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.

MHEVDTYP is a variable that would not be found in the electronic health record data. The information would be there but would be difficult to map because this variable is a "condition" associated with a specific date. For example, the instance of the "Diagnosis" of the clinical condition, such as diabetes, would likely be the first instance of "diabetes" in the records. However, there may be other records elsewhere and this would not necessarily be able to be discerned without further investigation. The concepts of relapse, infection, and symptoms are similar. In the records, these medical history terms will have dates but they will need to be verified for the validity of MHEVDTYP.

MHEVDTYP

Medical History Event Date Type

Char

(MHEDTTYP)

Variable Qualifier

Specifies the aspect of the medical condition or event by which MHSTDTC and/or the MHENDTC is defined. Examples: "DIAGNOSIS", "SYMPTOMS", "RELAPSE", "INFECTION".

Procedures and PRDOSE and PRDOSTXT

At this time there are ongoing discussions at HL7 on the recommendations for handling radiation, light therapy and similar non-medication "administrations". This will impact the modeling of the following concepts:

https://www.cdisc.org/standards/foundational/sdtmig/sdtmig-v3-3/html#Procedures, Section 6.1.5

Currently, these will be handled as extensions that tie the procedure to the study looking at the respective dates. The assertion would be specific to the study link.

Procedures and PRONGO

Ongoing Procedure

Procedure

status

Procedure.status

An example of an ongoing procedure, "hemodialysis with frequency of three times a week".

If the status is 'in-progress'/'active', then it's ongoing.

In the CDASH, PRONGO is as follows:

For guidance refer to CDASH IG, v2.1

Procedures and PRTRT, PRMODIFY and PRDECOD

In FHIR, there's no need to modify the PRTRT. There is the text the person actually saw/typed (errors and all) 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.

The PRMODIFY and PRDECOD variables work towards standardizing the term in the PRTRT variable, they are Synonym Qualifiers specifying an alternate name for the particular variable in an observation. The PRMODIFY variable is used to store the term for the procedure that has been modified to code against the dictionary (e.g., to correct typos or reorder words), when the original verbatim term is retained in PRTRT. It is a sponsor’s decision whether or not to use PRMODIFY - some sponsors go back to the investigator for corrections to allow coding and then just update the value in the PRTRT variable. If the value for PRTRT is modified for coding purposes, then the modified text is placed here. The dictionary- or sponsor-defined standardized text description of PRTRT, or the modified topic variable (PRMODIFY), if applicable. PRDECOD is used to provide a standardized procedure term. For submission the term collected would go in the PRTRT, the modified term (PRMODIFY) would go in the modified treatment value field, and then the standardized treatment name (PRDECOD) would go in the the standardized treatment field. The PRTRT is a required variable, the PRDECOD is permissable and the PRMODIFY is used to show traceability.

Vital Signs

In the VS domain for “VS Position of Subject” mapping, the current mapping is Observation.method

For the “Vital Signs Position of Subject” Field, the FHIR Observation.Method measures how the observation was collected. The CDASH term VS.VSPOS measures the body position (supine, sitting, standing) of the subject when the observation was collected. Currently, there are LOINC codes that contain the position that can be transformed into VSORRES and VSPOS.

• Observation.method.85354-0 (blood pressure)
• Observation.method.8461-6 (systolic blood pressure—supine) --> map to VSTEST: Systolic Blood Pressure; VSTESTCD: SYSBP; VSPOS: SUPINE (C62167)

This snapshot shows the orthostatic blood pressure panel which has LOINC codes for a position in relation to vital signs.

Source: https://loinc.org/34553-8/

For more information on LOINC Clinical observations and measures, see the LOINC Users’ Guide Section 4: https://loinc.org/kb/users-guide/clinical-observations-and-measures/

For more information on Vital Sign in the CDASHIG v2.1, please click here.

For more information on Vital Sign in the SDTMIG v3.2, please click here.

This shows how Vital Signs are represented in SDTMIG v3.2 (page 278) for the FHIR-CDISC mapping.