In the last month, the Food and Drug Administration (FDA) undertook two new steps related to Health IT in the United States While the FDA’s involvement in this area of technology remains very controversial, bothprojects sought to enhance collaboration with the Health IT industry.
First, on May 13-15, 2014, the FDA, Federal Communications Commission (FCC), and HHS Office of the National Coordinator for Health Information Technology (ONC) convened a workshop to provide the agencies with feedback on the recently released risk-based framework for Health IT that was set forth in the tri-agency draft report,FDASIA Health IT Report: Proposed Strategy and Recommendations for a Risk-Based Framework (Draft Report), released in April 2014. While the workshop provided little clarity on the details of implementation of the Draft Report concepts, the meeting did highlight some of the key issues with which developers and others working in the Health IT space are grappling.
On day one, the workshop began with a discussion among industry representatives, including healthcare institutions, trade groups, and agency participants about the overarching risk-based approach proposed by the Draft Report. Feedback from panelists was generally favorable, but concern was also frequently expressed that further details are needed in order for the industry to navigate the framework. The second half of the day featured discussion of quality management approaches. Panelists concurred that good quality management techniques are important to product development. However, it is not yet clear what requirements may be imposed on the industry rather than self-selected by companies.
The most highly anticipated portion of the workshop, the morning of Day two, was dedicated to the strategy proposed for the regulation of clinical decision support (CDS) software in the Draft Report. A dedicated panel of government and industry experts discussed the issues of differentiating “Health Management” CDS functionality, i.e., functionality that would fall outside FDA’s regulatory purview, from “Medical Device” CDS functionality, and how the four priority areas identified in the Draft Report as the pillars of the risk-based framework can be tailored for CDS tools that fall into the “Health Management” bucket.
There was considerable interest and discussion during the CDS panel sessions about the regulation of CDS under the proposed framework. Despite a clear desire for more clarity regarding the line between FDA-regulated CDS and “Health Management” CDS, there was little insight into the tri-agency’s bucketing of CDS in the Draft Report and no explanation of how such clarity will be gained going forward.
Key takeaways from the panel discussions on CDS included:
- CDS presents complex sociotechnical issues.
- Focus on functionality as opposed to platform is an appropriate starting point.
- There are many factors that may need to be considered in assessing the risk of any given CDS tool, such as:
- environment of use
- source of the information
- level of expertise of the user
- time constraints within which the user needs to act on the information
- transparency of the inputs to the CDS tool
- seriousness of the disease
- role of the CDS tool in the diagnosis or treatment of the patient
- how the information is displayed to the user
- The concept of the "learned intermediary" is important to the overall risk of a CDS product. However, based on panel discussions, the role of that concept in assessing where a CDS tool falls on the risk-based framework was less settled. Some participants argued that the potential for intervention by a clinician prior to action by the CDS should preclude FDA regulation. It was also noted that a "learned intermediary" does not have to be a healthcare professional, but could be a lay user, such that individual experience and knowledge can be tailored to information and decision presented by any given CDS tool.
- Integration and customization need to be considered as part of the risk assessment of CDS. The integration of various CDS tools with knowledge engines complicates the assessment of the risk presented by any given CDS tool. In addition, healthcare providers continually customize CDS tools to define the rules and update them. As such, post-customization testing should be routine.
- There has been a great deal of discussion as to whether legislation is needed to further clarify FDA’s role with respect to CDS, or whether that could be accomplished appropriately through new guidance documents. There was no consensus among panel members on this point, though some panel members called for legislation to ensure the necessary authority, resources, and clarity around CDS. Others called on FDA to issue the long-awaited CDS guidance document as a strawman in the process, to move the discussion to a more granular level.
In addition to categorization of CDS, the panel also discussed how the four priority areas identified in the Draft Report can be tailored for the “Health Management” CDS bucket that would be outside FDA’s purview. Key points from this discussion included:
- The agencies should leverage existing quality management, best practices, and standards.
- Clarity and certainty are needed so that companies are not required to go through both FDA regulation and separate certification processes.
- The learning environment is the most important aspect of the framework, as it will allow for the sharing of experiences with CDS and for improvements that can lead to better products, but should involve broad representation and input.
- Some level of risk tolerance is needed.
- Training at the front end, and continually, as the software tools are upgraded, is a necessity.
- Training on the use of CDS tools should involve both vendors and healthcare providers.
- Safety guidelines to help drive safe implementation practices should be developed and disseminated.
- Patient Safety Organizations should be engaged to work towards the collection of robust data from CDS vendors, providers, and patients, for quality improvement.
The overwhelming point of agreement on the issue of CDS within the proposed FDASIA Health IT framework was the immediate need for clear definitions for CDS going forward, and as the most pressing next step in this process.
Finally, the third day of the workshop focused on the Learning Environment and Safety Center aspects of the Draft Report. With respect to the Safety Center, there was general agreement that such a center is needed, but uncertainty was expressed about the nature of what is planned. It appears that the center will likely fall within ONC’s purview, but the structure and related requirements remain unclear. Nonetheless, ONC has committed to funding the center.
In follow-up to the meeting, the three agencies are working to incorporate the feedback received, as well as comments submitted via public docket (FDA-2014-N-0339-0001). The docket is scheduled to remain open until July 7, 2014. FDA is also reportedly continuing to work on the CDS guidance document that has been under development for several years.
Separate from the Health IT workshop, FDA launched the OpenFDA initiative on June 2, 2014. The initiative makes a number of FDA databases available in structured, computer-readable form to facilitate app and web development. Most notably, the initiative makes FDA’s adverse event databases available for development of data-mining applications. Reportedly those databases provide information on more than 3 million adverse event reports. While the OpenFDA data has other uses, it has been touted as an important tool to potentially be leveraged by Health IT developers. The project is facilitated by a new cloud computing infrastructure. Less than 24 hours after announcement of the initiative, the first app leveraging the data, OpenFDA Search, was announced with more expected in coming weeks.