Software as a Medical Device

The last decade has seen unprecedented advances in both medical device and information technologies. As the technologies used in these two sectors continue to develop and converge, new markets are created and manufacturers have responded by releasing new products and solutions. One such marketplace is Healthcare IT (HIT), where, for example, solutions are now being implemented enabling physicians to view patient records on a tablet device or remotely from the care location on a smart phone.

With the emergence of this HIT marketplace, and the regulations that come with it, manufacturers of Information Technology Equipment (ITE) and medical device solutions will be required to apply a new approach to compliance. Hardware compliance testing will still be required, but, in addition, items such as risk management, software validation, solution reliability and interoperability will become embedded in the de-facto language of conformity assessment.

This two-part series of articles provides an overview of the compliance related developments in the HIT domain – covering regulatory developments both recent and future, standards development activity and analysis of the potential impact to the in-house compliance process.

This first article begins with an overview of HIT to set it in a context relevant for compliance engineering analysis, and then proceeds to discuss the regulatory situation in the European Union (EU). Subsequent articles will cover the regulatory framework in other markets and an analysis of the related international standards development activity.

A Typical HIT solution

An HIT solution is essentially a deployed combination of clinical medical equipment together with the supporting IT infrastructure – workstations, backbone network and storage, software applications and services. The overall solution may be provided by one vendor or by some combination of IT equipment suppliers, IT services and clinical equipment suppliers.

The topology of HIT solutions will vary depending on the application. As can be seen from Figure 1 it can be simply confined to a specific clinical application environment such as a laboratory analyzing samples where results are stored locally.
Alternatively, as in Figure 2, the solution may incorporate various healthcare information sub-systems, (e.g. laboratory, radiology, order entry), patient administration systems, working across multiple hospital sites and interconnecting remotely with primary care physician and community care centres.

Figure 1

Figure 2

From a compliance perspective, both examples contain some mixture of the following key elements:

• IT hardware such as servers and storage equipment;
• medical (clinical) devices;
• standalone application and management software
• embedded software

The efficiencies and improvements to healthcare services that HIT solutions offer have been welcomed by all concerned. However as their prevalence increased the question of how they could potentially impact on patient safety due to their integral part in clinical diagnosis and treatment has begun to receive attention.

In the EU, it was recognized by the authorities that the existing legislation covering medical devices did not clearly identify how software used in a medical application should be treated. Manufacturers and Competent Authorities alike did not have a consistent framework for the assessment of medical software.

Software – A Medical Device?

In the EU both ITE and medical electrical equipment fall under the scope of the New Legislative Framework (NLF).with typical ITE equipment being covered by a combination of the Low Voltage/EMC/R&TTE Directives and electrical medical equipment by the Medical Devices Directive (MDD). Both categories also carry the CE mark as an indication to market surveillance authorities that their conformity has been assessed.

Since its publication in 1993 the MDD has effectively only been applied to the hardware aspects of medical electrical equipment, with the embedded software required by the product to perform its function being assessed by default as needed to support the hardware testing. Standalone medical software used in conjunction with other clinical or IT equipment had not been considered at all up to then.

This, according to the EU Commission, was never the intention of the MDD and so, in 2007, the MDD was amended¹ to specifically highlight the requirement for standalone software to be considered as a medical device. Article 1.2(a) was modified to explicitly include the word ‘software’ as one of the articles to be considered a medical device, subject to the other qualification criteria listed as part of the definition. The definition is copied here below for information:

2. For the purposes of this Directive, the following definitions shall apply:

(a) ‘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 and necessary for its proper application, intended by the manufacturer to be used for human beings for the purpose of:

• diagnosis, prevention, monitoring, treatment or alleviation of disease,
• diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap,
• investigation, replacement or modification of the anatomy or of a physiological process,
• control of conception,

and which does not achieve its principal intended action in or on the human body by pharmacological, immunological or metabolic means, but which may be assisted in its function by such means;

Software qualification and classification

