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.