SOFTWARE APPS AS MEDICAL DEVICES. The Regulatory Landscape 2015 WHITE PAPER WHITE PAPER PRODUCED BY MAETRICS

Transcription

1 WHITE PAPER SOFTWARE APPS AS MEDICAL DEVICES The Regulatory Landscape 2015 WHITE PAPER PRODUCED BY MAETRICS For more information, please contact: USA Office: UK Office:

2 Introduction The medical device industry has over the last two years witnessed a phenomenal rise in innovative software applications. The proliferation of smart phone and tablet technology whether from Apple or her Android counterparts has fueled the rise of innovative uses within the medical device industry. Apps are now available that contribute to the treatment of diabetes, facilitate the transfer of lab results to be displayed at a nursing station, and help detect cognitive disorders. This technology is contributing to major innovation efforts within the healthcare sector, and yet there is much confusion over how to deal with them for regulatory purposes. As regulatory specialists in this field, Maetrics has worked on a number of CE marking projects for medical device software app providers. In this paper, we offer our expertise and guidance from on-the-ground experience to help developers remain compliant and navigate their way through the regulatory landscape. When is Software a Medical Device? Many conventional medical devices contain software to control their functions, whether they are intended to be used for therapy or diagnosis; the classification of the device depends on the degree of risk to the patient. But what happens when a software-based application is used and it operates on a platform such as an ipad with no controlling function on any other equipment? According to the latest version of the Medical Devices Directive, which came into force in March 2010, stand alone software is considered to be an active medical device. This means that the classification rules for active devices apply and therefore this software could be classified as Class I, Class IIa or even Class IIb in cases where it is used to control or monitor the performance of Class IIb active devices. What about apps for ipads that indicate therapeutic pathways? Are these diagnostic? There have been many examples recently of applications designed to run on the popular ipad platform, including tools for assisting in the diagnosis of disease, interpreting data generated during patient examinations and calculating dosages of medicine based on patient characteristics. The decision on whether these are to be regarded as medical devices depends on the intended use of the application. If an application is intended to diagnose a disease or even assist the clinician in reaching a diagnosis, it could easily be argued that this becomes a medical device by the definition in the Medical Devices Directive, 93/42/EEC, which states in the latest version as amended by 2007/47/EC: 2016 Maetrics, All Rights Reserved 2

3 Medical device means any instrument, apparatus, appliance, software, material or other article, whether used alone or in combination, including the software intended by its manufacturer to be used specifically for diagnostic and/or therapeutic purposes for the purpose of diagnosis, prevention, monitoring, treatment or alleviation of disease Therefore, it can be seen that in the case of any software that is intended to be used for diagnostic purposes it is considered a medical device. Likewise, any software that is intended to be used to specify dosages of medicines is a medical device because it is being used for therapeutic purposes. How to Classify Devices Under the Medical Devices Directive? Under the Medical Devices Directive, Annex IX contains the rules for classifying the device as Class I, IIa, IIb or III: the higher the classification, the greater the risk to the patient. We would therefore expect that an application running on, for example, an ipad would not present a high degree of patient risk. However, it should be taken into account what mode of action of the software is intended. If the output from the software is to be interpreted by the clinician as part of a suite of diagnostic tools and is not used directly to determine a course of treatment, then it is more than likely classified in Class I, by Rule 12, which states that all other active devices are in Class I. Remember that standalone software is considered an active device. By reading the other foregoing rules 9, 10 and 11, it may sometimes be the case that the software has a greater impact, such as its use to monitor the performance of active therapeutic devices, which would then place the device in Class IIb. It is probably rare to find such applications at the current time, although in the future this may be the case. In the next year or two, there will be a recast of all three Medical Device Directives and the above situation could change. Note that in the case of a Class I device, there will be no requirement for Notified Body involvement to verify that the device is in compliance with the directive prior to CE marking. However, there is still the requirement to create a technical file, which should contain all the items listed in Annex VII of the directive Maetrics, All Rights Reserved 3

