Tres pasos para el desarrollo rápido de dispositivos médicos de alta calidad con cumplimiento de normas regulatorias

Integración de software en todo el ciclo de vida del desarrollo de productos

Los desarrolladores de dispositivos médicos se enfrentan con desafíos que son diferentes a los del desarrollo de productos en la mayoría de las industrias. El principal es el cumplimiento estricto de las normas de seguridad y estándares de la industria. Tres expertos de IBM describen tres pasos que ayudan a acelerar el desarrollo sin sacrificar la producción de dispositivos de alta calidad que cumplan con las normas.

Keith Collyer, PhD, Senior Solution Manager, Electronics and Medical Devices Industry Solutions, IBM

author photoEl Dr. Keith Collyer es experto en asuntos de ingeniería en sistemas y requisitos. Se capacitó como ingeniero electrónico y más tarde se dedicó al desarrollo de software. Su interés en aspectos relacionados con la "gente" lo acercó a la gestión de proyectos, al control de la calidad y los procesos, sin perder de vista la necesidad de desarrollar sistemas que satisfagan necesidades reales. A lo largo de casi toda su carrera profesional, se dedicó a ayudar a organizaciones grandes y pequeñas a introducir la gestión de requisitos. Los aspectos clave de esta actividad son: garantizar que el cliente entienda la necesidad de la gestión de requisitos y sus beneficios, aclarar y definir con el cliente los procesos implicados, incluir la información necesaria y las interrelaciones, y definir una implementación IBM Rational DOORS para responder mejor a las necesidades del cliente.



Martin R. Bakal, Worldwide Offering Manager, Electronics Industry, IBM

author photoMarty cuenta con más de una década de experiencia en varias capacidades en la industria del software y los sistemas integrados, trabajando con clientes de todo el mundo en diversas industrias tales como consumo, telecomunicaciones, dispositivos médicos y automotriz. Actualmente, es gestor de ofertas del software IBM Rational para la industria de electrónica. Parte de este rol consiste en coordinar la iniciativa para servir a la industria. Se presentó en muchas conferencias y escribió artículos para revistas.



Paridhi Verma, Go-to-Market Manager, Electronics Industry, IBM China

Paridhi Verma es gestora de mercado del software IBM Rational para la industria electrónica. Tiene una vasta experiencia en desarrollo electrónico, automotor, móvil y aeroespacial y de defensa. También cuenta con 10 años de experiencia de trabajo en IBM Research como ingeniera de redes y seguridad, donde diseñó e implementó sistemas de comercio electrónico seguro. Tiene una maestría en Ingeniería Eléctrica del Instituto Politécnico de la Universidad de Nueva York y es propietaria de la patente del sistema de alertas de emergencias de Internet.



13-05-2013

Comparación del desarrollo de dispositivos médicos con el desarrollo de otros productos

En muchos sentidos, el desarrollo de dispositivos médicos no difiere del desarrollo de otro tipo de producto. Por lo tanto, analicemos primero las similitudes.

Similitudes con el desarrollo de dispositivos médicos

Todo desarrollo de producto implica estos requisitos:

  • Comprender las necesidades de las partes interesadas y las restricciones relacionadas
  • Implementar una manera de cumplir con los requisitos
  • Comprobar que cumple con los requisitos
  • Garantizar una ganancia suficiente para permanecer en el negocio

El desarrollo de dispositivos médicos enfrenta desafíos específicos que también afectan a la mayoría de las compañías en la actualidad:

  • Mayor competencia
  • Necesidad de vender a mercados globales
  • Necesidad de reducir el tiempo de desarrollo y de salida al mercado

Diferencias

La diferencia más obvia entre el desarrollo de dispositivos médicos y el desarrollo de productos en general es el entorno altamente regulado en que se desarrollan, se venden y se usan los dispositivos médicos. Desde sus inicios, la industria ha estado trabajando dentro de marcos de conformidad estrictos. Esto tiene implicaciones que deben considerarse con cuidado:

  • Las agencias regulatorias estrictas exigen pruebas de conformidad y, lo que es aún más interesante, las normas varían según el mercado.
  • Los conflictos con las organizaciones regulatorias pueden ocasionar daños significativos.
  • Los ingenieros deben demostrar rastreabilidad desde las necesidades del usuario hasta los productos entregados.
  • Los fabricantes deben contar con sistemas para garantizar la gestión de las solicitudes y las quejas de los clientes y, de ser necesario, realizar cambios en los productos.
  • Todo debe documentarse e informarse.
  • Las fallas en los productos pueden ocasionar lesiones o incluso la muerte.

