Guía definitiva de software como

dispositivo médico (SaMD)

Ha pasado más de una década desde que Marc Andreesen escribió que "el software se está
comiendo el mundo". Desde entonces, el software se ha abierto camino en prácticamente todas
las industrias, agregando nuevas comodidades y nuevas capas de complejidad a la producción y
distribución de millones de productos.

La industria de productos sanitarios no es una excepción. Inicialmente, el software se usaba para

controlar los dispositivos de hardware. Pero no pasó mucho tiempo antes de que la gente
comenzara a diseñar soluciones de software sin ninguna relación directa con los equipos de
hardware. Estos productos, aunque no se parecen en nada a los productos sanitarios
tradicionales, aún tienen el potencial de mejorar la calidad de vida de los pacientes en todas
partes.

Sin embargo, todavía están clasificados como productos sanitarios por los organismos
reguladores de todo el mundo. Los conocemos como software como dispositivo médico (SaMD),
y en esta guía, quiero ayudar a desmitificar estos dispositivos y ofrecerle información sobre
cómo están regulados y qué puede esperar cuando se dispone a construir uno.
Comencemos por el principio.
Tabla de contenido
SOFTWARE COMO DISPOSITIVO MÉDICO (SAMD). VISIÓN GENERAL ..........................4
¿Qué es el Software como dispositivo Médico (SAMD)?.................................................... 4
¿Cómo sé si mi producto es un SAMD? ............................................................................. 4
¿Mi software se considera SaMD o SiMD? ........................................................................ 5
¿Cuáles son algunos ejemplos de SaMD? .......................................................................... 6
NORMATIVA GLOBAL................................................................................................6
¿Cómo se regula el SaMD en todo el mundo? ................................................................... 7
Lo que necesita saber sobre la regulación de SaMD en los EE. UU. .................................... 7
Lo que necesita saber sobre la regulación de software de dispositivos médicos en la UE.... 8
CLASIFICACIÓN .........................................................................................................8
¿Cómo se clasifica SaMD en los mercados regulatorios globales? ...................................... 9
Clase de riesgo SaMD y "Niveles de preocupación" en los EE. UU. ..................................... 9
Clase de riesgo de software de dispositivos médicos y "Regla 11" en la UE ........................ 9
Categorización de SaMD según IMDRF ........................................................................... 10
Clasificación de seguridad del software según IEC 62304................................................. 10
DESARROLLO DE SOFTWARE ...................................................................................11
Desarrollo de Software SaMD ........................................................................................ 11
IEC 62304 - Requisitos del ciclo de vida ........................................................................... 12
Proceso de desarrollo de software ................................................................................. 12
Proceso de mantenimiento de software ......................................................................... 13
Proceso de gestión de riesgos de software ..................................................................... 13
Proceso de gestión de configuración de software ........................................................... 13
Proceso de resolución de problemas de software ........................................................... 14
Validación de software para el desarrollo de SaMD ........................................................ 14
CIBERSEGURIDAD ...................................................................................................15
Ciberseguridad y SaMD .................................................................................................. 15
Lista de materiales de software (SBOM) para software como producto sanitario ............. 15
Regulaciones, orientación y recursos de seguridad cibernética ........................................ 16
REQUISITOS POST-COMERCIALIZACIÓN ...................................................................18
Requisitos Posteriores a la Comercialización para SaMD ................................................. 18
¿Cuándo requiere un SaMD un nuevo envío? ................................................................. 18
Realización de cambios en SaMD en los EE. UU. .............................................................. 18
 Realización de cambios en SaMD en la UE ...................................................................... 20
Inteligencia artificial y aprendizaje automático en SaMD ................................................ 21
CONSIDERACIONES FINALES ....................................................................................23
Reflexiones finales sobre el software como producto sanitario ....................................... 23
 SOFTWARE COMO DISPOSITIVO MÉDICO (SAMD). VISIÓN GENERAL

¿Qué es el Software como dispositivo Médico (SAMD)?

El Foro Internacional de Reguladores de Dispositivos Médicos (IMDRF) define SaMD como
"software destinado a uno o más fines médicos que realizan esos fines sin ser parte de un
dispositivo médico de hardware".

La FDA define SaMD como "Software que cumple con la definición de un dispositivo en 181
sección 201 (h) de la Ley FD&C y está destinado a ser utilizado para uno o más fines médicos
sin ser parte de un dispositivo de hardware".

Si bien estas definiciones son un excelente punto de partida, hay muchos matices sobre qué es
exactamente SaMD y cómo saber si su producto es SaMD. Entonces, echemos un vistazo más
de cerca a qué es el software como dispositivo médico, qué no es y cómo puede averiguar si su
producto se ajusta a la definición.

¿Cómo sé si mi producto es un SAMD?

La FDA es miembro de la IMDRF y está claro que ambas definiciones de SaMD comparten
una estructura similar. De acuerdo con las definiciones de la FDA y la IMDRF, hay dos
puntos que deben cumplirse para que el software alcance el estado de SaMD.

Para comenzar, debemos considerar si el software se puede caracterizar como un

dispositivo médico. La IMDRF simplemente establece que debe estar "destinado a uno
o más fines médicos", mientras que la FDA hace referencia específica a la definición de
un dispositivo en la sección 181 201 (h) de la ley FD&C, que establece que un dispositivo
es:

Un instrumento, aparato, implemento, máquina, dispositivo, implante, reactivo in vitro

u otro artículo similar o relacionado, incluido un componente o accesorio que es:

1. Reconocido en el Formulario Nacional oficial, o la Farmacopea de los Estados

Unidos, o cualquier suplemento a ellos,
2. Destinado a ser utilizado en el diagnóstico de enfermedades u otras condiciones,
o en la cura, mitigación, tratamiento o prevención de enfermedades, en el
hombre u otros animales, o
3. Destinado a afectar la estructura o cualquier función del cuerpo del hombre o de
otros animales, y que no logra los propósitos primarios previstos a través de la
acción química dentro o sobre el cuerpo del hombre o de otros animales y

que no logra sus propósitos primarios a través de la acción química dentro o sobre el
cuerpo del hombre o de otros animales y que no depende de ser metabolizado para el
logro de sus propósitos primarios. El término "dispositivo" no incluye funciones de
software excluidas conforme a la sección 520(o).

