Health Canada Posts New Notice and FAQ

Health Canada has posted a revised Notice and FAQ on Software Regulated as a Class I or Class II Medical Device (you will note that Health Canada no longer uses the term "Patient Management Software"). The new definition, from the FAQ is as follows:

"Software regulated as a medical device:

(1) provides the only means and opportunity to capture or acquire data from a medical device for aiding directly in diagnosis or treatment of a patient; or

(2) replaces a diagnostic or treatment decision made by a physician.

Software that fits part (1) of this definition would be picture archiving and communication system (PACS) and other types of software that have traditionally been licensed since they are adjuncts or accessories to medical devices.

The FAQ further clarifies that software used for remote patient monitoring (e.g. monitors used at home in a homecare situation), and software that controls or is embedded into a medical device are also medical devices.

These examples are covered under part 1 of the new definition. At this time, we are not aware of any product that meets part 2 of the definition (replaces a diagnostic or treatment decision made by a physician). It is expected that part 2 may come into play in the future when expert systems that replace a physician's judgement become available and are permitted to be deployed in the health system.

ITAC Health recommends that vendors and distributors of health software contact Health Canada to determine whether or not their products meet the new definitions.

EHR safety reporting system launched in US

Click here for article in Healthcare IT News.

Sources of Safety Risk in Software

In order to determine the appropriate standards for health software safety, we need to consider the sources of hazards. A scan of the literature reveals the following principal sources of safety risk:

1. Security risks as they relate to the integrity and availability of data and critical system assets (confidentiality doesn't figure in here to much) - This involves pretty much everything that could compromise the integrity and availability of software and associated data and includes viruses and other malicious code unauthorized access, and natural and man-made disasters. Best standards here are ISO/IEC 27001/27002/27799.

2. Software risks as they relate to the manufacture, installation and support of software products (including documentation, change management, and problem resolution processes). This includes software bugs (in both application software and underlying operating systems) and software that fails to meet user and performance specifications. This is essentially a quality issue and ensuring the application of an appropriate system development lifecycle methodology. Best standards here are ISO/IEC 13485/9001/ and their associated implementation guides and SDLC standards IEC 62304/ISO/IEC 12207.

ISO/IEC 14971 - Application of Risk Management to Medical Devices and its companion document IEC 80002-1 Medical device software - Part 1: Guidance on the application of ISO 14971 to medical device software provide guidance on the application of risk management practices to the manufacture and support of Medical Device Software (MDS). If one accepts that Clinical Management Software (CMS) and EHR Infrastructure Component Software (EICS) have similar risk profiles to MDS, then these standards would be appropriate.

3. Human factors engineering risks as they relate to the interface between the human user and whatever software, hardware or communications systems are deployed. This includes user interface (does it eliminate or promote user errors?), training, problem identification, escalation and resolution. This is essentially a quality issue as it relates to the software being developed in consideration of the user environment and user needs. Best standards here are ISO/IEC 13485/9001 and their associated implementation guides and SDLC standards IEC 62304/ISO/IEC 12207.

There is a purchaser/user dimension to human factors risk associated with end-user training (e.g. vendor has training available, but user doesn't apply it), work environment (stressed out or tired workers may make more errors), poor integration into clinical processes, etc. These are not addressed in any standard, but some guidance may be available from institutional certification and accreditation programs.

4. Project/installation risks as they relate to the installation and deployment of software systems. This includes user configuration, integration with clinical and business processes, and end-user training. On the manufacturer/vendor side quality standards 13485 and 9001 will require the vendor to ensure that readable documentation and training are available and are sufficient to enable user installation and configuration where necessary.

On the purchaser side, particularly around configuration management and integration of software into clinical and business processes, available guidance is limited. Some highly general guidance is available in project management standards (e.g. PMBOK). A standard for purchasers or users may be an area where TC215 can develop appropriate guidance for the deployment and support of health software.

5. Operations risks as they relate to the ongoing operation and maintenance of health software. This includes issues of change management, upgrades, bug fixes and patches, and performance levels. On the manufacturer/vendor side ISO/IEC 13485/9001 will require that required support services are in place and maintained.

On the purchaser/user side, technical management can be covered off applying ITIL or CObIT. Little guidance is available for end users activities. Again, this is an area where TC215 could provide some appropriate guidance.

New Definitions - MDS, CMS & EICS

As we go forward in discussions about standards in software, we need some new definitions. Unfortunately Health Canada has destroyed the term "patient management software". And of course there is the endless debate about whether a standard for medical device software is appropriate for EMRs, EHRs, Etc. There are many ways to slice and dice the definitions of software used in health care. Based on the issues raised during the Health Canada discussions and to clarify our language I propose the following definitions:

Medical Device Software (MDS) is any software that is used to:
- Control a medical device
- Receive and display data output directly from a medical device
- Receive, analyze and display data output directly from a medical device

MDS would include firmware imbedded into medical devices.

Clinical Management Software (CMS) is any software that is used to:
- Collect, process, store and display data used to support clinical decision making
- Combine and display clinical data from multiple sources
- Create and present new data through the analysis of clinical data (e.g. alerts)

CMS would include EMRs and EHRs. Anything below the HIAL.

EHR Infrastructure Component Software (EICS) is any software that is used to:
- Collect, process, store and communicate clinical data other than at the point of care (i.e. not CMS or MDS)
- Network or otherwise connect CMS systems and MDS systems

EICS would include middleware, software supporting security and privacy services, regional and provincial registries and repositories, etc. Anything in the HIAL or above.

Even these definitions can get confusing. For example, hook an electronic stethoscope up to a CMS and it becomes an MDS (at least according to Health Canada's proposed definition of software to be regulated as a medical device. I'm open to suggestions or alternate definitions. However, I will be using these definitions for my own analyses in the coming weeks.

Standards for Software Safety

Annex B of IEC 62304 provides a useful framework for standards associated with the safety of medical device software. On page 77 it states:

"There is no known method to guarantee 100% safety for any kind of software.

There are three major principles which promote safety for medical device software:

- Risk Management
- Quality Management
- Software Engineering"

In the medical device software world there are three standards that provide the essential guidance on software safety:

Risk Management - ISO 14971 - Medical Devices - Application of Risk Management to Medical Devices
Quality Management - ISO 13485 - Medical devices —— Quality management systems —— Requirements for regulatory purposes
Software Engineering - IEC 62304 - Medical Device Software - Software Lifecycle Processes

At least two of these standards have been adapted from more generic standards to meet the needs of the medical device software industry. In particular:

ISO 13485 is adapted from ISO 9001
IEC 62304 is adapted from ISO/IEC 12207 (Software Life Cycle Processes)

In pursuing this matter for clinical systems including EMRs and EHRs, we have three choices to choose from:

1. Adopt the standards that have been developed for medical device software (13485/14971/62304)
2. Adopt the more generic ISO standards (9001/12207)
3. Develop a unique set of standards for clinical systems including EMRs and EHRs

Thoughts?

Scope and Definition of Software Subject to Quality and Safety Standards

One of the big challenges in our recent discussions with Health Canada was the scope of software to be considered for licensing and the definition of that scope. The definition that Health Canada is landing on is as follows (from their draft FAQ - note that this has not yet been published and could be subject to change):

Software regulated as a medical device:

1. Provides the only means and opportunity (meaning in real time) to capture and acquire data from a medical device for aiding directly in diagnosis or treatment; or
2. Replaces a diagnostic or treatment decision made by a physician

This is a very restrictive definition that limits the software that is subject to licensing to software that is "adjunct" or connected directly to another medical device. Health Canada can provide no examples of what might fit the second part of the definition... but its expected that it may include expert systems that replace human clinical judgement in the future.

The other wrinkle in the Health Canada definition was that even though something might be considered a medical device, it doesn't require licensing unless it is sold. This then excluded ASP delivered solutions and any software developed in-house.

As an Industry we need to figure out the scope of software to be considered. We found that the Infoway blueprint was a useful frame of reference. So here's the challenge to the ISC - What components of the Infoway blueprint should be subject to quality management and safety standards? Are there software systems not included in the Blueprint that should be included (think consumer health platforms, smartphone apps, etc.)? Should there be an exception for in-house developed applications?

Post your replies on the blog.

Quality and Safety Standards that Apply to Health Software

I have been researching the various standards that may be considered in upcoming discussions about the ISO TC215 technical report on software and patient safety. Over the next days and weeks I'll email you with any interesting tidbits I uncover that may stimulate discussion. The actual standards themselves are quite expensive so I will provide wikipedia or SCC catalogue references to start you on your own research paths. Comments/reactions are most welcome.

Are there any other standards you think might apply?

To start - Standards in play:

ISO 13485 - Medical devices —— Quality management systems —— Requirements for regulatory purposes

ISO 14969 - Medical devices -- Quality management systems -- Guidance on the application of ISO 13485: 2003

ISO 14971 - Medical Devices - Application of Risk Management to Medical Devices

IEC 62304 - Medical Device Software - Software Lifecycle Processes

ISO 9001 - Quality Management Systems

ISO 90003 - Software engineering Guidelines for the application of ISO 9001:2000 to computer software

ISO 25238 - Health Informatics - Classification of safety risks from health software

ISO 27809 - Health Informatics - Measures for ensuring patient safety of health software

Health Canada to Scale Back Definition of Patient Management Software

ITAC Health has learned that Health Canada is planning to issue revised guidance in the form of an FAQ that will redefine Patient Management Software. It is expected that the new definition will be more restrictive than the definition in their May 21st Notice. It is likely than many patient management software products previously identified as Class I and Class II devices will no longer fit the new definition and will NOT require Medical Device Licenses. Health Canada has advised that they plan to issue the FAQ before the end of November.

ITAC Health recommends that health software manufacturers and vendors contact Health Canada's Medical Devices Bureau to confirm the status of their products. This includes products on which Health Canada had previously rendered classification decisions. Contact information for Health Canada follows:

Device Licensing Services Division
Medical Devices Bureau
Therapeutic Products Directorate
Health Canada
Room 1605, Statistics Canada Main Building
Tunney's Pasture, Address Locator 0301H1
Ottawa, Ontario
K1A 0K9

Phone: (613) 957-7285
Fax: (613) 957-6345
E-mail: device_licensing@hc-sc.gc.ca

ITAC Health Policy Statement on Medical Device Licensing

The following policy statement was approved by the ITAC Health Board on September 7, 2010.

Canada’s health ICT companies are committed to meeting the highest standards for patient safety in their products and services. For this reason, ITAC Health supports the application of Health Canada's Medical Devices Regulations (MDR) as they apply to patient management software defined in Health Canada's Notice dated May 21, 2010. This regulation is appropriate for patient management software products that manipulate and interpret clinical data, which require a high standard of quality.

ITAC Health believes the MDR to be an important vehicle to "raise the bar" in terms of software product quality, safety and effectiveness. It is national in scope, is based on recognized international standards, and is overseen by a legitimate authority with its basis in law. ITAC Health sees Medical Device Licensing as an important first step towards the end-to-end adoption and application of existing and emerging national and international standards for all components of the Canadian health information infrastructure. It is also a foundational element in a national strategy for conformance, certification and licensing that addresses the needs of all stakeholders.

We note that the requirements of the MDR include ISO quality management certification, which addresses the product development process, instructions for use, delivery procedures, training procedures, and support procedures. The MDR also includes the safety and effectiveness requirements in sections 10 to 20 of the regulations, labeling requirements, and requires that manufacturers and distributers have processes in place for complaint handling, problem reporting and recalls.

Member companies who manufacture and sell software products which they market as having the capacity to guide clinical behaviour, highlight clinical risks to users, or are otherwise relied-upon by health professionals to be accurate in their representation of clinical data, are complying with the MDR. Many vendors have for many years obtained the necessary licenses for their products consistent with Health Canada's MDR and the regulatory authorities in other countries. Other vendors are currently engaged in the process of obtaining ISO 13485 Certification and MDR Licensing and will be compliant by Health Canada’s deadline of September 1, 2011.

We acknowledge that a transition to such a regulated environment can be a complex and expensive endeavour. We believe Health Canada’s concession to extend the deadline for compliance to September 1, 2011 is supportive of private industry’s capacity to conform. We also acknowledge that budgeting and planning processes for government and other public agencies introduce a further level of complexity possibly warranting a further extension of time. This would involve giving additional time to those public agencies that develop and distribute software to adjust their internal processes and procedures for MDR compliance, and for those public agencies that need to maintain and support health-critical legacy software systems while they migrate to licensed software. ITAC Health would support changes to the Notice to facilitate such a transition provided that patient safety was not compromised in doing so and that such extension is not exploited to avoid the use of private industry solutions, or to circumvent a private company’s obligation to conform.

We believe that compliance with the MDR is in the best interests of vendors, who stand to gain from increased health care provider and consumer confidence in the safety and effectiveness of their products, and of health care providers and consumers who will have evidence that products have been developed under conditions that promote safety and effectiveness.

Are application service providers (ASP) subject to the Medical Devices Regulations?

Note: Exact text provided by Health Canada

ASPs (application service providers) do not fall within the scope of the Regulations since no sale of a medical device is taking place. However, if the ASP has purchased a medical device with which the ASP is providing a service, the manufacturer of the device is still required to comply with the requirements of the Medical Devices Regulations and obtain the appropriate licence prior to the sale to the ASP.

How will Health Canada treat legacy systems?

Note: Exact text provided by Health Canada.

For the purposes of this document, “legacy system” is defined as follows:

“legacy system” is software that was designed, sold and deployed prior to February 1, 2011 (Class I) or September 1, 2011 (Class II).

The Medical Devices Regulations prohibit the sale of a Class II, III or IV medical device unless the manufacturer of the device holds a device licence in respect of it. However, as legacy systems have been previously sold without immediate risks to public health having been identified, they have not been prioritized for compliance with this prohibition until September 1, 2011. After that date the sale of a legacy system that is a Class II, III or IV device without a licence will be prioritized for compliance as any other device (according to Policy 001 of the Health Product and Food Branch Inspectorate).

An establishment that imports or sells any medical device must also hold an Establishment Licence (“EL”) to do so. Compliance with that requirement has similarly not been prioritized until February 1, 2011. After that date the import or sale of a legacy system device without an EL will be prioritized for compliance as any other similar device (according to Policy 001 of the Health Product and Food Branch Inspectorate).

Neither servicing, maintenance nor use of a device is governed by these Regulations. Upgrading to a new version of the software, if the functionality, intended uses, or nomenclature of the system is altered, would be a “sale” of a medical device, and the new version would need to be licensed.

Is patient management software developed in-house by health care organizations subject to the Medical Devices Regulations?

Medical devices developed and used exclusively in-house by healthcare providers do not fall within the scope of the Regulations as they do not meet Section 2 of the regulations:

2. These Regulations apply to
(a) the sale and advertising for sale of a medical device; and
(b) the importation of a medical device for sale or for use on individuals, other than importation for personal use.

[Note: This answer was reviewed by Health Canada]

Is Middleware a Medical Device?

Note: Exact text provided by Health Canada.

For the purposes of this document, “middleware” is defined as follows:

“middleware” means a piece of software that connects two or more software applications so that they can exchange data. This includes software systems that facilitate the interaction of disparate components through a set of commonly defined protocols. The purpose is to limit the number of interfaces required for interoperability by allowing all components to interact with the Middleware using a common interface.

As defined above middleware would not fit the definition of a medical device.

Are COTS products Medical Devices?

COTS products (Commercial Off The Shelf) that are developed for general commercial use and are not specific to health care such as database applications, encryption applications, and web portal applications, are not considered medical devices, even when they are integrated into health information systems and infrastructures that process personal health information.

However, where COTS products such as databases and portals are integrated into a patient management software product that is classed as a Class II device, the patient management software manufacturer must verify and validate that the COTS product has been safely and effectively configured and integrated into the patient management software product.

[Note: This answer was reviewed by Health Canada]

Are EMRs Medical Devices?

NOTE - THIS POST IS NO LONGER VALID. HEALTH CANADA IS CHANGING ITS DEFINITION OF PATIENT MANAGEMENT SOFTWARE AND EMRS AND EHRS WILL NO LONGER BE CONSIDERED MEDICAL DEVICES. CLICK HERE FOR MORE INFO.

ITAC Health and MEDEC met with Health Canada by teleconference on Tuesday, August 10, 2010, to discuss issues surrounding Patient Management Software. One of the issues that required clarification was the question of whether or not Electronic Medical Records (EMRs) were Medical Devices under the Medical Devices Regulations. Health Canada clarified its interpretation as follows:

EMRs that are only intended to store and view patient information, and provide no analysis or decision support respecting diagnosis or treatment, do not fit the definition of a medical device (for example: the system captures and displays age, weight, notes about a patient’s appointment, patient test results, order processing, scheduling, or managing patient movement).

This would include software that would scan all of the patient records in a database, and based on some pre-determined criteria (age, gender, chronic diseases (diabetes, hypertension, heart disease), date of last test or immunization and combinations thereof), would flag to the physician, other heath care provider or admin staff to contact the patient and schedule the appropriate followup visit or test.

Such EMRs are not medical devices and do not require a medical device license unless they also perform one or more of the functions below and are used for diagnostic and/or treatment purposes.

EMRs are classed as Class II devices if they are used for the purpose of monitoring a physiological condition, state of health, illness or congenital deformity. This includes any patient management software involved in data manipulation, data analysis, data editing, image generation, determination of measurements, graphing, flagging of results, identifying a region of interest or performing calculations. Only software performing calculations that directly impact diagnosis and/or treatment of a patient merits a Class II designation.

For example:

1. An EMR that analyzes and provides the necessary information to flag drug interactions and patient allergies for a specific patient is a Class II device.

2. An EMR that receives and analyzes lab data for a specific patient and flags values that are out of the normal range is a Class II device.

There are few, if any, situations where an EMR will be classed as a Class I device. Health Canada is reviewing its definition of Class I devices to include only those devices that use real time data as an adjunct to a monitoring device for the purpose of aiding in treatment and/or diagnosis.

ITAC Health strongly recommends that if a manufacturer, vendor or distributor of an EMR has any doubt as to the appropriate classification of their product, that they contact Health Canada for a ruling. Be sure to maintain documentation of any advice provided by Health Canada on the classification of EMR products.

Patient Management Software Conference

ITAC Health and MEDEC invite you to an educational conference on Health Canada's recently released Patient Management Software Notice on Wednesday, September 8, 2010 in Toronto.

The conference is open to ITAC Health, MEDEC and COACH members and non-members.

Topics Include:

"Overview of Patient Management Software Notice and the Requirements for Licensing"
Sarah Chandler, Health Canada

"Customer Point of View" presentation and panel discussion
Neil Gardner, CIO, Saskatchewan Health
Lydia Lee, CIO, University Health Network Toronto
William Pascal, CTO, Canadian Medical Association

Vendor panel -- "The Good, the Bad and the Ugly of Navigating the Licensing Process"
Joe Whitney, MedManager
Laila Gurney, GE Healthcare

"Registrar's Outline on How to Prepare for ISO 13485:2003 CMDCAS"
Dion Goncalves, Intertek

Opportunity to network with others working through the process

Allstream Centre
Exhibition Place
105 Princes' Blvd.
Room 200 A/B/C, Toronto, ON M6K 3C3

For more information check out the ITAC Website.

Health Canada Revised Notice Posted

Health Canada's revised notice on licensing of patient management software can be found at the following URL's:

http://www.hc-sc.gc.ca/dhp-mps/md-im/update-miseajour/index-eng.php and
http://www.hc-sc.gc.ca/dhp-mps/md-im/activit/announce-annonce/index-eng.php

Health Canada Licensing Deadlines

We have just been notified by Health Canada that the revised notice concerning medical device licensing for patient management software will be issued very soon. In a nutshell, the deadline for obtaining establishment licenses for the sale of Class I medical devices is February 1, 2011. The deadline for obtaining medical device licenses for Class II devices is September 1, 2011. Health Canada is also preparing an FAQ which is not yet available.

ITAC Health encourages all members who manufacture, sell or distribute Class I or Class II patient management software to initiate the ISO 13485 certification and medical device licensing processes as soon as possible. Failure to obtain licenses by the deadlines noted above will mean that you will not be able to sell or distribute patient management software classified as Class I or Class II devices in Canada.

When the notice is available it will be posted at the following URLs.

http://www.hc-sc.gc.ca/dhp-mps/md-im/update-miseajour/index-eng.php and
http://www.hc-sc.gc.ca/dhp-mps/md-im/activit/announce-annonce/index-eng.php

ITAC Health and MEDEC form Collaboration

On April 5, ITAC Health and MEDEC formed a collaboration to advance healthcare through the use of health technology. The initial focus of the collaboration will be on ensuring that Canadian ICT and medical technology companies are aware of Health Canada’s announcement regarding regulations for patient management software, helping them to understand the medical device licensing process and representing the concerns of industry to Health Canada.

For more information, please see the following news release: ITAC Health and MEDEC collaboration.

Frequently Asked Questions About Patient Management Software Licensing

ITAC Health has published a guide in the form of an FAQ for ICT vendors who manufacture and sell patient management software in Canada. The FAQ includes more than 60 questions frequently asked by vendors and other health system stakeholders.

In responding to the questions, ITAC Health conducted a review of documentation published by Health Canada on its website, presentations by Health Canada officials, ISO 13485:2003 and various guides to ISO 13485:2003 published on the Internet. ITAC Health also interviewed officials from Health Canada, accredited registrars, Provincial Chief Information Officers (CIOs), CIOs from major health care organizations, and expert consultants.

Comments on a draft of this document were also provided by MEDEC members (Canada’s Medical Device Association) with experience working with Health Canada on the regulation of devices including devices that are stand alone software.

It is recommended that all ITAC member companies download and read this document as soon as possible.

Download FAQ on Patient Management Software Licensing.