La seguridad ha sido siempre uno de los elementos más importantes en el desarrollo de dispositivos médicos. Además, el software emerge como diferenciador clave. Las innovaciones fueron impulsadas por la variedad de software que van desde la cirugía robótica hasta la automatización del trabajo de laboratorio y la presentación de informes de resultados. El software integrado es capaz de superar los desafíos del desarrollo rápido de productos porque los usuarios pueden añadir funcionalidades más rápido al software que al hardware. El desafío es equilibrar el uso de software para producir dispositivos nuevos con las restricciones de las normas de seguridad y la complejidad del trabajo en un entorno interdisciplinario donde la seguridad es fundamental. Si una empresa no puede integrar sus disciplinas para posibilitar la colaboración en equipo, aumenta el tiempo de salida al mercado de productos nuevos. Por lo tanto, es sumamente importante vincular el desarrollo de software con el diseño de sistemas y el resto de los procesos de desarrollo.

Es esencial considerar si hay planes para vender un dispositivo en solo un país o a nivel internacional. Incluso cuando se vende en solo un país, se deben considerar las normas de los lugares donde se lleva a cabo la fabricación. Por ejemplo, las normas de la Administración de Medicamentos y Alimentos (FDA) de los Estados Unidos se aplican a los dispositivos médicos o a piezas de dispositivos vendidoso fabricados en los EE. UU.

Casi todos deben tener en cuenta distintos conjuntos de requisitos normativos. Esto es ambiguo porque estas normas generalmente se basan en filosofías diferentes. Las normas nacionales, como las de la FDA, generalmente están basadas en resultados, no en la prescripción de actividades específicas. Sin embargo, muchos estándares internacionales, como ISO o IEC, prescriben formas de trabajo. Las compañías de dispositivos médicos deben encontrar un equilibrio. Y eso no es todo. Muchas organizaciones nacionales se están inclinando al uso de estas normas internacionales. Todo esto contribuye a la complejidad a la hora de garantizar la conformidad con las normas aplicables.

Como si todo esto fuera poco, recuerde que el incumplimiento de estas normas puede traer consecuencias graves, incluidas grandes multas, el cierre de la empresa e incluso el encarcelamiento de los ejecutivos responsables.

Repercusiones y asistencia

En la práctica, todo esto significa que las personas responsables de los procesos en las empresas de dispositivos médicos deben conocer las diversas normas pero, si hacen bien su trabajo, no afectará a los desarrolladores de manera significativa.

La extensión para dispositivos médicos de la solución IBM® Rational® para ingeniería de sistemas y software ayuda a las compañías de dispositivos médicos a enfrentar estos desafíos.


Tres pasos para el desarrollo más rápido con cumplimiento de objetivos relacionados con la calidad y la seguridad

Reconocemos los problemas que enfrentan los desarrolladores de dispositivos médicos. Como respuesta, creamos la solución Rational para el desarrollo de dispositivos médicos (consulte los recursos para encontrar enlaces a información adicional). Brinda soporte a todas las actividades clave del desarrollo: la gestión de colaboración, configuración, validación y prueba, verificación, modelado y requisitos. Esta solución consta de los siguientes elementos:

  • Un conjunto de herramientas integrado
  • Prácticas específicas de dispositivos médicos e ingeniería en sistemas
  • Soporte de ingenieros de campo con experiencia.

Las prácticas relativas a los dispositivos médicos se concentran en el soporte del abordaje de control del diseño de la FDA y la IEC 62304, así como material para respaldar la validación de uso previsto del software de gestión de requisitos IBM® Rational® DOORS® dentrode su proceso. Las prácticas brindan una base para desarrollar el contenido específico de una organización. Muchas personas buscan "prácticas recomendadas" en áreas industriales, pero no existe realmente un solo conjunto de prácticas recomendadas para el desarrollo de dispositivos médicos. Esencialmente, la práctica recomendada para la ingeniería consiste en entregar lo que desean los interesados, dentro de las restricciones necesarias de tiempo, recursos, normas, etc. Usted podría decir que todo se reduce al mismo consejo que se da comúnmente a los representadores, que podría reformularse como "Diga lo que va a hacer, hágalo y luego demuestre que lo ha hecho".