Para utilizar correctamente esta definición, debe definir el uso previsto de su producto
y sus indicaciones de uso. Como repaso:
 • El uso previsto es el propósito de su dispositivo. Es para lo que se utilizará su
dispositivo.
• Las indicaciones de uso son las enfermedades o condiciones que su dispositivo
diagnosticará, tratará, evitará, curará o mitigará. Las indicaciones de uso
describen quién usará su dispositivo y por qué .

Una vez que haya definido estos usos, los puntos dos y tres en la definición de dispositivo
médico de la FDA deberían dejar bastante claro si su producto será regulado como un
dispositivo médico.

Si planea comercializar su producto de software en los EE. UU., le recomiendo que lea
detenidamente esta guía de la FDA sobre la política para funciones de software de
dispositivos y aplicaciones médicas móviles. Esta guía ofrece posturas claras sobre qué
funciones de software considera la FDA como un dispositivo médico, así como aquellas
que no considera dispositivos médicos o aquellas que no regula como tales.

Sin embargo, si aún no está seguro de si su producto es un dispositivo médico, lo mejor

que puede hacer es comunicarse directamente con la FDA.

¿Mi software se considera SaMD o SiMD?

Supongamos que ha determinado que su producto cumple con la definición de dispositivo
médico. Aún debe considerar la segunda mitad de las definiciones de SaMD de IMDRF y FDA.

• La definición de IMDRF nos dice que el software debe realizar sus propósitos “sin ser
parte de un dispositivo médico de hardware”.
• La FDA usa casi exactamente el mismo lenguaje, afirmando que SaMD “está destinado
a ser utilizado para uno o más fines médicos sin ser parte de un dispositivo de hardware”

Esto vuelve a reducir el alcance de SaMD. El software que se utiliza para alimentar el hardware
o controlar un dispositivo de hardware no cumple con los criterios de SaMD.

En cambio, ese tipo de software es lo que se conoce como SiMD, o "software en un dispositivo
médico".

En pocas palabras, cualquier software que ayude a ejecutar un dispositivo médico de hardware,
por ejemplo, potenciando su mecánica o produciendo una interfaz gráfica, es software en un
dispositivo médico. Algunos ejemplos incluyen:

• Software que controla el inflado o desinflado de un manguito de presión arterial

• Software que controla la administración de insulina en una bomba de insulina
• Software utilizado en un control de bucle cerrado de un marcapasos

Estos tipos de software también se conocen como "software integrado" de "firmware" o

"microcódigo", por lo que si escucha esos términos, sepa que indican SiMD, no SaMD.

Para que un producto se clasifique como SaMD, el software debe ser independiente de cualquier
hardware, ya que realiza las funciones que lo clasifican como dispositivo médico. La guía de
IMDRF sobre el posible marco para la categorización de riesgos y las consideraciones
correspondientes agrega varios puntos de aclaración a la definición de SaMD:
 • SaMD es un dispositivo médico e incluye un dispositivo médico de diagnóstico in vitro
(IVD).
• SaMD es capaz de ejecutarse en plataformas informáticas de uso general (propósito no
médico).
• “sin ser parte de” significa software que no es necesario para que un dispositivo médico
de hardware logre su propósito médico previsto.
• El software no cumple con la definición de SaMD si su propósito previsto es controlar un
dispositivo médico de hardware.
• SaMD se puede usar en combinación (p. ej., como un módulo) con otros productos,
incluidos los dispositivos médicos.
• SaMD se puede interconectar con otros dispositivos médicos, incluidos dispositivos
médicos de hardware y otro software de SaMD, así como software de propósito general.
• Las aplicaciones móviles que cumplen con la definición anterior se consideran SaMD.

NOTA: Si bien es importante diferenciar entre SaMD y SiMD, los dos tipos de software
comparten muchos de los mismos estándares de desarrollo, como IEC 62304, el estándar
internacional para los procesos del ciclo de vida del software. Si su software es realmente SiMD,
aún encontrará útiles muchos de los documentos de orientación y estándares en esta guía.

¿Cuáles son algunos ejemplos de SaMD?

La teoría es una cosa, pero a menudo es más fácil captar ejemplos reales. Revisaré algunos
ejemplos de SaMD aquí, pero puede encontrar más en la misma guía de IMDRF sobre la
clasificación de riesgos mencionada anteriormente:

• Software que permite que un dispositivo móvil vea imágenes de una resonancia
magnética, una ecografía o una radiografía que se utilizan con fines de diagnóstico
• Software que procesa imágenes para ayudar a detectar el cáncer de mama
• Software que diagnostica una condición utilizando el acelerómetro triaxial en un
teléfono inteligente
• Software que recopila datos de pacientes en tiempo real que es monitoreado por un
profesional médico y se usa para desarrollar planes de tratamiento.

Además, aquí hay algunos ejemplos del mundo real de clientes de Greenlight Guru cuyos
productos están categorizados como SaMD.

• Avatar Medical crea imágenes en 3D de pacientes en función de sus imágenes médicas

para ayudar a los cirujanos a visualizar mejor las imágenes.
• BrainKey usa resonancias magnéticas para crear una imagen 3D de su cerebro que
puede rastrear con el tiempo a medida que obtiene más resonancias magnéticas.
• Brain+ es una aplicación que trata la demencia mediante estimulación cognitiva.
• El software de Cloud of Care utiliza IA para aumentar la certeza y la eficiencia de las
lecturas de EEG a largo plazo en la epilepsia.

NORMATIVA GLOBAL
¿Cómo se regula el SaMD en todo el mundo?
Si bien hay muchos mercados para productos sanitarios en todo el mundo, EE. UU. y la UE son,
con mucho, los más grandes, por lo que estos son los mercados en los que nos centraremos en
esta sección.

El primer punto que quiero señalar es que un producto SaMD sigue siendo un producto
sanitarios y está regulado como tal.

Para empezar, se necesitará un sistema de gestión de calidad (SGC). En los EE. UU., debe seguir
las Regulaciones del sistema de calidad (QSR) de la FDA. Asimismo, en la UE, su SaMD se regirá
por el EU MDR (o EU IVDR si se trata de un dispositivo de diagnóstico in vitro). Y, por último, su
producto seguirá estando clasificado de acuerdo con la normativa aplicable en cualquiera de los
mercados.

Básicamente, vale la pena recordar que, si bien su SaMD puede ser significativamente diferente
de un producto sanitario de hardware tradicional, aún debe seguir las mismas regulaciones que
cualquier otro producto sanitario.

