Tema 1.6 — Seguridad clínica y gestión de riesgos

En una frase: La seguridad clínica es la práctica disciplinada y respaldada por evidencia de encontrar las formas en que tu tecnología digital podría dañar a un paciente y controlar esos peligros antes de que lleguen a alguien —la seguridad diseñada desde el primer boceto, no añadida antes de la puesta en marcha.

Por qué esto importa en la salud y la atención#

En la mayoría de los sectores, un defecto de software es un inconveniente: una página no carga, un pedido se duplica, un informe llega tarde. En la salud y la atención, la misma clase de defecto puede matar. Un campo de medicación que trunca un punto decimal, una pantalla de resultados que muestra al paciente equivocado, un algoritmo de triaje que silenciosamente deja de señalar un síntoma, una integración que silenciosamente descarta registros de alergias —cada uno es un error de software, y cada uno es también un peligro clínico capaz de causar daño grave o muerte. Por eso la seguridad clínica no es un detalle de calidad añadido sobre buena ingeniería; es una disciplina distinta y regulada con sus propios estándares, roles y evidencia.

Las consecuencias son asimétricas y a menudo invisibles. Cuando un sistema digital funciona, nadie ve el daño que previno; cuando falla, el daño puede ser catastrófico, retrasado y distribuido entre miles de pacientes antes de que alguien note un patrón. Esa combinación —alta consecuencia, baja visibilidad, amplio radio de impacto— significa que no puedes confiar en que los usuarios detecten problemas ni en que los incidentes te enseñen todo. Tienes que razonar sobre el daño de forma proactiva, antes del despliegue, y seguir razonando sobre ello mientras el sistema está en vivo. En el Reino Unido, este razonamiento proactivo no es opcional: se espera contractual y profesionalmente que las organizaciones del NHS y sus proveedores apliquen los estándares nacionales de gestión de riesgo clínico, y que puedan mostrar su trabajo. Hacer esto bien es inseparable de la evidencia (véase el Tema 1.3 — Decisiones basadas en evidencia), de la gobernanza de la información y la ciberseguridad (véase el Tema 1.7 — Gobernanza de la información, protección de datos y ciberseguridad), y de cómo operas los servicios una vez que están en vivo (véase el Tema 3.8 — Gestión de servicios y operaciones en vivo).

Conceptos clave#

Seguridad del paciente y gestión de riesgos. La seguridad del paciente es la prevención, reducción, reporte y análisis del daño a los pacientes por causa de la atención. La gestión de riesgo clínico aplica la disciplina general de la gestión de riesgos —identificar, evaluar, priorizar y controlar riesgos— a la pregunta específica de cómo un sistema de TI de salud podría contribuir al daño del paciente. Los dos estándares nacionales que rigen esto en Inglaterra son DCB0129 y DCB0160 (DCB significa Data Coordination Board; son estándares del Comité de Estandarización para Estándares de Información de Atención / SCCI, obligatorios bajo la Health and Social Care Act 2012). El DCB0129 impone obligaciones al fabricante o proveedor de un sistema de TI de salud; el DCB0160 impone obligaciones a la organización de salud que despliega y usa dicho sistema. Son complementarios: un caso de seguridad limpio de un proveedor no exime a un fideicomiso que despliega de su deber de evaluar los peligros introducidos por su propia configuración, flujo de trabajo y contexto.

El Oficial de Seguridad Clínica (CSO). Ambos estándares exigen un Oficial de Seguridad Clínica nombrado, adecuadamente cualificado y experimentado —un clínico registrado, en ejercicio activo, que haya completado formación reconocida en seguridad clínica— para poseer la actividad de gestión de riesgo clínico y aprobar personalmente el caso de seguridad. El rol de CSO es un requisito de competencia, no un título de trabajo que puedas asignar a quien esté libre. El CSO aprueba que los peligros han sido identificados y controlados a un nivel aceptable; es un juicio profesional que conlleva responsabilidad profesional.

Los artefactos de gestión de riesgo clínico. Tres documentos anclan la disciplina. El archivo de gestión de riesgo clínico es el contenedor de toda la evidencia de seguridad para un sistema. El registro de peligros es el registro vivo de cada peligro identificado, sus causas, consecuencias, calificación de riesgo, controles y riesgo residual. El caso de seguridad clínica es el argumento estructurado, respaldado por evidencia, de que el sistema es aceptablemente seguro para su uso previsto en su contexto previsto —acompañado de un informe de caso de seguridad que resume el argumento para su aprobación. Estos no son papeleo por el papeleo mismo; son cómo el razonamiento de seguridad se hace explícito, revisable y duradero.

