FHIR to CDISC Joint Mapping Implementation Guide
1.0.0 - STU 1 International flag

FHIR to CDISC Joint Mapping Implementation Guide, published by HL7 International - BR&R Work Group. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. 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

Medical History

Medical history could include information from a wide range of FHIR resources. However, the most typical resources are:

  • AdverseEvent - These would be filtered to only extract issues that would not qualify as 'adverse events', but were still potentially study-relevant (perhaps having occurred prior to the study).
  • AllergyIntolerance - captures both the propensity to reaction as well as specific reaction occurrences
  • Condition - used to capture healthcare problems as well as other conditions (e.g. pregnancy)
  • Observation - captures symptoms, assessments, non-study pertinent lab results (e.g. blood type), etc.

Mappings are provided for all of these.

MH 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(individual=(AdverseEvent.subject|Condition.subject|AllergyIntolerance.patient|Observation.subject).study.resolve().partOf.resolve().identifier

AdverseEvent.extension(workflow-researchstudy).valueReference.resolve().partOf.resolve().identifier

Condition.extension(workflow-researchstudy).valueReference.resolve().partOf.resolve().identifier

AllergyIntolerance.extension(workflow-researchstudy).valueReference.resolve().partOf.resolve().identifier

Observation.extension(workflow-researchstudy).valueReference.resolve().partOf.resolve().identifier

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.
Study Site Identifier SITEID
Core: HR
Type: Char
DM.SITEID
Core: Req
Type: Char
ResearchStudy.site
0..* Reference

ResearchSubject.where(individual=(AdverseEvent.subject|Condition.subject|AllergyIntolerance.patient|Observation.subject).study.resolve().identifier

AdverseEvent.extension(workflow-researchstudy).valueReference.resolve().identifier

Condition.extension(workflow-researchstudy).valueReference.resolve().identifier

AllergyIntolerance.extension(workflow-researchstudy).valueReference.resolve().identifier

Observation.extension(workflow-researchstudy).valueReference.resolve().identifier

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.
Subject Identifier for the Study SUBJID
Core: HR
Type: Char
DM.SUBJID
Core: Req
Type: Char
ResearchSubject.identifier
0..* Identifier

ResearchSubject.where(individual=(AdverseEvent.subject|Condition.subject|AllergyIntolerance.patient|Observation.subject)).identifer.value

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
Any Medical History Event MHYN
Core: O
Type: Char
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.
Category for Medical History MHCAT
Core: R/C
Type: Char
MHCAT
Core: Perm
Type: Char
Condition.category
0..* CodeableConcept
Binding: ConditionCategory extensible

Condition.category

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.
AdverseEvent.category
0..* CodeableConcept
Binding: AdverseEventCategory extensible

AdverseEvent.category

AllergyIntolerance.category
0..* code
Binding: AllergyIntoleranceCategory required

AllergyIntolerance.category

Observation.category
0..* CodeableConcept
Binding: ObservationCategory preferred

Observation.category

Subcategory for Medical History MHSCAT
Core: O
Type: Char
MHSCAT
Core: Perm
Type: Char
Condition.category
0..* CodeableConcept
Binding: ConditionCategory extensible

Condition.category

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.
AdverseEvent.category
0..* CodeableConcept
Binding: AdverseEventCategory extensible

AdverseEvent.category

AllergyIntolerance.category
0..* code
Binding: AllergyIntoleranceCategory required

AllergyIntolerance.category

Observation.category
0..* CodeableConcept
Binding: ObservationCategory preferred

Observation.category

Medical History Collection Date MHDAT
Core: O
Type: Char
MHDTC
Core: Perm
Type: Char
values: ISO 8601
Condition.recordedDate
0..1 dateTime

Condition.recordedDate

AdverseEvent.recordedDate
0..1 dateTime

AdverseEvent.recordedDate

AllergyIntolerance.recordedDate
0..1 dateTime

AllergyIntolerance.recordedDate

Observation.effectiveDateTime
0..1 dateTime

Observaton.effectiveDateTime

MH Sponsor-Defined Identifier MHSPID
Core: O
Type: Char
MHSPID
Core: Perm
Type: Char
Condition.identifier
0..* Identifier

Condition.identifier

If FHIR IDs are used for RELREC, then the sponsor should evaluate its use case as necessary prior to mapping.
AdverseEvent.identifier
0..1 Identifier

AdverseEvent.identifier

AllergyIntolerance.identifier
0..* Identifier

AlergyIntolerance.identifier

Observation.identifier
0..* Identifier

Observation.identifier

Medical History Event Date Type MHEVDTYP
Core: O
Type: Char
SUPPMH.QVAL 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.
Reported Term for the Medical History MHTERM
Core: HR
Type: Char
MHTERM
Core: Req
Type: Char
Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code

AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code

Medical History Occurrence MHOCCUR
Core: O
Type: Char
MHOCCUR
Core: Perm
Type: Char
Condition.verificationStatus
0..1 CodeableConcept con-3, con-5
Binding: ConditionVerificationStatus required

Condition.verificationStatus.where(%this IN {'refuted'|'entered-in-error'})

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
AllergyIntolerance.verificationStatus
0..1 CodeableConcept ait-1, ait-2
Binding: AllergyIntoleranceVerificationStatus required

(AllergyIntolerance.verificationStatus in {'unconfirmed'|'confirmed'|'refuted'|'entered-in-error'}).not()

Observation.effectiveDateTime
0..1 dateTime

Observation.effectiveDateTime

Medical History Event prespecified MHPRESP
Core: O
Type: Char
MHPRESP
Core: Perm
Type: Char
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
Prior Medical History Event MHPRIOR
Core: O
Type: Char
MHSTRTPT* MHSTRF* 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.
Ongoing Medical History Event MHONGO
Core: O
Type: Char
MHENRF
Core: Perm
Type: Char MHENRTPT
Core: Perm
Type: Char
values: AFTER, BEFORE, COINCIDENT, ONGOING, U
Condition.clinicalStatus
0..1 CodeableConcept con-3, con-4, con-5
Binding: ConditionClinicalStatus required

Condition.clinicalStatus

AdverseEvent.outcome
0..1 CodeableConcept
Binding: AdverseEventOutcome required

AdverseEvent.outcome

MH Disease or Symptom Under Control MHCTRL
Core: O
Type: Char
Condition.clinicalStatus
0..1 CodeableConcept con-3, con-4, con-5
Binding: ConditionClinicalStatus required

Condition.clinicalStatus = ('inactive','remission',resolved')

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.
AdverseEvent.outcome
0..1 CodeableConcept
Binding: AdverseEventOutcome required

Observation.outcome = ('resolved', 'resolvedWithSequelae')

AllergyIntolerance.clinicalStatus
0..1 CodeableConcept ait-1, ait-2
Binding: AllergyIntoleranceClinicalStatus required

AllergyIntolerance.clinicalStatus = ('inactive', 'resolved')

Medical History Event Start Date MHSTDAT
Core: O
Type: Char
MHSTDTC
Core: Perm
Type: Char
values: ISO 8601
Condition.onsetDateTime
0..1 dateTime

Condition.onset.onsetDateTime

AdverseEvent.date
0..1 dateTime

AdverseEvent.date

AllergyIntolerance.onsetDateTime
0..1 dateTime

AllergyIntolerance.onsetDateTime

Observation.effectiveDateTime
0..1 dateTime

Observation.effectiveDateTime

Medical History Event End Date MHENDAT
Core: O
Type: Char
MHENDTC
Core: Perm
Type: Char
values: ISO 8601
Condition.abatementDateTime
0..1 dateTime con-4

Condition.abatementDateTime

Medical History Event Location MHLOC
Core: O
Type: Char
MHLOC* Condition.bodySite
0..* CodeableConcept
Binding: BodySite example

Condition.bodysite

AllergyIntolerances are generally not associated with body sites.
Condition.bodySite
0..* CodeableConcept
Binding: BodySite example

AdverseEvent.resultingCondition.resolve().bodySite

Observation.bodySite
0..1 CodeableConcept
Binding: BodySite example

Observation.bodySite

Observation.specimen.resolve().collection.bodySite

Specimen.collection.bodySite
0..1 CodeableConcept
Binding: BodySite example

Observation.bodySite

Observation.specimen.resolve().collection.bodySite

Medical History Event Laterality MHLAT
Core: O
Type: Char
MHLAT* 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
Medical History Directionality MHDIR
Core: O
Type: Char
MHDIR* 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
MH Event Location Portion or Totality MHPORTOT
Core: O
Type: Char
MHPORTOT* This would likely be an extension on Condition. It is not relevant for the other resources
MH Modified Reported Term MHMODIFY
Core: O
Type: Char
MHMODIFY
Core: Perm
Type: Char
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.
MH Dictionary-Derived Term MHDECOD
Core: O
Type: Char
MHDECOD
Core: Perm
Type: Char
Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHDECOD).code

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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHDECOD).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHDECOD).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHDECOD).code