4 What is Needed for a Product Technical File? There is no reference to a technical file in the directive, but for any class of device, the manufacturer must prepare the following items in order to allow an assessment of conformity to the directive: + + A general description of the product, including any variants planned and its intended use(s) + + Design drawings, methods of manufacture envisaged and diagrams of components, subassemblies, circuits, etc. + + The descriptions and explanations necessary to understand the above-mentioned drawings, diagrams and operations of the product + + The results of the risk analysis and a list of the [harmonised] standards applied in full or in part, and descriptions of the solutions adopted to meet the essential requirements of the directive + + The results of the design calculations and of the inspections carried out, etc. + + The solutions adopted as referred to in Annex I [the essential requirements] + + The pre-clinical evaluation + + The clinical evaluation in accordance with Annex X + + The label and instructions for use For a device consisting entirely and solely of software, it is clear that the above requirements need to be interpreted carefully to ensure the correct information is recorded some examples of how to structure this information for software applications are given below. a) Description and Intended Use These must be provided in the technical file, so be sure to describe fully what the software is to be used for, by whom and under what conditions. Also specify what it is NOT intended to do or who it is not intended to be used by. Are there any special training requirements as a precursor to allowing it to be released for use? Make sure that all variants of the product are defined, even if they are at the planning stage. b) What is Required to Satisfy the Requirement to Create Design Drawings and Methods of Manufacture? In the case of a pure software medical device, this requirement would need to contain the software top-level description, the architecture definition, a description of the modules, their functions and how they relate and function together. The more information, the better! It is not adequate to simply provide a programme listing. Make sure that any features that are not readily understood are fully described. The other vital feature to highlight is whether the software uses any operating system functions and how access to them is controlled. The handling of fault conditions and fault reporting as well as the listing of fault definitions must be included. The methods for checking for dead or redundant (sometimes development!) coding must be specified. With regard to methods of manufacture, it is suggested that all the specific procedures and tools used to design the software in question are fully defined, as well as the test methods employed. Make absolutely certain that the test methods are consistent with the test results reported in the pre-clinical evaluation Maetrics, All Rights Reserved 4

5 C) What Is Required for Risk Management? For any medical device, it is incumbent on the manufacturer to conduct a Risk Management Exercise and keep the Risk Management File up-to-date throughout the lifetime of the product. Unless there are compelling reasons to do otherwise (and these must be justified), the risk management process should follow the requirements of EN ISO 14971:2012 Medical Devices The application of Risk Management to Medical Devices. There is no exception to this for software! Following this standard will ensure that risk management is in compliance with the directive. In addition to this, careful thought must be given to the way the application interfaces with the user, especially with regard to usability and the possibility of use errors, giving rise to additional hazards for the user or patient. In this regard, a sister standard to EN ISO 14971:2012 is EN 62366:2008 Medical Devices The application of Usability Engineering to Medical Devices. This can be applied if the user interface has features that could give rise to critical use errors. EN is very closely linked to EN ISO and cannot be used alone without it. For an assessment of how application software that has user interactions is to be specified and developed, the following are also useful: + + ISO :2006 Ease of operation of everyday products - Part 1: Design requirements for context of use and user characteristics + + ISO TR : Ergonomics of human-system interaction Part 100: Introduction to Standards Related to Software Ergonomics + + Other standards in the ISO TR 9241 series can be consulted as appropriate. The above standards are general to all user-interfacing software products - not just medical devices. d) How are Design Calculations to be Defined? This can be tricky for a software device! However, good practice is to show how the user specification has been met by the software design and to make sure that all verification and validation tests are directly related to a specific design input or group of inputs. A traceability matrix is a suggested method of providing this evidence. This is also a requirement of the FDA regulations (21 CFR part Design Controls) so the technical information created in this way can also be used to form a Design History File (DHF) for FDA submissions. The V Model used for Systems Engineering Design is a suitable method to build into the software development and test procedures to achieve full traceability of tests to requirements. e) What About the Essential Requirements? In order to demonstrate that the essential requirements (ER) of Annex I have been satisfied, a checklist should be compiled showing each ER in turn and specifying the following: + + Is this ER applicable to the (software) device? + + If not, specify why (justification rationale). + + If it is applicable, what standards, preferably Harmonised under the MDD, have been applied? + + Have the standards been applied in part or in full? 2016 Maetrics, All Rights Reserved 5