Identificamos dos temas comunes importantes para los dispositivos médicos:

  • Rastreabilidad. No solo para los requisitos, sino también para el diseño, las decisiones relativas al diseño, la verificación, la validación, las pruebas, etc.
  • Documentación. Toda industria regulada debe ser capaz de producir documentación que demuestre lo que se ha hecho. No obstante, muchas personas creen que la necesidad de producir documentación integral significa aplicar un abordaje estilo cascada de creación de documentación completa de una "etapa" antes de avanzar a la siguiente. Lo importante es producir documentación suficiente para justificar el trabajo que se está haciendo en cualquier punto. Esto respalda una gran variedad de ciclos de vida de desarrollo, desde el abordaje estilo cascada hasta otros más ágiles.

La solución IBM Rational para el desarrollo de dispositivos médicos brinda acceso a contenido específico de contextos que puede personalizar en cualquier momento. Por ejemplo, mientras escriben requisitos en DOORS, los ingenieros pueden encontrar las prácticas recomendadas para garantizar que los requisitos concuerden con el ciclo de vida de la compañía, determinar cómo se implementan estas prácticas en DOORS y revisar guías de alto nivel sobre temas como la rastreabilidad. Las siguientes secciones proporcionan más detalles.

Creemos que al adoptar estos tres pasos, es posible desarrollar dispositivos médicos rápidamente conservando el cumplimiento de las pautas regulatorias:

  1. Mejorar las actividades de procesos claves para probar la conformidad
  2. Identificar la herramienta necesaria para cada rol
  3. Implementar un conjunto de herramientas integrado

En conjunto, estos pasos fomentan la innovación ya que permiten a los equipos colaborar y centrarse en el diseño.

Paso 1. Mejorar las actividades de procesos clave para probar la conformidad

En el proceso de cascada tradicional, primero se crean los requisitos. Se espera que el desarrollo (la codificación) cumpla con los requisitos. Los métodos ágiles como la gestión de proyectos scrum trabajan de manera iterativa y han demostrado ser exitosos en el entendimiento y la entrega de lo que los usuarios necesitan. Los usuarios pueden optar por seguir estos u otros flujos de trabajo de procesos ya que no hay un proceso específico exigido en los estándares como IEC 62304 y 21 CFR Parte 820. No obstante, para cumplir con estos estándares, las compañías deben examinar sus procesos de desarrollo para determinar la compatibilidad con diversos mandatos normativos.

El objetivo de los requisitos de control de diseño de la FDA en CFR 21 Parte 820 es asegurarse de que el producto entregado cumpla con las necesidades del usuario explícitas y con las necesidades normativas. Los requisitos de control del diseño están basados en resultados y no en prescribir cómo deben hacerse las cosas.

La creación de un producto implica varios procesos. Estos pueden dividirse de varias maneras, pero los que se muestran en la Figura 1 son típicos. Los procesos mostrados pueden producirse en paralelo, y la flecha indica el flujo general de la información. Por ejemplo, no es posible diseñar hasta cumplir con algunos requisitos, no es posible desarrollar nada hasta tener algo diseñado, y no es posible hacer pruebas hasta tener algún producto. No obstante, ninguno de estos procesos debe estar "terminado" para iniciar el siguiente.

Figura 1. Procesos involucrados en la creación de un producto
requirements analysis, design, development, tests
Análisis de requisitos
Los requisitos deben comenzar con lo que necesitan los interesados. A partir de estos, es posible desarrollar de manera iterativa requisitos de sistemas de mayor nivel y requisitos derivados de menor nivel mediante un proceso ágil. Independientemente del proceso utilizado, es importante usar una herramienta para crear registros con una aprobación y un flujo de trabajo definidos. Los estándares normativos indican qué requisitos se vinculan con artefactos en todas las demás fases del proceso. Es fundamental validar los requisitos en función del material de origen.
 
Diseño
Este proceso comienza con la transformación de los requisitos en una arquitectura coherente, de modo que los ingenieros y desarrolladores puedan entender cómo se cumplirá cada requisito y para garantizar que no haya superposiciones ni brechas en los requisitos. Tenga en cuenta que no es necesario que esta arquitectura esté completa. Este proceso se repite a lo largo de todo el desarrollo, en todos los niveles. Similar al análisis de requisitos, es una buena práctica validar los resultados de estas tareas con técnicas como la simulación y los modelos ejecutables.
 