Con eso en mente, entremos en algunos de los matices de los panoramas regulatorios de SaMD
en los EE. UU. y la UE

Lo que necesita saber sobre la regulación de SaMD en los EE. UU.

La FDA reconoce que sus reglamentaciones sobre productos sanitarios se escribieron teniendo
en cuenta los productos sanitarios tradicionales, por lo que desde entonces han publicado
documentos de orientación específicos para el software en áreas como presentaciones previas
a la comercialización.

Su primera guía sobre presentaciones previas a la comercialización para SaMD se publicó en

2005. Si le parece que podría estar un poco anticuado, no está equivocado. Es por eso que la
FDA redactó una nueva guía para presentaciones previas a la comercialización para SaMD en
2021.

Aquí es donde las cosas se ponen complicadas. Tanto la guía actual como el borrador de la guía
enumeran la documentación que debe enviar en función del uso previsto de su SaMD.

Sin embargo, la guía actual (de 2005) divide SaMD en tres categorías, conocidas como "niveles
de preocupación", que se basan en la gravedad de la lesión que podría surgir de la falla del
dispositivo o fallas de diseño:

• Menor: es poco probable que los fallos o los defectos de diseño latentes causen lesiones
al paciente o al operador

• Moderado: los fallos o los defectos de diseño latentes podrían provocar directamente
lesiones menores al paciente o al operador, incluso a través de información retrasada o
incorrecta o a través de las acciones de un proveedor

• Mayor: los fallos o los defectos de diseño latentes podrían provocar directamente la
muerte o lesiones graves al paciente o al proveedor, incluso a través de información
retrasada o incorrecta o a través de las acciones de un proveedor.
El documento de orientación actual después especifica que la documentación que deberá enviar
se basa en el nivel de preocupación bajo el cual se encuentra su dispositivo. Tenga en cuenta
que el "nivel de preocupación" no es lo mismo que la clase de riesgo de su dispositivo.

Ahora veamos el borrador de la guía. En este caso, los tres niveles de preocupación han sido
reemplazados por dos niveles de documentación:

• Documentación básica
• Documentación mejorada

Como se puede imaginar, esto ha causado cierta confusión. No sabemos cuándo se finalizará el
borrador de la guía o incluso cómo se verá la nueva guía hasta que se haya finalizado. Entonces,
mientras tanto, le recomiendo que indique tanto su nivel de preocupación como si su dispositivo
requiere documentación básica o mejorada.

Eso puede sonar oneroso, pero la verdad es que el borrador de la guía y la guía publicada
requieren documentación similar, solo clasifican SaMD de manera diferente. Por lo tanto, la
documentación que recopile para una guía probablemente será la documentación que necesita
para la otra.

Si no está seguro de en qué categoría se encuentra su SaMD en cualquiera de las guías, sería
cauteloso y enviaría la documentación requerida para el nivel superior

Lo que necesita saber sobre la regulación de software de dispositivos médicos

en la UE
La regulación de SaMD en la UE es similar a la regulación en los EE. UU., ya que no difiere de la
forma en que se regulan los dispositivos médicos tradicionales. Aún deberá cumplir con todos
los requisitos relevantes en EU MDR y EU IVDR.

Sin embargo, es importante tener en cuenta que las reglamentaciones de la UE no utilizan el

término "software como dispositivo médico". Más bien, utilizan el término "software de
dispositivo médico" o MDSW para abreviar.

Afortunadamente, la Comisión Europea (CE) ha publicado varios documentos de orientación

relevantes para los fabricantes de SaMD.

• MDCG 2021-24 - Orientación sobre la clasificación de dispositivos médicos

• Infografía: ¿su software es un dispositivo médico?
• MDCG 2020-1: orientación sobre evaluación clínica y evaluación del rendimiento del
software de dispositivos médicos
• MDCG 2019-16 - Orientación sobre ciberseguridad para dispositivos médicos
• MDCG 2019-11 - Cualificación y clasificación de software

Me referiré a algunos de estos más adelante en la guía, pero por ahora, lo animo a que lea o al
menos marque estos recursos para una fácil referencia. Los encontrará inmensamente útiles,
especialmente si se pregunta si su software cumple con la definición de software de dispositivo
médico en la UE.

CLASIFICACIÓN
¿Cómo se clasifica SaMD en los mercados regulatorios globales?
Hasta ahora, hemos aprendido acerca de las reglamentaciones, la orientación y los estándares
internacionales que se aplican a SaMD.

Desafortunadamente, EE. UU. y la UE no solo tienen diferentes categorías de riesgo para

dispositivos médicos, sino que IMDRF e IEC 62304 también contienen métodos para categorizar
SaMD. Esto puede volverse confuso rápidamente, así que usemos esta sección para desglosar
cada categoría y clase y cómo se relacionan entre sí.
Clase de riesgo SaMD y "Niveles de preocupación" en los EE. UU.

Primero, tenemos el sistema estadounidense para clasificar SaMD. La FDA clasifica SaMD
utilizando las mismas clases de riesgo que los dispositivos médicos tradicionales: Clase I, Clase II
y Clase III.

Solo para reiterar, aunque tendrá que elegir un "nivel de preocupación" para su presentación
previa a la comercialización a la FDA, esto no determina su clase de riesgo. El nivel de
preocupación simplemente le indica la documentación que requerirá su presentación previa a
la comercialización. Si bien puede estar fuertemente relacionado con la clase de riesgo, su nivel
de preocupación no se usa para determinar la clasificación de riesgo de su dispositivo.

Clase de riesgo de software de dispositivos médicos y "Regla 11" en la UE

Al igual que con los EE. UU., no existe una clasificación de riesgo específica de MDSW en la UE.
El software de dispositivos médicos utiliza la misma clasificación de riesgo que los dispositivos
médicos tradicionales: clase I, clase IIa, clase IIb y clase III.

Pero el MDR de la UE tiene un esquema de cómo debe proceder para determinar la clase de
riesgo del software de su dispositivo médico, identificado como Regla 11.

La Regla 11, que se puede encontrar en el Anexo VIII de EU MDR , establece:

El software destinado a proporcionar información que se utiliza para tomar decisiones con fines
diagnósticos o terapéuticos se clasifica en la clase IIa, excepto si dichas decisiones tienen un
impacto que puede causar:

