PREVIOUS ARTICLE Ministry of F...
MHRA issues Guidance on Medical Device Stand alone Software Next

MHRA issues Guidance on Medical Device Stand alone Software

By Anura S. Fernando

Time To Read 1 minute

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 on Medical device stand-alone software including apps (including invitro diagnostic medical devices – IVDMDs) 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 apps. It helps them 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 app’s capabilities and limitations…particularly 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, in-vitro diagnostic medical device, module, and accessory. However, it 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 “stand-alone” 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 comprised of something more than just software, even if only a user interface. So it is a very important next step in maturing our understanding that we start to think about interoperability, as we begin to become more comfortable with what “stand-alone” software is and what it isn’t…and when we think about the quality of that interoperability between parts of the software system, it leads us to another relevant topic: cybersecurity.

Please complete the form to download this article.