Tuesday, November 16, 2010

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.


  1. Hi,

    My name is Abhijit and I have been following this blog closely. I believe the best standard so far for software process improvement is Capability Maturity Model Integration (CMMI) developed by Software Engineering Institute (SEI) at Carnegie Melon University. This standard has been accepted globally and addresses the specific needs of the software industry.

    I believe ISO 13485, ISO 9001 etc. are very manufacturing-specific and do not address the specific needs of the software industry that well. ISO has generated a number of guidelines to help software companies tailor these generic standards to the software industry, something I believe works at a high and superficial level. This is where CMMI beats ISO.

    CMMI is an organizational maturity model and not just a software process model. It has got five maturity levels:

    Level 1 - Basic (no planning)
    Level 2 - Managed (some planning and management aspects involved)
    Level 3 - Defined (practices defined at the org-level)
    Level 4 - Quantitatively Managed (numerical analysis brought into day-to-day operations)
    Level 5 - Optimizing (causal analysis and continual improvement)

    Most firms in North America choose to get certified at Level 3. Most firms in India get certified on Level 5 because it is more of a business mandate there. CMMI implementation is stringent, and once the certification is achieved, ISO models are more or less subsets of this standard.

    CMMI has a Risk Management process area which does not specifically address patient-health risks. This is where the ISO 14971 model should be used as a guideline.

    Also, the ISO 27001 model should be used for Information Security and Risk Management because it focusses on numerical assessment of various risks and security threats. It addresses aspects such as CIAL - Confidentiality, Integrity, Availability, and Legality, and also aspects such as Vulnerability, Threat and Probability.

    I believe CMMI, ISO 14971 and ISO 27001 used together would yield much better results and bring true value to Canadian software companies, and make them ready for expansion into other markets that demand these standards as prerequisites during the bidding process.


  2. Via email from Michael Whitt,

    There is another aspect within the Operations Risk arena, which I think of as a sort of migration/learning/implementation risk: the design and implementation of CPOE (and similar automation of evidence-based best-practice processes) by the end-user into an EMR. This sometimes takes place with no or next-to-no vendor involvement, and can involve very little internal IT resource, coming as it does under the auspice (generally) of "practice of medicine".
    Stand by for "expert systems"…