• la muerte o el deterioro irreversible del estado de salud de una persona, en cuyo caso
se incluye en la clase III; o

• un deterioro grave del estado de salud de una persona o una intervención quirúrgica,
en cuyo caso se clasifica en la clase IIb.

El software destinado a monitorear procesos fisiológicos se clasifica como clase IIa, excepto si
está destinado a monitorear parámetros fisiológicos vitales, donde la naturaleza de las
variaciones de esos parámetros es tal que podría resultar en un peligro inmediato para el
paciente, en cuyo caso es clasificado como clase IIb.

Todo el resto del software se clasifica como clase I.

La CE ha desarrollado la Regla 11 y su proceso de clasificación en MDCG 2021-24 y MDCG 2019-
11 . Sin embargo, como habrá notado al leer la Regla 11, la mayoría del software de dispositivos
médicos se clasificará como mínimo en la clase IIa según la regla.

Categorización de SaMD según IMDRF

La IMDRF también ha publicado una guía sobre la categorización de SaMD . Lo que notará de
inmediato cuando lea este documento es que la categorización IMDRF tiene cuatro categorías
posibles, en lugar de tres, y requiere una tabla para ayudarlo a identificar en qué categoría se
encuentra su dispositivo.

Esta tabla es bidimensional y requiere la identificación tanto de la situación o condición como

de la importancia de la información proporcionada por el SaMD.
Estado de la situación Importancia de la información proporcionada por SaND para la decisión de
o condición de atención médica
atención médica Tratamiento o diagnóstico Impulsar gestión clínica Informar gestión clínica
Crítico IV III II
Serio III II I
No-serio II I I
"Software como dispositivo médico": posible marco para la categorización de riesgos y las consideraciones
correspondientes, IMDRF

Actualmente, la categorización IMDRF no se usa mucho, probablemente porque parece agregar

una segunda capa confusa a la clasificación SaMD. Sin embargo, la categorización IMDRF puede
ser útil para ayudar a determinar su clase de riesgo en la UE, y para eso la utilizan la mayoría de
las empresas.

Uno de los documentos de orientación de la UE antes mencionados, MDCG 2019-11, incluye una
tabla que combina la categorización IMDRF y las clases de riesgo de la UE.

Importancia de la información proporcionada por el MDSW para una situación

de atención médica relacionada con el diagnóstico/terapia
Estado de la Alto Medio Bajo
situación o Tratamiento o Impulsa la gestión Informa gestión
condición de diagnóstico clínica clínica
IMDRF 5.1.1 IMDRF 5.1.2 (todo lo demás)
atención médica
Situación o estado Clase III Clase IIb Clase IIa
del paciente crítico Categoría IV.i Categoría III.i Categoría II.i
IMDRF 5.2.1
Situación o estado Clase IIb Clase IIa Clase IIa
del paciente seria Categoría III.ii Categoría II.ii Categoría I.ii
IMDRF 5.2.2
Situación o estado Clase IIa Clase IIa Clase IIa
del paciente No Categoría II.iii Categoría I.iii Categoría I.i
seria
Todo lo demás
Tabla 1: Guía de clasificación sobre la Regla II, MDCG 2019-11

Por lo tanto, si tiene la intención de vender su dispositivo en la UE, la categorización IMDRF

puede ser una herramienta útil para ayudarlo a determinar la clase de riesgo de su SaMD.

Clasificación de seguridad del software según IEC 62304

Finalmente, tenemos la clasificación de seguridad del software de IEC 62304, el estándar
internacional sobre procesos del ciclo de vida del software. Profundizaré en IEC 62304 más
adelante en esta guía, pero por ahora quiero centrarme en su sistema de clasificación.

El sistema de clasificación IEC 62304 tiene tres niveles basados en la gravedad de la lesión que
podría causar una falla de software:

• Clase A - sin lesiones

• Clase B - lesión no grave
• Clase C: lesiones graves o muerte

NOTA: La clasificación de seguridad del software no determina qué tan seguro es su software.
En cambio, es la base para determinar qué tan riguroso debe ser su proceso de desarrollo de
software.

La seguridad real de su dispositivo depende de sus procesos de diseño y desarrollo, no de una

clasificación de seguridad.

Algo que debe tener en cuenta es que su clasificación de seguridad según IEC 62304 no se
corresponde directamente con la clasificación de riesgo según las regulaciones de EE. UU. o la
UE. Sin embargo, la clasificación de seguridad tiene una fuerte correlación con la clase de riesgo.

Por ejemplo, si su clasificación de seguridad es de clase C, es muy probable que su dispositivo

sea de clase III (para EE. UU. o la UE). Pero posiblemente podría tener un dispositivo que sea de
clase de seguridad C, pero que caiga en una clase de riesgo más baja.

El punto es que el sistema de clasificación IEC 62304 se trata de seguridad, pero solo indica el
nivel de rigor que debe usar durante el desarrollo de software. No es un proxy perfecto para la
clasificación de riesgos y no le dice nada sobre la seguridad real de un SaMD terminado.

Si todavía estás conmigo, entonces date una palmadita en la espalda. Esto es complicado, pero
dependiendo de dónde planee comercializar su dispositivo, es posible que deba comprender
cómo usar cada uno de estos métodos de clasificación.

Quizás la conclusión más importante aquí es que nunca debe asumir que un método de
clasificación, como el nivel de preocupación o la clase de seguridad del software, se
corresponderá directamente con otro

DESARROLLO DE SOFTWARE

Desarrollo de Software SaMD

Empiece a hablar sobre el desarrollo de software en el mundo de los dispositivos médicos y es

probable que escuche muchas opiniones puntiagudas.

La gran razón de esto es simple. Muchos reglamentos, como el QSR de la FDA, se escribieron
teniendo en cuenta los dispositivos médicos de hardware tradicionales. Como tales, asumen un
estilo muy lineal de desarrollo de productos, en el que se realiza una tarea antes de pasar a la
siguiente. Esto se conoce generalmente como la metodología en cascada, y debido a que las
normas y estándares como IEC 62304 están escritos de esta manera, causa mucha angustia entre
los desarrolladores de software.

La mayoría de los desarrolladores de hoy utilizan una metodología ágil, un enfoque más flexible
basado en un ciclo continuo de iteración. Además de eso, muchas empresas emergentes de
SaMD no provienen del mundo de los dispositivos médicos tradicionales. Como resultado,
muchos de estos equipos piensan que es imposible aplicar una metodología ágil en el desarrollo
de dispositivos médicos basada en la normativa actual.