Análisis de peligros: identificación, análisis, evaluación, control. El bucle central es: identificación de peligros (imaginar sistemáticamente cómo el sistema podría contribuir al daño —mediante talleres, recorridos clínicos, análisis de modos de fallo), análisis de riesgo (estimar la gravedad del daño y la probabilidad de que ocurra), evaluación de riesgo (comparar el riesgo estimado con criterios de aceptabilidad), y control de riesgo (introducir medidas —cambios de diseño, alertas, formación, procedimientos— para reducir el riesgo inaceptable, y luego reevaluar el riesgo residual). El riesgo se reduce tan bajo como sea razonablemente practicable (ALARP): sigues controlando hasta que una mayor reducción sería enormemente desproporcionada respecto al beneficio obtenido.

Regulación de dispositivos médicos, la MHRA, y el software como dispositivo médico (SaMD). Parte de la tecnología de salud digital es un dispositivo médico regulado. El software que tiene un propósito médico —diagnosticar, prevenir, monitorear, predecir, tratar— puede ser en sí mismo un dispositivo médico: software como dispositivo médico (Software as a Medical Device, SaMD). En el Reino Unido, la Medicines and Healthcare products Regulatory Agency (MHRA) regula los dispositivos médicos, incluyendo el SaMD, y el estándar de ciclo de vida de software IEC 62304 rige cómo debe desarrollarse dicho software. Decidir si tu tecnología es un dispositivo regulado es una pregunta umbral con grandes consecuencias, y es separada de —aunque se sitúa junto a— la gestión de riesgo clínico DCB0129/0160.

Los Criterios de Evaluación de Tecnología Digital (DTAC). El DTAC es la línea base nacional que las organizaciones del NHS y de atención social usan para evaluar productos digitales antes de la contratación, cubriendo seguridad clínica (evidencia de cumplimiento del DCB0129), protección de datos, seguridad técnica, interoperabilidad y usabilidad. No reemplaza la gestión de riesgo clínico; comprueba que un proveedor la haya realizado.

Factores humanos y cultura de seguridad. Los factores humanos (ergonomía) son el estudio científico de cómo las personas interactúan con los sistemas en condiciones reales —fatiga, interrupción, carga cognitiva, fatiga por alarmas. La mayoría del daño digital surge no de código que está "equivocado" sino de diseños que hacen difícil la acción segura y fácil la insegura. La cultura de seguridad es el compromiso organizacional de sacar a la luz, reportar y aprender del riesgo sin culpa —la diferencia entre un equipo que oculta cuasi-incidentes y uno que los explota para la mejora.

Reporte de incidentes y aprendizaje. En Inglaterra, Learn from Patient Safety Events (LFPSE) es el servicio nacional para registrar eventos de seguridad del paciente, y el Patient Safety Incident Response Framework (PSIRF) establece cómo las organizaciones del NHS responden y aprenden de los incidentes —enfatizando el análisis de causa raíz proporcionado y basado en sistemas sobre la culpa. Los sistemas en vivo generan nuevos peligros, así que la seguridad clínica continúa después de la puesta en marcha a través de la retroalimentación de incidentes al registro de peligros.

Buenas prácticas#

1. Nombrar un Oficial de Seguridad Clínica competente y darle autoridad real. Nombra a un clínico registrado y en ejercicio con formación reconocida en seguridad clínica como CSO para cada sistema dentro del alcance, y asegúrate de que su aprobación sea un control genuino, no un sello de goma alcanzado el día antes del lanzamiento. El CSO debe poder decir "todavía no" y ser escuchado —lo que significa proteger su tiempo, su independencia y su posición ante la junta del programa. Un CSO que es anulado por la presión de entrega es una ficción de gobernanza.

2. Realizar la identificación de peligros temprano, con clínicos en la sala. Comienza los talleres de peligros en el descubrimiento y el diseño, no antes de la puesta en marcha, porque los controles más baratos y efectivos son cambios de diseño hechos antes de que se construya nada (véase el Tema 3.5 — Ciclos de vida de entrega). Trae clínicos de primera línea, no solo analistas, porque ellos saben cómo realmente sucede el trabajo —las interrupciones, las soluciones alternativas, la forma en que se lee una pantalla a las 3 de la madrugada. Recorre escenarios clínicos realistas y pregunta implacablemente: "¿cómo podría este sistema contribuir a que un paciente resulte dañado?"

