Request for Information on Data Collection for Emergency Clinical Trials and Interoperability Pilot, 65259-65262 [2022-23489]

Agencies

• OFFICE SCIENCE AND TECHNOLOGY POLICY

[Federal Register Volume 87, Number 208 (Friday, October 28, 2022)]
[Notices]
[Pages 65259-65262]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2022-23489]


=======================================================================
-----------------------------------------------------------------------

OFFICE SCIENCE AND TECHNOLOGY POLICY


Request for Information on Data Collection for Emergency Clinical 
Trials and Interoperability Pilot

AGENCY: Office of Science and Technology Policy (OSTP).

ACTION: Notice of Request for Information (RFI) on Data Collection for 
Emergency Clinical Trials and Interoperability Pilot.

-----------------------------------------------------------------------

SUMMARY: As described in the recent RFI on Clinical Research 
Infrastructure and Emergency Clinical Trials, the White House Office of 
Science and Technology Policy (OSTP), in partnership with the National 
Security Council (NSC), is leading efforts to ensure that coordinated 
and large-scale clinical trials can be efficiently carried out across a 
range of institutions and sites as needed to address outbreaks of 
disease and other emergencies. In this RFI on Data Collection for 
Emergency Clinical Trials and Interoperability Pilot, issued in 
partnership with the Office of the National Coordinator for Health 
Information Technology (ONC), OSTP and ONC seek input on viable 
technical strategies to distribute clinical trial protocols and capture 
clinical trial data using common application programming interfaces 
(APIs), in the pre-emergency phase as well as in emergency settings. 
One specific objective for this RFI is to gather information about 
whether there is value in a pilot or demonstration project to 
operationalize data capture in the near term, for example within 6-12 
months of the close of comments on this RFI.

DATES: Interested persons and organizations are invited to submit 
comments on or before 5:00 p.m. ET on December 27, 2022.

ADDRESSES: Interested individuals and organizations should submit 
comments electronically to [email protected] 
and include ``Data Collection for Clinical Trials RFI'' in the subject 
line of the email. Due to time constraints, mailed paper submissions 
will not be accepted, and electronic submissions received after the 
deadline cannot be ensured to be incorporated or taken into 
consideration.

Instructions

    Response to this RFI is voluntary. Each responding entity 
(individual or organization) is requested to submit only one response. 
Please feel free to respond to one or as many prompts as you choose.
    Please be concise with your submissions, which must not exceed 10 
pages in 12-point or larger font, with a page number on each page. 
Responses should include the name of the person(s) or organization(s) 
filing the comment.
    OSTP invites input from all stakeholders including members of the 
public, representing all backgrounds and perspectives. In particular, 
OSTP is interested in input from health information technology (health 
IT) companies, app developers, clinical trial designers, and users of 
health IT products. Please indicate which of these stakeholder types, 
or what other description, best fits you as a respondent. If a comment 
is submitted on behalf of an organization, the individual respondent's 
role in the organization may also be provided on a voluntary basis.
    Comments containing references, studies, research, and other 
empirical data that are not widely published should include copies or 
electronic links of the referenced materials. No business proprietary 
information, copyrighted information, or personally identifiable 
information should be submitted in response to this RFI. Please be 
aware that comments submitted in response to this RFI may be posted on 
OSTP's website or otherwise released publicly.
    In accordance with FAR 15.202(3), responses to this notice are not 
offers and cannot be accepted by the Federal

[[Page 65260]]

Government to form a binding contract. Additionally, those submitting 
responses are solely responsible for all expenses associated with 
response preparation.

FOR FURTHER INFORMATION CONTACT: For additional information, please 
direct questions to Grail Sipes at 202-456-4444 or 
[email protected].

SUPPLEMENTARY INFORMATION:
    Background on emergency clinical trial research: OSTP (in 
partnership with the NSC and other Executive Office of the President 
components) is leading an initiative to enhance U.S. capacity to carry 
out clinical trials in emergency situations. This initiative is 
undertaken in accordance with the 2022 National Biodefense Strategy for 
Countering Biological Threats, Enhancing Pandemic Preparedness, and 
Achieving Global Health Security \1\ and aligns with the goals of the 
American Pandemic Preparedness Plan (AP3).\2\
---------------------------------------------------------------------------

    \1\ 2022 National Biodefense Strategy for Countering Biological 
