Importante pasar a la norma IEC 62304:2006/A1:2015.

Tiene cambios entre otras cosas en la

clasificación. Aplicando a la clasificación los mecanismos de control de riesgos externos al software, es
decir del diseño del hardware, si podemos calificar todos los riesgos como aceptables podríamos
englobarlo como Class A, sino iríamos al Class B. Tiene importantes repercusiones a nivel documental

IEC 62304 Amd1 2015

Definitions
The definitions of software safety classes were totally reworded:

 The SOFTWARE SYSTEM is software safety class A if:

o the SOFTWARE SYSTEM cannot contribute to a HAZARDOUS SITUATION; or
o the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which
does not result in unacceptable RISK after consideration of RISK CONTROL
measures external to the SOFTWARE SYSTEM.

 The SOFTWARE SYSTEM is software safety class B if:

o the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which
results in unacceptable RISK after consideration of RISK CONTROL measures
external to the SOFTWARE SYSTEM and the resulting possible HARM is non-
SERIOUS INJURY.

 The SOFTWARE SYSTEM is software safety class C if:

o the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which
results in unacceptable RISK after consideration of RISK CONTROL measures
external to the SOFTWARE SYSTEM and the resulting possible HARM is death or
SERIOUS INJURY.

Flowchart
These definitions are accompanied by a flowchart, which explains at a glance the selection of safety
class.
The questions can be mapped to the above definitions:

 Answering 'No' to Question 1 = First bullet of definition of class A,

 Answering 'No' to Question 2 = Second bullet of definition of class A,
 Answering 'Yes' to Question 1 and 2 = first part of the definition of class B and class C (the
common part, before the words "and the resulting..."),
 Answering 'Non serious injury' to Question 3 = definition of class B,
 Answering 'Serious injury' to Question 3 = definition of class C.

Here is a snapshot of the flowchart found in section 4.3 of IEC 62304 Amd1 2015:
Consequence
The consequence of these definitions is the introduction of the acceptability of risks in the
assessment of software safety class:

 IEC 62304:2006: severity only

 IEC 62304:Amd1:2015: severity and risk acceptability.

Using the same legend as in the previous matrix, the software safety classes areas can be
represented like this:
The class A region can be extended to the upper side of the matrix. This is possible thanks to the
sentence in bold in the definition of class A written above. In our example, the cell (critical,
improbable) sees its corresponding software safety class set to class A, hence the risk is acceptable.

The software development process is divided into a set of activities, with most activities further divided
into a set of tasks. These activities are listed below:

 Software Development Planning

 Software Requirement Analysis

 Software Architectural Design

 Software Detailed Design

 Software Unit Implementation &Verification

 Software Integration and Integration testing

 Software System Testing

 Software Release.

The maintenance process activities are considered to be as important as the software development
process activities. These activities include:

 Generate Software Maintenance Plan

 Problem and Modification Analysis

Actividades para el desarrollo de software de dispositivos médicos

El fabricante establecerá un plan de desarrollo. Determinará en el mismo las actividades del proceso de
desarrollo, el campo de aplicación, la magnitud de tales actividades y las clasificaciones de
seguridad que asignará a los productos.
A continuación, el desarrollo del software médico se lleva a cabo en las siguientes etapas:
 Plan de desarrollo
Se debe establecer un plan de desarrollo software apropiado al campo de aplicación, magnitud, y
clasificaciones de seguridad del sistema. La metodología a aplicar debe estar completamente descrita:
especificando personal, tareas a realizar y criterios de aceptación para cada una de las etapas.
 Análisis de requisitos del software.
Deben quedar reflejados los requisitos exigibles al sistema a nivel funcional, tecnológico, informático,
regulatorio y de seguridad e integridad de datos.
 Diseño arquitectónico del software.
Es necesario especificar los elementos que componen el sistema para satisfacer el proceso a realizar. La
definición se enfocará tanto a nivel de componentes industriales, como elemento hardware y software.
 Diseño detallado del software.
Se debe desarrollar y documentar un diseño detallado por cada unidad de sistema informatizado
implementado.
 Implementación y verificación de la unidad software.
Conforme al plan de desarrollo establecido se debe verificar cada unidad de sistema informatizado
mediante ensayos con el fin de evaluar el cumplimiento de los requisitos exigidos.
 Integración de software y ensayos de integración.
Conforme al plan de desarrollo se debe verificar cada unidad de sistema informatizado mediante
ensayos. Es esta etapa se evaluará la integración de todos los componentes del sistema conforme al
diseño arquitectónico establecido y la integración de todos los elementos industriales, hardware y
software con operaciones manuales.
 Ensayos del sistema de software.
Conforme al plan de desarrollo, verificación de la operación del sistema. La estrategia de verificación
debe establecer y realizar un conjunto de ensayos, expresados como estímulos de entrada, resultados
esperados, criterio de procedimientos de pasa/falla.
 Liberación de software.
Asegura que el proceso de verificación ha sido completado y los resultados se han evaluado antes de
liberar el software.

Proceso de mantenimiento del software

El fabricante diseñará e implementará un plan de mantenimiento del software (o diversos planes, de
ser necesario), en el que detallará todas las actividades, tareas, procesos y sub-procesos que se deben
llevar a cabo. Estas actividades de mantenimiento tendrán lugar básicamente en tres etapas:
 Establecimiento del plan de mantenimiento.
 Análisis de problemas y modificaciones.
 Implementación de modificaciones.
El detalle de cada una de las actividades a realizar en estas tres etapas lo encontramos en el capítulo 6
de UNE-EN 62304.