Así que déjame dejar las cosas claras aquí y ahora. Sí, las regulaciones están escritas en un estilo
lineal que se sigue fácilmente con un enfoque en cascada. Sin embargo , todavía es muy posible
utilizar el desarrollo ágil de productos y seguir manteniendo el cumplimiento de todas las
normas y estándares pertinentes.

Por ejemplo, cuando observa por primera vez IEC 62304, notará que tiene una estructura muy
lineal. Pero aún es posible cumplir con sus requisitos utilizando el desarrollo ágil de productos.
De hecho, existe otro estándar AAMI TIR 45 que ofrece orientación sobre el uso de prácticas
ágiles en el desarrollo de software para dispositivos médicos.

Con eso fuera del camino, echemos un vistazo más de cerca a IEC 62304 y cómo se usa en el
desarrollo de SaMD.

IEC 62304 - Requisitos del ciclo de vida

IEC 62304 es un estándar de proceso, a diferencia de un estándar de producto. No le dirá los

requisitos específicos para su producto. En su lugar, ofrece un método para estructurar sus
procesos que dará como resultado un software seguro y eficaz, si se lleva a cabo correctamente.

Después de los requisitos generales, IEC 62304 explica los cinco procesos que deberá seguir
durante el ciclo de vida de su software:

1. Proceso de desarrollo de software

2. proceso de mantenimiento de software
3. Proceso de gestión de riesgos de software
4. Proceso de gestión de la configuración del software
5. Proceso de resolución de problemas de software

Proceso de desarrollo de software

El proceso de desarrollo de software, según IEC 62304, comienza con la planificación del
desarrollo de software y finaliza con el lanzamiento del software. Entre esos puntos, deberá
llevar a cabo una serie de pasos esenciales, que incluyen:

• Análisis de requisitos de software

• diseño de arquitectura de software
• Implementación y verificación de la unidad de software
• Integración de software y pruebas de integración.
• Pruebas de sistemas de software
Sin embargo, una vez que se ha lanzado el software, de ninguna manera habrá terminado con
sus responsabilidades. Recuerde, IEC 62304 es un estándar de ciclo de vida del software, lo que
significa que deberá mantener el software y resolver los problemas a medida que surjan.

Proceso de mantenimiento de software

IEC 62304 enumera los requisitos para un proceso de mantenimiento de software. Estos
requisitos serán muy similares a los requisitos de manejo de quejas de ISO 13485 y FDA 21 CFR
Parte 820.

El proceso de mantenimiento de software descrito en IEC 62304 consta de tres partes:

• Establecimiento de su plan de mantenimiento de software

• Análisis de problemas y modificaciones.
• Implementando modificaciones

SUGERENCIA: estudie su proceso de manejo de quejas existente antes de crear un nuevo

proceso para el mantenimiento del software. Es posible que ya haya mucha superposición entre
los dos, y es posible que no necesite dos procesos separados.

Proceso de gestión de riesgos de software

Si está llegando a IEC 62304 con antecedentes en la fabricación de dispositivos médicos,

entonces el proceso de gestión de riesgos de software que describe le resultará bastante
familiar. Esto se debe a que los requisitos de gestión de riesgos de la norma IEC 62304 se
correlacionan con los de la norma ISO 14971, la norma internacional sobre la aplicación de la
gestión de riesgos a los dispositivos médicos.

Y recuerde, se espera que los fabricantes de SaMD sigan la norma ISO 14971, al igual que
cualquier otro fabricante de dispositivos médicos.

Notará rápidamente la conexión entre los requisitos de ISO 14971 y los de IEC 62304, tales como:

• Un análisis del software que contribuye a situaciones peligrosas

• Medidas de control de riesgos
• Verificación de las medidas de control de riesgos
• Gestión de riesgos de cambios de software.

Tenga en cuenta que el hecho de que la gestión de riesgos tenga su propia sección no significa
que no sea relevante para otros procesos. De hecho, el propio proceso de desarrollo de software
puede utilizarse como medida de control de riesgos cuando se lleva a cabo de acuerdo con IEC
62304.

Proceso de gestión de configuración de software

La configuración del software es como la contabilidad de su software. Está realizando un

seguimiento de todo lo que necesitaría para recrear el software, que es fundamental para la
trazabilidad y la gestión de versiones.

Los requisitos establecidos en IEC 62304 incluyen:

 • Identificación de configuración
• Cambio de control
• Reporte del estado de configuración

Muchas empresas utilizan una matriz de configuración para ayudarse con la gestión de la
configuración. Esta matriz combina los elementos de software que desea controlar y cuándo se
lanzaron en una tabla práctica, como la que se ilustra a continuación.

Proceso de resolución de problemas de software

El término "proceso de resolución de problemas de software" es un poco inapropiado, porque

implica que necesita un proceso de resolución de problemas. En realidad, necesitará varios
procesos de resolución de problemas diferentes porque encontrará diferentes tipos de
problemas a lo largo del ciclo de vida del software.

IEC 62304 establece un esquema general para un proceso de resolución de problemas:

• Preparar informes de problemas

• Investigar los problemas
• Asesorar a las partes relevantes
• Usar el proceso de control de cambios
• Mantener registros
• Analizar problemas en busca de tendencias.
• Verificar la resolución de problemas de software
• Contenido de la documentación de prueba

Como regla general, es probable que encuentre menos problemas con el tiempo a medida que
su producto madure. Sin embargo, es probable que la gravedad de los problemas que encuentre
más adelante sean más graves y requerirán un proceso más riguroso para su resolución.

Validación de software para el desarrollo de SaMD

De acuerdo con las Regulaciones del Sistema de Calidad de la FDA,

Cuando se utilicen computadoras o sistemas automatizados de procesamiento de datos como
parte de la producción o del sistema de calidad, el fabricante [del dispositivo] deberá validar el
software de la computadora para su uso previsto de acuerdo con un protocolo establecido.

Para aquellos que provienen de un entorno de desarrollo de software, sin mucha información
sobre la industria de dispositivos médicos, el requisito de validar el software que se usa para
crear otro software puede ser un obstáculo inesperado. Sin embargo, este tipo de validación es
esencial para producir dispositivos médicos seguros, ya sean hardware o software.

