Caveats

While the most common use-cases for the mappings in this IG are for conversion of FHIR data into CDISC, the mappings are documented by listing the CDISC specifications first. This is because the CDISC scope is smaller than the FHIR scope and it is easiest to understand the mappings by organizing them according to the CDISC elements

The mappings listed here are version-specific. Implementers may attempt to leverage the mapping information when using alternate versions, but should be aware that changes between versions may render the mapping information inappropriate. CDISC and HL7 expect to produce new versions of this IG to document mappings for future releases of the specifications for both organizations.

The mappings are also based only on the information defined in the core specifications and, for FHIR, extensions defined in the core specification. Implementations will also need to consider mappings for supplemental qualifiers and local FHIR extensions.

Mappings

In this release, mappings are captured in a simple table structure intended to support the work of business analysts rather than a formal computably executable representation. This approach was chosen for a few reasons:

• As mentioned in introduction, mappings will need to be adjusted on a study-specific and implementation-environment specific basis. A business-analyst view of the mappings will be easier to use as a starting point for context-specific adjustment than a formally computable structure.
• Less formal tabular representations are easier for the community to review and verify.
• Different organizations are likely to have differing tooling stacks for performing data conversion, meaning that formally computable representations are less likely to be as broadly useful.
• Formal, executable mappings, such as those expressible with StructureMap are more time-consuming to create and test, and HL7 and CDISC do not want to undertake that effort unless there is a clear demand from the community for such artifacts to be produced.

Future versions of this implementation guide may include formal profiles of FHIR resources for use with CDISC standards, concept maps that support translation between CDISC and FHIR terminologies and extension definitions for data elements used in CDISC but not present in the FHIR core specification. Implementers are encouraged to provide feedback about what resources they would find most helpful.

Mapping tables are provided for each CDISC 'domain'. (Domains are a means of organizing related data in both the SDTM and CDASH specifications.) Not all CDISC domains are mapped in this release, but all of the primary clinical domains are included, specifically: Adverse Events (AE), Concommitant Medications (CM), Demographics (DM), Labs (LB), Medical History (MH), Procedures and Vital Signs (VS). Each domain table is organized into three sections. The first provides information about the CDISC domain elements, both from the SDTM and the CDASH perspective (though not all data elements will exist in both specifications). This portion of the table contains the following data elements:

• Name - a descriptive name for the data element. This is the descriptive name for the element as exposed in CDASH and/or SDTM. (If the names are different in the two specifications but it is known the content and mapping are the same, the CDASH name is chosen preferentially).
• CDASH Variable - the formal id for the variable in the CDASH standard. A fly-over provides the definition for the element in CDASH. This column will be omitted for mapped data elements that do not have a CDASH equivalent.
• SDTM Variable - the formal id for the variable in the SDTM standard. A fly-over provides the definition for the element in SDTM. This column will be omitted for mapped data elements that do not have a SDTM equivalent.

The second part of the mapping table indicates where the data element can be found in FHIR. In some cases, there will only be a comment indicating that no mapping currently exists (and that custom extensions would be needed). In other cases, there may be multiple FHIR rows for a single CDISC row if corresponding data might be found in multiple places. This section includes the following columns:

• Resource element - indicates the specific resource element in FHIR and provides a hyperlink to the associated data dictionary page in the FHIR core specification.
• Path - provides a description of how to navigate from the 'base' FHIR resource that corresponds to the equivalent domain to the specified data element. (See the FHIRPath section below.)

If no mapping is possible (via standard FHIR elements or extensions), then guidance will be provided about whether data might be expected to be gleaned in other ways (e.g. a custom extension) or whether the information is simply unlikely to be found in clinical systems exposing FHIR interfaces. Such gaps will be marked as 'gray'.

Finally, there is a comments column containing additional considerations related to the mapping.

NOTE:

There is an additional table on the Laboratory page that covers the LAB specification. It behaves slightly differently as the LAB specification uses XML rather than SAS and its elements are therefore expressed as XPaths rather than variable names. Otherwise, it behaves the same as those above.

The tables for each domain can be found by using the 'Mapping' menu link. As well, the downloads page includes a link to CSV and Excel files containing the same content as the complete set of mapping tables, with the exception that definitions are included as columns rather than flyovers.

FHIRPath

The syntax used to express the mappings to FHIR is based on a simplified version of the FHIRPath syntax. This syntax is used for a few reasons:

• FHIR data can be expressed in different syntaxes (XML, JSON and RDF) and FHIRPath is a syntax-independent path language.
• FHIRPath is more concise than other path language (e.g. XPath).
• FHIRPath includes built in extensions for traversing references to other resources and accessing extensions.
• If we ever move to fully computable mappings, they will need to be based on FHIRPath.

However, because the objective for this implementation guide is NOT fully computable mappings, we have taken a few liberties with the syntax for ease of conciseness and readability. Specifically:

• References to a 'contextual' resource are expressed as a simple resource path rather than using a FHIRPath context variable. E.g. ResearchSubject.where(patient=Observation.subject) means to find the ResearchSubject whose 'patient' element references the same resource as the context Observation resource's 'subject' element references.
• As in the example above, equality assertions of reference elements is taken to mean that they reference the same resource.
• When referencing CodeableConcept elements, the implication is that an appropriate code will be extracted from the coding.
• When referencing 'standard' extensions, the http://hl7.org/fhir/StructureDefinition/ prefix is ignored.
• Similarly, when referencing R5 pre-adoption extensions, the extension path of R5/someCode is interpreted to be http://hl7.org/fhir/5.0/StructureDefinition/.