modelo de interoperabilidad en chile -...
TRANSCRIPT
Modelo de interoperabilidad en Chile
2
Introducción
Objetivo
Contexto
Experiencia de uso
Conceptos
IHE/XDS/CDA
Conclusión y diálogo
Beneficios/Planificación
Nuestra agenda de hoyModelo de interoperabilidad en Chile
INDICE
3
Objetivo
INTRODUCCION
Objetivo Especifico
• Construir un modelo de interoperabilidad que permita compartir la información sanitaria
entre los prestadores y el Ministerio de Salud, comunicada de manera interoperable y
estandarizada.
• Brindar información para la continuidad del cuidado del paciente a los diferentes
profesionales independientemente de su ubicación geográfica .
4
Experiencias de uso
CONTEXTO
Modelos de interoperabilidad
Canada
Italia
Australia
Europa
Austria
USA
Uruguay
5
Inicio en el 2009 en:
• Quebec
• Ontario
• Alberta
• Columbia Británica.
Perfiles IHE:
• XDS
• ATNA
• PIX
• XDS-I.
Experiencias de uso
CONTEXTO
Canadá
6
4 Hospitales y 500 centros atención primaria:
• Prescripción Médica y Solicitudes Radiológicas-Laboratorio.
• SOLE (Epicrisis de Internación).
Infraestructura incluye:
• XDS Registry.
• XDS Repository compartido a nivel regional.
• PIX para identificación de pacientes.
• El contenido es CDA nivel 1 en PDF. Se planea la migración a CDA rel 2 con data estructurada.
Experiencias de uso
CONTEXTO
Italia
7
Región de Baja Austria (alrededor de Viena) Inicio 2007
1.5 millones de pacientes en línea.
11 hospitales conectados.
Perfiles IHE
• XDS
• PIX
• XDS-SD
• ATNA
• XUA
• BPPC.
Experiencias de uso
CONTEXTO
Austria
8
Centrada en:
• HISTORIA CLÍNICA RESUMIDA
• RECETA ELECTRÓNICA
Experiencias de uso
CONTEXTO
Europa
Participan 23 países, 47 socios
Objetivo: Poner las bases de interoperabilidad de los sistemas de información de las administraciones sanitarias europeas. Demostrar la interoperabilidad trans-fronteriza
9
Implementación de RCEConectividad Política Pública definida
¿Y nosotros?
CONTEXTO
Chile
1.630 prestadores conectados a la red intranet
de salud públicaForo Económico Mundial, Chile se ubica en el puesto 35 de 144 en el grado de
adopción de las TICs
10 años de historia de implementación de
registros clínicos electrónicos en el país.
Agenda Digital definió avanzar hacia una ficha clínica por
persona al 2030
Stand ByModelo de interoperabilidad en Chile
Integrating
The Healthcare
Enterprise
Promover la adopción coordinada de estándares existentes.Integrating the Healthcare Enterprise, que abreviamos como IHE y que
podría traducirse al castellano como Integrando las Empresas Sanitarias,
es una iniciativa de profesionales de la sanidad (incluyendo colegios
profesionales de médicos) y empresas proveedoras cuyo objetivo es
mejorar la comunicación entre los sistemas de información que se
utilizan en la atención al paciente. IHE define unos Perfiles de
Integración que utilizan estándares ya existentes para la integración de
sistemas de manera que proporcionen una interoperabilidad efectiva y
un flujo de trabajo eficiente. IHE nos permite alcanzar el nivel de
integración exigible en la era de la historia clínica electrónica.
11
Perfiles de integración
¿Qué es IHE?
CONCEPTOS
12
Para cada dominio se identifican diferentes perfiles Un perfil especifica como usar distintos estándares para resolver un problema de integración concreto en un dominio real.Ej: Flujo programado de radiología.
En cada perfil participan diferentes actoresActor: Sistema que juega un determinado rol en cada perfil.Ej: Modalidad.
En cada perfil se definen diferentes transacciones• Define Intercambio de Informacion mediante transacciones.• Cada transacción usa uno o varios estándares (ej: HL7 y DICOM).• Cada transacción involucra a dos o más actores.
Organización de las especificaciones de IHE
Dominio – Actor – Transacción/Acción
IHE
13
Interoperabilidad por capa
Perfil de Integración
IHE
Describe la solución para un problema de integración específico.
Documenta:• los roles de los sistemas (actores).• los estándares y detalles de diseño necesarios para
desarrollar sistemas que resuelvan dicho problema de integración.
LOINC SNOMED-CT
(SOAP, WS-Security, SSL)
ISO 13606 HL7 CDA
Repositorio de Documentos
(XDS)
Índice maestro de pacientes
(PIX /PDQ/PAM)
Registro de Documentos
(XDS)
Terminologías Estándares
Estándares de Contenido
Infraestructura de Salud
Tecnología
14
Cross Enterprise document sharing.
XDS.b
Patient identifier cross-referencing.
Patients demographicsquery.
PIX y PDQ
Audit Trail and nodeautentication.
ATNA
Patient AdministrationManagement.
PAMConsistent time
CT
Cross-comunity access
XCA
Diseño Estructural, considerando el escenario que define el contexto de IHE, con soporte para las distintas operaciones previstas en los perfiles de integración.
Perfiles
XDS
Contexto
15
XDS.b: Arquitectura Distribuida
Perfil de integración que facilita el registro, la distribución y el acceso de los registros clínicos electrónicos de lospacientes, entre las distintas organizaciones de salud.
Las funcionalidades de indexación y gestión de los documentos están separadas: la indexación está asociada a un serviciocentralizado denominado Registry, mientras la gestión física de los documentos está asociada a uno o más Repository.
Perfil XDS.b
Contexto
XDS
16
Standard XDS.b (Cross-Enterpise Document Sharing)
Al igual que en el contexto HL7, IHE define las transacciones especificas a ser activadas entre los actores involucrados en el proceso de intercambio de documentos, en referencia a otras normas relacionadas con la sintaxis de mensajes para utilizar.
DocumentSource
DocumentRepository
DocumentRegistry
Patient IndentitySource
DocumentConsumer
Provide and Register Document Set-b (ITI-41)
Integrated Document Source/Repository
Retrieve Document Set (ITI-43)
Patient Identity Feed (ITI-8)Patient Identity Feed HL7v3 (ITI-44)
Registry Stored Query (ITI-18)
Register Document Set-b(ITI-42)
Dentro del marco técnico IHE (http://www.ihe.net/technical_frameworks/#IT), se aclaran los siguientes conceptos:
-Las transacciones y su contexto de uso.-Los actores involucrados en cada transacción.-Reglas y controles que deben ser adoptadas por todos los actores.
Contexto
XDS
17
Componentes Aplicación que envía documentos o eventos clínicos de notificación al repositorio.
Document Source
Módulo que se ocupa de registro físico y almacenaje del documento.
Document Repository
Módulo que se ocupa de la clasificación de todos los documentos en el repositorio de
documentos asociado.
Document Registry
Módulo externo que proporciona la información demográfica de los pacientes asociados con el evento clínico o documento. Del mismo modo, el módulo proporciona información de ADT en el caso que el sistema este integrado.
Patient Indentity Source
Aplicación que busca documentos o eventos dentro del repositorio.
Document Consumer
Contexto
XDS
DocumentSource
DocumentRepository
DocumentRegistry
Patient IndentitySource
DocumentConsumer
Provide and Register Document Set-b (ITI-41)
Integrated Document Source/Repository
Retrieve Document Set (ITI-43)
Patient Identity Feed (ITI-8)Patient Identity Feed HL7v3 (ITI-44)
Registry Stored Query (ITI-18)
Register Document Set-b(ITI-42)
18
MetadataIntroducción
XDS
01
02
03 Documentar
Filtrar
Agrupar
Clasificar
USOS
El objetivo principal de una metadata es permitir encontrar otros datos/documentos
OBJETIVODatos que describen otros datos
DEFINICIÓN
Obtener prestaciones asociadas a un encuentro
médico
EJEMPLO
04
19
Privacidad y Seguridad
Document Sharing Metadata
Overview
Overview
Metadata
XDS
autorclassCode
confidencialityCodecreationTime
entryUUIDHash
legalAuthenticatorpatientID
practiceSettingCodeserviceStartTimeserviceStopTime
size
Ciclo de Vida
availibilityStatuscreationTime
legalAuthtenticator
Intercambio
entryUUIDformatCode
homeCommunityIDmimeType
PushMetadatarepositoryUniqueID
SizeuniqueID
URI
Descriptivo
AuthoravailibilityStatus
CommentsentryUUID
eventCodeListformatCode
healthcareFacilityTypeCodelanguageCode
mimeTypepatientID
practiceSettingCodeserviceStartTimeserviceStopTime
TitletypeCode
Identidad Paciente
patientIDsourcePatientID
sourcePatientInfo
ProcedenciaAuthor
creationTimehealthcareFacilityTypeCode
legalAuthenticatorpracticeSettingCode
sourcePatientIDsourcePatientInfo
Stand ByModelo de interoperabilidad en Chile
21
Es un estándar desarrollado por
Health Level Seven(HL7).
Aprobado por la American National
StandardsInstitute (ANSI). Perteneciente
HL7_V3
HL7
Es un estándar de marcaje, el cual
define estructura y la semántica de un documento clínico
para intercambiarlo
XML
HL7 definió un modelo
información de referencia, para la
generación e intercambio de
documentos clínicos
RIM
¿Qué es un CDA?
CONCEPTOS
Definición
22
Para definir la estructura y semántica de un CDA se utiliza:
El lenguaje de Marcado Extensible o Lenguaje de Marcas Extensible (XML del inglés eXtensible
Markup Language)
Un Modelo de Información de Referencia (RIM del inglés Reference Information Model) de HL7
Vocabularios controlados
Documentos clínicos legibles por computadoras y humanos
¿Qué es un CDA?
CONCEPTOS
Definición
23
CDA Release 1
– CDA Release 1 se convirtió en estándar HL7 y ANSI en el año 2000.
– Fue el primer modelo basado en el modelo semántico RIM.
– Utiliza el modelo RIM solo para la cabecera.
CDA Release 2
– CDA Release 2 se convirtió en estándar HL7 y ANSI en el año 2005 y el 2009 en estándar ISO.
– Utiliza el modelo RIM en cabecera y cuerpo.– Mejora la representación del evento clínico.– Es más rico en la expresión del evento y pretende
ser más simple que R1.
Versiones CDA
CONCEPTOS
24
Estructura CDA
CONCEPTOS
Ejemplo
Cabecera del CDA
• Contiene toda la metadata para manejar e indexar un documento• Quien, Que, Donde, Cuando entre otros
Cuerpo del CDA
• Contenido clínico• Puede ser o no estructurado
25
Niveles CDA R2
CONCEPTOS
CDA R2
LEVEL 1
Cuerpo no estructurado
LEVEL 2
Cuerpo con Secciones texto
libre en XML
LEVEL 3
Secciones Codificadas más
lenguaje de terminologías
clínicas
26
Objetivos
CONCEPTOS
CDA
Estandarización
Generar documentos
clínicos comunes
Compartir contenido Clínico
Compartir documentos
con contenido clínico para
reportes o repositorios
Transmisión por mensajería estructurada
Transmisión de los
documentos mediante
mensajes estructurados
27
PERSISTENCIAUn documento clínico continúa existiendo sin alteraciones por
un periodo de tiempo
ADMINISTRACIÓNUn documento clínico debe ser
mantenido por una organización
AUTENTICACIÓNUn documento clínico es un
conjunto de información el cual debe estar resguardado
CONTEXTOUn documento clínico cuenta
la historia sobre la atención
de un paciente
INTEGRIDAD
Deben existir referencia entre
toda la información de un
documento clínico
LEGIBILIDAD HUMANAUn documento clínico debe ser
leíble y entendible por un humano
Características
CONCEPTOS
CDA R2
28
Seguridad, Confidencialidad e integridad
CDA
La confidencialidad es manejada en el CDA y esta puede ser completa o por secciones.
Confidencialidad
Intercambio de datos entre diferentes organizaciones manteniendo CDA íntegros y completos cada vez que se requiera
Integridad
La responsabilidad de autenticar, la confidencialidad y retención del documento es de los sistemas que envían y consumen.
Seguridad
29
Conformidad
CDA
Es quien debe velar porque el documento se construya de manera integra
Autor
Quién está indicado como custodio en la cabecera es quien debe almacenar y mantener el documento original íntegro.
Custodio
Es un documento validado contra un esquema CDA, el cual es generado manualmente.
Validación
El destinatario del CDA es encargado de procesar el documento de acuerdo al estándar.
Destinatario
30
Generación, transmisión…
CDA
El estándar CDA no establece cómo se debe compartir los documentos, pero existen opciones como:DICOMMIMEFTPHTTP / HTTPSMensajes HL7 v2 y HL7 v3IHE XDS
Transmisión del mensaje
-Desde aplicaciones de cada prestador de salud-Conversión desde otros estándares (HL7 v2 o v3, DICOM, XML) -Mediante herramientas para generar formularios electrónicos
Generación
31
Modelo de Información de Referencia
El RIM define 6 clases fundamentales, capaces de generar una historia de la información de los pacientes, de manera continua en el tiempo del evento
RIM
CONCEPTOS
Entity Role
Role LinkAct
Relationship
Participation Act
plays
scopes
32
Mejorar el intercambio de
información basada en
documentos electrónicos
Permite generar la historia del paciente de
forma secuencial
Estandarización y validación de
los datos generados
Por que usar CDA
CONCEPTOS
Beneficios
Stand ByModelo de interoperabilidad en Chile
34
Ventajas
BENEFICIOS
¿Por qué interoperabilidad?
01
02 03
1. Información
Información sanitaria compartida
entre los prestadores y el Ministerio
de Salud, de manera interoperable y
estandarizada
2. TiempoDisminuir los tiempos y costos de
implementación, gracias a la creación
de guías de implementación, guías
técnicas.
.
Permite acceso, portabilidad e
intercambio de documentos a la
información mediante datos comunes
(metadata) de manera legible.
3. Acceso
35
Planificación de diseño del modeloEsta línea de trabajo tiene como objetivo crear un dialogo sobre el modelo de interoperabilidad
planteado por el Ministerio de Salud.
PLANIFICACION
Nivelación de estándares y diálogo
3 Julio 2018 24 Julio 2018
Presentación ProyectoHistoria Clínica
Compartida
Propuesta de diseño de Interoperabilidad
Diálogo
GRACIAS