Desarrollo
El desarrollo hace referencia al proceso de tomar el diseño y convertirlo en un producto con hardware o software. Una vez tomadas e implementadas las decisiones de diseño, estas tienen repercusiones en niveles inferiores. Los desarrolladores deben trabajar dentro de las restricciones impuestas o discutir la flexibilización de dichas restricciones.
 
Pruebas
Las pruebas se llevan a cabo en todo el proceso de desarrollo y fabricación. Las pruebas en función de los requisitos del sistema (o del componente) verifican el sistema y controlan que se haya desarrollado correctamente. La prueba de nivel de unidad verifica que cada componente funcione, mientras que la prueba de integración se asegura de que los diferentes componentes funcionen juntos y no ocasionen efectos secundarios adversos. Las pruebas en función de los requisitos de las partes interesadas validan todo el sistema como una caja negra para asegurarse de que cuente con la funcionalidad correcta. Cada disciplina de prueba es fundamental para cumplir con los requisitos del sistema y para garantizar que cumpla con los estándares relevantes.
 
Presentación de informes
La presentación de informes no se incluye en la Figura 1 porque está presente en todos los procesos. La demostración de la conformidad normativa es mucho más fácil con la presentación automatizada de informes. Esto es especialmente importante cuando las entidades normativas solicitan datos periódicamente. Muchos productores de dispositivos médicos ven la presentación de informes no solo como una manera de probar la rastreabilidad sino también como una manera de proteger sus sistemas de desarrollo de aquellos que no son miembros del proyecto, evitando de esta manera todo tipo de manipulación o pérdida de datos. Además, usan la presentación de informes para conservar toda la información junta en un repositorio. Una opción es imprimir y firmar estos documentos individualmente, pero esto lleva mucho tiempo, es costoso y tedioso. En cambio, cada vez es más común usar firmas electrónicas. Esto solo puede lograrse mediante posibilidades de presentación de informes sólidas.
 

La revisión de estas actividades clave brinda información sobre cuáles requieren mejoras. Luego, el equipo que revisa cada proceso para especificar las necesidades que debe satisfacer para cumplir con las normas regulatorias. Una vez establecidas esas necesidades, deben implementarse las herramientas apropiadas, lo que nos lleva al Paso 2.

Paso 2. Identificación de las herramientas necesarias para cada rol

Cada rol de equipo necesita herramientas específicas relacionadas. A menos que se cumplan estas necesidades, los miembros del equipo de desarrollo del producto no podrán asumir sus roles completamente.

Tabla 1. Herramientas necesarias para los roles involucrados en el desarrollo de productos
RolNecesidades
Ingenieros en sistemasUn entorno colaborativo para el análisis de requisitos, la gestión de arquitecturas, la gestión de configuraciones y cambios, los elementos de trabajo y conjuntos de cambios
Líderes de equipo de proyecto, desarrollo y pruebaGestión de trabajo y planes para los equipos de entrega de sistemas para todo el ciclo de vida del proyecto, colaboración de equipo
Ingenieros de hardwareSolución para desarrollar hardware, elementos de trabajo, conjuntos de cambio y rastreabilidad en sentido ascendente de productos de trabajo de ingeniería y rastreabilidad en sentido descendente de la integración y validación de sistemas
Ingenieros de softwareSolución de desarrollo de software completa para codificar (tal vez en base a modelos), gestión de configuraciones, elementos de trabajo, conjuntos de cambio, rastreabilidad en sentido ascendente de productos de trabajo de ingeniería en sistemas y rastreabilidad en sentido descendente de la integración y la validación de sistemas
Ingenieros de seguridadCentrarse en los requisitos de seguridad y en la garantía
Ingenieros de confiabilidadConfiabilidad de sistemas tomada por métricas, como el tiempo medio entre fallas y disponibilidad.
Ingenieros de calidadEntorno colaborativo para definir necesidades relativas a la calidad, para implementar procesos y garantizar que las aprobaciones estén implementadas correctamente
EvaluadoresEntorno colaborativo para la planificación, construcción y ejecución de pruebas, la gestión de la validación de sistemas y las pruebas de aceptación, y para la mejora de la eficacia de la asignación de recursos y pruebas

