201805 Clinical Research Track

Track Name

Clinical Research

Submitting WG/Project/Implementer Group

Biopharma FHIR Project Group

Justification

This track will continue to evaluate use of FHIR for clinical research of new biopharmaceutical experimental treatments, seeking to advance the use of FHIR resources as eSource data used to pre-populate clinical research case report forms for both regulated and non-regulated clinical research. Plans for this connection include participation from at least 3 clinical data system implementers and pharmaceutical companies. 3 detailed use case scenarios will be proposed, 2 of which build on prior work at previous connectathons, and one exploring a new area for writing back with updates to clinical data from a clinical system. This work will inform development of profiles and IGs to support clinical research using FHIR, which will likely inform projects of the BR&R workgroup.

Clinical Research studies currently require the redundant entry of clinical data that already typically reside in Meaningful Use conformant EHR systems. EHR data represents original records in electronic format that can be used as eSource and directly imported into clinical research EDC databases so as to improve the quality and consistency of data between EHR and EDC systems and eliminate the need for redundant data entry. Establishing interoperability between EHR and EDC systems to streamline and modernize clinical investigations should improve data accuracy, patient safety, and clinical research efficiency. Given the extreme cost and extended time required for randomized clinical trials, it would be substantially better to utilize EHR source data to directly populate clinical trial databases wherever feasible. As stated in its May 2016 FDA draft guidance titled “Use of Electronic Health Record Data in Clinical Investigations” FDA “encourages sponsors and clinical investigators to work with the entities that control the EHRs, such as health care organizations, to use EHRs and EDC systems that are interoperable. . . Establishing interoperability between EHR and EDC systems to streamline and modernize clinical investigations should improve data accuracy, patient safety, and clinical research efficiency.”

Proposed Track Lead

Geoff Low, Medidata; Wayne Kubick, HL7

See Connectathon_Track_Lead_Responsibilities

Expected participants

Medidata, UCB, Parexel

Roles

FHIR Client

Support the sending from an EHR or patient device of clinical research study data: create, read, search and update to a clinical study database system.

FHIR Server

Supports a FHIR API which can respond to requests from a clinical research FHIR clinical research client.

Clinical Trial Designer

Identifies data relevant to research studies that may be collected from EHRs or SMART-on-FHIR devices. Sets up patient matching criteria and identifiers for ResearchStudy and ResearchSubject for a synthetic test study. Creates study database, mappings/interfaces, EDC case report forms with variable mappings to FHIR that will receive EHR patient data for clinical trial subjects. Generate updates from EDC to apply to the EHR.

Clinical Trial Designer

Clinical Trial Designer[edit] Identifies data relevant to research studies that may be collected from EHRs . Sets up patient matching criteria and identifiers for ResearchStudy and ResearchSubject for a synthetic test study. Creates study database, mappings/interfaces, EDC case report forms with variable mappings to FHIR that will receive EHR patient data for clinical trial subjects. Generate updates from EDC to send to the EHR for keeping EHR and study databases in sync.

Data Collector

Queries API to identify patients by Study and Subject identifiers to pull EHR data for demographics, medications, observation and Condition data that maps directly to variables on eCRF. Provides data generated by patients to add to study databases or EHRs.

Scenarios

Scenario 1: Create Research Study and Research Subject Resources

One of the limiting factors for uptake is a lack of realistic scenarios/examples for early adopters to be able to utilize for understanding the intended use. The outcome of this Scenario will be a set of example ResearchStudy and ResearchSubject JSON code blocks that can be incorporated into the published FHIR Standards.

Precondition:

1 or more FHIR servers with patient data suitable for inclusion in an Rheumatoid Arthritis trial have been identified and can be accessed.

Action:

a) Create a Draft ResearchStudy for a Sample Phase I Rheumatoid Arthritis (RA) Study with the following identifiers:

 •	Study Name: RA1234
 •	Primary Sponsor: Fixemup Pharma
 •	NCT ID: NCT039888888

b) Add the following inclusion criteria as follows:

 •	Female Participants aged 45 and greater
 •	History of RA
 •	Currently or previously taking Steroid-based medication for treatment of primary condition

c) Change the status of the Study from Draft to Active d) Create three ResearchSubject resources to enroll in Study RA1234

Success Criteria:

Creation of Three sample ResearchStudy resources and three sample ResearchSubject resources

Bonus point:

a) Take a sample clinicaltrials.gov Study XML document and represent using a ResearchStudy resource. b) Provide a gap list of elements in the Study XML not covered by the ResearchStudy

Scenario 2: Synchronizing Data between Healthcare and Research Systems

Apply Real World Evidence updates to a Study database as new or changed data is recorded in Site EHR systems for participating Study Patients. Collect specific Patient data using a low-interventional method to support Real World Evidence (RWE) based outcomes research.

In the Real World, Patients seek care from many healthcare institutions (Sites) as needed, with few or any pre-scheduled visits. Clinical Research needs a scalable and automated way to know about and extract EHR data from Sites where Patients participating in a Study receive care. Key Point – no one knows when or at what Sites the Patents receive care beforehand.

Direct transfers from Site EHR systems to Study databases are ideal. Alternately, patient may extract data from an EHR via SMART apps and send the data to a Study database themselves.

Similarly, there is an intention that updated or corrected data should be able to be pushed back to the EHR systems – either as part of the conduct of a clinical study (automated data clarifications) or as part of the end of study data harmonization.

Precondition:

Patient records include demographics, MedicationStatement, Lab observation data, possibly problems, diagnosis. At least one patient has at least 2 sets of lab observations for at least 3 lab tests. Additional information, such as LOINC codes for the set of lab tests to be used and mappings to CDISC for these will be specified in advance.

Action:

a) Extract relevant EHR data that can be mapped to a clinical research Electronic Data Capture (EDC) database, import into EDC Study Database to auto-populate eCRFs. b) Push one CRF of data into one or more Resources in an EHR system

Success Criteria:

a) Test script verifies that the App can import EHR data for at least one subject in each of 2-3 different EHRs (preferably including 1 Epic system, 1 Cerner system and 1 other system) and auto-populate eCRFs in an EDC study database. b) Equivalent Data shown in EHR system after being entered in Data Capture System

Bonus point:

a) Identify and extract relevant unstructured data (from ClinicalNotes) that may be related to a pre-specified disease conditions b) Resolve abhorrent Data Point in EHR system using study data capture system query management functions; may involve sending a resource back to EHR which can view or import the updated/corrected record.

Scenario 3: 3. Investigate the AdverseEvent Resource

The AdverseEvent resource is a draft resource in the FHIR standard. It presents a useful resource for clinical investigations; the semantics of an Adverse Event in a clinical study are such that it can be difficult to align with other resources - examples of possible mappings have included AllergyIntolerance, Condition (Problem), ClinicalImpression, DetectedIssue, DiagnosticReport.

Use of the AdverseEvent resource will be a useful mechanism for the standardized representation of Adverse Event data for the purposes of exchange (and reporting)

Precondition:

a) An EHR system supporting the AdverseEvent Resource b) An EHR system with Patient Data that may be associated with an AdverseEvent

Action:

a) Construct an AdverseEvent Resource for a sample non-Serious Adverse Event b) Construct an AdverseEvent Resource for a sample serious Adverse Event

Success Criteria:

a) Two sample AdverseEvent resources are provided

Bonus point:

a) Map a sample ICG E2B message structure or a CDISC AE record to an AdverseEvent resource

Security and Privacy Considerations

OAuth will be used. Clinical Research scenarios require that access to patient identifying information be limited to the research site, so the use of the ResearchSubject anonymous identifier is critical.