3. Mantener un registro de peligros vivo, no un documento del día de lanzamiento. Trata el registro de peligros como un registro persistente que se abre en el descubrimiento y nunca se cierra mientras el sistema está en vivo. Cada peligro registra sus causas, el daño potencial, la calificación de riesgo inicial, los controles aplicados, y el riesgo residual tras los controles. Cuando un incidente, un cambio o un cuasi-incidente revela un nuevo peligro, entra en el registro y se trabaja a través del mismo bucle —el registro es la memoria de tu razonamiento de seguridad.

4. Hacer que la organización que despliega posea el DCB0160, incluso con un proveedor conforme. El caso de seguridad DCB0129 de un proveedor cubre el producto tal como fue construido; no puede cubrir cómo lo configuras, qué flujos de trabajo envuelves a su alrededor, o cuáles de tus poblaciones lo usan. Realiza tu propia evaluación DCB0160 para los peligros locales —integración con tus otros sistemas, tu calidad de datos, tus vías clínicas— y mantén tu propio registro de peligros. Asumir que el aseguramiento del proveedor cubre tu contexto es un atajo común y peligroso.

5. Hacer que el control de riesgo sea proporcionado y preferir el diseño sobre las advertencias. Clasifica los controles por fortaleza: diseñar el peligro fuera (restricciones, valores predeterminados, funciones forzadas) vence a una alerta en pantalla, que vence a una línea en un manual de formación. Reserva el aseguramiento más pesado para los peligros de mayor consecuencia y aplica un proceso más ligero y rápido a los cambios genuinamente de bajo riesgo —la proporcionalidad es lo que permite que la seguridad mantenga el ritmo con la entrega. Reduce el riesgo a ALARP y registra por qué el riesgo residual es aceptable.

6. Diseñar para los factores humanos, y respetar la fatiga por alarmas. Asume que los usuarios están ocupados, interrumpidos y reconociendo patrones, y diseña de modo que la acción segura sea la acción fácil y predeterminada. Protégete contra la sobrecarga de alertas: una alerta que se dispara con demasiada frecuencia se ignora, así que cada advertencia adicional debe ganarse su lugar o degrada a las que importan. Las pruebas de usabilidad en condiciones realistas son una actividad de seguridad clínica, no solo un detalle de diseño.

7. Determinar tu estatus regulatorio deliberadamente. Pregunta temprano si tu software cumple con la definición de dispositivo médico o SaMD, y si es así, involúcrate con los requisitos de la MHRA y el IEC 62304 desde el principio en lugar de descubrir la obligación tarde. Equivocarse en la clasificación es costoso en ambas direcciones —un dispositivo no registrado es un fallo legal y de seguridad, mientras que sobreclasificar una herramienta simple desperdicia capacidad de aseguramiento escasa. En caso de duda, busca asesoría regulatoria y documenta el razonamiento.

8. Usar el DTAC como un piso, no una línea de meta. Trata los Criterios de Evaluación de Tecnología Digital como el control mínimo de entrada para cualquier producto digital adquirido, confirmando que la seguridad clínica, la protección de datos, la seguridad, la interoperabilidad y la usabilidad han sido abordadas. Superar el DTAC significa que un proveedor ha hecho el trabajo; no significa que el producto sea seguro en tu contexto, así que empareja esto con tu propia evaluación DCB0160 y monitoreo en vivo.

9. Cerrar el bucle desde los incidentes en vivo hasta el registro de peligros. Conecta tu reporte de incidentes —presentaciones a LFPSE, investigaciones PSIRF, reportes locales de cuasi-incidentes— de vuelta a la gestión de riesgo clínico para que el daño y los cuasi-incidentes del mundo real actualicen tus peligros y controles. Un caso de seguridad que nunca se revisa después de la puesta en marcha se pudre, porque los sistemas en vivo, las integraciones y la práctica clínica todos se desvían (véase el Tema 3.8 — Gestión de servicios y operaciones en vivo). El aprendizaje se basa en sistemas y es consciente de la culpa, no una búsqueda de alguien a quien castigar.

