Feedback on FDA RFI to Use FHIR

Exploration of Health Level Seven Fast Healthcare Interoperability Resources for Use in Study Data Created From Real-World Data Sources for Submission to the Food and Drug Administration; Establishment of a Public Docket; Request for Comments

Comments are due Jun 23, 2025

Questions worth considering feedback on:

1. What challenges do you see for the pharmaceutical industry regarding the current state of submitting clinical study data collected from RWD sources to FDA?

Proposed answer:

Whether laboratory data is available as discrete data in the EHR-s depends on several factors. The most likely scenario for discrete data is when the testing was performed at the in-house laboratory and results are quantitative in nature. Lab results from outside laboratories may only be available in scanned paper reports or as downloaded pdf files, so in order to be available as discrete data would have to be transcribed and then transformed into FHIR. When it is available as discrete data it most likely arrived via HL7 V2 interfaces or a flatfile format, so also would need to be transformed before it is available via FHIR API.

Lab tests are often ordered as panels, with several observations being returned for a single order - how this panel should be represented in FHIR is still being debated at HL7, which could affect access to the full panel (use of DiagnosticReport or Observation.hasMember) and the universal realm Lab Report FHIR IG, built on FHIR R4, is still undergoing reconciliation after its first ballot.

While the Cancer Pathology Data Sharing FHIR IG was named in the HTI-2 Proposed Rule, it is not in production and has not received a lot of testing, though it is less likely that its data would be used in pharmaceutical industry trials.

2. What opportunities and/or challenges do you see for the pharmaceutical industry on reaching a future state of clinical study data submissions collected from RWD sources using HL7 FHIR ( e.g., business processes, technical considerations)?

3. What are your suggestions on how, from a data standards perspective, FDA might reach a future state of clinical study data submissions collected from RWD sources that aligns with ASTP/ONC health IT goals for HL7 FHIR-based exchange?

4. Does USCDI version 3 provide enough information for collecting RWD for research purposes? Is there information that USCDI version 3 does not sufficiently address?

Proposed answer:

For laboratory data, the proposed USCDI V3 and its implementation in US Core V6.1 does NOT include all required data elements needed to fully understand the laboratory test; applicable FHIR resources for this use case and the shortcomings in their definitions in US Core V6.1:

• US Core DiagnosticReport Profile for Laboratory Results Reporting

  • in US Core V8 the meta data element “lastUpdated” was added, which will support identifying the latest version of the resource (maybe move the required version to US Core V8?, but otherwise it seems complete enough in V6.1)

• US Core Laboratory Result Observation Profile

  • Missing reference range as a Must Support element, which is especially important for understanding quantitative results and will be ehlpful when comapring results from different laboratories

  • Missing date of analysis element, which is missing in base core FHIR (Segment OBX to Observation Map - HL7 Version 2 to FHIR v1.0.0), though US Core V6 mapping suggests using Observation.issued for this element

  • Missing must support elements that would help to better understand if the results from different laboratories can be compared by at least knowing the method and/or need to be able to identify the instrument/testkit used to produce the result.

• US Core Specimen Profile

  • In US Core V6.1 these elements are only optional:

    • Specimen Collection Date/Time, which provides the temporal aspect for interpretation (while it does reflect the same datapoint as in DiagnosticReport.effective and Observation.effective, it would still be good to explicitly include this data element here to avoid confusion with date and time of analysis (see issue#2 under observation)

    • Specimen Identitifer, which is the MAIN means for laboratories to track their data (.identitifer was added as must support in US Core V7) which may be important for further follow up

    • Specimen Source Site - represented in the base specimen resource as .collection.bodySite (important for several use case in the lab) and Specimen Condition (important for understanding why a result value may not properly reflect the health status of the patient, due to not ideal conditions of the sample tested) were added in as additional USCDI guidance, though are not Must Support elements in US Core V8

• In USCDI V6 Draft the Unique Device Identifer was expanded to include any devices, which would address the fact that we are currently missing a US Core profile for devices, that are NOT implantables to provide more detail on the lab equipment and test kits that were used to produce the result, which is critical for reconcilliation for effective data artifacts deduplication, for example as part of clinical trials, in patient charts for laboratory results from different institutions and for creation of Real World Evidence (RWE). Without sufficient details about the performed test, EHR-systems cannot safely ingest data, utilize in chart views, which may impact patient outcomes. If the Unique Device Identifier element is not expanded beyond the implantable devices, SHIELD has requested that USCDI V6 add USCDI Data Element Test Kit Unique Identifier and USCDI Data Element Instrument Unique Identifier to accommodate the laboratory data exchange use case.

5. Under TEFCA, a variety of “Exchange Purposes” are authorized. If “Research” was added as an “Exchange Purpose,” what role could TEFCA play with using RWD for clinical research? How could TEFCA support more efficient collection and exchange of RWD for clinical research purposes? What challenges might exist with this approach?