Medical History Event Lowest Level Term MHLLT
Core: O
Type: Char
MHLLT* Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHLLT).display

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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHLLT).display

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHLLT).display

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHLLT).display

MH Event Lowest Level Term Code MHLLTCD
Core: O
Type: Num
MHLLTCD* Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHLLT).code

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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHLLT).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHLLT).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHLLT).code

MH Event Preferred Term Code MHPTCD
Core: O
Type: Num
MHPTCD* Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHPT).code

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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHPT).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHPT).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHPT).code

Medical History Event High Level Term MHHLT
Core: O
Type: Char
MHHLT* Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.where(system=%MHHLT).display

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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHHLT).display

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.where(system=%MHHLT).display

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.where(system=%MHHLT).display

MH Event High Level Term Code MHHLTCD
Core: O
Type: Num
MHHLTCD* Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHHLT).code

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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHHLT).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHHLT).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHHLT).code

MH Event High Level Group Term MHHLGT
Core: O
Type: Char
MHHLGT* Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHHLG).display

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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHHLG).display

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHHLG).display

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHHLG).display

MH Event High Level Group Term Code MHHLGTCD
Core: O
Type: Num
MHHLGTCD* Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHHLG).code

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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHHLG).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHHLG).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHHLG).code

MH Event Primary System Organ Class MHSCOC* Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHHLG).code

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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHHLG).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHHLG).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHHLG).code

