The Food and Drug Administration has spent decades refining its processes for approving drugs and devices (and is still refining them), so what would happen if they extended their scope to the exploding health software industry?
The FDA, and its parent organization, the Department of Health and Human Services, are facing an unpleasant and politically difficult choice.
Sticking regulatory fences into the fertile plains of software development and low-cost devices will arouse its untamed denizens, who are already lobbying Congress to warn the FDA about overreaching. But to abandon the field is to leave patients and regular consumers unprotected. This is the context in which the Food and Drug Administration, the Office of National Coordinator, after consultation with outside stakeholders, released a recent report on Health IT.
I myself was encouraged by the report. It brings together a number of initiatives that have received little attention and, just by publicizing the issues, places us one step closer to a quality program. Particular aspects that pleased me are:
- The suggestion that quality programs should start to look at electronic health records (p. 8). EHRs have been certified by various bodies, but usually just to check off boxes and declare that the systems comply with regulations–neither the quality of their user interfaces nor the quality of their implementations have been questioned. Reportedly, the FDA considered “safety and quality standards” for electronic health records in 2010 but couldn’t get them adopted. It also checks certain forms of clinical decision support, but only if they are built into a regulated device. The current HHS report refers back to aspirational documents such as a Health Information Technology Patient Safety Action & Surveillance Plan and a set of guidelines on the safety of EHRs.
- A call for transparent reporting and sharing of errors, including the removal of “disincentives to transparent reporting”–i.e., legal threats by vendors (p. 25). Error reporting is clearly a part of the “environment of learning and continual improvement” I mentioned earlier. A regulation subgroup stated the need most starkly: “It is essential to improve adverse events reporting, and to enable timely and broader public access to safety and performance data.” Vague talk of a Health IT Safety Center (p. 4, pp. 14-15) unfortunately seems to stop with education, lacking enforcement. I distinctly disagree with the assessment of two commentators who compared the Health IT Safety Center to the National Transportation Safety Board and assigned it some potential power. However, I will ask ONC and FDA for clarification.
- A recognition that software is part of a larger workflow and social system, that designing it to meet people’s needs is important, and that all stakeholders should have both a say in software development and a responsibility to use it properly.
Don’t imagine that the FDA is unused to regulating software. For quite some time they have instituted practices for the software used in some medical devices , and have tried to keep them up-to-date.
A waterfall-like process of risk assessment and testing called computer system validation has long been required for pharma and devices.
