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