Dr. Fergal McCaffrey (Lero@DKIT)

The global medical device market is currently valued at $315 billion and is forecast to reach $362 billion by 2015. A steady growth between 4 and 6% is expected in most countries worldwide with a particular increase in China and regions where an increasing aging population is prevalent. With remote monitoring and increasing software complexity in hospital based systems, the medical device/healthcare software development market is set to grow considerably over the coming years.

Software performs an increasingly essential role in the provision of healthcare services, with software now playing an increasingly important role in medical diagnoses and treatment. Therefore, both the proportion of medical device functionality performed using software and the complexity of that software has substantially increased. Consequently, there a growing need to address the potential harm that can be caused by faulty software. In 2011, the FDA reported that “software failures were behind 24% of all the medical device recalls” [1]. In Europe, the medical device regulatory environment has been extended to include more focus on software. For example, the 2007/47/EC amendment to the Medical Device Directive recognises that standalone software can also be classified as a medical device in its own right if it fulfils the definition of a medical device. Consequently, a significantly increased proportion of software applications will now be classified as medical devices and must be developed in a regulatory compliant manner. Over the coming 4-8 years, this development will have a significant impact on the large number of software development organisations operating within the medical device domain, with regulatory compliance soon becoming a market access prerequisite such as does not presently exist. Many suppliers are likely to be ill-prepared for such a scenario.

Another growing trend in global healthcare is electronic medical records management. The use of Electronic Medical Record (EMR) systems in the USA by physicians increased from 18.2% in 2001 to 48.3% in 2010 and this is set to continue. The adoption of EMR systems could produce efficiency and safety savings of $81 billion annually and improve prevention of medical diseases [2]. However, security regulations provide a challenging impediment in global adoption of interconnected medical systems.

Mobile applications are perhaps the primary source of the standalone software that is now classified as a medical device. Yet the mobile app developers are not prepared to comply with the regulatory requirements set for medical device developers. With the use of mobile devices in health care rapidly increasing -“By 2017, mobile technology will be a key enabler of healthcare delivery reaching every corner of the globe” [3].

Medical device software development organisations may develop either standalone medical devices or devices that will be interconnected. Additionally, the software developed may be either embedded software as a component of a medical device or standalone software which may itself be classified as a medical device. However, it is important to note that no matter what type of medical device software is developed the manufacturer must comply with the regulatory requirements of the country in which they wish to sell their devices, as only medical devices that comply with such regulations are deemed safe and may be placed on the market. Such regulations require that highly effective software development practices are defined and adopted within medical device companies. Two of the largest global bodies responsible for issuing and managing medical device regulation belong to the central governing functions of the US and EU. In the case of the US, the Food and Drug Administration (FDA) issues the pertinent regulation. Under US regulation, there are three medical device safety classifications: Class I, Class II and Class III. In the EU, the corresponding regulation is outlined in the general Medical Device Directive  93/42/EEC, the Active Implantable Medical Device Directive 90/385/EEC, and the In-vitro Diagnostic Medical Device Directive 98/79/EC - all three of which have been amended by 2007/47/EC. Although slightly different to the US safety classifications that are based on clinical safety of the device, the EU classifications essentially embody similar classifications and limitations, where Class I corresponds to Class I, Class IIa and IIb to Class II, and Class III to Class III. A further safety classification applies to the software in the medical device as outlined in IEC 62304, wherein the safety classification is concerned with the worst possible consequence in the case of a software failure (as compared with general medical device safety classification which is based on the difficulty of a regulator to determine if the device will be safe). Hence, some Class II medical devices can cause serious injury or even death, but they are Class II because they are similar (in clinical use and safety) to well understood devices that have been used before. Since IEC 62304 safety classifications are based on failure of the software, it is possible that Class II medical devices can have Class III (or Class C by IEC 62304) software.

Adherence to the various medical device regulations outlined in the previous paragraphs may be demonstrated through the implementation of international standards and guidelines. In the medical device domain, ISO 13485 identifies the requirements for regulatory purposes from a quality management system  perspective. ISO 13485 can be used to assess an organisation’s ability to meet both customer and regulatory requirements. However, ISO 13485 does not offer specific guidance on software development. IEC 62304, which can be used in conjunction with ISO 13485, offers a framework for the lifecycle processes necessary for the safe design and maintenance of medical device software.

IEC 62304 is designed to complement not just ISO 13485, but also ISO 14971. ISO 14971 is responsible for establishing sufficient levels of risk management (with respect to product safety) in the development of medical devices. In addition to the standards and guidance noted above, significant additional detail is provided by the FDA in the form of three software guidance documents. When medical device development moves from the design phase into the production stage, further guidance is incorporated in order to support the safe industrialisation of medical device production – Good Automated Manufacturing Practice (GAMP). Many further standards also exist in the medical device development domain, including usability requirements described in IEC 62366, and performance requirements for safe electrical equipment detailed in IEC 60601-1.

Lero researchers in the Regulated Software Research Centre (RSRC) in Dundalk Institute of Technology perform medical device software engineering research and have developed a medical device software process assessment model MDevSPICE® to reduce the overhead associated with adhering to all the medical device specific standards and regulations by bringing them together into a single model. Developing MDevSPICE® required the RSRC to have a significant international standards engagement and part of this work lead to the development of IEC 80002-3 (Process Reference Model for IEC 62304), published in May 2014. IEC 80002-3 represents the culmination of many years of dedicated work by the RSRC, creating important new standards within the working groups of both the ISO and the IEC. Through working with international standards working groups such as IEC SC62A/ JWG3, IEC SC62A/JWG7 and ISO/IEC JTC1 SC7 WG10, the RSRC has advanced other standards, including IEC 80001-1-7 (Process Assessment Model for IEC 80001-1) and IEC 80001-2-8 (Guidance on standards for establishing Security Capabilities identified in IEC/TR 80001-2-2).

MDevSPICE® will be released to the global market in Q1.2015 and it will for the first time concentrate the accumulated medical device software best practices from all leading sources, while also supporting the industry and regulators in consistently and accurately evaluating software process implementation. This is good news for regulators, as a robust and thorough framework grounded in international standards will exist for assessing medical device software producers. And it is good news for the producers too, as all the medical device know-how will for the first time be assembled in a single, authoritative framework.

 

[1] FDA. FDA News on Software Failures Responsible for 24% of all Medical Device Recalls. 2012  [cited 2013 12.04]; Available from: http://www.fdanews.com/newsletter/article?articleId=147391&issueId=15890.

[2] Hillestad, R., J. Bigelow, and A. Bower, Can electronic medical record systems transform health care? Potential health benefits, savings, and costs. Health Aff, 2005. 24: p. 1103-11017.

[3] Interview with Jeanine Vos, Executive Director, mHealth at the GSMA. 2012.