Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo los microservicios podrían salvar el IoT médico


 A medida que el creciente número de dispositivos de IoT para consumidores nos facilita la vida, recopilan grandes cantidades de datos útiles Esta tendencia acaba de comenzar a abrirse camino en las industrias del fitness y la salud , con dispositivos como relojes inteligentes, sensores de ropa e insignias sociométricas que recopilan millones de temperaturas corporales, recuentos de pasos y frecuencia cardíaca. Esto suena como datos increíblemente valiosos, ¡y lo es! Es información de diagnóstico invaluable para los profesionales de la salud, ofrece capacidades de autocontrol de vanguardia a los consumidores y crea un tesoro de información de salud para los investigadores.

La advertencia es que los datos sensibles y confidenciales en el ámbito médico deben tratarse con cuidado. Desde una perspectiva legal, existen regulaciones estrictas sobre cómo se debe almacenar, transferir y usar. Los consumidores también tienen sus propias expectativas de privacidad y seguridad . Esto significa que trabajar con datos médicos no es tan sencillo como algunos esperarían.

Es más, los datos médicos vienen en todas las formas y tamaños, y de diversas fuentes. Como resultado, cualquier persona que quiera trabajar con datos médicos tiene el desafío adicional de tener que recopilarlos de diferentes maneras, procesar una variedad de formatos de datos y separar el material sensible del mundano, por las razones anteriores.

No es de extrañar, entonces, que trabajar con datos médicos ciertamente no sea fácil. Con estándares competitivos, nuevos dispositivos y un historial de lenta adopción tecnológica, el ingeniero de software de Nokia , Vlad Stirbu, ha buscado los microservicios basados en API como una solución para aprovechar al máximo los invaluables datos médicos.

Vea a Vlad Stirbu compartir sus ideas sobre cómo trabajar con datos médicos de IoT en la Cumbre de la Plataforma de APIs nórdicas de 2017:

Regulaciones y estándares para datos médicos

Al diseñar cualquier producto, las limitaciones legales deben tener prioridad. Como tal, es esencial estar familiarizado con las regulaciones de protección de datos que se aplican en su jurisdicción, que es el punto de partida para el proceso de desarrollo de Vlad. Afortunadamente, las regulaciones actuales son tales que adherirse a ellas garantiza que manejará los datos confidenciales de una manera que no solo es legal, sino que también es considerada con el consumidor, que es una cosa menos de la que preocuparse.

En los EE. UU., Estas regulaciones están descritas por HIPAA , o la Ley de Portabilidad y Responsabilidad de Seguros de Salud, en particular el Título II. HIPAA se introdujo en 1996, definiendo lo que constituye “información médica protegida” (PHI) y cómo debe usarse y divulgarse. Cualquiera que se ocupe de datos médicos en los EE. UU. Debe cumplir con la HIPAA, que se describe más adelante en este útil artículo .

En Europa, la regulación principal en juego es GDPR , o el Reglamento general de protección de datos. Este es un marco universal sobre cómo se deben manejar los datos de los consumidores en todas las industrias, y la atención médica no es una excepción. Del mismo modo, define qué se puede considerar "datos personales", así como cómo deben manejarse. Según el RGPD, toda la información médica se considera confidencial por naturaleza y tiene reglas especiales sobre cómo debe tratarse.

Además de estas regulaciones, que pueden considerarse requisitos legales, hay una serie de estándares populares que Vlad introduce en su presentación. Un ejemplo es la IEC 62304 , que está armonizada en Europa y los Estados, y proporciona un buen punto de referencia universal para lo que se puede esperar en las regulaciones más específicas de cualquiera de las jurisdicciones. En particular, IEC 62304 define los requisitos para el desarrollo de dispositivos médicos (incluidos los productos electrónicos de consumo que mencionamos anteriormente, entre otros) y software médico. También define el término "SOUP" (software de procedencia desconocida), un tema pertinente teniendo en cuenta el grado de diseño de las arquitecturas de microservicios de forma externa.

También existen estándares para almacenar e intercambiar información de salud de manera efectiva. Desarrollado por HL7, FHIR es uno de ellos; sugiere las mejores prácticas para la transferencia de datos, la autenticación y la entrega de carga útil. Finalmente, LOINC ofrece un estándar para recopilar y compartir mediciones, incluyendo, por ejemplo, qué unidades deben usarse; de esta manera los datos (en sí mismos) siguen un formato predecible a nivel científico.

Otras dificultades para recopilar datos médicos

Si navegar por estas regulaciones y estándares no fue suficiente trabajo, existen algunas otras dificultades evidentes al tratar con datos médicos. A saber, estos son los diversos formatos en los que pueden venir los datos y las fuentes de las que pueden originarse.

Formatos de datos en el dominio médico

Los datos médicos adoptan todo tipo de formatos . Esto no solo crea una confusión de unidades, con diferentes unidades adjuntas a las mismas medidas, sino que también da lugar a datos de densidades tremendamente variables. Como ejemplo en su presentación, Vlad ofreció una comparación entre los datos continuos de ECG y las mediciones puntuales del peso de una persona: 1 hora de lectura de ECG equivale a 1 millón de mediciones de peso.

