3. Contexto
¿Hacia la HCEU?
Convergencia de 2 realidades
Marco: HCEU, PDP, datos públicos
Buscamos:
Mejor uso de recursos
Mejor atención sanitaria
Mejor calidad de vida
Oportunidad:
PYMES y grandes proveedores
Madurez del mercado local para el exterior
Necesitamos:
Arquitectura de referencia y servicios mínimos
Estándares abiertos / Especificaciones compartidas
3
4. Arquitectura de HCE Única
Entorno para compartir y colaborar
Base de conocimiento
Especs. compartidas
Artefactos procesables
Reuso, interoperabilidad
HCE Global
Servicios públicos
• Información deidentificada
Servicios compartidos
• Autorización requerida
HCE Hospitalaria
Aps. de registro clínico
HCE Personal
Prevención, promoción, seguimiento, empoderamiento ...
4
5. Arquitectura de HCE Única
Características de la solución
Accesibilidad
Seguridad
Disponibilidad
Modificabilidad
Interoperabilidad
Longitudinalidad
Escalabilidad
Gestionabilidad
Sustentabilidad
5
6. HCE Hospitalaria I
HCEH debe:
interoperar con múltiples sistemas
• RAD, LAB, FAR, ADT, IMP, AUT, ...
soportar múltiples deptos. y especialidades
Arq. de referencia de HCEH:
Aps. de Registro Clínico (múltiples)
• Separación de UI (N dispositivos)
Servidor de HCE:
• integra toda la información clínica
Servidor demográfico
Base de conocimiento hosp.
• Interoperabilidad y estandarización
• Contenido clínico, reglas, procesos
Servicios
6
7. HCE Hospitalaria II
Arq. de referencia: características
Future proof: hecha para evolucionar
• Cambios en registros, procesos, nuevas prácticas, requerimientos
Cambios en requerimientos manejados por clínicos
Informáticos dedicados a sistemas, servicios y tecnologías
• Nuevas tecnologías y dispositivos
Genérico y flexible:
• Independiente de la tecnología
• Adaptable a requerimientos particulares de cada institución
• Orientado a servicios
Reusabilidad de componentes, interoperabilidad en mente
Gestionable:
• Pequeño, estandarizado, componentes reusables (KB)
La arquitectura (componentes y servicios) podría
certificarse (UNIT? AGESIC? MSP?)
7
8. HCE Global I
Integrador de información, servicios y actores
Índice de información clínica de distintas HCEHs
• XDS Registry
Identificación de pacientes
• PIX Manager
Identificación actores
• Registro del SNIS
Servicios públicos (sin estado)
Búsqueda de información (openEHR EQL, hQuery)
Servicios compartidos (pueden tener estado)
Solicitud de información entre actores (CCR,8CDA)
9. HCE Global II
Servicios para:
Continuidad del cuidado
• Desde el requerimiento de asistencia
Tratamiento, recuperación, rehabilitación, seguimiento
• Hasta el bienestar (no termina en el alta)
• Calidad asistencial
• Integración de actores y servicios asistenciales
Vigilancia epidemiológica
• Información sobre lo que ya ocurrió
Análisis de factores de riesgo y causas
Siniestros de tránsito, suicidios, homicidios, accidentes laborales
• Salud pública: condición de la población
• Toma de decisiones: definición de políticas
9
10. HCE Global III
Servicios para:
Control de enfermedades
• Prevención, promoción, intervención
• Monitoreo individual y poblacional
Georreferencia: plombemia, dengue, hantavirus
• Enfermedades de notificación obligatoria: automática!
Emergencias
• Resumen de HCE disponible cuando se necesite
• Medicación, problemas de salud (ej. alergias), vacunas
Investigación
• Búsquedas, reportes, casos, análisis... acceso a información
Formación
Empoderamiento
• Información y servicios para pacientes
Gestión macro del SNIS
10
11. Base de conocimiento I
Artefactos procesables compartidos
Gestión coordinada y controlada
• Evolución, versionado, auditoría / QA, proceso formal
• Evita esfuerzos duplicados, estandarización
• Roles clínicos y equipos multidisciplinarios en IM
Empoderamiento del personal de salud
Basados en estándares
Interoperabilidad intra e inter institución
Mantenibilidad
• Adaptarse a nuevos requerimientos sin modificar las aplicaciones
Uso efectivo de la información clínica
• Especificación, búsqueda y procesamiento
Orientada a estándares
11
12. Base de conocimiento II
Permite la “HCE virtual”
Contenido clínico
Interfaz de usuario
Procesos
Terminologías
Políticas
Reglas
Modelos
Consultas
Formatos
12
13. Estándares
¿Qué necesitamos?
Estándares a nivel nacional (acuerdos)
• Modelo de información (conceptual, estable)
• Modelo de contenido (concreto, cambiante)
• Terminologías (distintos niveles, distintos fines)
• Protocolos
Mensajería (formatos de intercambio)
• lo importante es el contenido
Transporte
• TCP, HTTP, SOAP, otros ...
• Infraestructura
Estándares abiertos (es clave)
Orientación a servicios
• Basta de duplicar información y procesos
Colaboración entre actores 13
14. openEHR I
Arquitectura de HCE “future proof”
Diseño en 2 niveles
http://openehr.org.es
Modelo de información (nivel 1)
Registros
• Jerarquía de información clínica
• Análoga a la organización de registros en papel
Registros de auditoría
Seguridad
Firma digital
Demográfico
14
15. openEHR II
Modelo de Contenido (nivel 2)
Variable
• Depende de los requerimientos
• Traducible
• Terminologías estándar
Fuera del software como arquetipos
• http://www.openehr.org/knowledge/
EQL:
• http://www.ncbi.nlm.nih.gov/pubmed/17911747
15
17. Estándares ISO
ISO 35.240.80: IT applications in health care technology
ISO 18308:
• Requerimientos de arquitectura de HCE
• Estructura, procesos, privacidad, seguridad, comunicación, evolución,
médico-legal.
• Principios que sustentan la HCE
Rápido, fiable, completo, exacto, seguro, accesible
• Usos primarios y secundarios
ISO 13606:
• Comunicación de registros clínicos
Entre sistemas de HCE o con repositorio central
HCE distribuida (federada)
• Compatible con el modelo dual de openEHR
• Modelo, arquetipos, terminología, seguridad, intefaces
http://www.iso.org/iso/products/standards/catalogue_ics_browse.htm?
ICS1=35&ICS2=240&ICS3=80 17
18. Estándares HL7, CCR, DICOM
HL7:
v2.x: mensajería (ER7 y XML)
v3: mensajería y documentación clínica (XML)
• Necesita guías de implementación
No es plug-n-play: análisis, mapeo de voc., interfaces.
No compatible hacia atrás
ASTM CCR:
Resumen de HCE (XML)
• Información más importante de salud y demográfica
Continuidad del cuidado
• Mejor que email o pdf
NEMA DICOM v3:
Estudios imagenológicos: persistencia y comunicación
• Modalidades, PACS, RIS, HCE (Q/R o WADO)
Plug-n-play 18
19. Estandarización a nivel nacional
Estrategia:
Elegir stack de estándares (SS)
• Adoptar, adaptar, crear, mantener
• Arquitectura de ref., servicios mínimos, estándares y espec. abiertas
Definir guías de implementación (IG)
Especificar implementaciones en tecnologías (ITS)
Certificación por etapas
• Parte de la sustentabilidad
Implementación
Factibilidad y sustentabilidad:
Depende de apoyo financiero y político
• Es necesario generar servicios de valor agregado
• Usar menos recursos y lograr mejores resultados
• HCEU es parte importante de la solución
19
20. Usos
Consulta médica remota
Informe radiológico remoto
Prescripción electrónica a farmacias externas
Sistema nacional de trauma
HCEP (prevención, promoción, control)
Seguim. enf. crónicas
Reservas online
¡Si se puede!
Usar menos recursos
Generar valor (recursos)
Mejorar la atención
20
21. Invitación a cursos
openEHR en español
openehr.org.es/curso
Interoerabilidad en SIS
openehr.org.es/cursoisis
21
22. ¡Muchas gracias por su
amable atención!
Ing. Pablo Pazos Gutiérrez
pablo@openehr.org.es
@ppazos 22
Pensar en las piezas que precisamos para armar lo que necesitamos, sabiendo que vamos a necesitar cambiar. Los invito en un viaje hacia una mejor atención sanitaria, un mejor uso de los recursos y una oportunidad para pequeñas y medianas empresas. ¿Qué es la HCEU? Acceso a toda la información clínica y demográfica de cada paciente Independientemente de donde se genere (transversal) Durante toda la vida del paciente (longitudinal)
Arquitectura: componentes, servicios, responsabilidades. Estándares y especificaciones: para distintas partes de la arquitectura, tecnologías que pueden servir (WebSockets, Protocol Buffers, ...)
HCEU - no puede ser única si no está informatizada. - sistemas distribuidos integrados para formar una gran info - estructura. - permite visión integrada de toda la información clínica de cada paciente, independientemente de dónde se haya generado. Oportunidad: Divide el problema en subproblemas muy específicos, los sistemas en subsistemas más simples y mantenibles, beneficios para el mercado (proveedores de cualquier tamaño pueden participar), madurez del mercado para salir al exterior. ¿por qué no un sistema único? LO DEJO PARA DEBATIR (gestión, política, costos, realidad, tecnología) - Cada institución tiene su realidad, su forma de gestionar, sus decisiones, sus procesos, y la HCE es el corazón de esa realidad. - Adaptar todas las instituciones a un único sistema sería demasiado costoso (en $, tiempo, costo político) y monopolizaría el mercado de proveedores. - En lugar de un sistema único: la idea de “HCE virtual” o “HCE en la nube” Brasil 190m hab, Argentina 40m hab, Chile 17m hab Gobierno electrónico: datos públicos y protección de datos personales. HCEU: decreto 2003: http://archivo.presidencia. gub . uy /decretos/2003093001. htm
Arquitectura en entornos federados Compartir más que datos: servicios HCEH: múltiples aplicaciones de registro clínico Ppt 8 Servicios de información pública: clave para la investigación y formación (tenemos terabytes de datos que no podemos usar, imaginemos lo que podrían hacer los investigadores, sería un avance enorme en investigación clínica, en prueba de efectividad de medicamentos y tratamientos, ...) Otros servicios de información que requieran autorización, ej: acceso a registros clínicos de un paciente de un hospital desde otro hospital. Esto es HCE Única!
Para crear el sistema, es necesario empezar por las instituciones!!!! Pero inteligentemente (estándares!!!) Varias ARCs: por tipo de atención (ambulatoria, emergencia/urgencia, hospitalización), por especialidad (oftalmológica, cirugía, cardiológica, ...), ... Separación de información clínica y demográfica. SHCE provee servicios de almacenamiento y búsqueda da inf clínica. - commits con firma, versionado, control de acceso - almacenamiento de info documental y persistente de salud (ej. Hipertensión, alergia, asma: resumen de HCE) - servicios sin estado (no hay workflow) - alta disp. y contingencia: combinación DB relacionales/transaccionales guardar y DBs noSQL escalables/distribuidas para búsqueda y reportes con grandes volúmenes de info agregada: MapReduce. UI separada de ARC - soporte a distintos dispositivos en distintas plataformas - ingreso y visualización de datos - login, sesión, workflow, validación de datos (usando artefactos de la KB) - protocolos de comunicación estandarizados permiten crear nuevas clases de Uis: ej. Basados en WebSockets o Protocol Buffers.
Future proof: la mantenibilidad debería ser parte del diseño porque es lo más costoso. Facilidad para adaptarse al futuro implica sistemas más inteligentes, más genéricos, con más vida útil, y que requieren menos recursos para mantenerse (60% del costo es en evolución) - Cambios por necesidades internas o externas (ley, decreto) Parte del sistema puede autogenerarse desde la base de conocimiento Separación de datos demográficos y clínicos : protección de datos: info en EHR Server está deidentificada => puede ser utilizado directamente para fines secundarios.
ACTUA DE MIDDLEWARE Nacional, regional, federada En la próxima contar cómo hace las cosas: alta disponibilidad, contingencia, actúa como XDS registry, múltiples formatos de salida, gestión de base de conocimiento, ... Identificación de actores: instituciones, rrh, financiadores, laboratorios, farmacias, ... Permite usos secundarios de la información Servicios públicos con información deidentificada Servicios autorizados de información: solo con ciertos actores y bajo convenios (como federación de sistemas) Servicios de información pública: clave para la investigación y formación (tenemos terabytes de datos que no podemos usar, imaginemos lo que podrían hacer los investigadores, sería un avance enorme en investigación clínica, en prueba de efectividad de medicamentos y tratamientos, ...)
Integración y coordinación de servicios e información Control: enfermedades de notificación obligatoria Información actualizada, completa, fidedigna (es lo que está pasando) VE = Salud Pública: condiciones de la población, Toma de decisiones: def. de políticas CE = Prevención y Promoción de la salud, Intervención. CC = desde la necesidad de asistencia hasta el bienestar: Tratamiento, Recuperación, Rehabilitación.
Integración y coordinación de servicios e información Control: enfermedades de notificación obligatoria Empoderamiento de pacientes y personal de salud Información actualizada, completa, fidedigna (es lo que está pasando) VE = Salud Pública: condiciones de la población, Toma de decisiones: def. de políticas CE = Prevención y Promoción de la salud, Intervención. CC = desde la necesidad de asistencia hasta el bienestar: Tratamiento, Recuperación, Rehabilitación.
HCE Virtual es un sistema de servicios integrado que al usuario le da la idea de un sistema único. Para poder crea esa visión única de sistemas heterogéneos, el enfoque de la base de conocimiento es el mejor.
Contenido clínico es más importante que los formatos que vamos a usar para intercambiar datos
Modelo de información: sale del análisis del dominio http:// www . information - management . com / issues /20020501/5170-1. html - clínico, administrativo, financiero, actores, ... Modelo de contenido: sale de requerimientos particulares Terminologías: nomenclaturas, diccionarios, clasificaciones
openEHR es compatible con otros estándares ej. 13606 y CDA Modelo sale del dominio Mostrar el modelo de entradas de openEHR
Propósito primario de la HCE proveer un registro documentado de la atención sanitaria que apoya el tratamiento presente y futuro por los mismos u otros clínicos Propósitos secundarios Médico legal, gestión de calidad, educación, investigación, salud pública, políticas, administración de SS, facturación/finanzas. Médico legal : pruebas de la atención prestada, indicación de cumplimiento de la legislación, reflejo de la competencia de los médicos. Los usos secundarios de la HCE pueden requerir información adicional que no es contenida en la propia HCE. Interoperabilidad es requerimiento de infraestructura. ISO 13606-1:2008 specifies the communication of part or all of the electronic health record (EHR) of a single identified subject of care between EHR systems, or between EHR systems and a centralized EHR data repository. ISO 13606-2:2008 specifies the information architecture required for interoperable communications between systems and services that need or provide EHR data. ISO 13606-2:2008 is not intended to specify the internal architecture or database design of such systems. ISO 13606-3:2009 defines term lists that each specify the set of values that particular attributes of the Reference Model defined in ISO 13606-1 may take. It also defines informative Reference Archetypes that correspond to ENTRY-level compound data structures within the Reference Models of open EHR and HL7 Version 3, to enable those instances to be represented within a consistent structure when communicated using ISO 13606-3:2009. ISO/TS 13606-4:2009 describes a methodology for specifying the privileges necessary to access EHR data. This methodology forms part of the overall EHR communications architecture defined in ISO 13606‑1. ISO/TS 13606-4:2009 seeks to address those requirements uniquely pertaining to EHR communications and to represent and communicate EHR-specific information that will inform an access decision. It also refers to general security requirements that apply to EHR communications and points at technical solutions and standards that specify details on services meeting these security needs. ISO 13606-5:2010 specifies the information architecture required for interoperable communications between systems and services that need or provide EHR data. The subject of the record or record extract to be communicated is an individual person, and the scope of the communication is predominantly with respect to that person's care. ISO 13606-5:2010 defines a set of interfaces to request and provide: an EHR_EXTRACT for a given subject of care as defined in ISO 13606-1; one or more ARCHETYPE(s) as defined in ISO 13606-2; an EHR_AUDIT_LOG_EXTRACT for a given subject of care as defined in ISO/TS 13606-4.
HL7 v2 dentro del hospital HL7 v3 almacenamiento y comunicación dentro y fuera ASTM el esquema lo provee la norma DICOM: incluye informes radiológicos
Estrategia: ver que está haciendo Brasil http://www.sbis.org.br/certificacao/Manual_Certificacao_SBIS_CFM_2011_v4_Consulta_Publica.pdf ITS: Significa ser independiente de la tecnología y de la marca Abre el mercado de proveedores pero de forma controlada sobre las características básicas de las soluciones Cada proveedor hará su “declaración de conformidad” con los estándares, para luego certificarse.
Consulta médica: revisión de estudios, repetición de medicamentos PHR: demora para estudios, resultados, info. útil (prevención, promoción, medicamentos, estudios, cuidados, alimentación saludable, actividad física, ...) HCEP: empoderamiento del paciente, permite prestar servicios que hoy no existen en Uruguay, ej. comunicación con el médico, consultas virtuales, repetición de medicamentos online ... (servicios que hoy no existen en Uruguay)