La vuelta al mundo sobre CDA r2
Anuncio
CDA R2 INFOLAC 2014 Fernando Campos Diego Kaminker HOSPITAL ITALIANO DE BUENOS AIRES KERN INFORMATION TECHNOLOGY S.R.L. Rev.- 1.4 HL7 ARGENTINA CHAIR HL7 INTERNATIONAL,AFFILIATE DIRECTOR 2014 CDA R2 CERTIFIED ANALYST HL7 VOLUNTEER OF THE YEAR 2012 CDA R2 CERTIFIED ANALYST HL7 VOLUNTEER OF THE YEAR 2008 HL7 AMBASSADOR V3/CDA © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 1 Agenda Presentación Conceptos Básicos de CDA Especificación de CDA Casos de Uso de CDA Ejemplos Niveles de Interoperabilidad Semántica Documentos vs. Mensajes Ejemplos de CDA R2 © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 2 ¿Qué es CDA? Un estándar de marcaje para definir la estructura y la semántica de un documento clínico que se requiere intercambiar entre distintos sistemas. Es un estándar ANSI realizado por el comité ‘Structured Documents Technical Committee (SDTC)´ de HL7. Es una especificación para el intercambio de documentos utilizando: XML, el Reference Information Model de HL7, la metodología de desarrollo de la v3 de HL7, y vocabularios controlados (SNOMED, LOINC, CIE-9-MC,...). © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 3 Historia Enero 1997: Primera reunión del grupo de interés de HL7 ... (a alguien le importará el resto) Julio 2003: Primer ballot a nivel comité de CDA R2 Enero 2005: Aprobación en ballot general CDA R2 Actualmente en discusión : CDA R2.1 / CDA on FHIR © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 4 ¿Qué es CDA? Un documento clínico de CDA tiene estas características: Persistencia por el período de retención legal Administrado por una organización encargada para tal fin (stewardship). Potencial para ser autenticado, firmado. Establece contexto. Completitud (autenticación aplicada a todo el documento y no a porciones fuera de contexto). Legilibilidad. Los documentos CDA no son: Fragmentos de datos si no están firmados. Registros acumulativos de historial médico. Acumulación de documentos firmados. Mensajes. © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 5 CDA en el mundo © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 6 CDA en el mundo Principales implementaciones a nivel mundial - por estricto orden arbitrario: Alemania: VHitG : Prescripciones, Resumen HC, Informe de Enfermedades Reportables Argentina: Historia Clínica Electronica Multimedia / Personal Healthcare Record (Hospital Italiano de Buenos Aires) Austria: Austrian eHealth / Cardiac Rhytm Management / Seguimiento de Implantacion de Dispositivos Implantables (CRM) Canadá: e-MS: Electronic Medical Summary (Vancouver Health Authority) Estonia: Resumen de Historia Clinica España: HC3 (Historia Clínica Compartida de Cataluña), Guía SACYL de CDA R2 Finlandia: Historia Clinica Electronica Global © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 7 CDA en el mundo Italia: Prescripción Médica y Solicitudes Radiologicas-Laboratorio (IBSE - Infrastruttura di Base della Sanità Elettronica ) - SOLE (Epicrisis de Internación) Holanda: Transfer of Care - Anatomia Patologica Francia: Registro Medico Personal Jordania/Israel/Palestina (Middle East Consortium for Infectious Disease Surveillance): Control de Infecciones por Salmonella y Shigella Turquía: NHIS - National Health Information System Japón (Nagoya): Seguimiento de Ataques Cardiacos (interconsulta, epicrisis, seguimiento, rehabilitación) Patient Referral Document México: Instituto Mexicano del Seguro Social : Consulta médica Historia Clinica Ambulatoria Korea del Sur: Nota de Consulta Ambulatoria © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 8 CDA en el mundo Nueva Zelanda: Prescripción Electrónica Rusia: Epicrisis - Resumen de Internación / Laboratorio Reino Unido - CFH (Connecting for Healthcare): Assessment Note Suiza: CDA-CH: Especificacion de Intercambio de Documentos en Suiza (10 tipos de documento) USA C-CDA como base del plan de ONC para 2015-2020 HIPAA Attachments Military Health Systems - Department of Defense - Clinical Summary Healthcare Associated Infection (HAI) reporting Uruguay: SUEIIDISS - CDA R2 como base para el intercambio de documentos en la HCE. IHE: IHE-LAB: Reportes de Laboratorio / IHE-XDS-I: Radiología IHE-PCC: Resumen de Historia Clinica para Intercambio entre Instituciones. © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 9 Objetivos Dar prioridad a la atención del paciente Permitir una implementación costo efectiva abarcando el más amplio espectro de sistemas como sea posible Utilizando estándares y promoviendo flexibilidad. Soportar el intercambio de documentos entre usuarios de diferentes niveles de desarrollo tecnológico Promover la longevidad de toda la información basada en esta arquitectura Habilitar un amplio rango de aplicaciones de procesos post-intercambio Promover el intercambio que sea independiente de la transferencia o del mecanismo de almacenamiento Preparar el diseño razonablemente rápido Habilitar a los reguladores a controlar sus propios requerimientos de información sin tener que extender esta especificación © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 10 Utilización Estandarización de Documentos Clínicos para intercambio Contenido Clínico Es definido por el RIM no por CDA CDA estandariza la estructura y la semántica necesaria para el intercambio de documentos Mensajería La especificación de mensajes para el uso de CDA está fuera de la especificación de CDA Sí se define cómo empaquetar un documento CDA dentro de un mensaje HL7 V2.x y V3 Administración o Gestión Documental CDA no especifica la creación o manejo de documentos sino sólo su marcación. La administración de documentos es interdependiente con CDA pero la especificación de mensaje para la administración de documentos esta fuera del alcance © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 11 Casos de Uso Acceso, portabilidad, intercambio de documentos. Buscar y localizar por paciente, proveedor, practicante, lugar, fechas, etc. Acceso a la información usando datos comunes (metadata) Gestión documental Integración Sistemas de transcripciones Registros EHR (Electronic Health Records) Reutilización de la información Resúmenes Reportes Soporte de decisiones Etc Es la ventaja de tener todos los documentos en un mismo formato, accesible de una forma común. © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 12 Escenarios Prestadores a Financiadores Auditoría Historia Clínica del Afiliado/Beneficiario Prestadores a Prestadores Historia Clínica del Paciente (Derivación, Cambio, Interconsulta) Informes Médicos Financiadores a Financiadores Historia Clínica (cambio de financiador, cobertura compartida) Prestadores/Financiadores a Salud Pública Historia Clínica Universal Historia Clínica Pacientes de Riesgo Salud Pública a Prestadores/Financiadores Historia Clínica Universal © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 13 ¿Por qué CDA? Documentos para la interoperabilidad Componente principal para registros electrónicos de salud a nivel local, regional o nacional. Todo el mundo utiliza documentos. Esto permite posibilitar paulatinamente un mejor intercambio de información. Muchos documentos CDA relacionados e indizados por su cabecera componen un registro electrónico de salud. © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 14 Legibilidad y Presentación Forma determinística de volcar el contenido de un documento CDA Debe ser posible volcar todos los documentos CDA con una única hoja de estilo* y con herramientas disponibles en el mercado Aplica al contenido autenticado y no al contenido para procesamiento informático Se deben proveer mecanismos para describir el proceso cuando el contenido estructurado es derivado de la narrativa y viceversa © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 15 Seguridad, Confidencialidad e Integridad Los sistemas que envían y reciben los CDA son los responsables CDA provee información sobre el estado de confidencialidad para ayudar a dichos sistemas en el manejo de información sensible Dicho estado de confidencialidad puede ser aplicado a todo el documento o sólo a segmentos específicos del mismo © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 16 Conformidad Un CDA válido es aquel cuya ínstancia XML valida contra el Schema CDA, y restringe el uso del vocabulario a los dominios especificados. Un CDA válido también debe adherir a los requerimientos de legibilidad humana, que asegura que el contenido legalmente autenticado en origen sea correctamente mostrado al que recibe. Un receptor de un documento CDA debe ser capaz de mostrarlo según las reglas. No es requerido que examine e interprete todas las entrada codificadas del documento, ni que valide contra alguna plantilla determinada. El generador debe poner el contenido legalmente autenticado en bloques narrativos, más allá de las entradas codificadas. No se requiere codificar todo el texto narrativo en entradas codificadas. En cada implementación se pueden definir responsabilidades originales de creación y recepción con respecto a secciones y/o entradas obligatorias © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 17 Extensibilidad Las extensiones locales se pueden incluir en un documento en un namespace distinto del v3. No pueden cambiar el sentido del marcado estándar CDA, y debe poder ser ignorado sin problemas para procesamiento y presentación. Se solicita a los usuarios de CDA formalizar los requerimientos de extensión para ser incorporados en futuras versiones del estándar. © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 18 Generación Los documentos CDA se pueden generar de muchas formas. Mediante aplicaciones del sistema de aplicación del hospital Mediante aplicaciones clientes estándar (transcripciones, dictado) Conversión desde mensajes de HL7 v2 o v3 Mediante transformaciones desde mensajes DICOM Mediante transformaciones desde otros documentos XML Mediante herramientas de eForms Microsoft InfoPath Adobe Acrobat Otras herramientas de muchos fabricantes (mas económicas) © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 19 Metadatos Metadatos : información sobre un item (documento o enunciado) para encontrarlo, en portales para médicos o pacientes. Interoperabilidad horizontal: a través de toda la red de cuidado del paciente: prestadores de salud, servicios sociales, amigos, familiares. Interoperabilidad vertical: agregado de datos para gerenciamiento y análisis centralizado, ‘big-data’. los metadatos deben ser completos, estandarizados, y sin ambigüedades: QUÉ / QUIÉN / DÓNDE / CUÁNDO / DATOS TECNICOS Mejor especificar un pequeño subconjunto de elementos obligatorios de metadatos que uno mayor pero con elementos opcionales. http://abiesuk.blogspot.com.ar/2013/07/metadata-for-clinical-documents-and.html © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 20 Metadatos QUÉ Clase – Categoría de alto nivel - código Tipo – Categoria de nivel más fino o granular – código Especialidad – código (Ginecología?) Tipo de Cuidado – código (Ambulatorio? Internado?) Ejemplo “Informe de Alta Cirugía Urología” Clase: Informe de Alta Tipo Cuidado: Cirugía Especialidad: Urología Título – legible para humanos Confidencialidad © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 21 Metadatos QUIEN Paciente: identificadores, datos demograficos mínimos Profesionales de Salud y Cuidado: creador, efector DONDE Ubicación CUANDO Fecha Evento Fecha Creación TECNICOS / EXTENSIONES Formato Lenguaje Identificador © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 22 Arquitectura – TODO CDA R2 en 1 slide (Casi!! ) © HL7 , HL7 Argentina, KERN-IT SRL INFOLAC 2014 - Intro a CDA R2 [email protected] 23 CDA R2 - ARQUITECTURA Revisemos la estructura de un documento CDA R2 con algunos ejemplos. Detalle de la Cabecera Cuerpo Entradas Codificadas © HL7 Argentina, KERN IT SRL INFOLAC 2014 [email protected] 24 http://goo.gl/hUSpUV Mejores Prácticas en Esquemas de Interoperabilidad Agenda (1) • Objetivos de un proyecto típico O1: Historia de Salud Única (HCE documental) O2: Consentimiento (Opt-In/Opt-Out) O3: Acceso a su historia para los pacientes (PHR) O4: Acceso a la HCE para los proveedores de salud O5: Soporte para Objetos Multimediales O6: Uso secundario de la información O7: Interoperabilidad Semántica Evolutiva 26 12/28/10 Agenda (2) • 10 definiciones D01 – Estrategias / Almacenamiento D02 – Transporte D03 – Seguridad D04 – Confidencialidad / Consentimiento D05 – Identificadores globales unicos (OIDs) D06 – Definicion del Contenido de los Documentos D07 – Estandares de Terminologia D08 – Mapeo de datos de las aplicaciones a documentos D09 – Consumo de documentos por las aplicaciones D10 – Procesos de Identificacion de pacientes Bonus track: Consideraciones 'políticas' 27 12/28/10 Objetivos de un proyecto típico O1: Historia de Salud Única (HCE documental) O2: Consentimiento (Opt-In/Opt-Out) O3: Acceso a su historia para los pacientes (PHR) O4: Acceso a la HCE para los proveedores de salud O5: Soporte para Objetos Multimediales O6: Uso secundario de la información O7: Interoperabilidad Semántica Evolutiva 28 12/28/10 OBJETIVOS [O1] - Historia de Salud Única Documental ¿La mejor historia? Quizás no. Pero... A. ¿Sobre qué podemos ponernos 'todos' de acuerdo? 1. Estructura de la Historia Clinica 'Completa' 2. Estructura granular de cada fragmento de información 3. Historia Clínica Electrónica “Documental” Acuerdo (o Regulación) sobre 'TIPOS DE DOCUMENTO' Ejemplos: Baleares, Castilla y León, Cataluña, epSOS (proyecto europeo), HCD, DMP (Francia), MU (USA)http://www.boe.es/boe/dias/2010/09/16/pdfs/BOE-A-201014199.pdf B. ¿Cuánto tiempo estamos dispuestos a demorar? 29 12/28/10 OBJETIVOS [O2] – Consentimiento Opt-In / Opt-Out El paciente debería ser capaz de elegir si quiere estar excluido del proyecto - para algún tipo de encuentro/documento - para algún encuentro específico - según el uso previsto de la información ...y debería poder cambiar de opinión en el futuro. 30 12/28/10 OBJETIVOS [O2] – Consentimiento Opt-In / Opt-Out Ejemplos: 1. “No quiero que mis datos de salud estén en el repositorio, jamás” 2. “No muestren mis registros de salud mental” 3. “Sólo muestren mis registros de salud mental a un psiquiatra involucrado en mi atención directa” 4. “Sólo muestren mis registros de abuso de drogas si el médico está en una sala de urgencias y me está tratando” 5. “Ahora me arrepentí. Quiero que toda mi historia sea accesible” 6. “Quiero que se vea todo. Pero solo si estoy yo presente o alguien de mi familia” 7. “No quiero que este informe donde consta mi ETS (enfermedad sexual transmisible) esté disponible en general. Sólo para mi urólogo” 8. “No quiero que usen mis datos para estadisticas o pruebas clinicas” 31 12/28/10 OBJETIVOS [O3] – Acceso a su historia para los pacientes PHR: El paciente puede acceder a partes relevantes de su historia a través de un portal Ejemplos: – Meaningful Use Stage 2 (USA) – Historia Clinica Personal (HIBA, Argentina) – Personally Controlled Health Care Record PCEHR (Australia) 32 12/28/10 OBJETIVOS [O3] – Acceso a su historia para los pacientes ¿Partes relevantes? (ejemplos) - Informes de laboratorio / imagen diagnostica - Resumen de Historia Clínica - Ingresar informacion para su medico (cumplimiento de dietas, ejercicio fisico, etc) - Alarmas o Alertas Personalizadas (portal,e-mail) - Informes de divulgación relacionados con su(s) problemas activos o prescripciones (Infobutton / 'information therapy') Ver: http://www.himss.org/content/files/553Getting%20patients%20to%20meaninful%20use.pdf 33 12/28/10 OBJETIVOS [O4] – Acceso para los proveedores de salud Permitir a los proveedores de salud (médicos, enfermeros, técnicos, nutricionistas, etc.) autorizados el acceso a la historia clinica unica – 24/7 (todos los dias, no importa el horario) – Desde sus aplicaciones habituales • Sin hacer ' ALT-TAB ' • Sin tener que ingresar en otra aplicación su usuario/clave, y seleccionar al paciente 34 12/28/10 OBJETIVOS [O5] – Soporte para objetos multimediales No podemos incluir ' solamente texto y números' (hace unos años era negociable) Ahora también se suele exigir la inclusión – aunque sea por referencia - de – Imágenes diagnósticas (ECO/TC/RX/AP/RM) – Electrocardiogramas / Encefalogramas – Videos (endoscopías) – Dispositivos implantables o especiales – Espirometrías – Constantes vitales 35 12/28/10 OBJETIVOS [O6] – Uso secundario de la información Aun sin ser un objetivo primario, los documentos contienen datos estructurados y codificados para: - Cumplir con requerimientos legales - Realizar estadisticas o trabajos clinicos - Realizar informes epidemiologicos - Alimentar historias clinicas estructuradas - Realizar informes de gestión o facturación - Utilizar sistemas de soporte a la decisión clínica 36 12/28/10 OBJETIVOS [O7]: Interoperabilidad Semántica Evolutiva El proyecto tiene que poder: – Integrar a distintos niveles de prestadores en etapas (hospitales, medicos, farmacias, laboratorios, centros de imagenes, etc.) – Mostrar resultados tangibles (Objetivos O1 a O6) en las primeras fases – Permitir un nivel de integración mínimo comprobable (documentos y contexto) y luego evolucionar ( uso secundario ) 37 12/28/10 10 claves de esquemas exitosos D01 – Estrategias / Almacenamiento D02 – Transporte D03 – Seguridad D04 – Confidencialidad / Consentimiento D05 – Identificadores globales unicos D06 – Definicion del Contenido de los Documentos D07 – Estandares de Terminologia D08 – Mapeo de datos de las aplicaciones a documentos D09 – Consumo de documentos por las aplicaciones D10 – Procesos Identificacion de pacientes Bonus track: Consideraciones 'políticas' 38 12/28/10 D01 – Estrategias / Almacenamiento ¿Dónde se van a almacenar los documentos? Opciones - En un único repositorio central - Varios repositorios y un registro central - Varios repositorios y varios registros Discusión: ¿Qué pasa con los prestadores pequeños (clinicas, médicos individuales)? ¿Se puede dejar que el paciente elija su repositorio/registro? (ej: google health/ms health vault) 39 12/28/10 D01 – Estrategias / Almacenamiento ¿Cómo se van a almacenar los documentos? Opciones: Base de datos relacional para metadatos y documentos. Base de datos relacional para los metadatos y file system para los documentos. Base de datos nativa XML Otros: Content Addressed Storage Discusión: ¿Los documentos se almacenan encriptados? ¿Se puede mezclar la información demográfica y la clínica en la misma base de datos? 40 12/28/10 D02 – Transporte ¿Cómo llega un documento hasta el repositorio? Opciones: 1. Mensaje HL7 v2 + MLLP / WS / HTTP-XML 2. Mensaje HL7 v3 + ebXML / WS o HTTP-XML 3. Servicio Web ad-hoc 4. IHE XDS (http://www.ihe.net/Profiles/) 5. Direct Project (MIME+S/MIME+X.509+SMTP) http://directproject.org/ 6. Connect Project WS http://bit.ly/9Z5cm7 41 12/28/10 D03 – Seguridad - Opciones para firmas digitales XMLDSIG por documento: - Almacenadas por separado - Ensobrando al documento - Embebidas en el documento - Evaluar los objetivos: no repudiación, detección de cambios en el documento durante su almacenamiento. - ¿Soportar más de una firma (una firma digital por autenticador del documento)? - Audit Log: registrar todos los accesos autorizados y los intentos no autorizados de acceso. - Otras consideraciones: ataques de tipo denial-of-service, acceso no autorizado, seguridad física, respaldos 42 12/28/10 D04 – Confidencialidad / Consentimiento Ejemplo 1. Evaluación del uso de los codigos de confidencialidad provistos por HL7 y el acceso basado en roles. 2. Evaluar el perfil IHE BPPC (Basic Patient Privacy Consents) : Discusión 1. ¿Hay información que el paciente NO PUEDE VER? 2. ¿Cuáles son los roles y sus accesos propuestos? 3. ¿Cuál es el poder de decisión del paciente? 43 12/28/10 D04 – Confidencialidad / Consentimiento Ejemplo - Por tipo de documento (DMP) 44 12/28/10 D05 – Identificadores Globales Únicos - Cómo obtener una rama de OIDs http://www.hl7.org/oid/index.cfm?ref=common Gráfico gentileza de HL7 Chile (www.hl7chile.cl) 45 12/28/10 D05 – Identificadores Globales Únicos - Guías para crear un árbol de OIDs para su organización y/o proyecto: Pacientes Prestadores Organizaciones Documentos Ordenes Dispositivos Edificios 46 12/28/10 D05 – Identificadores Globales Únicos - Asignación de OIDs (quién, cuándo, proceso administrativo) - Mantenimiento - Consultas al registro a través de WS o de página web Más sobre OIDs http://www.hl7chile.cl/Documentos/OIDs/ Guía de Asignación de OIDs HL7 Spain http://goo.gl/dgAql 47 12/28/10 D06 – Contenido de los documentos - Definir el contenido contextual - Definir el contenido clínico - Definir el contenido para uso secundario (estructurado, codificado) - Ver si se pueden utilizar guías/plantillas preexistentes 48 12/28/10 D06 – Contenido de los documentos - Para cada tipo de documento Definir el contenido contextual Definir el contenido clínico Definir el contenido para uso secundario (estructurado, codificado) Tratar de re-utilizar guías/plantillas preexistentes o (mejor) de proyectos anteriores, y de armonizar las nuevas que generamos. 49 12/28/10 D06 – Contenido de los documentos Guías y Plantillas Disponibles IHE http://wiki.ihe.net/index.php?title=CDA_Release_2.0_Content_Modules HL7 INTERNATIONAL http://wiki.hl7.org/index.php?title=Product_CDA_R2_IG Proyecto EPSOS http://www.epsos.eu/fileadmin/content/pdf/deliverables/D3.5.2_epSOS_Semantic-ServicesDefinition.pdf http://www.epsos.eu/fileadmin/content/pdf/deliverables/D3.9.1_Appendix_B1_Implementation.pdf CDA TOOLS www.cdatools.org LOCALES (de cada afiliado HL7 Internacional) 50 12/28/10 D06 – Contenido de los documentos Documentación de la especificación de contenidos y templates Advanced Requirement Tooling ART-DECOR Data Elements, Codes, OIDs, Rules Datasets: Conjuntos de datos Scenarios: Tipos de artefactos (documentos) según caso de uso. Terminology: Sistemas de Codificacion y conjuntos de valores. Templates: Plantillas de implementación en XML de los Datasets, reglas para la validación de los documentos 12/28/10 D06 – Contenido de los documentos ART-DECOR : Datasets 12/28/10 D06 – Contenido de los documentos ART-DECOR : Scenarios 12/28/10 D07 – Estandares Terminologicos Definir estandares terminologicos globales - Para la informacion demográfica Ejemplo: género/sexo del paciente - Para tipos de documento (LOINC/SNOMED) - Para las secciones del documento (LOINC/SNOMED) 54 12/28/10 D07 – Estándares Terminológicos Definir estándares terminológicos para datos estructurados, y subconjuntos apropiados: – Laboratorio (LOINC/SNOMED) – Radiología (SERAM/RadLex) – Medicamentos (SNOMED/Nomenclator) – Enfermería (NANDA/NIC/NOC) – Diagnósticos (CIE9/CIE10/SNOMED) – Procedimientos (CIE9/CPT) 55 12/28/10 D07 – Vocabulario / Estándares Terminológicos ART-DECOR : Terminology / Terminology Binding 12/28/10 D08 – De las aplicaciones a los documentos Generacion de documentos CDA R2 Opciones 1. Serialización canónica: datos → grafo del R-MIM en memria → Instancia XML de CDA R2. [MIF] 2. Transformación desde otros documentos XML (SQL → Otros XML → Instancia XML de CDA R2) [XSLT] 3. Transformación en dos etapas: (SQL → XML Intermedio Pre-Wire Format → Instancia XML de CDA R2) [XSLT] (Pre-Wire format: GreenCDA, hData, microITS) 4. Esqueleto Base (fragmentos de CDA R2 o template de CDA R2 completo ' completado ' con nuestros datos [DOM] 5. Herramientas de terceras partes (ejemplo: Mirth) 57 12/28/10 D08 – De las aplicaciones a los documentos ART-DECOR : Templates 12/28/10 D08 – De las aplicaciones a los documentos Validación de CDA R2 Opciones 1. Stylesheets 2. Esquemas CDA especiales (greenCDA, microITS) 3. Schematron->Stylesheets 4. Validación basada en MIF (proyectos MHDT, CdaTools) 5. Herramientas de terceras partes (ejemplo Mirth) Discusión No sobre-estimar a los desarrolladores Educar / Hacer todo lo mas simple posible No subestimar el tiempo necesario 59 12/28/10 D09 – Consumo de Documentos 1. Cómo consultar un registro / obtener un documento desde un repositorio 2. Cómo mostrar el documento al usuario 3. Procesamiento para uso secundario 4. Objetos multimedia 60 12/28/10 D09 – Consumo de Documentos 1. Cómo consultar un registro / obtener un documento desde un repositorio Opciones: 1. Mensaje HL7 v2 + MLLP / WS / HTTP-XML 2. Mensaje HL7 v3 + ebXML / WS o HTTP-XML 3. IHE XDS (http://www.ihe.net/Profiles/) 4. Direct Project (MIME+S/MIME+X.509+SMTP) 5. Connect Project WS 6. Otros (ad-hoc) 61 12/28/10 D09 – Consumo de Documentos 2. Cómo mostrar el documento al usuario Opciones: A. Explorador web separado B. Dentro de un formulario de la aplicación de historia clinica Discusión - hojas de estilo versionadas o especiales - almacenar localmente o registrar audit-log de lo que el usuario vió 62 12/28/10 D09 – Consumo de Documentos 3. Procesamiento Secundario Opciones: 1. Aplicaciones RIM-aware (entradas RIM-> base de datos RIMbased) o (entradas RIM -> objetos RIM -> Base de Datos relacionales) 2. Procesamiento DOM / x-path (buscar entradas con templates especificas y procesarlas) 3. Procesamiento Nativo del XML: realizar aprovechamiento secundario directamente sobre la base de datos en el conjunto de documentos. 63 12/28/10 D09 – Consumo de Documentos 4. Objetos Multimediales Discusión: a. Cómo ir del documento a la imagen u objeto - Instalacion de Visores en las estaciones de los medicos - Streaming / Uso de Ancho de Banda - Uso de DICOM ' Key Images' b. Evaluar el Uso de WADO ( Web Access to Dicom Objects Incluimos referencias absolutas (url) en documentos que no pueden modificarse. ¿Qué pasa si el PACS cambia? c. Acceso separado al PACS (Mas trabajo y posibles errores para los medicos) 64 12/28/10 D10 – Procesos de Identificacion de pacientes Evaluar si es necesario (usualmente lo es) – Gestion Federada de Identificadores de Paciente ( ejemplo : perfil PIX/PDQ de IHE), funciones: - Transmitir informacion desde el origen al manager - Proveer acceso a la lista de identificadores a traves de consultas o actualizaciones Si el identificador de paciente es único y universalmente usado por todas las aplicaciones, este componente no es necesario (rara vez ocurre) 65 12/28/10 Bonus Track (1) Consideraciones Politicas – Asegurar Consenso para el contenido de los tipos de documento y el vocabulario con los grupos medicos involucrados (y otros proveedores de salud). – Buscar ' líderes de opinión' que entiendan y apoyen el proyecto en cada comunidad de prestadores. 66 12/28/10 Bonus Track (2) Consideraciones Politicas Educar a los pacientes: que significa cada nivel de consentimiento Educar a los usuarios: '¿cómo busco la ultima cirugia de un paciente?' / usabilidad y seguridad de los pacientes Educar a los funcionarios: ¿cuánto tiempo va a tomar este proyecto? y...¿por qué? 67 12/28/10 Bonus Track (3) Consideraciones Politicas Comenzar con algo simple y luego agregar tipos de documento y complejidad. Visibilidad: documentar todas las decisiones y motivaciones. 68 12/28/10 http://goo.gl/hUSpUV La vuelta al mundo en CDA R2 Projectos de HCE compartida basados en CDA R2 1 Objetivos 2 Decisiones 3 A viajar: DMP, PCEHR, HIBA, HC3, epSOS 4 Conclusiones 5 Preguntas Pag. 3 Agenda Pequeño Glosario Inicial • HCE = Historia Clínica Electrónica - equivalente a ECE (Expediente Clínico Electrónico) • HCE compartida - historia clínica compartida por más de una institución o prestador • Prestador: médico u otro profesional de la salud: enfermera, nutricionista, etc. Individual: una sola persona, Organización: Hospital, Clínica, Sanatorio, Laboratorio de Examenes Clínicos, Farmacia, Centro de Diagnóstico por Imágenes • CDA R2: Clinical Document Architecture Release 2.0: Estándar de HL7 que define el contenido de la información intercambiada entre prestadores en forma de DOCUMENTO (ejemplo: informe de alta, epicrisis, nota de consulta, etc.) • Vocabulario controlado, Terminología: Conjunto controlado de conceptos que permite intercambiar información ‘COMPRENDIENDO’ lo que se intercambia Objetivos de HCE compartida basada ¿Para qué hacemos esto? en CDA R2 Objetivos Primarios Repositorio longitudinal de Historia de Salud y/o Continuidad de Cuidados (Basada en Documentos) Acceso para prestadores a la historia compartida 24/7, desde su propio software de HCE Acceso para los pacientes (PHR) It´s the patient, stupid! Privacidad, Seguridad ”Every breath you take…” Pág. 4 Objetivos de HCE compartida basada ¿Para qué hacemos esto? en CDA R2 Objetivos Secundarios Consentimiento “¿¡Cómo puedo borrarme de esta cosa?!” Soporte Multimedial “¡Quiero ver mi radiografía de tórax, no el informe!” Uso Secundario de la Información “¿Cuántos pacientes en total con diabetes?“ Interoperabilidad Semántica Evolutiva ”¿Necesitamos cambiar todo el software que utilizamos de golpe?” Pag. 5 Agenda Projectos de HCE compartida basados en CDA R2 1 Objetivos 2 Decisiones 3 A viajar: DMP, PCEHR, HIBA, HC3, epSOS 4 Conclusiones 5 Preguntas Pag. 3 Decisiones Leer antes de probar esto en casa Temas a Discutir (no técnicos) Gobernanza Retorno de Inversión - Sostenibilidad Educación de Pacientes Educación de Prestadores / Efectores Formación y Certificación de Vendedores de Software Pag. 7 Leer esto antes de probar de hacerlo en casa Decisiones Infraestructrura Estrategias de Identificación de Pacientes Estrategias de Almacenamiento Transporte de Documentos Firma digital y Seguridad Privacidad / Confidentialidad / Consentimiento Pag. 8 Decisiones Leer esto antes de probar de hacerlo en casa Contenido de los Documentos Identificadores Globalmente Únicos Generación de Documentos Consumo de Documentos y Extracción de Datos Tipos de Documentos, Plantillas, Texto, Elementos estructurados Vocabularios / Terminologías controladas Pag. 9 Agenda Projectos de HCE compartida basados en CDA R2 1 Objetivos 2 Decisiones 3 A viajar: DMP, PCEHR, HIBA, HC3, epSOS 4 Conclusiones 5 Preguntas Pag. 3 ¡A viajar! Algunos proyectos que revisamos* De todo el mundo DMP (Dossier Médical Personnel)-Francia Personally Controlled EHR – Australia HC3 – Cataluña, España Proyecto epSOS, Unión Europea *NOTA: Esto es lo que pudimos averiguar, preguntar y obtener respuesta, o leer en la documentación o especificaciones. Si alguien se ofende o siente que alguna información es incorrecta o está distorsionada, ofrezco mis mas sinceras disculpas. Y como dicen los italianos. “SE NON È VERO, È BEN TROVATO” Pag. 11 DMP – Dossier Medical Personnel Objetivos and Resultados Objetivos: “permitir a los prestadores de salud que atienden a un paciente compartir la información requerida para la coordinación del tratamiento” Alcance: todo el país (toda Francia) 372,878 carpetas creadas (hasta el 1/9/2013) €210MM? inversión en 5 años 203 organizaciones participantes 148 aplicaciones DMP-compatibles Pag. 12 MM = 000 000 DMP – Dossier Medical Personnel Temas No Técnicos Gobernanza: creada y mantenida por l’ASIP Santé que significa: “Agencia de Información de Sistemas Compartidos de Información de Salud” Educación de Pacientes y Prestadores: varios videos disponibles en el sitio de DMP dmp.gouv.fr (en Francés, je suis désolé!) – para pacientes y prestadores, Q&A y un curso de e-learning al respecto. Educación y Certificación de Vendedores: información y guías públicas de implementación. Programa de Certificación. Ejemplos de código en Java y C# Pag. 13 DMP – Dossier Medical Personnel Infraestructura Estrategia de Identificación de Pacientes: INS-A (Identificador Nacional de Salud) + servicios web Estrategia de Almacenamiento: Repositorio Central de Documentos Transporte de Documentos: IHE XDS.b o SOAP+Mensajes HL7 V3 Firma Digital / Seguridad : SAML, Digital Signing for XML Document (XADES), separada del doc. Privacidad: opt-in explícito. El paciente puede excluir el acceso por tipo de documento y prestador Pag. 14 DMP – Dossier Medical Personnel Contenido de los Documentos Identificadores Globalmente Únicos (administrados por ASIP) Para pacientes (INS) Para prestadores (a través de la tarjeta CPS) Para organizaciones Consumo de Documentos: Pag. botón o ícono especial que llama a un servicio web brindado por DMP 15 DMP – Dossier Medical Personnel Contenidos de los Documentos Tipos de Documento, Plantillas, Texto, Estructura Definiciones de cabecera generados por ASIP: HIS Interoperability Framework Content Layer Common Rules and Templates for CDA Headers module (Hay una traducción al inglés de la versión 1.0) NonXMLbody: pdf/jpg/tiff/rtf/text Soporte para DICOM Pag. 16 DMP – Dossier Medical Personnel Contenido de los Documentos La versión más moderna (11/2012) incluye definiciones basadas en perfiles de IHE para: Alta Hospitalaria Resumen Médico Cardiología Resultados de Laboratorio Certificado de Salud Pediátrica Tarjeta de Vacunación Reporte de Imagenología Directiva Anticipada para la Atención Médica Pag. 17 DMP – Dossier Medical Personnel Contenido de los Documentos Terminología / Vocabularios Procedimientos, Imágenes, Patología: CCAM Diagnósticos: ICD-10 Resultados de Consultas: DRC (dictionaire de results de consultation- Societe Francaise de Medicine) Labs: LOINC Pag. 18 PCEHR– Personally Controlled EHR Objetivos y Resultados Objetivos: “enfrentar la fragmentación de la información permitiendo a cada persona acceder más fácilimente a su propia información de salud y hacer su información accesible de forma segura sus distintos prestadores de salud involucrados en su cuidado” Alcance: país entero (Toda Australia) Pag. 19 PCEHR– Personally Controlled EHR Objetivos y Resultados 210000 usuarios registrados (Mayo 2013) Inversión mayor a $400 MM (2010-) 243 organizaciones participando 15 aplicaciones compatibles Pag. 20 PCEHR– Personally Controlled EHR Temas No Técnicos Gobernanza: por ley gestionada por el Departamento de Salud y Vejez. Desarrollada por una agencia llamada NEHTA. Educación de Pacientes y Prestadores: centro de aprendizaje, sitios web. Incentivos MONETARIOS para prestadores Pag. 21 PCEHR– Personally Controlled EHR Temas No Técnicos Privacidad: opt-in explícito, los pacientes tienen que ‘abrir una cuenta’ a través de un proceso específico, y seleccionar un nivel de acceso para sus prestadores. Certificación y Educación de Vendedores: Centro para desarrolladores con acceso a todas las especificaciones, ejemplos y seminarios. No hay una lista de productos certificados aún (vendors.nehta.gov.au) Pag. 22 PCEHR– Personally Controlled EHR Contenido de los Documentos Identificadores Globalmente Únicos IHI - Identificador Individual de Salud HPI-I - Identificador Individual de Prestador HPI-O - Identificador Individual de Organización Consumo de Documentos Guía de Implementación sobre como ‘mostrar’ un documento CDA de PCEHR. Pag. 23 PCEHR– Personally Controlled EHR Contenido de Documentos Tipos de Documento, Plantillas, Texto, Estructura Foco en definición lógica basada en arquetipos, más alla de la implementación como CDA R2 Pag. 24 PCEHR– Personally Controlled EHR Contenido de los documentos Definiciones lógicas y guías de implementación para: Directivas de Cuidado Adelantadas Sumario Electrónico de Alta Manejo Electrónico de Medicación Interconsulta Electrónica Notas y resumen de salud ingresadas por el paciente. Resumen de eventos compartidos PCEHR Carta del Especialista Pag. 25 PCEHR– Personally Controlled EHR Contenido de los Documentos Terminología Cada guía especifica sus vocabularios y conjuntos de códigos. Esto incluye: SNOMED CT-AU, LOINC para tipos de documento Vocabularios específicos australianos para sexo, uso de nombres, estado o tribu indígena, etc. Pag. 26 HC3 – Historia Clinica Compartida de Cataluña Objetivos y Resultados Objetivos: “es el registro electrónico con el conjunto de los documentos conteniendo datos e información relevante acerca de la situación de un paciente durante la provisión de cuidado de su salud” Alcance: regional (Cataluña es una de las regiones autónomas de España) Pag. 27 HC3 – Historia Clinica Compartida de Cataluña Objetivos y Resultados 74000 accesos/mes (prestadores) Sin información accesible sobre la inversión 468 organizaciones participantes 11 aplicaciones compatibles con HC3 51,000,000 de documentos publicados También publicada como PHR (Carpeta Personal de Salud), con bajo nivel de acceso aún (50 hits diarios) Pag. 28 HC3 – Historia Clinica Compartida de Cataluña Temas No Técnicos Gobernanza: gestionada por TicSalut, Departament de Salut, Cataluña Educación de Vendedores: TicSalut provee servicios para vendedores incapaces de conectar sus propios productos, incluyendo configuración de middleware (Mirth). Consentimiento: la generación de documentos para HC3 es OBLIGATORIA para los prestadores. La participación en CPS es opcional para los pacientes. Pag. 29 HC3 – Historia Clinica Compartida de Infraestructura Cataluña Estrategia de Identificación de Pacientes: Tarjeta CIP de Cataluña + otros 2 posibles identificadores (nacional, europeo) Estrategia de Almacenamiento: repositorio central+repositorios individuales, registro central.. Document Transport: SOAP/IHE/servicios web ad-hoc. Seguridad / Firma Digital : PKI/ SAML Multimedia: todos los objetos DICOM están disponibles Pag. 30 HC3 – Historia Clinica Compartida de Cataluña Contenido de los Documentos Identificadores Globalmente Únicos Gestionados por TICSALUT para prestadores, organizaciones y vocabularios locales. Consumo de Documentos Portal Ad-hoc , con acceso a través de SAML Acceso a traves de cada HCE si la HCE lo implementa Pag. 31 HC3 – Historia Clinica Compartida de Cataluña Contenido de los Documentos Tipos de Documentos, Plantillas, Estructura Los contenidos mínimos de los documentos para las HCE fueron definidos por una ley española La ley contiene especificaciones para Reporte de Alta, Reporte de Emergencia, Laboratorio, Patologia, Imagenologia, Enfermeria, y Resumen de Historia HC3 cumple con lo definido por la ley española Pag. 32 HC3 – Historia Clinica Compartida de Cataluña Contenido de los Documentos CDA R2 IG para: Informe de Alta Informe de Alta de Emergencias Reporte de Enfermería Nota de Consulta Ambulatoria Reporte de Imagenologia Reporte de Laboratorio y Anat. Patologica Vacunación Resumen de Historia Pag. 33 HC3 – Historia Clinica Compartida de Cataluña Contenido de los Documentos Terminología SNOMED CT (versión en Catalán, administrada por TicSalut) ICD9, ICD10 NANDA (para enfermería) SERAM (para imagenología) LOINC para tipos de documento y laboratorios Pag. 34 Proyecto epSOS Objetivos y Resultados • Objetivos: “permitir el intercambio de información personal de salud a través de las fronteras” ‘servicios epSOS’ : (servicios inteligentes abiertos para pacientes europeos) - Prescripción Electrónica, Resumen de pacientes (más servicios planeados a futuro) Alcance: se está probando ahora en 11 países: Austria, República Checa, Dinamarca, Francia, Grecia, Italia, Holanda, Noruega, Eslovaquia, España, Suecia - 23 países participan en total Pag. 35 Proyecto epSOS Objetivos y Resultados Inversión : USD 50 MM + FTEs contribuídas de países y compañias participantes. El proyecto comenzó en 2008. Su objetivo es probar conceptos de interoperabilidad entre países, y está en una fase de prueba, así que no hay resultados publicados disponibles en términos de su uso efectivo Pag. 36 Proyecto epSOS Temas No Técnicos Gobernanza: coordinado por la Swedish Association of Local Authorities and Regions (SALAR) Educación de Pacientes y Prestadores: hay una guía para pacientes y prestadores en el sitio de epSOS donde se puede encontrar que hospitales tienen acceso a epSOS y como utilizarlo Certificación y Educación de Proveedores: documentación accesible en forma gratuita en www.epsos.eu Pag. 37 Proyecto epSOS Temas No Técnicos Consentimiento: opt-in para pacientes, declarado a un epSOS health professional y luego (en otro país) el paciente necesita ir a otro epSOS Point of Care donde un nuevo consentimiento se requiere tanto para acceder al resumen de historia como para crear un nuevo resumen. Pag. 38 Proyecto epSOS Infrastructure Estrategia de Identificación de Pacientes: Servicios nacionales a través de identificadores nacionales o regionales + número de asegurado (opcional) Estrategia de Almacenamiento: repositorios nacionales Transporte de Documentos: servicios web basados en perfiles IHE XDS llamados National Interface + National Connector Seguridad : ’core elements’: Security Manager, Policy Manager, Consent Manager, Audit Manager Pag. 39 Proyecto epSOS Contenido de los Documentos Identificadores globalmente únicos Asignados a nivel nacional salvo para los vocabularios y set de datos epSOS Consumo de Documentos Para resumen de historia de paciente...…¡complicado! Involucra la traducción inter-lenguajes del contenido clínico epSOS provee traducciones a través de sus propios servicios semánticos y de vocabulario (ejemplo: el resumen es de un médico español, pero lo tiene que leer un médico francés) Pag. 40 Proyecto epSOS Contenido de los Documentos Tipos de Documento, Plantillas, Estructura Los contenidos están definidos en la guía de implementación epSOS CDA R2. Algunas de las secciones definidas para los documentos son: Alergias, Medicaciones, Vacunación, Historia de Enfermedades Anteriores, Procedimientos e Intervenciones, Dispositivos, Estado Funcional, Signos Vitales, Resultados, Plan de Cuidado Pag. 41 Proyecto epSOS Contenido de los Documentos • Terminología: epSOS produjo sus propios servicios terminológicos para medicaciones y, problemas. Tienen que traducir el contenido original del documento al lenguaje destino Pag. 42 Agenda Projectos de HCE compartida basados en CDA R2 1 Objetivos 2 Decisiones 3 A viajar: DMP, PCEHR, HIBA, HC3, epSOS 4 Conclusiones 5 Preguntas Pag. 3 Conclusiones Algunas reflexiones finales CDA está bien, pero se necesita mucho más que CDA (‘infoestructura’, aspectos no técnicos) Surgen ‘buenas prácticas’ comunes a todos los proyectos (uso de XML Signature, IHE XDS, SAML). No parece ser posible alcanzar el aprovechamiento masivo de estos proyectos si el consentimiento es ‘opt-in’. Hay una tendencia a ‘compartir el documento + el contenido clínico’, no ‘solo el documento’ Pag. 44 Y un e-mail Pag. 45 Conclusiones Conclusiones Le parece completamente inentendible? Para nosotros es CDA… En todo el mundo! Pag. 46 Pero la lista podria continuar... Agradecimientos Virginia Lorenzi y Frances Morrison (Columbia University NY) Carlos Gallego (HL7 Spain / epSOS) Richard Dixon Hughes (HL7 Australia) Xinting Huang (HL7 China) Fernando Campos (HL7 Argentina) Pag. 47 http://goo.gl/hUSpUV Integrar el CDA a la Historia Clínica Electrónica Necesidad de interoperabilidad Aplicaciones y propósitos distintos. Hospital Italiano Necesidad de Seguridad ¿ Como asegurarnos que el registro electrónico permanece inalterable en el tiempo ? Necesidad de Portabilidad Compartir la documentación con otros actores, instituciones, pacientes, financiadores. Solución Una arquitectura basada en estándares. Interoperabilidad sintáctica HL7 permite interoperabilidad estándar en estructuración de la información Solución Interoperabilidad semántica Necesitamos un mismo lenguaje. Creación de Master Files. Los MF son un conjunto de registros y vocabularios que permiten identificar instancias de entidades. Personas, Áreas Jerárquicas, Lugares, Pacientes Solución Escalabilidad • Adopciones de estándares globales Estándares que usamos Estándares de mensajería: Para el intercambio de los datos HL7 y para el intercambio de imágenes, DICOM Estándares de terminología: SNOMED para términos patológicos, LOINC para resultados de laboratorio, o CIE para los diagnósticos. Decisiones a tomar al encarar un repositorio documental 01 – Estrategias / Almacenamiento 02 – Transporte 03 – Seguridad 04 – Confidencialidad / Consentimiento 05 – Identificadores globales únicos 06 – Definición del Contenido de los Documentos 07 – Estándares de Terminología 08 – Consumo de documentos por las aplicaciones 1 – Estrategia – Almacenamiento y transporte Almacenamiento Repositorio central, un file system donde los documentos pueden ser solo guardados y no modificados. Accedidos desde el EHR, el PHR y se generan CDs para intercambiar información con financiadores. Base de datos relacional para los metadatos y file system para los documentos. Transporte WS que se encarga de parsear al menos el header del documento y registrarlo el modelo relacional y almacenarlo en el sistema de archivos. 3 – Seguridad Firma electrónica embebidas en el documento. 3 – Seguridad Solución HIBA 4 – Confidencialidad / Consentimiento Evaluación del uso de los códigos de confidencialidad provistos por HL7 y el acceso basado en roles. Evaluar el perfil IHE BPPC (Basic Patient Privacy Consents) : Solución HIBA Uso de los códigos de confidencialidad provisto por HL7 incluidos en el CDA. 4 – Confidencialidad / Consentimiento Uso de los códigos de confidencialidad provisto por HL7 incluidos en el CDA. <!--representa un tipo de documento clínico --> <code code="34108-1" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Nota de Evaluación"/> <!-- Título del Documento, contenido narrativo --> <title>Hospital Italiano de Bs. As. - Historia Clínica </title> <!--representa la fecha de creación de documento clínico --> <effectiveTime value="20051203153025"/> <!--N=normal (todo individuo autorizado relacionado con medicina o necesidades pertinentes) R=restringido (sólo prestadores que tengan relación de atención médica con el paciente) V=muy restringido (Sólo personas autorizadas por la autoridad a cargo de la HC del paciente)--> <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/> 5 – Identificadores globales únicos Obtener una rama de OID http://www.hl7.org/oid/index.cfm?ref=common 5 – Identificadores globales únicos 5 – Identificadores globales únicos Utilizar OIDs para identificadores generados por la aplicación. <!--representa el lenguaje de los datos. Usa el estándar de la IETF, RFC 3066.--> <languageCode code="es-AR"/> <!--representa un id que es común a todas las revisiones de los documentos.--> <setId extension="HCA23789" root="2.16.840.1.113883.2.10.1.2.1"/> <!--representa el número de versión del documento.--> <versionNumber value="1"/> 6 – Contenido de los documentos Plantillas CCD (Continue Care Document), que es una implementación de CCR (Continue Care Record) usando la especificación de CDA Guía de implementación local, para los CDAs que no están cubiertos por las plantillas CCD. Enfermería principalmente. 6 – Contenido de los documentos Concepto de sesión médica para el registro clínico. Es el agrupador natural de las diferentes acciones que toma un profesional de la salud y registra en la HCE en un encuentro con el paciente. Ejemplo : Paciente que concurre al médico por fiebre y tos. 6 – Contenido de los documentos Agrega el problema y registra la evolución 6 – Contenido de los documentos Le solicita una Radiografía de Tórax 6 – Contenido de los documentos Pide una interconsulta con el servicio de Neumonología 6 – Contenido de los documentos Indica un antigripal 6 – Contenido de los documentos Del relacional al documental 6 – Contenido de los documentos 6 – Contenido de los documentos 6 – Contenido de los documentos 6 – Contenido de los documentos 7 – Estándares de Terminología Definir estándares terminológicos globales. - Para la información demográfica Ej: género/sexo - Para tipos de documento (LOINC/SNOMED) - Para las secciones del documento (LOINC/SNOMED) ¿Qué/cuáles vocabulario(s) utilizar? • Problemas de Salud – Diagnósticos, Signos, Síntomas • Procedimientos • Indicaciones – Farmacológicas – No farmacológicas • Exámenes – Solicitud de exámenes • Examen Físico – Signos Vitales Elección de terminología La decisión más fácil: SNOMED-CT • SNOMED CT es esencialmente la terminología clínica más completa en el mundo – No hay opciones comparables, todo lo demás es más limitado • El resto del mundo está yendo a su adopción – En uso en más de 60 países (30%) Interoperabilidad Semántica • Servidor de Terminología Pieza de Software que brinda los siguientes servicios: –Vocabulario de interface de acuerdo a la jerga local y conceptos más utilizados –Codificación Automática en línea por repetición de textos o sugerencia de términos relacionados –Basado en UMLS 2004 (incluye Snomed CT) –Salida de los diagnósticos con diversos vocabularios según la necesidad de análisis (CIAP, CIE-9CM, CIE-10, nomenclador, etc.) –Relaciona conceptos, permitiendo subir o bajar el detalle de los mismos. 18/03/2015 147 Servidor de Terminología Clínica HIBA Web Service Respuestas del HIBA Oferta de Opciones TEXTO RECONOCIDO TEXTO NO RECONOCIDO Salida Código CIE-9-MC Salida Código CIE-10 Código de SNOMEDCT DIAGNÓSTICO VÁLIDO DIAGNÓSTICO NO VÁLIDO 8 – Consumo de documentos por las aplicaciones Cómo mostrar el documento al usuario Procesamiento para uso secundario Objetos multimedia 8 – Consumo de documentos por las aplicaciones 8 – Consumo de documentos por las aplicaciones CDAs integrado dentro de la HCE – Módulo evoluciones CDA 8 – Consumo de documentos por las aplicaciones PORTABILIDAD – INTEROPERABILIDAD !!!! Navegador de CDAs que se entrega al financiador CDA 8 – Consumo de documentos por las aplicaciones Documentos pendientes de firmar 8 – Consumo de documentos por las aplicaciones INTEROPERABILIDAD !!!!! Navegador de CDAs de resultados dentro de la HCE 8 – Consumo de documentos por las aplicaciones INTEROPERABILIDAD !!!!! Navegador de CDAs de resultado de diagnóstico por imágenes 8 – Consumo de documentos por las aplicaciones Desde el CDA, acceso al visor DICOM 8 – Consumo de documentos por las aplicaciones CDA desde el Portal Personal de Salud del Paciente. 8 – Consumo de documentos por las aplicaciones CDA desde el Portal Personal de Salud del Paciente. 8 – Consumo de documentos por las aplicaciones CDA desde el Portal Personal de Salud del Paciente. http://apps.nlm.nih.gov/medlineplus/services/mpconnect_service.cfm?mainSearchCrit eria.v.cs=2.16.840.1.113883.6.1&mainSearchCriteria.v.c=16683&mainSearchCriteria.v.dn=&informationRecipient.languageCode.c=sp 8 – Consumo de documentos por las aplicaciones Documentos desde dispositivos móviles 8 – Consumo de documentos por las aplicaciones Imágenes desde dispositivos móviles Muchas gracias… Diego Kaminker KERN-IT srl, Information Architect, Gerente/Socio HL7 International - Affiliate Director Columbia Univ NY HIT Certificate Program, HIME role, consultor [email protected] Fernando Campos Msc. Lic. Jefe Área Ingeniería de Software Departamento de Informática en Salud Hospital Italiano de Buenos Aires – Argentina HL7 Argentina Chair [email protected]
