HL7 FHIR Implementation Guide: Common Terminology Criteria (CTC) Adverse Events Release 1 - DRAFT
0.0.1 - DRAFT United States of America flag

HL7 FHIR Implementation Guide: Common Terminology Criteria (CTC) Adverse Events Release 1 - DRAFT, published by HL7 International Clinical Interoperability Council. This guide is not an authorized publication; it is the continuous build for version 0.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/standardhealth/fsh-ae/ and changes regularly. See the Directory of published versions

Implementation

Implementation Notes

This page contains miscellaneous information on modeling and FHIR implementation. The content is primarily directed at informaticists and implementers of the following adverse reporting methods:

  • CTEP Clinical Trial Monitoring Service (CTMS)
  • CTEP Clinical Data Update Service (CDUS)

The following topics are addressed:

Understanding this Guide

The CTC Adverse Event Implementation Guide was developed using the standard HL7 FHIR publishing tools. The page layouts and symbols are explained in the FHIR documentation.

Each profile is shown in multiple views. The “Differential Table” view represents the difference between the current profile and its base resource or profile. When interpreting this view, bear in mind that the immediate parent may not be a base FHIR resource, but it could be a US Core profile or another profile in this guide.

The data elements identified in this process were modeled using FHIR Shorthand (FSH) and SUSHI and exported as FHIR Profiles. The profiles, related FHIR artifacts, and other technical implementation information, constitute the bulk of this IG.

Concept Model

The CTC Adverse Event model was informed by data elements identified in an adverse event collection workflow from a vendor based EHR. The conceptual organization of an individual CTC adverse event in the context of FHIR resources and elements is illustrated below.

CTC Adverse Event Logical Model

Compatibility and Conformance with mCODE

The CTCAdverseEvent profile can exist independently as a profile reference or derived by other FHIR implementation guides like mCODE. The mCODE bundle an open and allows the existence of other FHIR profiles and base resources, a CTCAdverseEvent. It allows for the flexibility of the receiver to either process all entries inside a bundle for comprehensiveness or to just retrieve the minimal and necessary set of bundle entries which support a CTC adverse event.

Artifacts

This is a set of experimental profiles for representing adverse events (AE). The definitions are FHIR interpretation of Common Terminology Criteria (CTC). The profiles and value sets and are intended to give minimal and sufficient information for CTCAE reporting. A summary table is shown below with a more detailed summary available in the Artifacts page.

Type Name Description Example
Profile CTCAdverseEvent Records an AE Example 1, Example 2
Extension CTCAEGrade Records the CTC Grade Example 1, Example 2
Extension AdverseEventExpectation Whether event was expected Example 1
Extension AdverseEventResolvedDate Date when the AE ends Example 1
CodeSystem CTCAEGradeCS Defines CTC Grades n/a
ValueSet CTCAEGradeVS Values for CTC Grade n/a
ValueSet AdverseEventSeriousnessVS Values for seriousness n/a
ValueSet AdverseEventExpectationVS Values for expectation n/a
ValueSet CTCAETermVS CTCAE terms for AE n/a
ValueSet AdverseEventRelatednessVS Likelihood that AE is related to intervention n/a

CTC AE Messaging Flow

The implementation can support either sending an individual CTC adverse event resource, or as part of an AE bundle. Messaging flows in both cases are shown below:

CTC Adverse Event Message ExchangeCTCAE Data ReceiverCTCAE Data SenderCTC AdverseEvent ExchangeGET [base]/CTCAdverseEventHTTP response 200 containing CTCAdverseEvent instance with assigned FHIR ID

Representing Adverse Event Terms and Grades

Adverse events are represented as two concepts:

  • CTCAE term - The adverse event observed.
  • CTCAE grade - A level of severity for the noted CTC adverse event.

MedDRA is the preferred terminology for specifying the CTCAE term. NCI CTCAE 5.0 contains a cross-walk between assigned NCI Thesaurus (NCIT) codes and MedDRA lower level terms if there is need to support NCIT instead.

For simplicity and to better align with MedDRA, this IG does not use the NCI assigned concepts for grade and instead creates a local code system and value set, ctcae-grade-value-set, to generally represent the CTCAE grades that can be applied across all CTCAE terms.

Some clinical workflows require that you assert the absence of a solicited adverse event. The NCI CTCAE 5.0 cross-walk table represents grades ranging from 1 to 5 and CTCAE which ranges from mild to death but does not have a way to assert that a solicited adverse event is absent. This IG specifies an adverse event grade value set with a “grade 0” to represent absence.

Terminology Preferences

This implementation guide supplies terminology bindings drawn primarily from LOINC for “observables”, and SNOMED-CT for values, results and findings. When appropriate codes are not available in the preferred vocabulary, alternative vocabularies are used, in the following order of preference: SNOMED-CT (if the element is an observable), NCI Thesaurus, NCI Metathesaurus, and local codes.

Value sets from the FHIR specification and US Core were reused to the extent possible. New value sets where created only when no known existing value sets were deemed to be fit for purpose.

Relevant CTEP codes and values are listed here.

The CTCAE Adverse Event reporting is based on CTCAE 5.0 and corresponds to MedDRA version 20.1. The CTCAE terms for the CTCAETermVS defined in this IG includes the codes for the NCI Preferred Terms and the MedDRA LLT (Lowest Level Terms) that map to the CTCAE terms as defined in the NCI CTCAE Cross-walk.

Representing Provenance

Provenance information includes the “who, what, when, where, why” associated with collection, transfer, and updating of clinical information. This IG relies on FHIR’s native mechanisms for recording and tracking provenance. As such, this IG shares all the capabilities and limitations of FHIR provenance tracking. The user should refer to the FHIR specification for more information.