El desafío aquí es construir un sistema que pueda ingerir estos datos sin problemas mientras los interpreta correctamente, y este problema se amplifica cuando los datos se obtienen de múltiples fuentes, cada una con sus propios estándares de formato ...

Lea también: Cómo las API están optimizando la atención médica

Orígenes de los datos en el siglo XXI

Como señala Vlad, cualquier dato (los datos médicos no son una excepción) pueden llegar a usted de varias formas. En algunos casos, los datos se agrupan directamente, pero en otros, los datos pueden pasar a través de puertas de enlace o almacenarse primero con terceros . Esto no solo introduce preocupaciones de seguridad adicionales (ya que todos los aspectos de las rutas más complicadas deben ser seguros, por no mencionar que cumplen con la ley), sino que también significa que las cargas útiles se entregan de diversas maneras .

Esto solo tiene en cuenta la electrónica de consumo y las aplicaciones web; Si quisiera combinar estos datos con, digamos, registros de pacientes de hospitales locales, habría una gran cantidad de otros requisitos para manejar los datos, además de otro formato para procesar.

Arquitecturas de microservicios como punto de partida

Al abordar estas preocupaciones, Vlad dice que el enfoque lógico es adoptar una arquitectura de microservicio . De esta manera, los datos se pueden dividir y manejar por separado según su naturaleza: si son sensibles o no y deben tratarse de manera especial, qué formato toman, etc. Esta solución es intrínsecamente rápida y flexible; solo asegúrese de cumplir con las regulaciones locales de protección de datos y haga todo lo posible por adherirse a FHIR y LOINC caso por caso para sus datos, ¿verdad?

Desafortunadamente, las cosas se complican muy rápidamente, ya que se agregan cada vez más microservicios y se deben realizar cambios. Vlad lo compara con un mono colgado de un árbol: "comienza a pesar [abajo] y no sabes cuánto tiempo puede colgar allí". En lugar de empezar de nuevo, presionó para que la arquitectura de microservicios funcionara, y el secreto radicaba en una gobernanza eficaz ...

Consulte también: Protección de dispositivos médicos de IoT

Cómo mantener una arquitectura de microservicio

Vlad propone algunas ideas simples pero efectivas para administrar plataformas de microservicios que siguen creciendo en complejidad . El consejo se aplica tanto a todas las industrias como a la médica:

1. Aproveche al máximo los estándares

Puede parecer obvio, pero Vlad promueve el uso de estándares por una razón: hacen que todos los aspectos del desarrollo, desde el formato de datos hasta el diseño de microservicios, sean mucho más intuitivos para los desarrolladores antiguos y nuevos. Además de los estándares descritos anteriormente, Vlad sugiere el uso de procedimientos operativos estandarizados, ya sea que estén escritos en código o en inglés simple.

2. Agrupar microservicios basados ​​en elementos comunes

Otra sugerencia es la "sedimentación de capacidades": agrupar microservicios en función de sus puntos en común . Al crear funciones comunes en una capa de plataforma, por ejemplo, los desarrolladores pueden ahorrar tiempo y al mismo tiempo mantener conectados varios microservicios. Esto evita que las diferentes ramas de la plataforma se alejen demasiado.

3. Ofrezca a los desarrolladores una vista de cerca

Según la experiencia de Vlad, dar a los desarrolladores una vista superior del sistema es perjudicial o, en el mejor de los casos, ineficaz. En cambio, una mejor medida es brindar a los desarrolladores una vista de cerca solo de sus dependencias directas, para que puedan enfocarse en construir el microservicio perfecto para el problema exacto en cuestión (esta fue la ventaja principal de adoptar una arquitectura de microservicio en primer lugar ). Puede lograr esto con una variedad de herramientas; Vlad usa Docker Compose .

4. Aproveche las herramientas siempre que sea posible

Hablando de herramientas, hay muchas disponibles para ayudar en el viaje del microservicio. El uso de herramientas no solo estandariza automáticamente los asuntos para usted, sino que también ahorra tiempo. Una de esas "herramientas" es la especificación OpenAPI , que simplifica el desarrollo junto con una gran cantidad de otros beneficios .

Más: Información sobre el diseño de microservicios

Tomando el consejo de Vlad

De todos los datos que existen, los datos médicos son algunos de los más difíciles de manejar: vienen en diferentes formatos, de diferentes fuentes y están estrictamente regulados. Esto lo convierte en un candidato principal para una arquitectura de microservicios administrada de cerca, que se mantiene simple al seguir los estándares al pie de la letra, agrupar las características en los microservicios, dejar de lado el punto de vista integral y usar herramientas siempre que sea posible.

Usar el enfoque de Vlad para los microservicios con otros datos confidenciales de alto riesgo, tal vez datos financieros o legales, es una forma segura de cubrir sus responsabilidades como desarrollador sin complicar demasiado las cosas. Quizás se pueda utilizar un enfoque similar en el movimiento de banca abierta de hoy , para exponer API potentes mientras se mantiene la seguridad y la versatilidad.

Publicar un comentario

0 Comentarios