To embed, copy and paste the code into your website or blog:
After having dealt with the issue when software may be considered a medical device according to its
intended purpose (in part 2) and the implications of the new
risk classification regime (in part 3), in this part 4 of our series on Software as a Medical Device in Europe, we will now explore key changes to the quality assurance and documentation requirements for stand-alone medical device software (“
MDR”).
INTRODUCTION: A NEW LIFE CYCLE-FOCUSED APPROACH
MDD”) primarily focusses on the pre-approval stage of a medical device and how the manufacturer can obtain the CE marking, the MDR deploys a product life cycle-focused approach, aiming to establish responsibilities of medical device companies throughout the life cycle of the product. While not all requirements are new, to ensure conformity of the MDSW with the MDR, detailed and partly enhanced requirements concerning quality management, risk management, clini
Having shed light on the relevance of the
intended purpose of a medical device when determining whether software qualifies as medical devices software (“
MDSW”) under the new EU Medical Device Regulation 2017/745 (“
MDR”) in part 2 of our series of articles, in this part 3, we now turn to the issue of risk classification of such MDSW under the MDR.
INTRODUCTION
MDD”), most stand-alone MDSW (
i.e., MDSW not implemented in a more complex medical device, such as control software) including, for instance, a mobile app that allows users to take pictures of moles on their skin and evaluates whether it is a melanoma, are classified as Class I medical devices and therefore subject to self-certification (
In Part 2 of our series of consecutive articles on the reformed regulatory framework under the EU Medical Device Regulation 2017/745 (“MDR”), which will soon govern medical devices.