¿Cuánta validación se requiere? Bueno, en la guía de la FDA sobre los Principios generales de
validación de software , se establece: "El nivel de esfuerzo de validación debe ser acorde con el
riesgo que representa la operación automatizada".

Por ejemplo, si la aplicación de software que está utilizando para la prueba no funciona
correctamente y le da un resultado falso, o no prueba todo lo que debería, entonces está ante
un problema grave que podría afectar la salud del paciente. y seguridad.

Por otro lado, no necesita validar algo como Microsoft Excel para uso general. Es un producto
ampliamente utilizado que representa poco riesgo para su producto.

Solo recuerde que toda su validación debe realizarse de acuerdo con un protocolo
documentado. Y los resultados de esa validación también deben documentarse.

En última instancia, la decisión de validar o no una herramienta de software depende de usted.

Tenga en cuenta, sin embargo, que sea cual sea su decisión, se espera que la justifique.

CIBERSEGURIDAD

Ciberseguridad y SaMD
La seguridad siempre es primordial cuando se trata de dispositivos médicos. Y crear SaMD
seguro significa considerar un elemento adicional: la ciberseguridad.

Ya sea que venga del mundo del desarrollo de software o de la industria de dispositivos médicos,
la necesidad de medidas de seguridad cibernética ya debería ser clara. Ha habido una serie de
ataques de alto perfil en la industria de la salud en la última década, y se descubren nuevas
vulnerabilidades todo el tiempo. De hecho, la atención médica se menciona regularmente como
una de las industrias con mayor riesgo de ataques cibernéticos .

Todo esto significa que los fabricantes de dispositivos ya no pueden darse el lujo de poner la
ciberseguridad en un segundo plano o tratar de agregarla a un dispositivo terminado. Las
amenazas son reales y es fundamental que las tome en serio para proteger la seguridad de los
usuarios de su dispositivo.

Lista de materiales de software (SBOM) para software como producto sanitario

El 12 de mayo de 2021, la administración Biden emitió la Orden ejecutiva sobre la mejora de la

ciberseguridad de la nación . Un aspecto importante de esta orden ejecutiva fue su enfoque en
una lista de materiales de software (SBOM).
Un SBOM es un inventario anidado de todo el software de terceros que existe dentro de SaMD
o SiMD. Una lista de materiales de software es crucial para la seguridad de su producto, ya que
proporciona una lista de ingredientes para su dispositivo.

Si se encuentra una vulnerabilidad en algún componente de software ampliamente utilizado,

puede verificar rápidamente si ese componente está en su lista de ingredientes. Si es así, sabrá
qué productos están afectados y podrá alertar rápidamente a los proveedores y trabajar para
solucionar el problema.

La orden ejecutiva ordenó a la Agencia Nacional de Telecomunicaciones e Información (NTIA)

que creara una lista de los elementos mínimos que se requieren para un SBOM, que la NTIA ha
publicado desde entonces . Los elementos mínimos incluyen:

• Campos de datos : documente la información de referencia sobre cada componente que

debe rastrearse: proveedor, nombre del componente, versión del componente, otros
identificadores únicos, relación de dependencia, autor de los datos de SBOM y marca
de tiempo.
• Soporte de automatización: admita la automatización, incluso a través de la generación
automática y la legibilidad de la máquina para permitir la escalabilidad en todo el
ecosistema de software. Los formatos de datos utilizados para generar y consumir
SBOM incluyen etiquetas SPDX, CycloneDX y SWID.
• Prácticas y Procesos - Definir las operaciones de solicitudes, generación y uso de SBOM
incluyendo: Frecuencia, Profundidad, Desconocidos Conocidos, Distribución y Entrega,
Control de Acceso y Alojamiento de Errores.

Ahora, puede estar mirando estos elementos mínimos y pensando que esto parece mucho
trabajo para armar. Y no está equivocado: es cierto que compilar un SBOM por su cuenta y
monitorear cada componente en busca de nuevas vulnerabilidades es un trabajo pesado. Es por
eso que recomendaría usar una herramienta SBOM automatizada que compilará todo esto por
usted y monitoreará de manera proactiva los elementos en su SBOM en busca de nuevas
vulnerabilidades.

Hay una serie de herramientas disponibles para su uso, incluida la herramienta de gestión de
vulnerabilidades y análisis SBOM de nuestros socios en MedCrypt. Lo animo a explorar sus
opciones antes de construir su SBOM manualmente.

Los requisitos de SBOM son nuevos, y sé que siempre hay cierta resistencia inicial a un requisito
completamente nuevo, pero realmente es crítico (y esperado) que tenga un SBOM para su
software como dispositivo médico.

Regulaciones, orientación y recursos de seguridad cibernética

La ciberseguridad es un campo relativamente nuevo y en constante evolución tanto para los

reguladores como para los profesionales de dispositivos médicos. Sin embargo, los organismos
reguladores se están poniendo al día, publicando documentos de orientación y recursos que
todo profesional de SaMD debe leer y comprender.

He compilado una breve lista de ellos aquí y es un buen lugar para comenzar si se pregunta qué
esperarán los organismos reguladores de usted y su producto con respecto a la ciberseguridad:
 • Manual de estrategias para el modelado de amenazas en dispositivos médicos . El