Since the amendment came into effect on March 21, 2010 there has been a comprehensive debate amongst the interested parties (Member State Competent Authorities, Commission services, industry and notified bodies) with a view to arriving at agreement on which types of standalone software application should qualify as medical devices, according to the definition above and for those that do, how they are to be classified.

Qualification of software as a medical device

Unit B2 of the Health and Consumers Directorate of the EU Commission have been working to produce a guideline document to assist with the process of qualifying software as a medical device. The guideline document is nearing completion and is currently with the Medical Devices Expert Group (MDEG) for review and approval. It is anticipated that the guideline will be published as a MEDDEV early in 2012. MEDDEVs are guidelines aimed at promoting a common approach by manufacturers and Notified Bodies involved in conformity assessment procedures according to the relevant annexes of the MDD, and by the Competent Authorities charged with safeguarding Public Health.

In deciding whether or not a standalone software is a medical device it is anticipated that some of the key considerations enshrined in the guidance will be :

• The decision to consider standalone software as a medical device shall be based on its intended purpose, as defined by the manufacturer. A device must have a medical purpose to be qualified as a medical device.
• Is the software performing an action on data different from storage, archival, lossless compression, communication or simple search?
• Standalone software that is not a medical device, but is an accessory to a medical device, may fall under the scope of the MDD.
• The risk related to malfunction of standalone software used within a healthcare environment is in itself not a criterion for whether or not it qualifies as a medical device.

Classification of standalone medical software

Once a standalone software is qualified as a medical device as per the qualification criteria defined, the guidance document will then proceed to clarify how the standalone software is to be classified as per Annex IX of the MDD

These classifications are of critical importance as each classification specifies a different route to conformity assessment, some involving Notified Bodies and others not (the MDD uses classifications I, II, IIIa and IIIb).

Other considerations

The other significant change in the MDD amendment is the introduction of an essential requirement relating to risk management of software.

MDD Annex I requirement 12.1 is amended as follows:

(g) the following Section shall be inserted:

‘12.1a For devices which incorporate software or which are medical software in themselves, the software must be validated according to the state of the art taking into account the principles of development lifecycle, risk management, validation and verification.’;

This essential requirement will have to be underpinned by appropriate EU Official Journal harmonized standards for software development. The recently published IEC 80001-1 standard on risk management for IT networks incorporating medical devices is one such candidate standard.

Further Regulatory Developments for HIT

So far this article has focused on standalone software and how the MDD has been amended to clarify the framework for how such software is to be assessed. While this is a significant move, it is only one element of wider developments underway in the EU in the field of eHealth, HIT being a subset of the eHealth ecosystem.

The key components of these developments are discussed in the following sections.

Standardization Mandate M/403

This mandate was issued by the Commission to the European Standards Development Organizations (SDO) on March 6, 2007. The title of the mandate is Mandate to the European Standardisation Organisations CEN, CENELEC and ETSI in the field of Information and Communication Technologies, applies to the domain of eHealth.

It is widely recognized that eHealth has major business potential for industry, with associated benefits to the citizen and the healthcare profession, but to make eHealth services available and beneficial for EU health professionals and citizens, safe and secure interoperability is a pre-requisite. The primary driver for the Mandate is therefore to achieve common agreed upon set of standards and conformance verification procedures that will facilitate safe and secure interoperability. In this context, interoperability is more than just technical interoperability, but also includes semantic and linguistic criteria, cultural aspects, and organizational issues.

Phase 1 is now complete. This involved listing all existing relevant standards and technical reports, and defining a plan for Phase 2 that will enable the objectives of the mandate to be realized, with a prioritization given to the most crucial standards.

Phase 2 is scheduled to complete in 2012. The top priority use cases being worked on are Patient Summary (electronic health record) and ePrescription. One of the five pillars of this Phase 2 work is development of conformance test plans and tools. The outcome from this work will be a set of protocol suites that HIT solutions must conform to.

Commission Recommendation 2008/594/EC

