The purpose of this track is to develop methods to use the HL7 FHIR standard to retrieve relevant data from Real World Data sources – for now primarily Electronic Health Record (EHR) systems - and ultimately transform that data into a format suitable for submission to pharmaceutical regulatory agencies.
The main goal of this track is to help define a minimal set of clinical research FHIR resources and elements in an EHR that can be utilized in an interoperable and consistent manner for clinical research objectives (e.g., academic, regulatory, etc.). An implementation guide is being developed that defines FHIR profiles that can be used in an EHR setting to represent data that will be supportive of RWD research needs and also to retrieve relevant research data from Real World Data (RWD) sources to facilitate downstream use (directly or after transformation) for submissions to pharmaceutical regulatory agencies. The downstream use of retrieved data is not covered in this guide but separate efforts exist to give advice for such use (for example, the FHIR to CDISC Joint Mapping Implementation Guide). Many sources of RWD exist, but for the current phase of work, the scope of this Implementation Guide is limited to the use of Electronic Health Record (EHR) systems as sources of RWD. The intent is for future iterations of the Implementation Guide to have a wider scope of RWD such as from Registries, Payer systems, and HIEs. Additionally, our focus is currently limited to the use of EHR data for retrospective analysis of data which already exists as part of normal healthcare encounters - not data created as part of prospective clinical studies.
We are very aware that the use of EHRs as a mode of direct data collections for traditional prospective clinical trials (sometimes called “electronic source data” or “eSource” activities) is also of great interest. While this is not currently in scope of this implementation guide, we consider it highly likely that types of solutions developed for eSource and for RWD will have significant overlap.
The guide is dependent on the International Patient Summary (IPS) project for a baseline dataset from which to build its profiles. The profiles built will enhance the IPS profiles for the purposes of conveying data needed for clinical research.
This guide defines the FHIR building blocks to meet use cases which will eventually mature the minimal set of common resources and elements. It is being developed using an iterative use case approach, identifying the minimal set of EHR-based information needed to answer a small set of research questions and creating a set of FHIR profiles for representing this needed information in an EHR, then repeating the process with a new question. As more use cases are considered, more common resources and elements will be added to the guide. It provides an opportunity to help establish future US Core, Australia Core, Japan Core, etc. as they wish to scale their guides and profiles. The mappings to achieve different outcomes are dependent on other projects (eg. FHIR to CDISC, FHIR to OMOP, etc.).
Test an Implementation Guide
Scott Gordon, Jean Duteau
Track Lead Email(s)
Vulcan Project page, notes, etc: https://confluence.hl7.org/display/VA/Real+World+Data
Last Connectathon September 2022): 2022 - 09 Vulcan - Real World Data (RWD) for Research and Regulatory Submissions - FHIR - Confluence (hl7.org)
Current Implementation Guide draft: http://build.fhir.org/ig/HL7/vulcan-rwd/index.html
Call for participants
Track Kick off Call
Held December 20th
Clinical Input Required?
Optional but desired:
|Vulcan Schedule of Activities; Vulcan Adverse Events|
For initial testing of this IG, the RWD track needs two types of “implementers”:
In upcoming testing, we would like:
A simple demonstration of success may be a comparison of the Retrieved data set to the Source data to assess if everything was retrieved which should have been any nothing was retrieved that should not have been. Our initial goal in the upcoming September Connectathon is that we either demonstrate success or, just as useful, reveal issues to be remedied somewhere in the process (either in implementation logic or the IG itself).