modelado de amenazas es uno de los mejores métodos para fortalecer la seguridad de
su SaMD. Es por eso que la FDA ha desarrollado este manual de modelado de amenazas.
En él encontrará recursos para desarrollar y adaptar las prácticas de modelado de
amenazas de su empresa.
• Ciberseguridad para dispositivos médicos en red que contienen software listo para usar
(OTS) . Esta es la guía de la FDA sobre el uso de software listo para usar (comercializado
en masa) en dispositivos médicos. Una vulnerabilidad en este tipo de software puede
suponer un riesgo para el funcionamiento de los dispositivos médicos y, por lo general,
requiere un mantenimiento continuo durante todo el ciclo de vida del producto. Esta
guía aclara cómo se aplican regulaciones como la QSR a las actividades de
mantenimiento de la ciberseguridad.
• Ciberseguridad en dispositivos médicos: consideraciones del sistema de calidad y
contenido de las presentaciones previas a la comercialización (BORRADOR). Este
borrador de la guía de la FDA aún no se ha finalizado. Sin embargo, las guías preliminares
representan el pensamiento más reciente de la agencia sobre un tema. Y aunque
algunos elementos de la guía pueden cambiar antes de que se finalice, este borrador es
una lectura esencial para los fabricantes de SaMD.
• Gestión Postmarket de la Ciberseguridad en Dispositivos Médicos . Este documento de
orientación de la FDA proporciona las recomendaciones de la agencia para gestionar las
vulnerabilidades de seguridad cibernética posteriores a la comercialización en
dispositivos médicos. Ofrece recomendaciones específicas y fomenta un enfoque de
ciclo de vida total del producto para la ciberseguridad.
• MDCG 2019-16: Orientación sobre ciberseguridad para dispositivos médicos . Este
documento de orientación está destinado a ayudar a los fabricantes a cumplir con los
requisitos del Anexo I de EU MDR y EU IVDR, con respecto a la ciberseguridad. También
incluye las expectativas de otras partes interesadas, como integradores, operadores
económicos y usuarios.
• Principios y prácticas de IMDRF para la ciberseguridad de dispositivos médicos . Esta
guía se emitió para ofrecer las mejores prácticas y los principios generales para la
ciberseguridad de los dispositivos médicos. El objetivo declarado de la IMDRF para la
guía es "facilitar la convergencia regulatoria internacional sobre la ciberseguridad de los
dispositivos médicos", y ofrece recomendaciones tanto para los fabricantes de
dispositivos como para las partes interesadas externas, como los proveedores.

Para una inmersión aún más profunda, consulte la página de seguridad cibernética de la FDA,
que contiene una larga lista de noticias y actualizaciones, libros blancos e informes, documentos
de orientación, vulnerabilidades conocidas y otros recursos sobre seguridad cibernética.

También vale la pena señalar que un proyecto de ley bipartidista conocido como la Ley PATCH
se está abriendo paso actualmente en el Congreso de los EE. UU. Si se convierte en ley, impondrá
una serie de requisitos de ciberseguridad para los fabricantes que soliciten la aprobación previa
a la comercialización. También codificará la necesidad de un SBOM y requerirá que los
fabricantes aborden las vulnerabilidades de ciberseguridad posteriores al mercado.

Si hay algo que puedo recalcarle sobre la ciberseguridad, es que debe comenzar a pensar en ello
desde el principio. La expectativa es que esté abordando la seguridad cibernética durante todo
el proceso de diseño, en lugar de tratarla como un "extra" que se agrega una vez que su producto
está terminado.
Cuanto antes empiece a pensar en la ciberseguridad para su SaMD, más fácil será cumplir con
las expectativas reglamentarias (y evitar infringir cualquier ley, en caso de que se apruebe la Ley
PATCH). Sin embargo, lo más importante es que integrar la ciberseguridad en el diseño de su
dispositivo dará como resultado un producto más seguro para los pacientes y los proveedores
que lo utilizan.

REQUISITOS POST-COMERCIALIZACIÓN

Requisitos Posteriores a la Comercialización para SaMD

Vale la pena repetir que, si bien existen matices y problemas adicionales que abordar con
respecto a SaMD (como la ciberseguridad), el software como dispositivo médico todavía está
sujeto a las mismas regulaciones que los dispositivos médicos de hardware.

Esto significa que todos los requisitos posteriores a la comercialización de regulaciones como
QSR de la FDA, MDR de la UE o IVDR aún se aplican en gran medida a su SaMD. Además, si ha
seguido la norma IEC 62304 para el desarrollo de software, su proceso de mantenimiento de
software y su proceso de resolución de problemas de software lo ayudarán a cumplir con
algunos de estos requisitos posteriores a la comercialización.

Para obtener una comprensión más completa de estas reglamentaciones, consulte algunas de
las guías, podcasts y seminarios web relacionados con la poscomercialización de nuestra
biblioteca de recursos gratuitos de dispositivos médicos .

Dicho esto, hablemos de algunas de las características inherentes a SaMD que requieren un
enfoque diferente en la etapa posterior a la comercialización del ciclo de vida de un dispositivo
médico.

¿Cuándo requiere un SaMD un nuevo envío?

Hacer un cambio en un dispositivo médico que está en el mercado siempre requerirá un

escrutinio. Como mínimo, deberá documentar el cambio que ha realizado. Pero si un cambio es
lo suficientemente significativo, es posible que deba volver a enviar la documentación que
necesitaba para colocar el dispositivo en el mercado en primer lugar.

Cuando su producto es un software, decidir si necesita un nuevo envío es aún más complicado.
Entonces, echemos un vistazo a cómo tomará esa decisión.

Realización de cambios en SaMD en los EE. UU.

El software como dispositivo médico es similar a los dispositivos médicos tradicionales en el

sentido de que si desea realizar cambios en su dispositivo, tiene dos opciones:

• Notificar a la FDA sobre el cambio a través de un nuevo 510(k), un 510(k) especial o un

suplemento PMA
• Documente el cambio internamente a través de una carta a archivo
La elección que haga depende de la importancia del cambio que esté realizando y de si afecta la
seguridad, la eficacia o el rendimiento del dispositivo. Para un dispositivo médico de hardware,
generalmente es más fácil saber si su cambio es lo suficientemente significativo como para
justificar una notificación a la FDA. Pero con el software, la decisión puede ser un poco más
complicada.

Afortunadamente, la FDA ha publicado una guía sobre cómo decidir cuándo enviar un 510(k)
para un cambio de software en un dispositivo existente para ayudar a los fabricantes de SaMD.
Al igual que con todos los documentos de orientación enumerados en esta guía, lo animo a leer
todo. Sin embargo, este diagrama de flujo le dará una idea de las preguntas que debe hacer
durante el proceso de toma de decisiones.
 Decidir cuándo presentar un 510(k) para un cambio de software en un dispositivo existente, FDA

Realización de cambios en SaMD en la UE

Los requisitos para una notificación de un cambio en su dispositivo en la UE son similares. El

Anexo X de EU MDR establece:
 El solicitante informará al organismo notificado que haya expedido el certificado de
examen UE de tipo de cualquier cambio previsto en el tipo aprobado o de su finalidad
y condiciones de uso previstas.

Los cambios en el dispositivo aprobado, incluidas las limitaciones de su propósito

