Aplicación para el manejo de enfermedades crónicas
Sector: Salud digital, terapias digitales
El escenario
Imagina que estás creando una app para pacientes con diabetes tipo 2 e hipertensión. Los pacientes reportan alimentación, actividad, glucemia y presión arterial, y los coordinadores de cuidados siguen su evolución en un panel entre consultas. Quieres venderla a varias redes de clínicas.
Cada red quiere algo un poco distinto: otro protocolo de presión arterial, otras metas de glucemia, otros campos para sus coordinadores. Y algunas pedirán los datos en el formato que habla su propio sistema: un flujo HL7 v2, openEHR o FHIR.
Qué sale mal sin la herramienta adecuada
- El esquema de la base de datos se modifica por cada cliente nuevo, y el código deriva en un problema de mantenimiento con ramas específicas por cliente.
- Agregar un campo para un cliente arriesga romper a otro.
- "¿Podemos sacar nuestros datos?" se vuelve un proyecto a medida para cada cliente, porque el modelo de datos es privado de tu producto.
Cómo se puede usar Atomik
- Modela un núcleo clínico compartido. Define plantillas openEHR para los dominios comunes a todos los clientes (presión arterial, glucosa, medicación, síntomas autorreportados).
- Extiende por cliente. Las necesidades específicas pasan a ser nuevas versiones de plantilla o plantillas adicionales. Sin migración de esquema y sin cambios de código en la capa de datos.
- Mantén separados a los clientes. Atomik es de un solo inquilino (single-tenant), así que un enfoque típico es una instancia de Atomik por cliente, lo que además ayuda con los requisitos de gobernanza de datos.
- Construye el panel como un cliente liviano. Las listas de pacientes, tendencias y alertas salen de consultas guardadas llamadas por la API REST. Acotar una consulta a los pacientes de una clínica es cuestión de la instancia y de los criterios de la consulta, no de una rama de código aparte.
- Entrega los datos en el formato del cliente. Los datos guardados en Atomik ya son openEHR, así que los clientes nativos openEHR no necesitan conversión. Para FHIR y HL7 v2, CaboLabs puede aportar la capa de integración (una fachada FHIR adaptada a los perfiles de cada cliente, e integración HL7 v2). Es trabajo de integración, no algo que se activa con un interruptor.
Cómo puede ayudar CaboLabs
Atomik fue creado por CaboLabs, una empresa especializada en integración de sistemas de salud, migración y consolidación de datos, y gestión y auditoría de datos clínicos. Además del software, CaboLabs ofrece servicios que encajan con este escenario:
- Estándares y arquitectura de datos clínicos para startups. Revisar o diseñar el modelo de datos para que soporte openEHR, FHIR o lo que requiera tu mercado. Ver Servicios para startups de salud digital.
- Diseño de APIs e integración. Diseñar el contrato de la API y las integraciones con el sistema de cada cliente. Ver Diseño de APIs.
- Integración FHIR y HL7 v2. La fachada FHIR y la capa HL7 v2 mencionadas arriba son trabajo de integración que CaboLabs puede aportar. Ver Integración de HIS.
- Modelado openEHR. Diseñar las plantillas base compartidas y las extensiones por cliente. Ver Implementación openEHR.
Nada de esto es necesario para usar Atomik; puedes hacerlo con tu propio equipo u otro proveedor. Si quieres conversar sobre tu caso, contacta a CaboLabs.
Qué te da esto
Necesidades de datos específicas de cada cliente resueltas como plantillas y no como cambios de esquema, y un almacén que puede entregar su contenido a otros sistemas en un formato estándar.
Por qué Atomik encaja
Un producto que atiende a muchas clínicas necesita datos que se adapten a cada una sin reescribir la aplicación, y que puedan salir en el formato que hable el sistema del cliente.