2016年 9月 15日
On August 25, 2016, the UK Medicines and Healthcare Products Regulatory Agency (MHRA) issued a guidance covering “Medical device stand-alone software including Apps.” The guidance is applicable to the current medical device directives 93/42/EEC and may be replaced when the new EU Medical Device Regulations are put into force.
The new MHRA guidance includes apps (including in vitro diagnostic medical devices or IVDs), and provides very helpful clarifications to some key stakeholders. First and foremost, it helps patients and users of healthcare apps to become more attuned to the risks that may be associated with the use of such products.
The guidance also helps patients and users recognize that responsible use is not just the purview of the app developers but that they themselves, as patients, must have an understanding of the apps’ capabilities and limitations…particularly the fact that an app will most likely follow the old computer science adage of “garbage in / garbage out.”
The guidance goes on to address some key definitions from the specific perspective of how stand-alone software may, by itself, represent these defined terms such as medical device, IVD, module, and accessory. However, the guidance acknowledges that there is currently no definition in the Medical Device Directives for “system.” While there are references to products placed on the market “together,” and to decomposing complex system capabilities into “functions,” it appears that there is still much to be done in bringing systems engineering into the picture.
Why is this so important when discussing apps and standalone software? The answer is somewhat straightforward: Software by itself cannot do much, so at its most innocuous, it would be the “glue” that binds the parts of a system together, and at its most concerning, it would be the “brains” that are responsible for system safety. Either way, it is clear that the intended purpose of a system can be much greater than the mere sum of its parts, and so recognizing software as a medical device (SaaMD) has much to do with its relationship to the whole system, ultimately comprising something more than just software, even if only a user interface.
So it is a very important next step in furthering our understanding that we start to think about interoperability, as we begin to become more comfortable with what standalone software is and what it isn’t. When we think about the quality of that interoperability between parts of the software system, it leads us to another relevant topic: cybersecurity.
Anura Fernando is Senior Customer Solutions Consultant at UL.