Sin embargo, contar con las mejores herramientas no resultará eficaz sin una vinculación adecuada entre ellas. Esto nos lleva al Paso 3.

Paso 3. Implementación de un conjunto de herramientas integrado

Sin integraciones en todo el ciclo de vida de entrega del sistema, los equipos trabajan en silos. Para proporcionar dispositivos médicos que respondan a las necesidades cambiantes del mercado, los equipos de ingeniería deben desempeñarse de manera eficaz y gestionar todos los artefactos mediante la colaboración. La Figura 2 muestra cómo la solución IBM Rational para ingeniería de sistemas y software brinda estos requisitos de integración, arquitectura, diseño y desarrollo, gestión de configuraciones y cambios y control de calidad.

Como muestra el diagrama de la Figura 2, la solución integrada Rational ayuda a satisfacer las necesidades de los roles de cada equipo. Es la combinación lo que hace que esta solución sea tan eficiente.

Figura 2. Solución Rational para ingeniería de sistemas y software
diagram of open lifecycle integration elements

Los tres pasos —la mejora de las actividades de procesos clave, la identificación de herramientas necesarias para cada rol y el conjunto de herramientas integrado— requieren una solución completa en lugar de adoptar una herramienta basada en puntos. En la Tabla 2 se resumen los pasos y se muestra la correlación entre la solución integrada Rational y las actividades y necesidades, y se resalta el vínculo con las herramientas.

Tabla 2. Correlación de actividades, herramientas y soluciones Rational
Paso 1. Mejora de actividades de procesos clavePaso 2. Herramientas para roles específicos de equiposPaso 3. Soluciones integradas
Análisis de requisitosInformesIngenieros en sistemas:
Rational DOORS, IBM® Rational® Rhapsody®, IBM® Rational Team Concert™
Rational DOORS se integra con el software Rational Rhapsody para tareas de ingeniería en sistemas. El software Rational Team Concert se usa para la gestión de ciclos de vida de los artefactos de cambio.
DiseñoInformesIngenieros en sistemas o ingenieros de confiabilidad:
DOORS, Rational Rhapsody
El software Rational DOORS y Rational Rhapsody con el perfil de análisis de seguridad se usan para identificar y clasificar peligros, errores y medidas de seguridad.
DesarrolloInformesLíderes de equipos de proyecto, desarrollo y pruebas:
Rational Team Concert, IBM® Rational®

Ingenieros de software de gestión de calidad: Rational Team Concert, DOORS, Rhapsody, Rational Quality Manager
El software Rational Team Concert y Rational Quality Manager software ayudan con la transparencia en vivo mediante la colaboración, la automatización y la presentación de informes del software Rational Rhapsody de productos de trabajo de entrega del sistema, junto con Rational Team Concert en Eclipse IDE, integra desarrollos basados en modelos mediante UML.
PruebasInformesEvaluadores de software y sistemas:
Rational Quality Manager
El software Rational Quality Manager brinda un entorno colaborativo para la gestión de validación de sistemas y las pruebas de aceptación, y crea rastreabilidad en todo el ciclo de vida.

Resumen

Los tres pasos que discutimos aquí pueden ayudar a acelerar el desarrollo de sus productos. Para producir dispositivos médicos que cumplan con las necesidades y los estándares cambiantes del cuidado de la salud, el equipo que diseña los sistemas de los dispositivos médicos debe colaborar para gestionar todos los productos de trabajo del desarrollo. El software IBM Rational brinda una solución integrada para estos equipos de ingeniería de modo que puedan abordar los desafíos del desarrollo de software de dispositivos médicos. La solución ofrece un proceso basado en principios de desarrollo ágil y añade el modelado de arquitecturas, la gestión de requisitos sofisticada y la posibilidad de presentar informes de manera automática no solo para que los dispositivos médicos cumplan con los diversos estándares normativos como 21 CFR Parte 820 e IEC 62304, sino que también reduce el esfuerzo necesario para probar esta conformidad mediante la vinculación de herramientas de desarrollo.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Rational
ArticleID=929550
ArticleTitle=Tres pasos para el desarrollo rápido de dispositivos médicos de alta calidad con cumplimiento de normas regulatorias
publish-date=05132013