Threats, Enhancing Pandemic Preparedness, and Achieving Global 
Health Security (October 2022), section 4.1.4.
    \2\ First Annual Report on Progress Towards Implementation of 
the American Pandemic Preparedness Plan (September 2022), at 22-23.
---------------------------------------------------------------------------

    In the recent RFI on Clinical Research Infrastructure and Emergency 
Clinical Trials, OSTP is seeking input on the emergency clinical trials 
effort generally, including U.S.-level governance models to support the 
emergency clinical trials effort. Governance functions might include 
determining when coordinated, large-scale clinical research is needed, 
including research on countermeasures, to address outbreaks of disease 
or other biological incidents. A further governance function might be 
to develop clinical trial protocols (in coordination with external 
stakeholders), which could range from relatively simple studies to more 
complex ones involving the evaluation of investigational agents. OSTP 
also seeks comment in the RFI on Emergency Clinical Trials on how 
emergency clinical trial data should be managed to facilitate 
researchers' access and analysis of results. One potential model would 
be the use of a centralized data repository and biorepository for 
specimens collected during trials.
    In this RFI on Data Collection for Emergency Clinical Trials and 
Interoperability Pilot, to further prepare the U.S. clinical trials 
enterprise to carry out coordinated, potentially large-scale research 
protocols in an emergency setting, OSTP is seeking input on how best to 
operationalize protocol distribution and data capture from a technical 
perspective. Specifically, in this RFI we seek input on viable 
technical strategies to distribute clinical trial protocols and capture 
clinical trial data using common Health Level 7 (HL7) Fast Healthcare 
Interoperability Resources (FHIR[supreg])-based APIs, in the pre-
emergency phase as well as in an emergency setting. We seek comment on 
how to build towards both of these goals in a data capture pilot or 
demonstration project. This pilot, if implemented, could provide 
training for sites in underserved communities, thereby enlarging and 
strengthening the overall clinical trials infrastructure.
    Desired use case: OSTP is still in the process of collecting 
information on governance models and other aspects of the emergency 
clinical trials initiative. For purposes of responding to this RFI, 
however, we would like responders to consider the following multi-step 
use case.
    1. A U.S.-level governing entity would oversee development of a 
clinical trial protocol for broad distribution across clinical trial 
networks and sites.
    2. Study sites would enroll participants in the trial (potentially 
using software mechanisms that can alert sites to potential subjects 
for a specific protocol in a manner that increases the diversity of 
trial populations). Sites would obtain appropriate e-consents and 
authorizations from participants.
    3. Clinical trial data is typically sent to the trial sponsor 
though an electronic case report form (eCRF), which is the record of 
data that is required under the protocol to be captured for each trial 
participant. A data element in an eCRF is the smallest unit of 
observation for a particular subject.
    4. The eCRFs would be transmitted electronically via common APIs to 
the sponsor.
    5. The study site's health IT system would present the eCRF content 
to clinicians in a manner that expedites data collection and (ideally) 
fits within clinician workflows.
    6. As the clinician obtains data elements to complete the eCRF, 
that data would be captured in the patient's electronic health record.
    7. The clinical trial data would also be sent to a central data 
repository or small set of data repositories for researchers to 
analyze. It would be sent via common APIs so that researchers can 
easily interpret the eCRF data elements. Commercial cloud solutions are 
likely to house the data repository or repositories. Nonetheless, we 
would like a solution that would work across multiple cloud vendors.
    For the purposes of this RFI, we are interested in the feasibility 
of all steps in the above hypothetical use case; we would also like 
input on how much of the use case could be operationalized in a pilot 
or demonstration project that might move forward in a timeframe of 6-12 
months from the close of comments on this RFI.
    ONC standards for interoperability: We believe that a pilot or 
