William A. Hyman
Professor Emeritus, Biomedical Engineering
Texas A&M University, w-hyman@tamu.edu
Read other articles by this author
ONC has released another Notice of Proposed Rulemaking, this time entitled 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program. It comes in at 734 pages.
In brief, the 2016 21st Century Act mandated certain actions by ONC (among others) aimed at advancing interoperability; supporting the access, exchange, and use of electronic health information; and addressing occurrences of information blocking. ONC has proposed rolling these matters into a revised version of the variously modified 2015 Edition certification criterion for EHRs. Curiously it seems that 2015 Edition nomenclature will remain even after the changes are made. Why won’t it then be called the 2019 Edition, which might reduce confusion? Despite its complexity, it was reassuring to read that the newly proposed rules will save billions of dollars. It will be interesting to figure out in whose pocket all this savings has ended up.
In the rule the has expressed interest in following FDA’s lead in its Software Precertification Program Pilot. The core idea in the FDA pilot is that the FDA would certify software developers instead of looking primarily at their products. It is interesting that there would be two levels of excellence under FDA Pre-Cert, allowing for a developer to be declared “excellent” or, in effect, “not so excellent. ONC suggests that they can piggy-back on the FDA’s effort and provide regulatory benefits to pre-certified health IT developers. The proposed rule avoids the issue that products under the FDA’s Pre-Cert program are medical devices even though they may consist only of software. Health IT products under ONC’s definition are decidedly not medical devices by earlier declaration, even though EHRs do many things that fall within the general definition of a medical device. This carveout was made law in the Cures act where the definition of a medical device was changed to exclude software intended to serve as electronic patient records. ONC does note that recognition of Pre-Cert may eventually be determined to be infeasible or insufficient to meet ONC’s goals of reducing burden and promoting innovation.
Still in somewhat of a limbo is software that provides Clinical Decision Support (CDS) which may or may not be a medical device. This distinction hinges in part on whether or not the provider can independently understand how the CDS reached its conclusions. This may draw a line between an algorithmic CDS (eg following a practice guideline) and a machine learning CDS which is fundamentally not the product of logical analysis and understanding but instead is basically limited to pattern recognition. Another link between FDA and ONC is additional consideration of the inclusion of FDA’s Unique Device Identifier numbers for implanted devices as part of the EHR. Also proposed in the ONC proposal is that certain segments of the healthcare enterprise receive addition attention and certification criteria. This included prescribing, pediatrics, and opioid use.
EHR related communications receive attention on two fronts. One is the familiar challenge of EHRs being able to communicate with each other in a seamless and useful manner. The other is the ability of EHR owners (lessors?) and users to discuss and report EHR shortcomings free from vendor restrictions. In this regard the Cures act mandated that in order to maintain certification a vendor may not prohibit or restrict communication regarding usability, interoperability, security, or user experience. Here it can be noted that unlike EHRs, medical devices have both voluntary and mandatory reporting of user experience with a focus on adverse events. The Cures act mandated some form of EHR reporting but ONC acknowledges that they have not yet established such a program. The rule proposes to implement a broad general prohibition against developers imposing prohibitions and restrictions on user communications. The broadest prohibitions would apply to disclosures to government agencies required by law; information about adverse events, hazards, and other unsafe conditions; information about cybersecurity issues; information blocking; and failures to comply with certification requirements. There are some exceptions proposed including restrictions during testing. In an interesting anticipation of vendor abuse in this regard it is suggested that test period durations might have to be limited so that a product cannot be deemed by the vendor to be in continuous testing and thereby avoid compliance.
APIs get extensive discussion with numerous mentions and more than 70 pages of detailed discussion. Interesting terminology here is that APIs should be available for use “without special effort”. ONC is interpreting this to mean that APIs be standardized, transparent and pro-competitive. The latter includes that external APIs not be interfered with including by additional cost or access requirements that create an impediment. Privacy and access also receive extensive discussion including who can invoke it and who can waive it, what costs are permissible, and the ever-present technical issues of data protection.
There are many other elements in the proposed rule which I leave to your bedtime reading, but don’t procrastinate because comments are due in 60 days.