MH Event Primary System Organ Class Code MHSOCCD
Core: O
Type: Num
MHSOCCD* Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHSOC).code

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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHSOC).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHSOC).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHSOC).code

FHIR map (or gap) CDISC Comment
Label Element FHIRPath CDASH SDTM
Study Identifier ResearchStudy.identifier
0..* Identifier

ResearchSubject.where(individual=(AdverseEvent.subject|Condition.subject|AllergyIntolerance.patient|Observation.subject).study.resolve().partOf.resolve().identifier

AdverseEvent.extension(workflow-researchstudy).valueReference.resolve().partOf.resolve().identifier

Condition.extension(workflow-researchstudy).valueReference.resolve().partOf.resolve().identifier

AllergyIntolerance.extension(workflow-researchstudy).valueReference.resolve().partOf.resolve().identifier

Observation.extension(workflow-researchstudy).valueReference.resolve().partOf.resolve().identifier

STUDYID
Core: HR
Type: Char
STUDYID
Core: Req
Type: Char
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.
Study Site Identifier ResearchStudy.site
0..* Reference

ResearchSubject.where(individual=(AdverseEvent.subject|Condition.subject|AllergyIntolerance.patient|Observation.subject).study.resolve().identifier

AdverseEvent.extension(workflow-researchstudy).valueReference.resolve().identifier

Condition.extension(workflow-researchstudy).valueReference.resolve().identifier

AllergyIntolerance.extension(workflow-researchstudy).valueReference.resolve().identifier

Observation.extension(workflow-researchstudy).valueReference.resolve().identifier

SITEID
Core: HR
Type: Char
DM.SITEID
Core: Req
Type: Char
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.
Subject Identifier for the Study ResearchSubject.identifier
0..* Identifier

ResearchSubject.where(individual=(AdverseEvent.subject|Condition.subject|AllergyIntolerance.patient|Observation.subject)).identifer.value

SUBJID
Core: HR
Type: Char
DM.SUBJID
Core: Req
Type: Char
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
Any Medical History Event 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. MHYN
Core: O
Type: Char
Category for Medical History Condition.category
0..* CodeableConcept
Binding: ConditionCategory extensible

Condition.category

MHCAT
Core: R/C
Type: Char
MHCAT
Core: Perm
Type: Char
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.
AdverseEvent.category
0..* CodeableConcept
Binding: AdverseEventCategory extensible

AdverseEvent.category

AllergyIntolerance.category
0..* code
Binding: AllergyIntoleranceCategory required

AllergyIntolerance.category

Observation.category
0..* CodeableConcept
Binding: ObservationCategory preferred

Observation.category

Subcategory for Medical History Condition.category
0..* CodeableConcept
Binding: ConditionCategory extensible

Condition.category

MHSCAT
Core: O
Type: Char
MHSCAT
Core: Perm
Type: Char
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.
AdverseEvent.category
0..* CodeableConcept
Binding: AdverseEventCategory extensible

AdverseEvent.category

AllergyIntolerance.category
0..* code
Binding: AllergyIntoleranceCategory required

AllergyIntolerance.category

Observation.category
0..* CodeableConcept
Binding: ObservationCategory preferred

Observation.category

Medical History Collection Date Condition.recordedDate
0..1 dateTime

Condition.recordedDate

MHDAT
Core: O
Type: Char
MHDTC
Core: Perm
Type: Char
values: ISO 8601
AdverseEvent.recordedDate
0..1 dateTime

AdverseEvent.recordedDate

AllergyIntolerance.recordedDate
0..1 dateTime

AllergyIntolerance.recordedDate

Observation.effectiveDateTime
0..1 dateTime

Observaton.effectiveDateTime

MH Sponsor-Defined Identifier Condition.identifier
0..* Identifier

Condition.identifier

MHSPID
Core: O
Type: Char
MHSPID
Core: Perm
Type: Char
If FHIR IDs are used for RELREC, then the sponsor should evaluate its use case as necessary prior to mapping.
AdverseEvent.identifier
0..1 Identifier

AdverseEvent.identifier

AllergyIntolerance.identifier
0..* Identifier

AlergyIntolerance.identifier

Observation.identifier
0..* Identifier

Observation.identifier

Medical History Event Date Type If MHSTDTC and/or the MHENDTC are extracted from FHIR, their meaning is fixed, and thus so will be the value of this element. MHEVDTYP
Core: O
Type: Char
SUPPMH.QVAL 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.
Reported Term for the Medical History Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code

MHTERM
Core: HR
Type: Char
MHTERM
Core: Req
Type: Char
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code

Medical History Occurrence Condition.verificationStatus
0..1 CodeableConcept con-3, con-5
Binding: ConditionVerificationStatus required

Condition.verificationStatus.where(%this IN {'refuted'|'entered-in-error'})

MHOCCUR
Core: O
Type: Char
MHOCCUR
Core: Perm
Type: Char
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
AllergyIntolerance.verificationStatus
0..1 CodeableConcept ait-1, ait-2
Binding: AllergyIntoleranceVerificationStatus required

(AllergyIntolerance.verificationStatus in {'unconfirmed'|'confirmed'|'refuted'|'entered-in-error'}).not()

Observation.effectiveDateTime
0..1 dateTime

Observation.effectiveDateTime

Medical History Event prespecified 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 MHPRESP
Core: O
Type: Char
MHPRESP
Core: Perm
Type: Char
Prior Medical History Event 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.
MHPRIOR
Core: O
Type: Char
MHSTRTPT* MHSTRF*
Ongoing Medical History Event Condition.clinicalStatus
0..1 CodeableConcept con-3, con-4, con-5
Binding: ConditionClinicalStatus required

Condition.clinicalStatus

MHONGO
Core: O
Type: Char
MHENRF
Core: Perm
Type: Char MHENRTPT
Core: Perm
Type: Char
values: AFTER, BEFORE, COINCIDENT, ONGOING, U
AdverseEvent.outcome
0..1 CodeableConcept
Binding: AdverseEventOutcome required

AdverseEvent.outcome

MH Disease or Symptom Under Control Condition.clinicalStatus
0..1 CodeableConcept con-3, con-4, con-5
Binding: ConditionClinicalStatus required

Condition.clinicalStatus = ('inactive','remission',resolved')

MHCTRL
Core: O
Type: Char
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.
AdverseEvent.outcome
0..1 CodeableConcept
Binding: AdverseEventOutcome required

Observation.outcome = ('resolved', 'resolvedWithSequelae')

AllergyIntolerance.clinicalStatus
0..1 CodeableConcept ait-1, ait-2
Binding: AllergyIntoleranceClinicalStatus required

AllergyIntolerance.clinicalStatus = ('inactive', 'resolved')

Medical History Event Start Date Condition.onsetDateTime
0..1 dateTime

Condition.onset.onsetDateTime

MHSTDAT
Core: O
Type: Char
MHSTDTC
Core: Perm
Type: Char
values: ISO 8601
AdverseEvent.date
0..1 dateTime

AdverseEvent.date

AllergyIntolerance.onsetDateTime
0..1 dateTime

AllergyIntolerance.onsetDateTime

Observation.effectiveDateTime
0..1 dateTime

Observation.effectiveDateTime

Medical History Event End Date Condition.abatementDateTime
0..1 dateTime con-4

Condition.abatementDateTime

MHENDAT
Core: O
Type: Char
MHENDTC
Core: Perm
Type: Char
values: ISO 8601
Medical History Event Location Condition.bodySite
0..* CodeableConcept
Binding: BodySite example

Condition.bodysite

MHLOC
Core: O
Type: Char
MHLOC* AllergyIntolerances are generally not associated with body sites.
Condition.bodySite
0..* CodeableConcept
Binding: BodySite example

AdverseEvent.resultingCondition.resolve().bodySite

Observation.bodySite
0..1 CodeableConcept
Binding: BodySite example

Observation.bodySite

Observation.specimen.resolve().collection.bodySite

Specimen.collection.bodySite
0..1 CodeableConcept
Binding: BodySite example

Observation.bodySite

Observation.specimen.resolve().collection.bodySite

Medical History Event Laterality 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 MHLAT
Core: O
Type: Char
MHLAT*
Medical History Directionality 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 MHDIR
Core: O
Type: Char
MHDIR*
MH Event Location Portion or Totality This would likely be an extension on Condition. It is not relevant for the other resources MHPORTOT
Core: O
Type: Char
MHPORTOT*
MH Modified Reported Term This would need to be captured as an extension on AdverseEvent.event.text. A new standard extesnsion should be proposed MHMODIFY
Core: O
Type: Char
MHMODIFY
Core: Perm
Type: Char
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.
MH Dictionary-Derived Term Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHDECOD).code

MHDECOD
Core: O
Type: Char
MHDECOD
Core: Perm
Type: Char
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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHDECOD).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHDECOD).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHDECOD).code

