WHITEPAPER: SOFTWARE APPS AS MEDICAL DEVICES THE REGULATORY LANDSCAPE

Transcription

1 WHITEPAPER: SOFTWARE APPS AS MEDICAL DEVICES THE REGULATORY LANDSCAPE White paper produced by Maetrics For more information, please contact global sales With offices around the world Maetrics, All Rights Reserved +

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 fuelled the rise of innovative uses within the medical device industry. There are now apps available that contribute to the treatment of diabetes, apps that facilitate the transfer of lab results to be displayed at a nursing station, and apps that 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. 2

3 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 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 which 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: 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 which is intended to be used for diagnostic purposes is a medical device. Likewise any software which is intended to be used to specify dosages of medicines is a medical device because it is being used for therapeutic purposes. 3

4 How to classify 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 stand-alone 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 of 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. 4

5 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 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 diagram of components, sub-assemblies, circuits, etc; The descriptions and explanations necessary to understand the above mentioned drawings and diagrams and the 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 This 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 would need to contain the software top-level description, the architecture definition, 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 which 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. 5

6 The handling of fault conditions and fault reporting and 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. 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 the 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 error 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 which could give rise to critical use errors. EN is very closely linked to EN ISO 14971, and cannot be used alone without it. For assessment of how application software which 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 6

7 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 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 check list 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? 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 Clinical Evaluation? In the above list of the documentation requirements for a medical device, there are two items 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 which 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 actual clinical performance of similar applications or 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. 7

8 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 stand-alone 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 apps store, there is no physical packaging, labelling or printed instructions. This means that the manufacturer must seek to ensure that the CE mark, 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 start-up of the application. The manufacturer must ensure that all this information is subsequently available and easily accessible, for example the use of an icon which 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. 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. 8

9 What differences are there between European (CE Marking) and other Regulatory requirements? In the United States the medical devices 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:- s/ucm htm 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 once on the market is to gather real data on clinical performance, both to ascertain whether there are any trends which require action and to inform the regular updating of the Risk Management File. In the case of software downloads, this should in theory be simple to manage. Any application which is downloaded from an apps store should be able to be traced to a user, and fault and comments collected on-line. 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

10 How might operating system upgrades affect the 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 against a background of 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 there is a potential for the application to fail or, even worse, to appear to function correctly but deliver erroneous results. 10

11 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 stand-alone 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. 11

12 Global Acumen From A Single Source - EU Authorized Representative - Quality Remediation - Global Regulatory Issues, 483s, Warning Letters, - CAPA - Regulatory Compliance - Regulatory Submissions - Quality Audits & Assessments - Quality System Implementation & Process Improvement - Validation Strategies, Planning, & Execution - For all types -process, software, test method, etc. - Complaints, Adverse Events & Recalls - Sterilization/contamination control - UDI - Supply chain management - Make/buy, distribution, test/quality, functions & delivery - Supply Chain Risk Assessment - Supplier Quality Auditing, Qualification & Management - Commissioning Of Facilities & Utilities - Manufacturing engineering services - Post-market surveillance - Mock FDA Inspections - Implementation & Validation Of Software Systems - Organizational change management - Maetrics U Quality Training White paper produced by Maetrics For more information, please contact global sales globalsales@maetrics.com With offices around the world Maetrics, All Rights Reserved +