[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