By Garrett Seeley
Cybersecurity, network security, and risk assessment are all HTM buzz words of the past decade. We have delt with these issues intermittently. However, the reality of increased computer integration into all aspects of healthcare has created vulnerabilities, both from system errors and from potential attacks.
According to the FDA, over 6% of recalls were caused by defects introduced when changes were made to the software after its deployment, i.e. in the field. (See FDA: General Principles of Software Validation; Final Guidance for Industry and FDA Staff, sample time from 1992 to 1998) That is a dramatic number considering it was updated over 20 years ago. This was before the saturation of computers in medical devices, and I can only imagine the number has increased since then. What we face now is a new future of potential software issues causing interruption to workflow and possible safety concerns.
To help mitigate this, the FDA and CMS have a new publication, the Computer Software Assurance for Production and Quality System Software. This publication is in the final stages of approval and is available in draft form from the FDA website (September 2022 draft version). As it stands, we really do not know what will be in the final draft. To help understand the FDA approach to software maintenance, I have read both publications and hopefully this article will help shed some light on the rumors of software maintenance in the HTM field.
In Computer Software Assurance for Production and Quality System Software, the FDA makes recommendations for the original equipment manufacturers (OEM) in production of medical devices. This publication focuses mostly on the manufacturing process, but it does include language for tracking software performance during the equipment life cycle. Some may jump to conclusions that HTM or IOT are required to maintain medical device computer software in the field. Some may even include telehealth and ancillary or third-party Internet of Medical Things (IoMT) software in that conclusion. Please be reassured that most of the recommendations focus on OEM obligations of testing to insure the operation of the devices prior to installation.
Where things get interesting is where the publication recommends tasks for maintaining the device software throughout the life cycle. This can be construed that it includes software of computers used to access the device to perform maintenance or monitoring. If enforced in this manner, it could influence maintenance of devices in the field. The actual impact will be vague until a final release is made public.
At this point, it focuses on the manufacturing process and not field operations. Some of the more interesting suggestions are for unscripted testing, things that go beyond the check list and really test the system, both passively and obtrusively. It is doubtful such tests will be performed, at least initially by the average field service engineer (FSE). This is mainly for the OEM to implement a specialist who can do such integrity testing. Keep in mind, this is for each device. Manufacturers may be obligated to hire a lot more cybersecurity specialists in the field in a very short while. That is perhaps my biggest takeaway from these publications.
This leads to a broader discussion of the need for change in the HTM in-house operations. In the past, software checks and maintenance were defined in the 2002 publication General Principles of Software Validation; Final Guidance for Industry and FDA Staff. In this, the FDA defined checking software as “Test cases should address error and alarm conditions, startup, shutdown, all applicable user functions and operator controls, potential operator errors, maximum and minimum ranges of allowed values, and stress conditions applicable to the intended use of the equipment. The test cases should be executed, and the results should be recorded and evaluated to determine whether the results support a conclusion that the software is validated for its intended use.” This is pretty much a simple operational check and not really a detailed check on the stability of the software. In fact, average HTM technicians rarely have access to software validations tools or even check lists to verify stability of the system. This is all in debate and subject to change. The General Principles of Software Validation is an attempt to take a better look at software maintenance during the manufacturing cycle. At this point, there is no required change for the standard HTM technician or the OEM field service engineer.
If the FDA would take an approach to include the concept of software validation expanded to device maintenance, things would get a bit more interesting. The past changes to HTM by the FDA and CMS have left the field concerned about new legislation. It is natural for the standard bench biomed to have some trepidation about maintaining software. Often, PM checklists simply verify the unit software is functional and accessible. In general, OEM testing of software integrity is reserved for FSE technicians only, and then under specific circumstances. Quite often the answer is to reload software. Of course, stipulations such as service support agreements could expand some of these features to in-house operations, but contracts still apply. All things considered, if the FDA is considering a mandate for the periodical testing of software, it could be a good thing. I am optimistic as to the possibility of having more tools for software testing in the hands of the standard biomed. It will be interesting to see how this policy change plays out.
Regardless of possible future changes to software testing, a process update is sorely overdue. The standards for software maintenance are from 2002. Systems have changed drastically in that time. IoMT is slowly creeping into everyday life. Additionally, most HTM professionals have little understanding of software validation.
In short, we have not changed our way of business and that emphasizes the need for better software evaluations in the field. As we become more dependent on computers and software, we will have to be more vigilant in the monitoring of that software. It is just a matter of time until a mandate gets placed on HTM to do so. After all, change like this is needed. Although this will increase tasks during a PM, it will also lead to more operations, more HTM positions, and overall increase the quality of care. Perhaps under the circumstances, we need to keep an open mind as to the potential for an updated standard, even if it gives more tasks.
For now, let’s all take the cautiously optimistic approach and get up to speed on the standards of software validation at the in-house HTM level. More articles on this subject will follow.