6 + + Specify where the evidence for compliance with the ER is to be found test report reference, Risk Management Report, etc. It is essential that this checklist covers all 14 ERs. f) What About a Clinical Evaluation? In the above list of the documentation requirements for a medical device, two items are related to clinical: the pre-clinical evaluation and the clinical evaluation. The former can be defined as any testing of the device, in this case the software, prior to any exposure of it to real patients. Any testing conducted must be fully documented in terms of its purpose and expected outcomes, as well as any corrections to the design that result. The testing can usually be driven by the control measures adopted in the Risk Management Exercises. The directive always specifies that a clinical evaluation be conducted and documented. This can start as a literature review to capture the actual clinical performance of similar applications, software or other systems intended to be used in the same or similar therapeutic or diagnostic area of the intended use of the new device. In some cases, there will be insufficient data available in the literature and therefore a clinical investigation will be required. Guidance on how to create a system of robust clinical evaluation is available in the Guidelines on Medical Devices document: MEDDEV Again, if the device is standalone software, there is no exception to the requirements! g) What About Labelling and Instructions for Use? As software applications of this type are routinely downloaded from an app store, there is no physical packaging, labelling or printed instructions. This means that the manufacturer must seek to ensure that the CE mark, the identification of the variant and version of the software and any warnings or specific instructions are made available to the user in order to comply with the directive. The favoured approach is to set the download so that this information is clearly displayed at the startup of the application. The manufacturer must ensure that all this information is subsequently available and easily accessible, such as an icon that leads to a display of all the information. Care must be exercised that, when new versions are published, any changes to this information are immediately displayed and are available. It is also a requirement of the essential requirements of the directive that the date or version of the Instructions for Use is identified on it. Is a Software Lifecycle Management Process Required? Yes, in short! The manufacturer will be expected to apply the requirements of IEC Medical Device Software Software Lifecycle Processes Maetrics, All Rights Reserved 6

7 This specifies that from the beginning of the software development, the manufacturer shall assign to each software system a software safety class (A, B or C) according to the possible effects on the patient, operator, or other people resulting from a hazard to which the software system can contribute. These classes are based on the following severities of harm: Class A: No Injury or Damage to Health is Possible. Class B: Non-Serious Injury is Possible. Class C: Death or Serious Injury is Possible. This implies that some degree of preliminary hazard analysis should take place at the outset of the development, even before the full risk evaluation is conducted, as the classification into A, B and C has large implications on which elements are necessary to control and document during the software development cycle. What Differences are there Between European (CE Marking) and Other Regulatory Requirements? In the United States, the medical device industry is regulated by the Food and Drug Administration (FDA). The FDA has published guidelines on mobile applications this guidance is to be found at: In other worldwide markets, expect that the authorities will be following either the European Medical Devices directive (for example, the Therapeutic Goods Act in Australia is similar in content to it) or the guidance issues by the FDA. How is Post-Market Information to be Collected? One key requirement of any CE-marked medical device on the market is to gather real data on clinical performance, both to ascertain whether any trends require action and to provide regular updates to the Risk Management File. In the case of software downloads, this should in theory be simple to manage. Any application that is downloaded from an app store should be able to be traced to a user, and fault and comments collected online. The use of customer surveys will be facilitated by maintenance of a user database. In order for this to be effective, there must be traceability controls in place. There must also be a procedure in place specifying how the manufacturer responds to incidents as defined in MEDDEV Maetrics, All Rights Reserved 7

8 How Might Operating System Upgrades Affect Validated State of the Application? A key requirement for software running on mobile platforms is that it retains its tested, validated status. This can be difficult to achieve in conjunction with updates to operating systems. The manufacturer must ensure the following: + + The application software should be as far as possible completely independent of operating system features. For example, calculations and management of databases must occur within the application and not rely on any functions supplied with the platform. + + Update regimes for the platform must be fully understood and any operation system updates must be fully tested with the application before released. For the most part, the greatest risk is for the application to cease running rather than to partially fail. However, it is incumbent upon the manufacturer to carry out testing, update the Risk File (if appropriate) and warn all users if the application has the potential to fail or, even worse, to appear to function correctly but deliver erroneous results. Conclusion Whenever software is used to provide a therapeutic or diagnostic outcome, then all the requirements specified in the Medical Devices Directive must be fulfilled. Special care must be taken when the software is standalone and can be downloaded, especially when considering what technical information is required and how it should be presented to the regulators. There must be systems in place to monitor how the device performs once on the market and all the regional requirements for incident reporting must be adhered to. Careful interpretation of the requirements is needed to ensure that the device is compliant, and this can be done with the support of regulatory specialists who understand the ins and outs of the Medical Devices Directive. They can take into account the uniqueness of your device and support you through the entire process, from concept to delivery to market. The contents of this presentation are copyright 2015 Maetrics. All rights reserved. This presentation contains information in summary form and is intended for general guidance only. It is not intended to be a substitute for detailed research or the exercise of professional judgment. Maetrics LLC cannot accept responsibility for loss occasioned to any person, firm, company or corporation acting or refraining from action as a result of any material in this publication. On any specific matter, reference should be made to the appropriate professional advisor Maetrics, All Rights Reserved 8

9 For more information, please contact: USA Office: UK Office: