¿Se puede aplicar 'Agile' a los equipos de TI de atención médica?

¿Se puede emplear a Agile en un campo como Healthcare IT, donde gran parte de la atención al paciente depende de la calidad y la entrega oportuna de los sistemas?

Sí, el desarrollo ágil desempeña absolutamente un papel en el desarrollo de TI de atención médica. Nadie, ni el usuario final, ni el paciente y, desde luego, no el equipo de desarrollo están bien atendidos por un proceso de desarrollo mal hecho. Teniendo en cuenta algunos de los principios que subyacen en el manifiesto Ágil (lista desgarrada descaradamente de Wikipedia con mi comentario):

• Satisfacción del cliente mediante la entrega rápida de software útil . ¿Cuándo no es este un objetivo?
• Bienvenido a los requisitos cambiantes, incluso tarde en el desarrollo . Healthcare IT se integra en un campo que, aunque está absolutamente inundado de tecnología, no está particularmente enfocado en IT. El potencial para un sistema diseñado para "acertar" desde el principio es bastante bajo.
• El software de trabajo se entrega con frecuencia (semanas en lugar de meses) . Como usuario final de algunas de estas cosas, Dios me encantaría. Los cambios rápidos y de trabajo son invaluables, y lo que convierte a Healthcare IT de "lo que necesitamos hacer" a "lo que cambia la forma en que hago mi trabajo".
• El software de trabajo es la principal medida de progreso . Tiene sentido en la mayoría de las aplicaciones, por lo que realmente no hay razón para que no se extienda a HIT.
• Desarrollo sostenible, capaz de mantener un ritmo constante . Usted ve esto en todo el cuidado de la salud, desde la vigilancia de infecciones hasta el HIT hasta las instalaciones. La atención médica no es un ciclo de auge o caída, es un ritmo constante.
• Cooperación cercana y diaria entre empresarios y desarrolladores . La mayoría de HIT no es una herramienta para desarrolladores. Es una herramienta hecha por desarrolladores. El contacto con el cliente es, y debe ser, clave. También es mucho más fácil adoptar un sistema si funciona y se integra en el flujo de trabajo del cliente, en lugar de tener que ser agregado, parcheado, etc.
• La conversación cara a cara es la mejor forma de comunicación (ubicación conjunta) . Desde mi interacción con los médicos, es mucho más fácil hacer cosas en persona, preferiblemente con papel, que de cualquier otra manera.
• Los proyectos se basan en individuos motivados, en los que se debe confiar . Esto es algo que mejorará tu vida, así que sí, debería adoptarse;)
• Atención continua a la excelencia técnica y buen diseño . Este es de nuevo uno de esos "todos deberían hacer esto, así que, por supuesto, tú deberías". Pero considere la complejidad de los sistemas HIT y las innumerables formas en que terminan siendo utilizados, día tras día. Un sistema de mala calidad no lo va a cortar.
• Simplicidad . Debería funcionar fuera de la caja. Debería funcionar bien, todo el tiempo y en la forma en que se supone que debe hacerlo. La gente es idiota Los trabajadores de la salud son personas. Por lo tanto ... ya sabes el resto. La simplicidad ayuda.
• Equipos autoorganizados . Este podría ser un poco más difícil para HIT. Honestamente, no tengo la confianza suficiente para decir de una forma u otra si la autoorganización en este entorno es buena o no.
• Adaptación regular a las circunstancias cambiantes . HIT es una industria activa y en crecimiento con cargas regulatorias complejas y cambiantes. Ser capaz de adaptarse parece una idea decente.

Las discusiones sobre el uso del desarrollo de software de dispositivos médicos ágiles en un entorno regulado por la FDA han existido por un tiempo y son relevantes para esta pregunta. Aquí hay algunas razones de por qué:

1. Los pros y los contras del desarrollo Waterfall vs. Iterative son esencialmente los mismos y deberían considerarse para cualquier proyecto de IT de salud.
2. Los sistemas de calidad obligatorios de la FDA (ver Principios generales de validación de software; Orientación final para la industria y el personal de la FDA ) para el desarrollo de software de dispositivos médicos utilizados es el estándar de oro de la industria. Cabe señalar que estas regulaciones no dictan ninguna metodología de desarrollo particular. En cualquier caso, la calidad del software Health IT mejoraría enormemente si todos siguieran estas mejores prácticas.
3. La mayoría del desarrollo de software de Heath IT no opera actualmente bajo estos estándares regulatorios de la FDA. A medida que las barreras para la interoperabilidad de dispositivos médicos siguen cayendo, en particular para las plataformas móviles, esto es probable que va a cambiar - ver las direcciones de la FDA Aplicaciones Móviles médica .
4. Además, si está desarrollando software comercial de TI de salud, debe preguntarse si está creando un sistema de datos de dispositivos médicos (MDDS): ¿Mi producto es un MDDS?

La respuesta corta es sí". Una respuesta más larga pero más precisa es "Si te lo tomas en serio".

Hay algunos temas a tener en cuenta, que me gustaría separar en preocupaciones relacionadas con (a) la seguridad del paciente y la calidad del producto, y (b) la regulación de la industria.

Por el lado de la seguridad y la calidad, tenga en cuenta que hacer un software seguro es difícil. Unos pocos programadores buenos con algunos conocimientos de dominio pueden obtener un software increíblemente útil que es bastante seguro. Si forman parte del despliegue en un entorno clínico local, y pueden seguir respondiendo y ajustándose a los eventos durante el despliegue y el uso del software, el software puede proporcionar valor, salvar o mejorar vidas con solo unas pocas lesiones o muertes relacionadas con errores de uso o errores de software. Pero el software requerirá que los programadores estén allí, todo el tiempo, respondiendo, co-evolucionando el software a medida que evoluciona el uso del software. Este no es un proceso escalable y cuando los programadores mueren o se aburren, el sistema puede volverse muy peligroso muy rápidamente. Para mejorar estos resultados y crear software seguro, Hay pasos importantes del proceso de desarrollo que deben tomarse mientras se desarrolla el software. Una buena introducción "lista para usar" se puede encontrar en el estándar internacional para el desarrollo de software de dispositivos médicos, ISO / IEC 62304. El concepto principal es la gestión de riesgos de seguridad en todas las etapas: durante el análisis de casos de uso y el desarrollo de historias, requisitos aclaración, diseño de sistemas y arquitectura, implementación, pruebas de unidad e integración. Ser ágil no hará que nada de este trabajo desaparezca, o sea menos difícil, pero al enfocarse en la creación de valor y eliminar el trabajo (como características innecesarias o ciclos de prueba / reparación de verificación excesiva) que no crea valor, el desarrollo ágil puede permitir que un equipo integre este trabajo en el desarrollo, lo que resulta en un software más seguro desarrollado al mismo tiempo. Las prácticas de desarrollo iterativas comúnmente utilizadas por los equipos ágiles son muy adecuadas para realizar el trabajo de gestión de riesgos de seguridad, evolucionando a lo largo de la vida del proyecto en lugar de ser una ocurrencia tardía. Y después de que el software esté operativo, se deben considerar los comentarios de los usuarios y cualquier evento que pueda causar lesiones, individualmente y en conjunto, para mantener el software seguro de usar. Agile puede ayudar aquí si proporciona un proceso rápido y seguro para incorporar cambios sin romper otras partes del sistema, lo que a su vez requiere una buena arquitectura e interacciones de diseño bien entendidas que se crearon cuando se desarrolló el software. evolucionando a lo largo de la vida del proyecto en lugar de ser una ocurrencia tardía. Y después de que el software esté operativo, se deben considerar los comentarios de los usuarios y cualquier evento que pueda causar lesiones, individualmente y en conjunto, para mantener el software seguro de usar. Agile puede ayudar aquí si proporciona un proceso rápido y seguro para incorporar cambios sin romper otras partes del sistema, lo que a su vez requiere una buena arquitectura e interacciones de diseño bien entendidas que se crearon cuando se desarrolló el software. evolucionando a lo largo de la vida del proyecto en lugar de ser una ocurrencia tardía. Y después de que el software esté operativo, se deben considerar los comentarios de los usuarios y cualquier evento que pueda provocar lesiones, individualmente y en conjunto, para mantener el software seguro de usar. Agile puede ayudar aquí si proporciona un proceso rápido y seguro para incorporar cambios sin romper otras partes del sistema, lo que a su vez requiere una buena arquitectura e interacciones de diseño bien entendidas que se crearon cuando se desarrolló el software.

La segunda preocupación es regulatoria. En un mundo ideal, las normas de seguridad se aplicarían a todos los productos que pudieran ser lo suficientemente peligrosos, y un proveedor podría cumplir haciendo algunas cosas simples una vez que comiencen a cruzar la línea. En la práctica, las regulaciones globales son complejas y rápidas en esta industria, lo que significa que un día puede desarrollar una pequeña aplicación para iPhone que muestra algunos datos médicos, y al siguiente se espera que cumpla con las normas ISO y FDA para la "gestión de calidad sistema "o QMS. Eso puede dar miedo a las empresas que no han tenido un SGC formal en el pasado. Y ágil puede exacerbar esto porque puede comenzar con un concepto de producto y, a través del desarrollo evolutivo, ingresar involuntariamente a un uso previsto regulado (como mostrar datos de diagnóstico clínico a un usuario). Es octubre de 2011; Mi consejo para cualquier compañía que esté considerando comercializar un producto que tenga "salud", "medicina", "atención médica" en el nombre de la categoría es que deben tener un plan para cuando el producto que fabrica se regule por uno o más reguladores de dispositivos médicos en todo el mundo. Una vez más, ágil puede ayudar, porque las prácticas ágiles generalmente producen (o podrían producir fácilmente) productos conformes para satisfacer a los clientes reguladores tanto para envíos de autorización previos al mercado (como FDA 510k), certificación (como ISO 13485) y operaciones posteriores a la comercialización. El desarrollo de prueba primero encaja perfectamente en el software médico. La integración continua, las pruebas unitarias automatizadas y los metadatos de sprint SCRUM pueden proporcionar evidencia objetiva completa de que la gestión de riesgos y la verificación adecuada se realizan no solo como una ocurrencia tardía sino que se incorporan al proceso de desarrollo. En la mayoría de los casos, creo que ágil produce más artefactos que "cascada", tal vez no de la misma forma. Pero la conversión de las salidas en algo que satisfaga a los reguladores es un problema relativamente pequeño para resolver.

En resumen ... sí, Virginia, existe un desarrollo ágil para el desarrollo de software de TI (y otros dispositivos médicos). Como todas las cosas ágiles, se necesita dedicación para procesar, apoyo comercial y coraje.

Sí, una de las premisas del desarrollo ágil es la participación del cliente. Esto es crítico en los sistemas y procesos de TI de atención médica. Los departamentos de TI de atención médica tomarán mejores decisiones si un representante del cliente está involucrado y brinda información sobre cómo las decisiones afectarán la atención al paciente.

Creo que es posible, pero la industria necesita un gran cambio de paradigma. Estoy en mi segundo año como desarrollador de atención médica, y la confianza y la autoorganización no son evidentes. El cuidado de la salud se beneficiaría enormemente de adoptar formalmente ágil, ya que de todos modos es principalmente un caos, con un desarrollo iterativo llamado "thrash" y requisitos de cambio tardío porque, bueno, el diseño inicial grande no funciona de todos modos.

Entiendo tu pregunta. Un buen ejemplo de desarrollo ágil es crear un sitio web para alguien. Por lo general, un cliente no sabe exactamente lo que quiere, por lo que hay mucha interacción con el cliente.

La informática sanitaria podría parecer un campo muy predefinido en la informática; con sus estándares estrictos (DICOM, HL7) parece que solo hay una forma de implementarlos, pero también hay muchas preferencias y toma de decisiones.

En mi opinión, sea cual sea el producto que esté fabricando, no podrá determinar TODOS los requisitos con anticipación, por lo que un método de desarrollo de software ágil funciona muy bien.

Como se señaló, la respuesta es sí.

Al aplicar Agile a áreas reguladas o de alto riesgo, debe definir "Listo" en cada iteración de modo que se incluyan el cumplimiento normativo y otras estrategias de mitigación de riesgos. Por ejemplo, esto puede requerir que la documentación de control de calidad, la trazabilidad de los requisitos, la auditoría de seguridad y otras acciones se completen en cada iteración.

Existe un buen arte y práctica, por ejemplo, para la aplicación de enfoques ágiles en entornos regulados por la FDA.

La respuesta corta: sí. Hay un buen blog sobre Agile en entornos de alta seguridad que ofrece algunos consejos.

Sin embargo, hay algunos compromisos que deben hacerse. Considere el Manifiesto Ágil :

Individuos e interacciones sobre procesos y herramientas.

Software de trabajo sobre documentación completa

Colaboración del cliente sobre negociación de contrato

Responder al cambio sobre seguir un plan

Los organismos reguladores valoran el lado izquierdo tanto como los equipos ágiles, pero requieren más énfasis en el lado derecho de lo que haría un equipo ágil típico. La FDA, por ejemplo, requiere que valide sus procesos y herramientas, solicita un diseño bastante completo y documentación de prueba, y definitivamente requiere una buena cantidad de planificación.

Por otro lado, muchos principios ágiles encajan muy bien en el mundo de la salud, incluidos:

• TDD y programación de pares: aumente la calidad
• Estrechos bucles de comentarios de los clientes: la validación temprana es excelente
• Planificación iterativa: los organismos reguladores se tratan de planificación

Algunas disciplinas ya son de naturaleza ágil. La enfermería, por ejemplo, se basa en ciclos de 'evaluación-evaluación-planificación-intervención' que dependen de múltiples iteraciones de diagnóstico / pronóstico para lograr gradualmente resultados finales.

Sin embargo, sería una combinación fatal tratar de sugerir que los servicios de atención médica prestados de tal manera son específicamente adecuados para una aplicación esencialmente única de desarrollo de software ágil hacia una herramienta o sistema de software para su uso en la prestación de dicho servicio.

AAMI está trabajando activamente en un Informe de información técnica titulado:
AAMI TIR SW1, Orientación sobre el uso de prácticas ágiles en el desarrollo de software de dispositivos médicos.

He oído que puede publicarse en 2012.

Discute la alineación de los principios del Manifiesto Ágil (ver la respuesta de EpiGrads) con los requisitos reglamentarios, procesos típicos y otros aspectos prácticos del producto asociados con el software de dispositivos médicos.