previsto y las condiciones de uso, requerirán la aprobación del organismo notificado
que emitió el certificado de examen UE de tipo cuando dichos cambios puedan afectar
la conformidad con los requisitos generales de seguridad y rendimiento o con las
condiciones prescritas para el uso. del producto. El organismo notificado examinará los
cambios previstos, notificará su decisión al fabricante y le facilitará un suplemento del
informe del examen UE de tipo. La aprobación de cualquier cambio en el tipo aprobado
tomará la forma de un suplemento del certificado de examen UE de tipo.

Los cambios en la finalidad prevista y las condiciones de uso del dispositivo aprobado,
con excepción de las limitaciones de la finalidad prevista y las condiciones de uso,
requerirán una nueva solicitud de evaluación de la conformidad.

Aunque los requisitos de MDR no son exactamente los mismos que las pautas de la FDA, debería
poder notar un tema similar en ambos: las modificaciones que cambian el uso previsto del
dispositivo requieren una nueva presentación a la FDA o una solicitud a su organismo notificado.

Inteligencia artificial y aprendizaje automático en SaMD

Hay una advertencia más en el proceso de toma de decisiones para una nueva presentación: la
inteligencia artificial (IA).

La IA es una de las tecnologías de más rápido crecimiento que se aplica a los dispositivos
médicos. Nuestra encuesta de referencia de la industria, el Informe sobre el estado de la calidad
de los dispositivos médicos, el desarrollo de productos y la comercialización de 2022 , encontró
que una cuarta parte de los encuestados incluye IA en sus productos.

Esto incluye el aprendizaje automático (ML), un subconjunto de la IA cuyo uso se ha disparado

en muchas industrias en los últimos años.

El aprendizaje automático se refiere a un algoritmo que tiene la capacidad de cambiar o mejorar

sus resultados a medida que "aprende" de una cantidad cada vez mayor de entradas. Cuantos
más datos recibe un algoritmo de ML, más precisos pueden ser sus resultados.

Esta tecnología ofrece un potencial increíble para el diagnóstico y muchos otros dispositivos
médicos, pero plantea un dilema. Cuando hablamos de SaMD, el cambio en el algoritmo que le
permite mejorar es técnicamente un cambio en el propio dispositivo.

Entonces, ¿cómo sabe si ese cambio ha alcanzado el nivel de requerir un nuevo envío para su
SaMD?

Este es todavía un territorio relativamente nuevo para los fabricantes de dispositivos médicos y
los organismos reguladores. Sin embargo, la FDA ha publicado un marco normativo propuesto
para las modificaciones del software basado en inteligencia artificial/aprendizaje automático
(AI/ML) como dispositivo médico (SaMD) para abordar este problema. Si bien recomiendo
encarecidamente leer el documento completo, hay un par de cosas que quiero señalar aquí.
En primer lugar, la FDA aún espera que los fabricantes consulten y utilicen el documento de
orientación, Cómo decidir cuándo presentar un 510(k) para un cambio de software en un
dispositivo existente , que analizamos anteriormente en esta sección.

En segundo lugar, la FDA también propone un marco para las modificaciones de AI/ML basado
en el principio de un "plan de control de cambios predeterminado". Básicamente, esto
establecería los parámetros de cualquier modificación anticipada cuando envíe su primer envío
previo a la comercialización.

Este “plan de control de cambios predeterminado” toma la forma de dos documentos que
describen dos tipos diferentes de modificaciones. La FDA se refiere a estos como:

• Especificaciones previas de SaMD (SPS): las modificaciones anticipadas del fabricante

de SaMD en el "rendimiento" o las "entradas" o los cambios relacionados con el "uso
previsto" de SaMD basado en AI/ML. Estos son los tipos de cambios que el fabricante
planea lograr cuando el SaMD esté en uso. El SPS dibuja una "región de posibles
cambios" en torno a las especificaciones iniciales y el etiquetado del dispositivo original.
Esto es "en lo que" el fabricante pretende que se convierta el algoritmo a medida que
aprende.

• Protocolo de cambio de algoritmo (ACP): métodos específicos que tiene un fabricante

para lograr y controlar adecuadamente los riesgos de los tipos anticipados de
modificaciones delineadas en el SPS. El ACP es una descripción paso a paso de los datos
y procedimientos a seguir para que la modificación logre sus objetivos y el dispositivo
permanezca seguro y efectivo después de la modificación. Así es como el algoritmo
aprenderá y cambiará sin dejar de ser seguro y efectivo.

Bajo este marco propuesto, la FDA sugiere que las modificaciones que caen dentro de los límites
acordados de SPS y ACP solo tendrían que ser documentadas por el fabricante. Básicamente,
estas son las modificaciones que usted informó a la FDA que podrían ocurrir a medida que
cambia el algoritmo.

Las modificaciones fuera de los límites de SPS y ACP requerirían una nueva presentación 510(k)
si las modificaciones afectan la seguridad o eficacia del dispositivo.

Sé que es mucho para asimilar, por lo que este diagrama de flujo debería ayudarlo a entenderlo.
 Marco normativo propuesto para las modificaciones del software basado en inteligencia artificial/aprendizaje
automático (AI/ML) como dispositivo médico (SaMD), FDA

Además del marco regulatorio propuesto por la FDA, la FDA, Health Canada y la Agencia
Reguladora de Medicamentos y Productos para el Cuidado de la Salud del Reino Unido se han
unido para emitir principios rectores para las Buenas Prácticas de Aprendizaje Automático para
el Desarrollo de Dispositivos Médicos . Este recurso es breve y directo, y es una lectura esencial
para cualquier persona que cree un producto que incluya ML.

CONSIDERACIONES FINALES

Reflexiones finales sobre el software como producto sanitario

Si ha llegado a este punto de la guía (incluso si acaba de hojear los encabezados), creo que estará
de acuerdo en que el mundo de SaMD es complejo y evoluciona.

Todavía hay áreas grises dentro de las regulaciones y guías para SaMD que deberán abordarse
en los próximos años. Todavía queda mucho trabajo por hacer en temas como la ciberseguridad.
Y hay una curva de aprendizaje empinada para los desarrolladores de software que ingresan al
mundo de los dispositivos médicos, y viceversa.

Pero también hay una inmensa oportunidad y emoción en este espacio. Lo último que quiero es
que termine esta guía y se desanime por el trabajo que implica crear un software seguro y eficaz
como dispositivo médico. Con las herramientas adecuadas y el mejor asesoramiento experto
disponible, no hay razón por la que su empresa no pueda crear SaMD de alta calidad que mejore
la calidad de vida de millones de pacientes.