demonstration project such as described above would be well supported 
by the regulatory and governance structure for interoperability of 
electronic health records (EHRs) that has been put in place by the 
Office of the National Coordinator for Health Information Technology 
(ONC). Among other initiatives, ONC is currently supporting development 
of the United States Core Data for Interoperability (USCDI) standard; 
the FHIR application programming interfaces (APIs); and Substitutable 
Medical Applications and Reusable Technologies (SMART) platform 
technologies that are compatible with FHIR interfaces and have given 
rise to a category of ``SMART on FHIR'' APIs. Certified health IT 
developers seeking certification on their Health IT Modules are 
currently working to meet various ONC certification criteria intended 
to improve data interoperability. For example, certified developers are 
required to implement certified API technology capable of patient and 
population services based on FHIR Release 4, the FHIR US Core 
Implementation Guide, and based on the HL7 FHIR[supreg] Bulk Data 
Access (Flat FHIR[supreg]) (v1.0.0: STU 1), August 22, 2019 
Implementation Guide, by December 31, 2022.
    In addition, ONC published the Trusted Exchange Framework, Common 
Agreement--Version 1, and QHIN Technical Framework--Version 1 on 
January 19, 2022. The overall goal of the Trusted Exchange Framework 
and Common Agreement (TEFCA) is to establish a universal floor for 
interoperability across the country. The Common Agreement will 
establish the infrastructure model and governing approach for users in 
different networks to securely share basic clinical information with 
each other--all under commonly agreed-to expectations and rules, and 
regardless of which network they happen to be in. Entities seeking to 
be designated as Qualified Health Information Networks (QHINs),\3\ per 
the

[[Page 65261]]

Common Agreement, can apply for that designation on a voluntary basis. 
A QHIN is a network of organizations that work together to share health 
information. The goal of TEFCA is for QHINs to connect directly to each 
other to ensure interoperability between the networks they represent 
and to serve a wide range of end users.
---------------------------------------------------------------------------

    \3\ The Common Agreement defines a QHIN as ``to the extent 
permitted by applicable Standard Operating Procedure(s) (SOP(s)), a 
Health Information Network that is a U.S. Entity that has been 
Designated by the RCE and is a party to the Common Agreement 
countersigned by the RCE.'' See Common Agreement for Nationwide 
Health Information Interoperability Version 1, at 10, 6 (Jan. 2022), 
https://www.healthit.gov/sites/default/files/page/2022-.
---------------------------------------------------------------------------

    The Common Agreement defines Exchange Purpose(s) \4\ as ``the 
reason, as authorized by this Common Agreement including the Exchange 
Purposes SOP \5\, for a Request, Use, Disclosure, or Response 
transmitted via QHIN-to-QHIN exchange as one step in the 
transmission.'' Although research is not an authorized Exchange Purpose 
under the current version of the Common Agreement, it is a planned 
future Exchange Purpose, and responses to this RFI could inform how 
TEFCA might best support research in the future.
---------------------------------------------------------------------------

    \4\ See Common Agreement for Nationwide Health Information 
Interoperability Version 1, at 6 (Jan. 2022), https://www.healthit.gov/sites/default/files/page/2022-.
    \5\ The current version of the TEFCA ``Standard Operating 
Procedure: Exchange Purposes'' specifies that authorized Exchange 
Purposes under the Common Agreement and that SOP are: Treatment, 
Payment, Health Care Operations, Public Health, Government Benefits 
Determination, and Individual Access Services.
---------------------------------------------------------------------------

    The implementation SOPs for Public Health and some other current 
Exchange Purposes, including Payment, Health Care Operations, and 
Government Benefits Determination, have not yet been developed. These 
SOPs will need to specify constraints, and at least some of the to-be-
defined constraints are likely to be applicable to a future research-
focused Exchange Purpose. Therefore, this RFI also seeks input on how 
TEFCA's Public Health Exchange Purpose Implementation SOP might be 
designed to enable public health authorities to answer questions that 
align with the activities described in this RFI.
    More information on ONC data interoperability initiatives is 
available at https://www.healthIT.gov, and more specific information 
about TEFCA at https://www.healthit.gov/TEFCA and https://rce.sequoiaproject.org/.
    Information Requested: OSTP invites input from all interested 
parties as outlined in the instructions. Respondents may provide 
information for one or as many topics below as they choose.
    Our goal for this RFI is to support optimized data collection for 
