Skip to content Skip to navigation

Washington Debrief: Federal Agencies, Stakeholders Discuss the Best Way to Regulate HIT

May 20, 2014
by Jeff Smith, Director of Public Policy at CHIME
| Reprints
Jeff Smith, Director of Public Policy at CHIME

Federal Agencies, Stakeholders Discuss the Best Way to Regulate HIT

Key Takeaway: More than 100 stakeholders joined officials from the FDA, ONC and FCC to discuss a draft regulatory framework for health IT.

Why it Matters: A final report is expected in the fall, and it will dictate how these agencies will regulate health IT functionality for the foreseeable future. The federal government is faced with a difficult task: providing regulatory clarity now and flexibility later. There are risks involved with both over- and under-regulating health IT, such as preventing lifesaving technologies from entering the market because of lengthy approval processes or, conversely, causing patient harm because of lax oversight and a lack of standards. At the same time, businesses need clear definitions of regulations and standards so they can plan development cycles. If you are interested in joining the CHIME workgroup that will provide recommendations to Food and Drug Administration (FDA), the Office of the National Coordinator for Health IT (ONC), and the Federal Communications Commission (FCC) about the report, click here.

When the dust settles from last week’s marathon FDASIA (Food and Drug Administration Safety and Innovation Act) workshop, what impressions will remain in the multi-agency’s final draft report?

The majority of stakeholder opinion regards the FDASIA Health IT Report as a sensible approach to a nebulous, albeit complex, problem. The tri-category approach delineating degrees of patient safety risk and portending degrees of regulatory burden will remain at the framework’s core. However, stakeholders were quick to identify technology’s ability to permeate multiple – indeed all – categories. For this reason, the final framework may well include a conceptual fourth category for health data. It appears unlikely that the FDA will impose its medical device process on the vast majority of health IT software, as they note in the report, although several organizations called for legislation to ensure this does not happen in the future. Rather, the ONC is poised to handle all health software (and functionalities) that fall below a relatively high threshold for risk to patient safety. To do this, ONC is looking to launch a $5 million Health IT Safety Center to:

  1. Help coordinate patient safety organization (PSO) activity;
  2. Harmonize safety event reporting standards; and
  3. Develop a “learning health system.”

Day One There seemed to be consensus from the first panel around the functionality approach in the report. This approach suggests that the FDA should not regulate platforms, but they should regulate devices and software/software functions that directly affect patients’ health. The panel also agreed that software categories need to be clearly defined for developers to provide predictability, clarity and flexibility for innovation. The categories of health IT functionality include:

  1. Administrative (admissions, billing, scheduling, etc.)
  2. Health management – also called clinical software (CDS, provider order entry, patient identification, etc.)
  3. Medical device (detection and diagnosis software, radiation treatment planning, etc.)

However, several stakeholders identified data integrity as a cross-cutting challenge. For example, administrative software, considered to be inherently less dangerous than health management software, is less safe if it is the source of a patient data mismatch. The second panel debated accountability for patient safety, especially when IT’s intended use is complicated by local technology implementations. Panel participants from the vendor/developer camp and provider camps agreed that transparency in the lifecycle process – from product development and approval to end-user training and implementation – will improve patient safety.

Day Two The second day focused on clinical decision support in the morning and standards as a safety mechanism in the afternoon. In many ways, CDS sits at the framework’s epicenter. The dividing line for FDA oversight and ONC oversight will likely run straight through CDS. If the CDS is tied directly to a medical device, the FDA will have purview; if not, ONC will be the regulator of record. Regardless of how the CDS gets to market, stakeholders were adamant that providers need more intensive and frequent training on how to use such tools if the maximum amount of risk to patients is to be mitigated. Additionally, most stakeholders agreed that CDS tools need more transparency, so clinicians are better able to understand the source of the information used to suggest a decision.