Hacia la Historia Clínica Electrónica Única de cada persona

5,510 views

Published on

Hacia la Historia Clínica Electrónica Única de cada persona, arquitectura, estándares y estrategia.

Published in: Health & Medicine
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,510
On SlideShare
0
From Embeds
0
Number of Embeds
2,589
Actions
Shares
0
Downloads
0
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide
  • 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!
  • Acceder -> Redes -> Servicios -> Estándares -> Certificación -> Sustentable
  • 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)
  • Hacia la Historia Clínica Electrónica Única de cada persona

    1. 1. Hacia la Historia ClínicaÚnica de cada persona Ing. Pablo Pazos Gutiérrez openEHR.org.es 1
    2. 2. Agenda Contexto Arquitectura de HCE Única Estándares y especificaciones Ejemplos de uso 2
    3. 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. 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. 5. Arquitectura de HCE Única Características de la solución  Accesibilidad  Seguridad  Disponibilidad  Modificabilidad  Interoperabilidad  Longitudinalidad  Escalabilidad  Gestionabilidad  Sustentabilidad 5
    6. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
    16. 16. openEHR ADL 16
    17. 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. 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. 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. 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. 21. Invitación a cursos openEHR en español  openehr.org.es/curso Interoerabilidad en SIS  openehr.org.es/cursoisis 21
    22. 22. ¡Muchas gracias por su amable atención! Ing. Pablo Pazos Gutiérrez pablo@openehr.org.es @ppazos 22
    23. 23. ProyectosInteresantes 23
    24. 24. EHRGen24
    25. 25. EHRGen25
    26. 26. EHRGen26
    27. 27. EHRGen27
    28. 28. hQuery28
    29. 29. hQuery29
    30. 30. CKM30
    31. 31. CKM31
    32. 32. CKM32
    33. 33. Links EHRGen  http://code.google.com/p/open-ehr-gen-framework/ hQuery  http://projecthquery.org/ CKM  http://www.openehr.org/knowledge/ Informática Médica y Estándares  http://informatica-medica.blogspot.com/ 33

    ×