10. Construir una cultura de seguridad justa y que reporta. Haz que sea seguro y esperado reportar cuasi-incidentes y desafiar un lanzamiento por motivos de seguridad, porque los peligros de los que nunca escuchas son peligros que no puedes controlar. Los líderes marcan este tono respondiendo a las malas noticias con curiosidad y mejora en lugar de culpa, y tratando la cautela del CSO como valiosa en lugar de obstructiva. La cultura es el sustrato del que dependen todas las demás prácticas aquí.

Preguntas para debatir con tu equipo#

1. ¿Dónde en nuestra cartera actual estamos confiando en el aseguramiento de seguridad de un proveedor para cubrir riesgos que en realidad son nuestros? Esta pregunta sondea la división DCB0129/DCB0160, que los equipos rutinariamente difuminan. El caso de seguridad DCB0129 de un proveedor aborda el producto tal como fue fabricado, pero en el momento en que lo configuras, lo conectas a tus otros sistemas, envuelves flujos de trabajo locales a su alrededor, y lo apuntas hacia tu población específica de pacientes, introduces peligros que el proveedor nunca evaluó y no podría haber evaluado. La tensión honesta es que realizar tu propia evaluación DCB0160 cuesta tiempo clínico y analítico escaso, y es tentador tratar el aseguramiento limpio de un proveedor y un DTAC aprobado como suficientes. Trabaja a través de un despliegue en vivo o inminente y pregunta concretamente: ¿quién es nuestro CSO nombrado para él, tenemos nuestro propio registro de peligros, y qué peligros surgen puramente de nuestro contexto local en lugar del producto mismo? Una buena respuesta nombra sistemas específicos donde la evaluación local es escasa, distingue los peligros del producto de los peligros del despliegue, y se compromete a poseer estos últimos en lugar de asumir que están cubiertos.

2. ¿Qué tan proporcionado es nuestro proceso de seguridad clínica —estamos enterrando cambios de bajo riesgo en papeleo mientras los cambios de alta consecuencia se deslizan por el impulso? El tema argumenta que el aseguramiento debería escalar con el riesgo clínico: el escrutinio más pesado para los peligros de mayor consecuencia, un proceso más ligero y rápido donde el riesgo es genuinamente bajo. Esta pregunta pone a prueba si tu organización realmente calibra, o aplica un único ajuste contundente. Ambas direcciones de fallo son reales y costosas —un proceso uniformemente pesado entrena a los equipos a ver la seguridad clínica como un impuesto burocrático y a buscar formas de evitarlo, mientras que un proceso uniformemente ligero deja pasar un cambio en un cálculo de dosificación de medicamentos con el mismo esfuerzo que un cambio en una página de ayuda. El peligro más sutil es que el impulso, no el riesgo, decide el escrutinio: un programa insignia con atención ejecutiva puede adquirir un aura de inevitabilidad que desalienta al CSO de decir "todavía no". Examina dos o tres cambios recientes de riesgo claramente diferente y pregunta si el esfuerzo invertido coincidió con el potencial de daño, y si alguien se sintió capaz de ralentizar el de alto perfil. Una respuesta honesta admite dónde el proceso está mal calibrado en cualquier dirección y trata la proporcionalidad como un juicio explícito y defendible en lugar de un reflejo.

3. Cuando algo casi salió mal con uno de nuestros sistemas digitales, ¿qué sucedió realmente después —y diría un clínico de primera línea que era seguro plantearlo? Esta pregunta examina la cultura de seguridad y el bucle de aprendizaje de incidentes, que es donde los compromisos declarados se encuentran con la realidad. La seguridad clínica depende de escuchar sobre cuasi-incidentes, pero las personas solo reportan cuando reportar se siente seguro y valioso, y cuando ven que lleva al cambio en lugar de a la culpa. La tensión es que bajo presión de entrega y reputacional, el instinto es justificar un cuasi-incidente, cerrarlo rápidamente y seguir adelante —especialmente si sacarlo completamente a la luz retrasaría un lanzamiento o avergonzaría a un patrocinador senior. El enfoque de PSIRF, basado en sistemas y consciente de la culpa, existe precisamente porque buscar a un individuo a quien culpar suprime el reporte que necesitas y pasa por alto las causas sistémicas reales. Fundamenta la discusión en un cuasi-incidente o incidente reciente específico: ¿se registró, llegó al registro de peligros, se realizó una investigación proporcionada, y realmente cambió algo? Una buena respuesta es franca sobre si reportar se sintió seguro, distingue el aprendizaje genuino del cierre de papeleo, y nombra comportamientos concretos que los líderes adoptarán para que la próxima persona que detecte un peligro hable.

4. ¿Hemos determinado honestamente cuáles de nuestros productos son dispositivos médicos regulados —y quién es responsable de esa decisión? El estatus regulatorio es una pregunta umbral con consecuencias desproporcionadas, y es fácil dejarla sin responder porque responderla puede ser inconveniente. El software que diagnostica, predice, monitorea o trata puede ser en sí mismo software como dispositivo médico, involucrando las obligaciones de la MHRA y el estándar de ciclo de vida IEC 62304 —separado de, y adicional a, la gestión de riesgo clínico DCB0129/0160. La tensión va en ambas direcciones: subclasificar te deja enviando un dispositivo no registrado, un fallo legal y de seguridad que puede surgir catastróficamente a escala, mientras que sobreclasificar una herramienta administrativa simple quema capacidad de aseguramiento escasa que necesitabas en otro lugar. El peligro es que la clasificación cae entre roles —los clínicos asumen que los ingenieros decidieron, los ingenieros asumen que el equipo regulatorio o comercial decidió, y nadie realmente ha escrito el razonamiento. Mira concretamente los productos en tu cartera que están más cerca del límite —cualquier cosa con una regla de triaje, una puntuación de riesgo, un algoritmo de alerta— y pregunta quién hizo la determinación del dispositivo, sobre qué base, y si está documentada y revisada a medida que cambian las funcionalidades. Una respuesta honesta nombra los productos límite, señala una justificación registrada y defendible para cada uno, y es franca sobre dónde la decisión nunca se tomó realmente.

5. ¿Estamos diseñando los peligros fuera, o estamos acumulando silenciosamente alertas y advertencias que nuestros clínicos ya han aprendido a ignorar? El tema clasifica los controles por fortaleza —diseñar el peligro fuera vence a una alerta en pantalla, que vence a una línea en un manual de formación— sin embargo, las alertas son el camino de menor resistencia, porque añadir una advertencia es rápido y se siente responsable mientras que rediseñar un flujo de trabajo es lento y disputado. Con el tiempo, este sesgo se acumula en fatiga por alarmas: se disparan tantas advertencias que los clínicos reconocen patrones pasando por todas ellas, incluyendo la que importa, así que cada nueva alerta puede en realidad reducir la seguridad. La tensión real es que cada alerta innecesaria tiene un patrocinador que la añadió de buena fe después de algún incidente, lo que hace que las advertencias sean políticamente difíciles de eliminar incluso cuando están degradando el sistema. Los factores humanos son la disciplina aquí —diseñar de modo que la acción segura sea la acción fácil y predeterminada para un usuario ocupado, interrumpido, leyendo una pantalla a las 3 de la madrugada— y las pruebas de usabilidad en condiciones realistas son una actividad de seguridad clínica, no un detalle de diseño. Examina un sistema que tus equipos realmente usan y pregunta cuántas alertas encuentra un clínico en una tarea típica, cuáles de ellas realmente cambian el comportamiento, y dónde una función forzada o un mejor valor predeterminado podría haber reemplazado completamente una advertencia. Una buena respuesta resiste el reflejo de añadir otra alerta, trata la carga de alertas como un peligro medible por derecho propio, y está dispuesta a eliminar advertencias que ya no se ganan su lugar.

6. A medida que nuestros sistemas en vivo, integraciones y vías clínicas se desvían con el tiempo, ¿cómo sabemos que nuestro caso de seguridad todavía se sostiene? La seguridad clínica no termina en la puesta en marcha; los sistemas en vivo generan nuevos peligros, y el mundo alrededor de un sistema sigue moviéndose —una integración previa cambia sus datos, una vía clínica se rediseña, un proveedor lanza una actualización, una nueva cohorte de pacientes comienza a usar la herramienta. Un caso de seguridad aprobado hace dos años describe un sistema y un contexto que puede que ya no exista, así que la pregunta es si tu registro de peligros es un registro vivo o un documento que se firmó una vez y se dejó pudrir (véase el Tema 3.8 — Gestión de servicios y operaciones en vivo). La tensión es que mantener el razonamiento de seguridad después del lanzamiento compite con la nueva entrega por el mismo tiempo escaso de CSO y clínico, y la desviación es gradual e invisible de una forma que rara vez exige atención hasta que algo falla. Los ángulos concretos incluyen el control de cambios que vuelve a activar la evaluación de peligros cuando cambian la configuración o las integraciones, la revisión periódica de los peligros de mayor consecuencia, y el monitoreo que realmente detectaría un control degradándose silenciosamente. Elige un sistema que ha estado en vivo durante un año o más y pregunta cuándo se revisaron sus peligros por última vez, qué ha cambiado debajo de él desde la aprobación, y quién notaría si un control clave dejara de funcionar. Una respuesta honesta distingue los sistemas con gestión de seguridad continua genuina de los que se deslizan sobre un caso de seguridad obsoleto, y se compromete con un ritmo proporcionado de revisión vinculado al cambio real en lugar de solo al calendario.

