This may be a duplicate as I thought I had scheduled it once before, but it isn't showing up in my blog or my schedule.
I had a chance to read a blog today describing how our basic concept of device good manufacturing practices needs to be enhanced to deal with the increasing presence of medical devices that consist solely of software. I must confess I was expecting this discussion to be about “loosening the controls” for software and was pleasantly surprised to see a more serious discussion about how to interpret the requirements found in ISO 13485 (the fundamental basis of cGMP for devices) for application to software systems.
For those of you who aren’t familiar with the notion of cGMP, it is an acronym for current good manufacturing practices which describes quality systems that need to be in place to design, produce, store, ship, install and maintain healthcare products. For pharmaceutical manufacturing, cGMP requirements can be found in the code of federal regulations at 21 CFR 210,211; for medical devices, it can be found 21 CFR 820 (Quality System Regulations).
Both describe the need for a well-documented and effective quality system. What Mr. Giantsidis points out is that the meaning of the terms and concepts with cGMP in any current quality system need to be updated to address unique issues of software-only systems, many of which have product development cycles that are far faster than we normally associate with mechanical, or electromechanical devices and may have different hazards to consider.
There are two reasons I would recommend reading this blog:
- It provides insights into the processes we should expect of our vendor partners who develop and deploy software products
- It provides insights we should apply to ourselves when we install, upgrade, and maintain software systems in our practice environments.
Having said that, there were some of the points that were made in this blog that I think bear more discussion as it relates to our practice:
- People – the blog focuses mainly on technical human resources and those resources are important. It has been my experience, however, that no amount of technical training replaces the inherent and cultural understanding of pharmacy practice and medication management processes needed to automate our practice environment; that can best be provided by an experienced medical informaticist (in our case, a pharmacy informaticist).
- Environment/Tools – when creating software for use in medical environments, especially when that software is to be regulated as a medical device, one must be conscious not only regarding the development and software management tools but must also be aware of regulatory requirements regarding the software environments in which the device is certified to operate, and common limitations that may be found within acute care facility environments. That may mean, for example, that the software product has to be developed to operate reliably irrespective of what cybersecurity measures may be in place in the working environment. It may also mean that the software requirements are sufficiently articulated that an IT organization can determine what, if any, enhancements may be required in the facility network to support those requirements.
- Product Realization – Table 1 in this section of the blog contains a reasonably complete discussion of risk management and the important requirements that
- risk control measures be verified and validated and that these risk mitigations be traceable to the software hazards they are intended to address.
- these measures also inform the kinds of operational validation that we must perform on our software.
- risk management scenarios include “reasonably foreseeable misuse”. That is, we cannot just review the “happy path” of software being used as is expected; we must also consider likely software misuse (including creative workarounds).
- Design and Development – A subject that is often a concern and is not mentioned in this blog is user-interface design. Ideally, a software product follows user interface design paradigms associated with widely used software products to leverage the habits, knowledge, and awareness of the user. This can minimize the amount of training a software product requires. Presentation of controls (e.g., buttons, lists, etc.) should minimize the opportunity for the user to take an unintended action and must identify and challenge any potentially destructive action (such is irredeemably removing key information), giving the user the opportunity to reconsider that action.
Another key consideration in the user interface is maintenance of context and minimization of duplicate entry. A user should always be able to confirm where they are in a process, especially as screens change, and not be required to remember and physically re-enter information they have supplied on previous screens.
Another consideration that is crucial both to design and implementation involves making the software easier to use correctly than incorrectly. It has been my experience that, when the intended operation of the software is more burdensome than workarounds and yields no perceived benefit to the user, users will likely invent workarounds that may or may not be hazardous but will definitely confound the quality of the data produced by the system.
Finally, especially for software-as-a-service (SaaS - hosted) systems, critical applications must have a way to continue to operate and supply value when connection to the internet is interrupted.
- Integration and Testing – one strategy that is, in my experience, key to managing testing appropriately is to compartmentalize functions within a software system, grade those functions in terms of the hazards they represent, and base both unit and integration testing strategy on the hazard grade(s) of the component(s) that were modified. Components with a high hazard potential must be carefully developed, extensively tested, and then used untouched for as long as is possible. This simplifies the overall testing strategy. If changes within a release do not affect critical software components or how they are used, the amount of testing may be reduced.
- Use of third-party tools – the blog does a good job of discussing third-party tools, especially open-source tools. I would only add that disclosure of the use of those tools be included in product descriptions for transparency.
It seems apparent that our industry is moving away from deployed and locally installed software and towards hosted SaaS systems. The concepts described here, and in the blog, should be applicable to both regulated and unregulated software systems.
As always, the thoughts in this blog are my own, and not those of ASHP or of my employer.
Dennis A. Tribble, PharmD, FASHP
Ormond Beach, FL
datdoc@aol.com