clinical trials carried out across a range of institutions and sites, 
both in emergency settings and in the pre-emergency phase, under the 
use case described above. We also seek input specifically on the value 
of designing a pilot or demonstration project to operationalize data 
capture in the near term, for example within 6-12 months of the close 
of comments on this RFI. With those goals in mind, we request input on 
the following topics:
    1. United States Core Data for Interoperability (USCDI). We seek 
input on how U.S. Government and external stakeholders might leverage 
USCDI and future extensions of USCDI standards (such as USCDI+, an 
extension that supports federal partner program-specific requirements) 
to support emergency clinical trial research. It would also be helpful 
to receive comment on areas in which additional extensions might be 
necessary.
    2. HL7 FHIR APIs. We seek comment on how U.S. Government and 
external stakeholders might leverage FHIR APIs to support research in 
emergency settings as well as in the pre-emergency phase, and in what 
areas further advances might be needed. Specific topics in this 
connection include:
    a. Use of an API that supports FHIR Bulk Data Access to support 
clinical research; whether bulk data exports from EHR systems can be 
used to support certain clinical trial protocols.
    b. Use of the FHIR Questionnaire and QuestionnaireResponse 
resources to support clinical research.
    3. SMART on FHIR APIs: We seek input on how U.S. Government and 
external stakeholders might leverage SMART on FHIR APIs, and in what 
areas further extensions might be needed. It would be helpful to 
receive comments on:
    a. The most promising ways to create SMART on FHIR technologies 
that are portable across different institutions and EHR systems, but 
also provide adequate functionality to support emergency clinical trial 
research.
    b. Whether the portability of SMART on FHIR tools provides a way to 
reach institutions and sites that have limited information technology 
resources; any promising ways to use SMART on FHIR to expand clinical 
research into underserved settings.
    4. Clinical Decision Support (CDS) Hooks: We seek comments on how 
the HL7 CDS Hooks specification might be used to support clinical 
research, for example by creating prompts within the practitioner 
workflow during interaction with patients; and any advances that might 
be needed to support the use case described above.
    5. Operationalizing protocols of varying complexity. As noted 
above, emergency clinical trial designs could range from relatively 
simple protocols to more complex studies involving the evaluation of 
investigational agents. We would appreciate comments on the following 
topics:
    a. Whether any of the tools described above might be particularly 
well suited for certain types of studies.
    b. For example,
    i. Whether a bulk FHIR API export could be used to gather data for 
a simple trial protocol that is relatively close to the standard of 
care for a particular condition.
    ii. Whether a FHIR Questionnaire/QuestionnaireResponse or a SMART 
on FHIR form would be useful in capturing data for a more complex 
protocol, such as one that involves an investigational agent.
    c. Any technical limitations that we should be aware of regarding 
use of the above tools to operationalize clinical trial protocols.
    6. Consent, deidentification, return of results. The use case in 
this RFI contemplates that data would be managed through a central 
repository or repositories and made available to researchers beyond a 
patient's home institution.
    a. In light of this, we seek comment on how the tools described 
above can be used to obtain, collect and/or manage any required 
informed consents and/or authorizations from patients or individuals in 
accordance with applicable regulations.
    b. We also seek input on what additional capabilities would be 
required to deidentify or otherwise manage protected health 
information. It would be helpful to receive comments on which 
deidentification and protection approaches are sufficiently mature to 
support a pilot effort in the near term.
    c. Ideally, patient authorization would allow clinical trial data 
to be used for additional research beyond the original study. We would 
appreciate input on how the content collected for consent and 
authorization as well as the interfaces with deidentification 
technologies should be designed to enable flexible and responsible 
reuse of clinical trial data.
    d. We seek comment on any technical capabilities that could support 
return of results to study sites or participants, where appropriate.
    e. We seek comment on any regulatory or ethical guidelines that are 
relevant to patients' consents and authorizations under the use case 
described in this RFI, and on ways in

[[Page 65262]]

which technical solutions might help ensure adherence to applicable 
regulatory or ethical guidelines.
    7. User interface and experience. With all of the above 
technologies, we seek input on:
    a. The best way to optimize the experience of health care 
providers, administrators, and other users, so as to maximize the 
utility and uptake of the product.
    b. To the extent a particular form, app or other tool requires 
input from a health care provider or other user, the best ways to 
increase the likelihood that users will actually provide that input. It 
would be helpful to receive comments on methods that are available for 
completing empty fields after the fact, or otherwise managing any 
missing data.
    c. For clinicians and health IT users: what existing tools, apps, 
or processes you have found most usable and why.
    8. Capturing data elements required for clinical trial protocols.
    a. We seek comment on the most promising technical approaches that 
would leverage common APIs to translate a particular clinical trial's 
data elements into data elements captured by user-facing tools (e.g., 
FHIR Questionnaire feeding into a SMART on FHIR form or application).
    b. If a tool such as a FHIR Questionnaire, FHIR 
QuestionnaireResponse, or SMART form or app is used to capture required 
data elements in this way, we seek comment on whether that creates an 
effective method for ``pushing out'' a research protocol to 
investigators and sites.
    c. It would be helpful to receive comments on how best to ensure 
compliance with regulatory requirements for eCRFs when designing 
interfaces for data capture.
    9. TEFCA and QHINs. As noted above, TEFCA is in the implementation 
phase at this time. In the future, the TEFCA QHINs are expected to 
support implementation of the FHIR APIs (see the ONC Recognized 
Coordinating Entity's January 2022 FHIR Roadmap for TEFCA Exchange 
\6\). We would appreciate comment on the opportunities and challenges 
regarding development of API implementations toward the use case 
described above, particularly given the current status of TEFCA and 
QHIN participation. Specific topics in this connection include the 
following:
---------------------------------------------------------------------------

    \6\ https://rce.sequoiaproject.org/three-year-fhir-roadmap-for-tefca/.
---------------------------------------------------------------------------

    a. Certain policy and/or technical constraints will need to be 
specified for currently authorized Exchange Purposes under the Common 
Agreement (e.g., Public Health). We seek comment on which of these 
constraints will also be applicable to a future research-focused 
Exchange Purpose.
    b. Opportunities that may exist for using the initially authorized 
Exchange Purposes to accomplish the use case described in this RFI.
    c. How the Public Health Exchange Purpose could be used to advance 
the goals of this RFI; what aspects of the use case described above 
might fall within the scope of the Public Health Exchange Purpose.
    d. How a future research-focused Exchange Purpose could be 
structured to advance the goals of this RFI.
    e. Other opportunities or constraints related to TEFCA that should 
be considered with regard to this RFI.
    10. Emerging technologies. We welcome comments on any future 
technological developments we should anticipate. Relevant technical 
developments include but are not limited to differential privacy; 
federated machine learning; other technologies referenced in the recent 
OSTP RFI related to privacy-enhancing technologies (PET) (see Federal 
Register: Request for Information on Advancing Privacy-Enhancing 
Technologies); and technologies outside of the PET space. Specific 
topics in this area include:
    a. How future technologies might affect the use case and underlying 
assumptions laid out in this RFI.
    b. How future technologies might change the nature of the software 
architecture, data architecture, or potential data collection solutions 
for clinical trials.
    11. Pilot or demonstration project. We seek comment on how the U.S. 
Government can best work with external stakeholders and developers to 
develop a pilot or demonstration project that will operationalize 
clinical trial data capture and serve as a basis and model for data 
collection in the event of an emergency. This pilot or demonstration 
project could also potentially support clinical research in the pre-
emergency phase. Specific topics include:
    a. Whether data can be managed through a central repository or 
small set of central data repositories; options for cloud-based data 
storage.
    b. Technical options that might hold promise in the short term to 
enable researchers from diverse locations to analyze the data collected 
from multiple clinical trial sites. We also seek comment on any 
additional options that should be considered in the long term.
    c. Whether any parts of the pilot would be appropriately supported 
as
    i. A demonstration project with commercial partnership.
    ii. A public-private partnership.
    iii. An agency-funded program.
    12. Specific commercial capabilities. Commenters who are developing 
a technology or product that might be relevant to any of the topics set 
forth above are welcome to include a description of that product. 
Comments about a specific technology or product should be limited to 
three pages or less.

    Dated: October 25, 2022.
Stacy Murphy,
Operations Manager.
[FR Doc. 2022-23489 Filed 10-27-22; 8:45 am]
BILLING CODE 3270-F1-P