This page is part of the Adverse Event Clinical Research R4 Backport (v1.0.0-ballot: STU 1 Ballot 1) based on FHIR R4. . For a full list of available versions, see the Directory of published versions
Official URL: http://hl7.org/fhir/uv/ae-research-backport-ig/ImplementationGuide/hl7.fhir.uv.ae-research-backport-ig | Version: 1.0.0-ballot | |||
IG Standards status: Trial-use | Maturity Level: 2 | Computable Name: AdverseEventClinicalResearchR4backport |
Page standards status: Informative |
Contents:
The intent of this guide is to provide a profile on the FHIR AdverseEvent Resource suitable for Clinical Research.
A single Adverse Event (AE) may need to be reported in multiple ways. Choosing the appropriate form of the reporting is dependent upon workflow patterns. In particular, the implementation guides for Clinical Care adverse events and Clinical Research adverse events provide important extensions, value-sets and examples for implementing AdverseEvent.
This guide, the Clinical Research adverse event implementation guide, is for the clinical research setting. In this setting, the event is tracked and evaluated as part of the clinical research process for the research study.
In the research setting an adverse event is the result of an intervention that caused unintentional harm to a specific subject or group of subjects (this is surfaced in the profile as a constraint of ‘actual’ for the value of ‘actuality’). An example of an adverse event in the clinical research setting would be a patient develops renal failure while on a study drug. These events are characterized by the need to capture cause-and-effect (although they might not be known at the time of the event), severity, and outcome.
The context of an adverse event is also important, and captured in the AdverseEvent Clinical Research Profile data elements. A subject may have condition(s) or current treatments (medications, diet, devices) that impact their response to a newly introduced medication, device or procedure. Knowledge of these variables is essential in establishing a cause-and-effect relationship for an adverse event. This information is represented with corresponding resources (e.g. Procedure Resource for procedures, etc.) and referenced.
A potential adverse event may also be called a near miss or an error, these are not reported with the AdverseEvent Clinical Research Profile.
This FHIR IG enables the collection of adverse events in real-world data (RWD) sources such as electronic health records (EHR) and personal health records (PHR) that occur during clinical trials. It ensures the appropriate AE representation required to support clinical research trials within a regulated environment. As the AEs are collected in RWD sources, the data can be transmitted via FHIR to clinical trial management systems, regulatory agencies, sponsors, and clinical research organizations for further processing and reporting.
In the pre-market clinical research setting, serious adverse events must be reported to the sponsor, clinical research organization, and regulatory agencies within a specific time frame for Institutional Review Boards (IRBs) and Data Safety Monitoring Board (DSMB) review. By using this IG, a clinical investigator can document an AE in the EHR, it can be received by a secondary clinical trial management system for triage and then forwarded to the sponsor and regulatory agencies. Similarly, a patient on a clinical trial can record an adverse event in their PHR that is then shared with the clinical investigator and reported to the sponsor and regulatory agencies as necessary. In a post-market situation, a patient, provider, or manufacturer can record the adverse event in a system and then report it to the FDA as a FHIR based MedWatch form.
Within this guide are several examples. Every effort has been made to capture the most important details of the use of the AdverseEvent profile. However, some examples may provide only a stub to referenced resources (e.g. instances of Patient Resource will be referenced using logical ids but are not resolvable, implementation of Patient is left for other guidance and is not the subject of this guide). Connectathons are ideal opportunities to create, compare and consider the holistic implementation of all FHIR Resources.
This implementation guide is focused on the use of the AdverseEvent Resource in Clinical Research. When reviewing profiles begin with the snapshot view to understand the entire set of data elements and rules for implementation. The differential only shows changes from the parent. The snapshot shows all the constraints and rules, including those inherited from the parent. Those new to FHIR should review the Understanding FHIR section below.
FHIR STU4 contained a non-normative version of the AdverseEvent Resource. The specification here is based on changes made in R5 and supersedes the use of the R4 Resource.
This implementation guide is based on the HL7 FHIR standard. It uses terminology, notations and design principles that are specific to FHIR. Before reading this implementation guide, it's important to be familiar with some of the basic principles of FHIR as well as general guidance on how to read FHIR specifications. Readers who are unfamiliar with FHIR are encouraged to review the following prior to reading the rest of this implementation guide.
Implementers should use this guide to communicate AdverseEvent Clinical Research events in an interoperable way. It is understood that this guide is not complete, and implementers might identify additional concepts and data elements. It is recommended that additional Implementation Guides should be adapted from this one as a base for tighter specifications such as in oncology clinical trials.
This IG is sponsored by the HL7 HL7 Biomedical Research and Regulation Work Group and co-sponsored by the HL7 Patient Care and Devices Work Groups.
The development of the Clinical Research Adverse Event Implementation Guide was made possible by the Vulcan FHIR Accelerator, a member driven community that exists to help Clinical and Translational Research start using FHIR to manage the vast amount of data they have to work with.
The authors of this guide wish to recognize the following Vulcan member organizations that contributed their time and expertise to the continued development of this guide: