Conformidad con openEHR
Si tu proyecto requiere un CDR que sea demostrablemente conforme con openEHR — no solo "inspirado en" él — esta página documenta dónde se sitúa Atomik frente a la especificación, con honestidad y en detalle.
Atomik cumple con las especificaciones de openEHR en múltiples niveles. CaboLabs ha trabajado en el área de Verificación de Conformidad de openEHR durante los últimos 4 años — nuestro trabajo se convirtió en la base de la especificación oficial de Conformidad de openEHR (actualmente en BORRADOR).
Como parte de nuestro trabajo en el área de Verificación de Conformidad, hemos diseñado el Marco de Conformidad de openEHR, que tiene un alcance más amplio que la especificación de Conformidad de openEHR actual, y que consideramos la base para un Programa formal de Certificación de Software openEHR.
Hay algunas lecciones aprendidas de trabajar en el área de conformidad durante mucho tiempo.
- Hay distintos tipos de sistemas que pueden cumplir con las especificaciones de openEHR
- Los sistemas pueden implementar partes de la especificación de openEHR específicas para ese tipo de sistema
- Hay distintos niveles de cumplimiento según las especificaciones implementadas y cuánto se desvían esas implementaciones de las especificaciones. Con base en esto se puede implementar un Puntaje de Conformidad; un puntaje más alto significa que la implementación es más estricta respecto a la especificación, un puntaje más bajo significa que no hay implementación o una mayor desviación de las especificaciones
- La conformidad se verificará principalmente usando APIs REST, aunque hay componentes de openEHR que aún no tienen una API oficial, como Demographics
- Las implementaciones de openEHR deberían publicar un documento de Declaración de Conformidad que declare formalmente cómo se implementaron las especificaciones de openEHR en un sistema determinado; esta práctica es muy común en el software de imagenología que implementa DICOM, y debería ser una práctica común también para openEHR
Conformidad de Atomik
Las tablas a continuación documentan el estado de conformidad de Atomik. Estamos construyendo reportes automatizados de pruebas de conformidad para ejecutar pruebas de Verificación de Conformidad y ofrecer una imagen continuamente actualizada e imparcial de qué está implementado y en qué nivel. Nuestro objetivo: cuando uses Atomik, puedas demostrar cumplimiento con openEHR con un Puntaje de Conformidad alto — no solo declararlo.
Conformidad con el Modelo de Información de openEHR
En resumen: las únicas clases que Atomik no soporta actualmente son EHR_EXTRACT e IMPORTED_VERSION.
| Tipo de RM | Paquete | Notas |
|---|---|---|
| EHR | ehr | |
| EHR_STATUS | ehr | |
| FOLDER | common.directory | |
| COMPOSITION | composition | |
| EVENT_CONTEXT | composition | |
| VERSIONED_EHR_STATUS | ehr | |
| VERSIONED_FOLDER | common.directory | |
| VERSIONED_COMPOSITION | ehr | |
| CONTRIBUTION | common.change_control | |
| ORIGINAL_VERSION | common.change_control | |
| SECTION | content.navigation | |
| OBSERVATION | content.entry | |
| EVALUATION | content.entry | |
| INSTRUCTION | content.entry | |
| ACTION | content.entry | |
| ADMIN_ENTRY | content.entry | |
| ACTIVITY | content.entry | |
| ISM_TRANSITION | content.entry | |
| INSTRUCTION_DETAILS | content.entry | |
| HISTORY | data_structures.history | |
| POINT_EVENT | data_structures.history | |
| INTERVAL_EVENT | data_structures.history | |
| PERSON | demographic | |
| GROUP | demographic | |
| ORGANISATION | demographic | |
| AGENT | demographic | |
| ROLE | demographic | |
| PARTY_RELATIONSHIP | demographic | |
| PARTY_IDENTITY | demographic | |
| CONTACT | demographic | |
| ITEM_TREE | data_structures.item_structure | |
| ITEM_LIST | data_structures.item_structure | |
| ITEM_TABLE | data_structures.item_structure | |
| ITEM_SINGLE | data_structures.item_structure | |
| CLUSTER | data_structures.representation | |
| ELEMENT | data_structures.representation | |
| ARCHETYPED | common.archetyped | |
| AUDIT_DETAILS | common.generic | |
| PARTY_PROXY | common.generic | |
| DV_BOOLEAN | data_types.basic | |
| DV_IDENTIFIER | data_types.basic | |
| DV_TEXT | data_types.text | |
| DV_CODED_TEXT | data_types.text | |
| CODE_PHRASE | data_types.text | |
| DV_ORDINAL | data_types.quantity | |
| DV_INTERVAL | data_types.quantity | |
| DV_PROPORTION | data_types.quantity | |
| DV_QUANTITY | data_types.quantity | |
| DV_COUNT | data_types.quantity | |
| DV_DATE | data_types.quantity.date_time | |
| DV_TIME | data_types.quantity.date_time | |
| DV_DATE_TIME | data_types.quantity.date_time | |
| DV_DURATION | data_types.quantity.date_time | |
| DV_MULTIMEDIA | data_types.encapsulated | Permite guardar datos binarios o referencias externas a datos binarios, como estudios DICOM con URLs WADO o WADO-RS. Para un uso intensivo de recursos multimedia, se recomienda usar un repositorio externo con referencias desde el CDR de openEHR. |
| DV_PARSABLE | data_types.encapsulated | |
| DV_URI | data_types.uri | |
| DV_EHR_URI | data_types.uri |
Las siguientes clases no están implementadas por falta de soporte en las herramientas de modelado y de casos de uso para almacenar datos para ellas: DV_STATE, DV_PARAGRAPH, TERM_MAPPING, REFERENCE_RANGE. Si un cliente requiere soporte para alguna de esas clases, podemos agregarlas.
Conformidad con AOM / ADL de openEHR
Atomik no usa Arquetipos directamente, usa Plantillas en forma de Plantillas Operacionales (OPT). Por lo tanto no necesita soportar ADL. La implementación de AOM tiene todas las clases necesarias para cargar, procesar y guardar un OPT, y está basada en AOM 1.4. No tenemos planes de implementar AOM 2 en nuestra hoja de ruta actual.
Conformidad con TOM de openEHR
Template Object Model (TOM) es una especie de especificación virtual que nunca fue formalizada pero que se usa en la práctica para definir, gestionar y compartir Plantillas Operacionales entre sistemas openEHR. El TOM es básicamente AOM 1.4 como modelo base junto con los Esquemas XML (artefactos ITS) que representan el formato de serialización de las Plantillas Operacionales. Esto es lo que implementa Atomik, ya que trabaja solo con OPTs.
Conformidad con la API REST de openEHR
Atomik cumple con la API de EHR, incluyendo los siguientes recursos: EHR, EHR_STATUS, CONTRIBUTION, COMPOSITION y DIRECTORY. Atomik implementa la versión 1.0.2 de la API REST de openEHR.
Una nota sobre las consultas: Atomik no implementa AQL, implementa un formalismo de consultas distinto llamado Simple Archetype Query Model (SAQM) que no depende de una sintaxis específica, y que es portable entre distintos proveedores. AQL no es 100% portable porque la especificación se enfoca demasiado en la sintaxis, pero muy poco en los procesos internos involucrados en la ejecución de la consulta. Estamos trabajando en la especificación de SAQM, que estará disponible públicamente para cualquiera que quiera implementar un formalismo de consulta alternativo para CDRs de openEHR. Una nota relacionada es que el componente de Query de la capa de servicios de openEHR acepta distintos formalismos de consulta, siendo AQL el único oficial (por ahora). Aunque debería hacerse una armonización entre el Modelo de Servicios y las especificaciones de la API REST para que este aspecto de soportar un formalismo variable para consultar un CDR de openEHR quede formalmente definido allí.
Referencia de especificación: https://specifications.openehr.org/releases/ITS-REST/Release-1.0.2/ehr.html#directory
Conformidad con los Componentes Arquitectónicos de openEHR
Atomik es conforme con los componentes de openEHR de EHR y Demographic, lo que permite gestionar el registro clínico y el registro de partes, incluyendo relaciones, roles, identidad e información de contacto.
Atomik soporta el componente de terminología de openEHR, que es de uso interno para puntos de datos específicos, y soporta condiciones semánticas basadas en terminologías externas (actualmente enfocado en SNOMED CT). Esta última característica podría extenderse para integrar también validación terminológica de datos (verificar que los códigos sean correctos en los registros enviados por un sistema cliente a Atomik).
Referencia de especificación: https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html
Conformidad con el Modelo de Servicios de openEHR
El Modelo de Servicios de openEHR (SM) es un ejercicio de formalizar una capa de servicios independientemente de su implementación, por lo que es una especificación más genérica que la API REST, y la especificación de la API REST debería tener bindings a cada componente, tipo y operación definidos en el SM. Lamentablemente la especificación del SM se creó después de que se publicara la especificación de la API REST, por lo que se necesita trabajo de armonización en esa área para poder formalizar cómo se documenta y verifica la conformidad respecto al SM (esto se explica en el Marco de Conformidad de openEHR que diseñamos).
Referencia de especificación: https://specifications.openehr.org/releases/SM/latest/openehr_platform.html
Conformidad de Versionado de openEHR
openEHR define una forma muy genérica de versionar cualquier tipo de nivel superior que desciende de LOCATABLE (COMPOSITION, EHR_STATUS, FOLDER y PARTY), basada en ramificación (branching). Esta forma de versionado requiere procesos complejos de bifurcación/ramificación y fusión que son bastante inusuales en un entorno clínico. Por eso elegimos restringir aún más las capacidades de versionado a un caso de uso más realista y más común en entornos clínicos: el versionado lineal. Eso significa que no hay "ramificación" ni "fusión", solo "crear siguiente versión", lo que genera una lista de versiones en lugar de un árbol, como: v1, v2, v3, y así sucesivamente.
Conformidad de Validación de Datos de openEHR
La validación de datos de openEHR involucra dos niveles: sintáctico y semántico. La validación sintáctica consiste en verificar la conformidad de los formatos de intercambio (JSON/XML) contra los Esquemas JSON y XML canónicos oficiales [1][2].
La validación semántica ocurre una vez que los payloads de intercambio se validan y se parsean a instancias del RM, las cuales se validan contra las estructuras, restricciones y terminología presentes en la Plantilla Operacional correspondiente. Nota que no hay una especificación formal sobre cómo deben reportarse los errores de validación semántica de datos. Nuestro enfoque es informar al cliente dónde se ubica el error en los datos, devolviendo una ruta de datos (data path), y qué restricción se violó, devolviendo una ruta de plantilla (template path). Atomik también devuelve un mensaje de error de validación de datos para dar detalles sobre qué salió mal, de modo que los clientes tengan toda la información que necesitan para saber qué ocurrió, así pueden corregir los problemas y reenviar los datos.