Interoperability standards and schema
Standards development activities undertaken since the early 1980s aimed to provide solutions to these interoperability challenges., El Digital Imaging and Communications in Medicine (DICOM®), Comité de estándares de la National Electrical Manufacturers Association (Nema), fue uno de los primeros en desarrollar un estándar para comunicar información de imágenes médicas , ahora publicado por la Organización Internacional de Normalización (ISO12052:2017). Todos los estándares de nivel de salud siete (HL7) son publicados por una organización nacional oficial de estándares, el Instituto Nacional Americano de estándares (ANSI)., Es importante tener en cuenta que los estándares HL7 (nivel de salud siete) se centran en la interoperabilidad técnica (intercambio de datos de salud), lo que resulta en una interoperabilidad operativa limitada (semántica).
el ahora muy popular estándar Fast Healthcare Interoperability Resources (FHIR®) ha mejorado enormemente los flujos de información operativa . El modelo de referencia HL7 FHIR® se define mediante una colección de modelos de información (recursos). Estos pueden ser perfilados (o no) para generar un modelo de información clínica., Los recursos FHIR® se producen a partir de un superconjunto de datos que se encuentran en sistemas heredados para ser utilizados directamente por los desarrolladores. Estrictamente hablando, estos no son «modelos», ya que no se utilizan las prácticas habituales de herencia, encapsulación de elementos comunes o tipificación. El uso exitoso de la norma FHIR® depende del grado de acuerdo alcanzado entre las partes. Alcanzar un acuerdo de esta manera es más fácil de lograr dentro de las organizaciones por un pequeño número de partes interesadas, incluidos los médicos, que los acuerdos para adaptarse a redes más extensas. Esto limita las oportunidades de reutilización del software .,
una revisión de seis organizaciones de atención responsable de Medicare de Estados Unidos ha vuelto a destacar la necesidad de adoptar un enfoque estándar. Se encontró que aquellos que utilizaron un único sistema de historia clínica electrónica a través de sus redes de proveedores, pudieron compartir datos en tiempo real, mejorando la capacidad de los proveedores para coordinar la atención. Otros tenían acceso a sólidos intercambios de información sanitaria que permitían el acceso a los datos de los pacientes de proveedores externos. A pesar de esto, se observó que no se ha realizado todo el potencial de la salud.,e el resultado de la pobre interoperabilidad comprometiendo la capacidad de atención resultando en:
•
dependencia de otros medios para compartir datos incluyendo llamadas telefónicas y faxes,
•
Uso pesado y frustrante de EHRs,
•
agotamiento médico debido a la carga de trabajo asociada con la gestión de EHR,
•
Acceso a intercambios de información de salud con datos escasos o incompletos creando dificultad con respecto a la coordinación de la atención,
•
incapacidad para ofrecer •
incapacidad de usar Analytics para personalizar la atención para satisfacer las necesidades individuales de un paciente.,
una iniciativa del sector privado está llevando a cabo actualmente un proyecto destinado a promover la adopción por la industria de estándares modernos y abiertos de interoperabilidad conocidos como el proyecto Argonaut . El propósito de este proyecto es desarrollar una API basada en FHIR®de primera generación y una especificación de servicios de datos básicos para permitir el intercambio ampliado de información para registros electrónicos de salud y otras tecnologías de información de salud basadas en estándares de Internet y patrones y estilos arquitectónicos. Este trabajo está siendo patrocinado por numerosos proveedores, incluyendo Cerner, Epic y Accenture., El alcance de este trabajo consiste en acelerar el desarrollo del modelo FHIR® centrándose en perfiles y documentación FHIR® más específicos, incluido un enfoque en las especificaciones de seguridad y la documentación que acompañan para permitir que se logre la interoperabilidad entre los sistemas propietarios heredados, donde sus proveedores controlan contractualmente el acceso a los datos. El uso de estas API crea riesgos inherentes de errores y seguridad del paciente debido a la asignación de datos.
las organizaciones de atención médica están ahora en el proceso de administrar la rápida adopción de FHIR® y el mayor uso de API., A partir de una infraestructura nacional de la perspectiva debe ser el medio para facilitar la reutilización de algunos utilizan frecuentemente clave FHIR® modelos. Estos pueden ser elegidos para convertirse en estándares HL7 aprobados. Sin la adopción de modelos estándar acordados, habrá una proliferación de modelos FHIR ® desarrollados para satisfacer las necesidades locales, muchas repeticiones e inconsistencias que limitan el progreso nacional general hacia el logro de un ecosistema de salud digital bien conectado., Los modelos FHIR ® no cumplen con las convenciones de modelado bien conocidas, como lo demostró Beale, quien concluyó que:
los recursos de FHIR parecen ser el resultado de comités separados que trabajan casi sin referencias cruzadas, metodología o base de diseño común. El resultado es que cada recurso es algo así como una» bolsa de atributos», presumiblemente debido a la aplicación de la llamada regla 80/20 en el contexto del Comité.
los modelos FHIR® deben considerar un número muy grande e inmanejable de puntos de datos., Esta limitación se supera mediante la adopción de modelos genéricos que son perfectamente adecuados para la mensajería, pero no para el almacenamiento semánticamente coherente de datos clínicos. El contexto es esencial para la forma en que los médicos procesan la información. El contexto debe tenerse en cuenta al desarrollar sistemas de apoyo a la toma de decisiones o de inteligencia artificial, al adoptar diversas estrategias de análisis de datos y para cualquier número de normas pertinentes, incluidas las utilizadas para la cartografía de datos.,
se dice que los recursos FHIR® contienen un continuo de niveles ontológicos, tienen dos características indeseables en un modelo de información estable:
volatilidad: los recursos clínicamente específicos claramente tendrán que cambiar con el tiempo. Cómo esto afecta a los perfiles dependientes es una pregunta interesante;
open-endedness — uno debe suponer que el conjunto de recursos simplemente seguirá creciendo para acomodar nuevas categorías principales de información clínica.,
las consecuencias de estos factores son que el modelo «nunca está terminado» y que cualquier base de datos o software basado en él también necesitará mantenimiento continuo. Hay otra cuestión relacionada con el procesamiento de la información en fases posteriores para uso secundario de datos. Eso es una incapacidad para saber si las estructuras de datos que parecen ser casi iguales pueden ser tratadas de la misma manera; el valor predeterminado con FHIR es que cada recurso es su propia cosa ., Un experto en estándares internacionales señaló que:
FHIR ® fue diseñado y pensado como un estándar de API / intercambio, la mayoría de las principales organizaciones ITC (Google, Microsoft, IBM, etc.) y al menos un importante proveedor de EHR (Cerner) han adoptado FHIR® como un esquema de objeto de persistencia y un esquema de almacén de datos. FHIR ® sigue siendo poco específico a nivel internacional, ya que la vinculación de conjuntos de valores se relega a las guías de implementación (por ejemplo, la Guía de implementación de FHIR® Central de EE., Dadas las predisposiciones nacionales actuales hacia los códigos nacionales de tecnología de la información de salud (HIT) (prácticamente todos los países tienen su propia maldita publicación de códigos de procedimiento, y curiosamente el mundo entero aún no está utilizando la CIE11) esta separación es altamente pragmática. Las barreras a la interoperabilidad Internacional de HIT tienen menos que ver con las especificaciones técnicas de sintaxis, y mucho más que ver con la tendencia casi intratable de los países a especificar sus propios sistemas de codificación, A veces propietarios.,
La adopción del marco arquitectónico openEHR requiere el uso de un enfoque de modelado más completo . Estos modelos pueden vincularse con los modelos FHIR® cuando sea necesario, por ejemplo, el arquetipo de riesgo de reacción adversa openEHR y el recurso de tolerancia a la alergia FHIR® se publicaron conjuntamente y se alinearon a finales de 2015., Los arquetipos incorporan el trabajo colaborativo llevado a cabo por una gran comunidad internacional virtual de profesionales multidisciplinarios que convierten los datos de salud en una forma electrónica (computable) basada en la evidencia para garantizar la interoperabilidad universal dentro de cualquier ecosistema de salud digital. Este enfoque consiste en un modelado de fuente única de varios niveles dentro de una arquitectura de software orientada a servicios delineada por un conjunto de especificaciones publicadas por la openEHR foundation y disponibles gratuitamente para cualquier persona.,
el openEHR es una especificación estándar abierta regida por una fundación sin fines de lucro, está disponible gratuitamente para ser implementado por cualquier desarrollador. Las especificaciones de OpenEHR, el resultado de 25 años de investigación y desarrollo, representan la única instancia seria del modelo de referencia ISO 13606 para la comunicación de historias clínicas electrónicas que detalla una estructura jerárquica para la información clínica . Esta norma se está utilizando cada vez más en proyectos masivos en el Reino Unido, Noruega, Finlandia, Eslovenia y Alemania., También China, Chile, Brasil, Italia y el Caribe han adoptado este enfoque. De hecho, la ISO 13606 se derivó de la experiencia de openEHR, y más recientemente se ha visto influenciada por la experiencia con otras normas, incluido FHIR®. El trabajo de modelado clínico es más extenso que el realizado en cualquier otro lugar anteriormente con una comunidad de voluntarios de más de 2000 personas de 93 países.
los modelos clínicos del dominio ISO13606 conocidos como «arquetipos» son externos al software., Cada arquetipo define un número máximo de puntos de datos y grupos de datos posibles que se aplican al concepto modelado. Esto proporciona un número máximo de contextos diferentes para adaptarse a todas las especialidades clínicas y posibles usos de los datos. Las plantillas, que consisten en una capa de» recombinación «de modelos para definir conjuntos de datos, utilizan solo los puntos de datos de un conjunto (cualquier número o selección) de arquetipos que se requieren para cualquier» caso de uso » o aplicación específica, como cualquier tipo de evaluación clínica., Las plantillas pueden utilizarse como definiciones de mensajes para sistemas heredados, así como conjuntos de datos para nuevas aplicaciones, incluidos formularios. Esto significa que cualquier conjunto de arquetipos se puede reutilizar para múltiples casos de uso. Permite que partes significativas del software se deriven de los arquetipos. Los arquetipos representan datos atómicos en un estándar abierto; un factor crítico de éxito capaz de soportar los cambios en la tecnología, particularmente el intercambio y la persistencia.,
estos «arquetipos» (modelos) son utilizados por varias aplicaciones, incluso en el Servicio Nacional de salud del Reino Unido, donde se utilizan para la conversión de sistemas sombra que permiten el uso de repositorios de datos neutrales del proveedor. Otros usuarios son: Queensland Health y algunos hospitales privados para sus sistemas de control de infecciones, una serie de centros de salud primaria de Western Sydney y EHR compartido de Northern Territory Health, y socios de la industria openEHR cuyos sistemas están ampliamente implementados en los países escandinavos., Los componentes y sistemas conformes son «abiertos» en términos de modelos de datos y API. Estratégicamente, el enfoque openEHR tiene un enfoque de registro de salud muy adecuado para la atención centrada en el paciente. Este enfoque permite un mercado de software basado en plataformas o «back-end abierto» en el que los proveedores de la industria de la salud y los desarrolladores de soluciones interactúan entre sí a través de modelos de información estandarizados, modelos de contenido, terminologías e interfaces de servicio.,
una colaboración abierta de individuos, industria, organizaciones de estándares y proveedores de atención médica han acordado trabajar juntos para acelerar el desarrollo de estándares abiertos para la interoperabilidad en el sector sanitario y social. Han proporcionado un foro de colaboración para compartir experiencias y aportar soluciones destinadas a superar este panorama confuso. En julio de 2018 publicaron un resumen de lo que se ha descrito aquí . Se señaló que esas numerosas normas estaban convergiendo. Los estándares FHIR® y openEHR no abordan el mismo problema., Ambos crean modelos de información clínica, pero los modelos openEHR (arquetipos) son independientes de los proveedores centrados en los datos en todas las plataformas openEHR. FHIR ® se centra en las aplicaciones, ya que crea un modelo común para su uso en cualquier aplicación para luego formar la base de la definición de interoperabilidad entre aplicaciones, independientemente de los modelos abiertos o propietarios en los que se hayan construido. Aquellos que hacen uso de soluciones de interoperabilidad centradas en aplicaciones lo hacen para permitir el uso continuo de costosos sistemas heredados.,
openEHR y FHIR® proporcionan enfoques complementarios pero diferentes para conectar un complejo mosaico de aplicaciones en un único sistema coherente . El enfoque openEHR centrado en los datos se centra en la normalización de los datos de salud en primer lugar, y la construcción de nuevos sistemas sobre los sistemas heredados para evitar los problemas de interoperabilidad en conjunto. Se trata de definir una capa de datos dentro de una arquitectura de sistema abierta. Esta es la capa más importante, ya que facilita el uso óptimo de los datos para mejorar los resultados, gestionar mejor las enfermedades crónicas y permitir una mejor gestión de la salud de la población., Esto requiere que los datos se almacenen en formatos neutrales del proveedor en lugar de los formatos propietarios de la mayoría de los sistemas heredados. El enfoque centrado en los datos permite el almacenamiento y uso de datos de salud digital durante toda la vida de cualquier paciente.
casi todos los sistemas basados en openEHR están desarrollando actualmente interfaces FHIR® para garantizar que puedan respaldar el viaje del paciente entre los sistemas openEHR y no openEHR . el esquema de conectividad openEHR se puede construir una vez y compartir entre todos los proveedores de openEHR, ya que se basan en arquetipos openEHR comunes., Las aplicaciones agrupadas en una plataforma basada en openEHR no necesitan soluciones de intercambio como FHIR® porque pueden comunicarse directamente entre sí a través de repositorios de datos clínicos compartidos. Esto permite a los nuevos participantes en el mercado concentrarse en el desarrollo de aplicaciones verdaderamente innovadoras y cumplir funcionalmente con los requisitos clínicos de nicho. La capacidad de FHIR ® solo es necesaria para permitirles comunicarse con aplicaciones propietarias de proveedores de ecosistemas más amplios .
Leave a Reply