En la práctica: un ejemplo de salud y atención#

Un sistema de atención integrada (ICS) está desplegando una herramienta de derivación electrónica compartida que permite a los médicos de cabecera derivar pacientes directamente a servicios comunitarios, con un conjunto de reglas de triaje incorporado que dirige los casos urgentes a una cola más rápida. Un enfoque impulsado por la entrega tomaría el caso de seguridad DCB0129 del proveedor, aprobaría el DTAC, y se pondría en marcha para cumplir una fecha prometida a la junta.

En su lugar, el programa nombra a un médico de cabecera en ejercicio con formación en seguridad clínica como Oficial de Seguridad Clínica y abre un archivo de gestión de riesgo clínico y un registro de peligros al inicio del diseño. Los talleres tempranos de peligros con médicos de cabecera, enfermeras comunitarias y administradores sacan a la luz varios peligros que el caso a nivel de producto del proveedor nunca tocó —todos surgiendo del despliegue local. El peor: las reglas de triaje se configuraron según las propias definiciones de servicio del ICS, y un error de mapeo podría dirigir una derivación urgente de cáncer de piel a una cola de dermatología rutinaria con semanas de espera. Ese peligro se califica como de severidad alta, probabilidad plausible.

Trabajando el bucle de control de riesgo, el equipo prefiere el diseño sobre las advertencias. Añaden una función forzada para que una marca clínica urgente no pueda ser anulada silenciosamente por la lógica de enrutamiento, un informe de reconciliación que un clínico revisa diariamente, y —lo más bajo en la jerarquía— una nota de formación. El riesgo residual se recalifica y se juzga aceptable y ALARP; el CSO registra por qué. Porque la herramienta solo enruta y no diagnostica en sí misma, el equipo la evalúa como que no alcanza el umbral de SaMD, documenta ese razonamiento, y lo archiva. Las pruebas de factores humanos detectan un problema separado: una alerta de "derivación duplicada" demasiado entusiasta se dispara con tanta frecuencia que los médicos de cabecera ya la están ignorando, así que se rediseña para activarse solo en duplicados genuinos.

En la puesta en marcha, el caso de seguridad DCB0160 es aprobado por el CSO, no por el director del programa. Tres semanas después, un informe de LFPSE y un cuasi-incidente señalado por una recepcionista revelan un nuevo peligro —un campo de texto libre que se está usando para introducir información urgente que el enrutamiento nunca ve. Bajo PSIRF, se realiza una revisión proporcionada y basada en sistemas, el peligro entra en el registro, se programa un cambio de diseño, y se informa un control provisional la misma semana. El caso de seguridad es un argumento vivo, y el registro muestra exactamente cómo se razonó sobre cada peligro —que es lo que un inspector, un forense, o un nuevo CSO dentro de dos años necesitará.

Perspectivas sectoriales#

Todos tienen el mismo deber de controlar el riesgo clínico, pero la maquinaria, los incentivos y las presiones difieren marcadamente según la organización.

Startup#

Una startup de salud digital a menudo encuentra la seguridad clínica como una puerta de contratación: un comprador del NHS pide DTAC y un caso de seguridad DCB0129, y hay una carrera de última hora. El movimiento ganador es construir la gestión de riesgo clínico desde el primer sprint —un registro de peligros junto al backlog, un Oficial de Seguridad Clínica accesible (a menudo contratado en lugar de empleado, pero genuinamente competente y empoderado)— porque adaptar retroactivamente un caso de seguridad a un producto terminado es lento, costoso y poco convincente. Los fundadores también deben confrontar la cuestión de SaMD con honestidad y temprano, ya que descubrir a mitad de escala que el producto es un dispositivo médico no registrado es un riesgo legal y de seguridad existencial. Bien hecho, los artefactos maduros de seguridad clínica se convierten en un activo comercial que acorta los ciclos de venta del NHS.

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados, una agencia de atención domiciliaria, una clínica de un solo emplazamiento, o un pequeño proveedor de tecnología de salud que ya superó la etapa previa a los ingresos— carga con el mismo deber DCB0160 que un gran fideicomiso cuando despliega y configura sistemas digitales, pero sin ninguna capacidad de sobra para cumplirlo. Rara vez hay un CSO dedicado o un analista de seguridad en la nómina, así que la ruta práctica es contratar a un clínico competente y en ejercicio de forma contratada y mantener un registro de peligros ligero pero genuino en lugar de fingir que el deber no aplica. Los peligros locales más agudos suelen ser de configuración y flujo de trabajo —cómo se configura el registro compartido, cómo se manejan las marcas urgentes, cómo la solución alternativa de un administrador a tiempo parcial se convierte en un riesgo de enrutamiento— precisamente los peligros que el caso DCB0129 de un proveedor nunca cubre. La proporcionalidad es la amiga del proveedor pequeño aquí: concentra el poco tiempo de aseguramiento que tienes en los peligros de mayor consecuencia, usa el DTAC y el caso de seguridad del proveedor como un piso al elegir productos, y apóyate en recursos compartidos como el apoyo de seguridad clínica del ICS en lugar de intentar construir todo el aparato solo.

Gran organización#

Un fideicomiso del NHS o un ICS carga con doble responsabilidad: despliega sistemas de otros bajo DCB0160 y a menudo construye o configura fuertemente los propios bajo DCB0129. El fallo característico es institucional —un programa insignia de historia clínica electrónica cuya fecha de puesta en marcha tiene peso político, así que la cautela del CSO se trata silenciosamente como un obstáculo. El correctivo es estructural: dar al CSO independencia y un veto real, mantener un registro de peligros vivo a través del patrimonio en lugar de un estante de documentos del día de lanzamiento, y conectar el aprendizaje de LFPSE y PSIRF de vuelta a la gestión de riesgo clínico como un proceso permanente. A escala empresarial, los mayores peligros son peligros de integración y configuración, que ningún aseguramiento de proveedor cubre, así que la propiedad local no es negociable.

Gobierno#

Un organismo nacional —NHS England, la MHRA, DHSC, NICE— establece los estándares que otros deben cumplir, así que sus formas de trabajar dan forma a todo el sistema: DCB0129/0160, DTAC y la regulación de SaMD son instrumentos de seguridad a escala poblacional. Las decisiones aquí atraen escrutinio regulatorio, parlamentario y público, y un sistema obligatorio a nivel nacional que lleva un peligro latente distribuye ese daño entre millones antes de que nadie vea el patrón. Las obligaciones son la proporcionalidad hecha explícita en estándares publicados, transparencia sobre el riesgo residual, y mantener el marco regulatorio actualizado a medida que la tecnología —especialmente la IA— lo supera (véase el Tema 8.4 — Gobernanza de la IA y las tecnologías emergentes). El riesgo distintivo a esta escala es sistémico: ordenar una tecnología en todo el patrimonio con evidencia de seguridad escasa arraiga un peligro en todas partes a la vez.

Modos de fallo comunes#

• Seguridad añadida al final. Producir un caso de seguridad la semana antes de la puesta en marcha para satisfacer un control. Antídoto: abrir el registro de peligros en el descubrimiento; diseñar fuera los mayores peligros.
• Aseguramiento de proveedor confundido con seguridad local. Tratar un caso DCB0129 y un DTAC aprobado como cobertura de tu despliegue. Antídoto: poseer tu propia evaluación DCB0160 y registro de peligros local.
• CSO como sello de goma. Un Oficial de Seguridad Clínica sin tiempo, independencia o autoridad para decir "todavía no". Antídoto: proteger el rol y hacer que la aprobación sea un control genuino.
• Registro de peligros muerto. Un documento escrito una vez y nunca revisado después del lanzamiento. Antídoto: mantenerlo vivo; alimentarlo con incidentes y cambios.
• Sobrecarga de alertas. Tantas advertencias que los clínicos las ignoran todas, incluyendo las vitales. Antídoto: diseño de factores humanos; cada alerta debe ganarse su lugar.
• Cultura de culpa. Castigar a individuos por cuasi-incidentes, de modo que el reporte se seca. Antídoto: una cultura justa y basada en sistemas alineada con PSIRF.
• Umbral regulatorio omitido. Enviar SaMD sin reconocerlo como un dispositivo regulado. Antídoto: evaluar y documentar el estatus de dispositivo médico temprano.

Modelo de madurez#

Lista de verificación#

• Un Oficial de Seguridad Clínica competente, en ejercicio y formado está nombrado para cada sistema, con tiempo y autoridad para decir "todavía no".
• Un archivo de gestión de riesgo clínico, un registro de peligros vivo y un caso de seguridad clínica existen para cada sistema dentro del alcance.
• La identificación de peligros comenzó en el descubrimiento, con clínicos de primera línea en la sala.
• La organización que despliega ha realizado su propia evaluación DCB0160, no solo aceptado el caso DCB0129 del proveedor.
• Los controles de riesgo prefieren diseñar fuera sobre alertas sobre formación, con el riesgo residual reducido a ALARP y justificado.
• El estatus de dispositivo médico / SaMD ha sido evaluado y documentado, y las obligaciones de la MHRA / IEC 62304 se han involucrado donde sea relevante.
• El DTAC se ha completado como un piso, emparejado con la gestión de riesgo clínico local.
• Las pruebas de factores humanos y usabilidad en condiciones realistas se han realizado; la carga de alertas está controlada.
• Los incidentes en vivo (LFPSE) y el aprendizaje de PSIRF se retroalimentan al registro de peligros como un proceso permanente.
• Reportar cuasi-incidentes y desafiar un lanzamiento por motivos de seguridad es visiblemente seguro y esperado.

Fuentes clave#

• NHS England — DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems.
• NHS England — DCB0160: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems.
• NHS England — formación de Oficial de Seguridad Clínica y orientación de gestión de riesgo clínico.
• NHS England — Criterios de Evaluación de Tecnología Digital (DTAC).
• MHRA — orientación Software and Artificial Intelligence (AI) as a Medical Device.
• IEC — IEC 62304: Medical device software — software life cycle processes.
• ISO — ISO 14971: Application of risk management to medical devices.
• NHS England — servicio Learn from Patient Safety Events (LFPSE).
• NHS England — Patient Safety Incident Response Framework (PSIRF).
• Organización Mundial de la Salud — Global Patient Safety Action Plan 2021–2030.

Referencias#

1. Patient safety — Wikipedia — https://en.wikipedia.org/wiki/Patient_safety
2. Risk management — Wikipedia — https://en.wikipedia.org/wiki/Risk_management
3. Hazard analysis — Wikipedia — https://en.wikipedia.org/wiki/Hazard_analysis
4. Safety case — Wikipedia — https://en.wikipedia.org/wiki/Safety_case
5. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
6. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
7. Ergonomics (human factors) — Wikipedia — https://en.wikipedia.org/wiki/Ergonomics
8. Safety culture — Wikipedia — https://en.wikipedia.org/wiki/Safety_culture
9. As low as reasonably practicable (ALARP) — Wikipedia — https://en.wikipedia.org/wiki/As_low_as_reasonably_practicable
10. Root-cause analysis — Wikipedia — https://en.wikipedia.org/wiki/Root-cause_analysis
11. IEC 62304 — Wikipedia — https://en.wikipedia.org/wiki/IEC_62304
12. DCB0129: Clinical Risk Management in the Manufacture of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
13. DCB0160: Clinical Risk Management in the Deployment and Use of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
14. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
15. Software and Artificial Intelligence (AI) as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
16. IEC 62304: Medical device software — software life cycle processes — International Electrotechnical Commission — https://www.iso.org/standard/38421.html
17. ISO 14971: Application of risk management to medical devices — International Organization for Standardization — https://www.iso.org/standard/72704.html
18. Learn from Patient Safety Events (LFPSE) service — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/learning-from-patient-safety-events/
19. Patient Safety Incident Response Framework (PSIRF) — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/incident-response-framework/
20. Global Patient Safety Action Plan 2021–2030 — World Health Organization — https://www.who.int/teams/integrated-health-services/patient-safety/policy/global-patient-safety-action-plan