Gestión de modelos de datos
Tu modelo de datos es el contrato entre tus plantillas y todo lo que depende de ellas — consultas, validaciones, integraciones. Un OPT mal diseñado no falla de forma ruidosa; limita silenciosamente lo que podrás preguntarle a tus datos más adelante.
En Atomik, todos los modelos de datos para contenido de EHR y Demographic se definen mediante Plantillas Operacionales (OPTs) de openEHR.
Hay dos formas de cargar un OPT en Atomik. La primera es a través del Web Console, usando la funcionalidad de carga. La segunda es vía la API REST.
Cargar OPTs mediante el Web Console permite subir varias versiones de la misma plantilla. Todas las versiones quedan almacenadas, y solo la última está activa. El Web Console también permite eliminar plantillas que ya no necesites. Aunque si tienes datos almacenados para una plantilla, esa plantilla no podrá eliminarse. El borrado está más pensado para las fases de diseño y desarrollo que para un entorno de producción. En producción preferimos inactivar la plantilla, lo que también se hace desde el Web Console.
Al crear plantillas desde la API REST de openEHR, no se permite subir varias versiones de la misma plantilla. Si la plantilla ya existe, se enviará al cliente una respuesta 409 Conflict. Eso está en conformidad con las especificaciones de la API REST de openEHR. Así que cuando se trabaja con plantillas durante el diseño y desarrollo, y se usa solo la API REST, para eliminar plantillas la única opción es hacerlo desde el Web Console, ya que todavía no existe una operación de borrado a nivel de la API REST.
Internamente, Atomik usa los OPTs para:
- validar los datos enviados
- indexar datos
- crear y ejecutar consultas
Una plantilla bien definida es crucial para aprovechar al máximo todas esas funcionalidades.
- Los datos enviados contra él pasan la validación estructural pero fallan al indexarse correctamente — las consultas devuelven resultados incompletos sin error evidente
- Enlaces de terminología faltantes o incorrectos hacen que las consultas semánticas de SNOMED CT no puedan coincidir con tus datos
- Versiones de plantilla sin compatibilidad hacia atrás rompen las consultas entre versiones — obligándote a mantener lógica de consulta paralela a medida que tu modelo evoluciona
- Cardinalidades demasiado restrictivas rechazan datos clínicos válidos en el límite de la API, generando pérdida silenciosa de datos en los pipelines de integración
Si no estás seguro de si tu OPT está bien formado para uso en producción, el openEHR Toolkit incluye herramientas de validación y generación de datos de prueba que pueden revelar estos problemas antes de que lleguen a datos reales.