This recommendation, issued in July 2008, relates to cross-border interoperability of electronic health record systems. It provides a set of guidelines for developing and deploying interoperable electronic health record systems, contributing to the main Commission policy objective of achieving overall European eHealth interoperability by the end of 2015.

So this can be achieved the Recommendation invites Member States to undertake actions at a number of levels:

• political
• organizational
• technical interoperability of EHR systems
• semantic interoperability of EHR systems
• certification of EHR systems
• protection of personal data
• monitoring and evaluation
• education and awareness training

It further expands the certification of EHR systems action as follows in Article 9(b):

“put into place a joint or mutually recognised mechanism for conformity testing and certification of interoperable electronic health records and other eHealth applications, such as the techniques and methodologies offered by various industry consortia”;

There is a clear indication in this article that not only is the intention to introduce a conformity assessment scheme for eHealth, but that the Commission will leverage the existing work performed by the ICT fora and consortia standardization organizations e.g. ANSI HL7 and SNOMED². This move to recognise industry fora and consortia is further evidenced by the review that is currently in progress of the ICT standardization process in Europe.

Europe 2020 Strategy and Digital Agenda

Adopted in May 2010 the Digital Agenda is a flagship initiative for smart, sustainable and inclusive growth to develop an economy based on knowledge and innovation.

It contains a renewed commitment to eHealth through aiming to ensure:

• patient empowerment – support patients access to eHealth services, including patients records and telemedicine services
• sharing knowledge for better care –
• minimum data set for patients’ summaries
• interoperability – standardization, certification and testing

Copied below are two of the key actions from section 2.7.2 of the Digital Agenda document.

ACTIONS

The Commission will work with Member States Competent Authorities and all interested stakeholders to:

• Key Action 13: Undertake pilot actions to equip Europeans with secure online access to their medical health data by 2015 and to achieve by 2020 widespread deployment of telemedicine services;
• Key Action 14: Propose a recommendation defining a minimum common set of patient data for interoperability of patient records to be accessed or exchanged electronically across Member States by 2012¹;
• Other actions:

Foster EU-wide standards², interoperability testing and certification of eHealth systems by 2015 through stakeholder dialogue;
Reinforce the Ambient Assisted Living (AAL) Joint Programme to allow older people and persons with disabilities to live independently and be active in society.

¹ In line with data protection requirements
² Under Mandate 403 (CEN)

Again, the importance of standards, interoperability testing and certification are highlighted as fundamental to the success of eHealth. In pursuit of this objective the Commission is supporting, via the epSOS initiative, a large scale pilot project across Member States, for the purpose of demonstrating interoperability of patient record systems and e-prescriptions.

Conclusions

It has always been and remains today a challenge for regulatory authorities and standardization bodies to keep abreast with the rate of development in technology driven markets. eHealth is one such market but with even the smallest probability of a potential impact to patient safety due to an unregulated marketplace we can expect to see significant effort applied to this area over the coming months and years. There are interesting times ahead for us traditional compliance engineering professionals.

Notes

1. Directive 2007/47/EC of the European Parliament and of the Council of 5 September 2007
2. HL7: www.hl7.org; SNOMED: http://www.ihtsdo.org

These materials are not offered as and do not constitute legal advice or opinions. Seek independent legal advice with respect to compliance or any particular issue. The content of this document reflects the opinions of the individual author and may not reflect the opinions of Dell Inc.

Brian Mcauliffe is currently employed as a Senior Engineer with Dell Inc. based in Ireland and working in the Global Regulations & Standards group. Brian has worked in compliance for 20 years with compliance testing laboratories and a number of product development companies in the telecoms and ITE sectors. He is active in the standards development process being an expert member of CENELEC and IEC technical committees and has been Chairperson of TechAmerica Europe Standards & Certification working group since 2009. Brian is currently studying part time for an M.Sc. in Health Informatics from the University of Limerick (www.ul.ie). These materials are not offered as and do not constitute legal advice or opinions. Seek independent legal advice with respect to compliance or any particular issue. The content of this document reflects the opinions of the individual author and may not reflect the opinions of Dell Inc.