Medical History Event Lowest Level Term Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHLLT).display

MHLLT
Core: O
Type: Char
MHLLT* 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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHLLT).display

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHLLT).display

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHLLT).display

MH Event Lowest Level Term Code Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHLLT).code

MHLLTCD
Core: O
Type: Num
MHLLTCD* 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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHLLT).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHLLT).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHLLT).code

MH Event Preferred Term Code Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHPT).code

MHPTCD
Core: O
Type: Num
MHPTCD* 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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHPT).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHPT).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHPT).code

Medical History Event High Level Term Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.where(system=%MHHLT).display

MHHLT
Core: O
Type: Char
MHHLT* 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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHHLT).display

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.where(system=%MHHLT).display

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.where(system=%MHHLT).display

MH Event High Level Term Code Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHHLT).code

MHHLTCD
Core: O
Type: Num
MHHLTCD* 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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHHLT).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHHLT).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHHLT).code

MH Event High Level Group Term Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHHLG).display

MHHLGT
Core: O
Type: Char
MHHLGT* 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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHHLG).display

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHHLG).display

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHHLG).display

MH Event High Level Group Term Code Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHHLG).code

MHHLGTCD
Core: O
Type: Num
MHHLGTCD* 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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHHLG).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHHLG).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHHLG).code

MH Event Primary System Organ Class Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHHLG).code

MHSCOC* 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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHHLG).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHHLG).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHHLG).code

MH Event Primary System Organ Class Code Condition.code
0..1 CodeableConcept
Binding: ConditionKind example

Condition.code.coding.where(system=%MHSOC).code

MHSOCCD
Core: O
Type: Num
MHSOCCD* 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.
AdverseEvent.event
0..1 CodeableConcept
Binding: AdverseEventType example

AdverseEvent.event.coding.where(system=%MHSOC).code

AllergyIntolerance.code
0..1 CodeableConcept
Binding: AllergyIntoleranceCode example

AllergyIntolerance.code.coding.where(system=%MHSOC).code

Observation.code
1..1 CodeableConcept
Binding: ObservationCode example

Observation.code.coding.where(system=%MHSOC).code