Short Description

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.  

Long Description

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.).

Type

Test an Implementation Guide

Track Lead(s)

Scott Gordon, Jean Duteau

Track Lead Email(s)

gideon.gordon@fda.hhs.govjean@duteaudesign.com

Specification Information

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

  • Source: an “EHR” or FHIR data source/server, with medical records (synthetic is acceptable) containing example patients conforming to the RWD Implementation Guide being created.
  • Retriever: some actor with any form of application or code that will be used to query and retrieve data needed from the Source.

Track Pre-requisites

  1. Have read the current Vulcan/RWD Implementation Guide draft: http://build.fhir.org/ig/HL7/vulcan-rwd/index.html 
  2. Any or all of the following:
    1. Environment (ie, Server) to server as a Source of data which adheres to the requirements of the RWD implementation guide (preferred to test our assumptions and server as a "proof of concept" for interoperability in RWD research)
    2. Environment (ie, Server) to server as a Source of data which does not necessarily adhere to the RWD IG requirements - to serve as a "real world" check on the delta between the needs of the IG versus the "average" EHR that currently exist
    3. Access to an environment that will allow us to compare the use and population of all data elements of interest in the IG with one or many real EHR systems - a combination of conformance statements and actual "survey" of whether elements contain data or do not.  This can even include data that was not in FHIR at the source but was subsequently converted to FHIR.  There is NO need for anyone but the data owner to have access to the actual data in this option.  It will serve as another "real world" assessment of the gap between the IG and average EHRs
    4. Development environment with code that supports any "implementation" use: Retriever or Source.

Zulip stream

https://chat.fhir.org/#narrow/stream/267892-Vulcan.2FRWD

Track Kick off Call

Held December 20th

View recording

Clinical Input Required?

  • Sources: “EHR” or FHIR data sources/servers, with medical records (synthetic is acceptable) containing example patients conforming to the RWD Implementation Guide.
  • Retriever: person with any form of application or code that will be used to query and retrieve data needed from the Source.

Optional but desired:

  • Reviewer: person with any form of application or code that can be used to view FHIR output data in a human readable format for easy compare-and-contrast of outputs from different data sources
  • Transformer: person with any form of application or code that will transform the output FHIR data by a predetermined mapping to an output format - FHIR-to-SDTM is a plus.

Related Tracks?

Vulcan Schedule of Activities; Vulcan Adverse Events

Testing Scenario:


For initial testing of this IG, the RWD track needs two types of “implementers”:

  1. A Source: an “EHR” or FHIR data source/server, with medical records (synthetic is fine) conforming to the RWD Implementation Guide being created. This setup should have typical abilities to be queried and data retrieves as per normal FHIR mechanisms (FHIR queries, other APIs, etc).
  2. A Retriever: some actor with any form of application or code that will be used to query and retrieve data needed from the Source. The Retriever will also be fully aware of the Profile definitions/IG rules so they will have a common understanding of exactly what resources and sub-elements will contain the information they are looking for.

In upcoming testing, we would like:

  • Source implementers to have a publicly accessible EHR analog or FHIR server (not connected to any PHI/PII a sandbox system) ready with a reasonable quantity of data conforming to the RWD IG. To meet the requirements of this IG, it is likely that such data will need to be synthetic in some way.
  • Retriever implementers, with only basic instructions about accessing the Source (instructions on access, the available methods of querying, etc), to be able to accurately and completely retrieve the needed data (perhaps with a few different queries).

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).  

Artifacts

Report-out Slide deck: