CDA R2 INFOLAC Diego Kaminker. Fernando Campos

Transcripción

1 CDA R2 INFOLAC 2014 Fernando Campos HOSPITAL ITALIANO DE BUENOS AIRES HL7 ARGENTINA CHAIR CDA R2 CERTIFIED ANALYST HL7 VOLUNTEER OF THE YEAR 2012 Diego Kaminker KERN INFORMATION TECHNOLOGY S.R.L. HL7 INTERNATIONAL,AFFILIATE DIRECTOR CDA R2 CERTIFIED ANALYST HL7 VOLUNTEER OF THE YEAR 2008 HL7 AMBASSADOR V3/CDA Rev HL7 Argentina, KERN IT SRL INFOLAC

2 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

3 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 diego.kaminker@kern-it.com.ar 3

4 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 diego.kaminker@kern-it.com.ar 4

5 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 diego.kaminker@kern-it.com.ar 5

6 CDA en el mundo HL7 Argentina, KERN IT SRL INFOLAC

7 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 diego.kaminker@kern-it.com.ar 7

8 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 diego.kaminker@kern-it.com.ar 8

9 USA Nueva Zelanda: Prescripción Electrónica CDA en el mundo 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) C-CDA como base del plan de ONC para 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 diego.kaminker@kern-it.com.ar 9

10 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 diego.kaminker@kern-it.com.ar 10

11 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 diego.kaminker@kern-it.com.ar 11

12 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 diego.kaminker@kern-it.com.ar 12

13 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 diego.kaminker@kern-it.com.ar 13

14 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 diego.kaminker@kern-it.com.ar 14

15 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 diego.kaminker@kern-it.com.ar 15

16 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 diego.kaminker@kern-it.com.ar 16

17 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 diego.kaminker@kern-it.com.ar 17

18 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 diego.kaminker@kern-it.com.ar 18

19 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 diego.kaminker@kern-it.com.ar 19

20 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. HL7 Argentina, KERN IT SRL INFOLAC 2014 diego.kaminker@kern-it.com.ar 20

21 QUÉ Clase Categoría de alto nivel - código Metadatos 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 diego.kaminker@kern-it.com.ar 21

22 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 diego.kaminker@kern-it.com.ar 22

23 Arquitectura TODO CDA R2 en 1 slide (Casi!! ) HL7, HL7 Argentina, KERN-IT SRL INFOLAC Intro a CDA R2 diego.kaminker@kern-it.com.ar 23

24 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 diego.kaminker@kern-it.com.ar 24

25 Mejores Prácticas en Esquemas de Interoperabilidad

26 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

27 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

28 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

29 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) B. Cuánto tiempo estamos dispuestos a demorar? 29 12/28/10

30 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 /28/10

31 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

32 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

33 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, ) - Informes de divulgación relacionados con su(s) problemas activos o prescripciones (Infobutton / 'information therapy') Ver: Getting%20patients%20to%20meaninful%20use.pdf 33 12/28/10

34 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

35 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

36 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 12/28/10 36 clínica

37 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

38 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

39 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

40 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

41 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 ( 5. Direct Project (MIME+S/MIME+X.509+SMTP) 6. Connect Project WS /28/10

42 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

43 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

44 D04 Confidencialidad / Consentimiento Ejemplo - Por tipo de documento (DMP) 44 12/28/10

45 D05 Identificadores Globales Únicos - Cómo obtener una rama de OIDs Gráfico gentileza de HL7 Chile ( /28/10

46 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

47 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 Guía de Asignación de OIDs HL7 Spain /28/10

48 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

49 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 /28/10

50 D06 Contenido de los documentos Guías y Plantillas Disponibles IHE HL7 INTERNATIONAL Proyecto EPSOS Definition.pdf CDA TOOLS LOCALES (de cada afiliado HL7 Internacional) 50 12/28/10

51 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 12/28/10 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

52 D06 Contenido de los documentos ART-DECOR : Datasets 12/28/10

53 D06 Contenido de los documentos ART-DECOR : Scenarios 12/28/10

54 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

55 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

56 D07 Vocabulario / Estándares Terminológicos ART-DECOR : Terminology / Terminology Binding 12/28/10

57 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] 12/28/ Herramientas de terceras partes (ejemplo: Mirth)

58 D08 De las aplicaciones a los documentos ART-DECOR : Templates 12/28/10

59 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

60 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

61 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 ( 4. Direct Project (MIME+S/MIME+X.509+SMTP) 5. Connect Project WS 6. Otros (ad-hoc) 61 12/28/10

62 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

63 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 /28/10

64 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

65 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

66 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 /28/10

67 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

68 Bonus Track (3) Consideraciones Politicas Comenzar con algo simple y luego agregar tipos de documento y complejidad. Visibilidad: documentar todas las decisiones y motivaciones /28/10

69 La vuelta al mundo en CDA R2

70 Projectos de HCE compartida basados en CDA R2 Agenda Objetivos Decisiones A viajar: DMP, PCEHR, HIBA, HC3, epsos Conclusiones Preguntas Pag. 3

71 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

72 Objetivos de HCE compartida basada Para qué hacemos esto? Objetivos Primarios en CDA R2 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

73 Pag. 5 Objetivos de HCE compartida basada Para qué hacemos esto? 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 en CDA R2 Necesitamos cambiar todo el software que utilizamos de golpe?

74 Agenda Projectos de HCE compartida basados en CDA R Objetivos Decisiones A viajar: DMP, PCEHR, HIBA, HC3, epsos Conclusiones Preguntas Pag. 3

75 Decisiones Leer antes de probar esto en casa Gobernanza Temas a Discutir (no técnicos) 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

76 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

77 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

78 Agenda Projectos de HCE compartida basados en CDA R Objetivos Decisiones A viajar: DMP, PCEHR, HIBA, HC3, epsos Conclusiones Preguntas Pag. 3

79 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

80 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 MM = Pag. 12

81 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

82 Pag. 14 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

83 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: botón o ícono especial que llama a un servicio web brindado por DMP Pag. 15

84 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

85 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

86 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

87 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

88 PCEHR Personally Controlled EHR Objetivos y Resultados usuarios registrados (Mayo 2013) Inversión mayor a $400 MM (2010-) 243 organizaciones participando 15 aplicaciones compatibles Pag. 20

89 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

90 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

91 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

92 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

93 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

94 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

95 HC3 Historia Clinica Compartida de Objetivos y Resultados Cataluña 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

96 HC3 Historia Clinica Compartida de Objetivos y Resultados Cataluña 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

97 HC3 Historia Clinica Compartida de Temas No Técnicos Gobernanza: gestionada por TicSalut, Departament de Salut, Cataluña 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

98 Pag. 30 HC3 Historia Clinica Compartida de Infraestructura Estrategia de Identificación de Pacientes: Tarjeta CIP de Cataluña + otros 2 posibles identificadores (nacional, europeo) Cataluña 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

99 HC3 Historia Clinica Compartida de Contenido de los Documentos Identificadores Globalmente Únicos Cataluña 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

100 HC3 Historia Clinica Compartida de Contenido de los Documentos Cataluña 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

101 HC3 Historia Clinica Compartida de Cataluña CDA R2 IG para: Contenido de los Documentos 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

102 HC3 Historia Clinica Compartida de Contenido de los Documentos Cataluña 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

103 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

104 Proyecto epsos Objetivos y Resultados Inversión : USD 50 MM + FTEs contribuídas de países y compañias participantes. El proyecto comenzó en 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

105 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 Pag. 37

106 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

107 Pag. 39 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

108 Proyecto epsos Pag. 40 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)

109 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

110 Proyecto epsos Terminología: epsos produjo sus propios servicios terminológicos para medicaciones y, problemas. Tienen que traducir el contenido original del documento al lenguaje destino Contenido de los Documentos Pag. 42

111 Agenda Projectos de HCE compartida basados en CDA R Objetivos Decisiones A viajar: DMP, PCEHR, HIBA, HC3, epsos Conclusiones Preguntas Pag. 3

112 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

113 Y un Conclusiones Pag. 45

114 Conclusiones Le parece completamente inentendible? Para nosotros es CDA En todo el mundo! Pag. 46

115 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

116 Integrar el CDA a la Historia Clínica Electrónica

117 Necesidad de interoperabilidad Aplicaciones y propósitos distintos. Hospital Italiano

118 Necesidad de Seguridad Como asegurarnos que el registro electrónico permanece inalterable en el tiempo?

119 Necesidad de Portabilidad Compartir la documentación con otros actores, instituciones, pacientes, financiadores.

120 Solución Una arquitectura basada en estándares. Interoperabilidad sintáctica HL7 permite interoperabilidad estándar en estructuración de la información

121 Interoperabilidad semántica Necesitamos un mismo lenguaje. Creación de Master Files. Solución Los MF son un conjunto de registros y vocabularios que permiten identificar instancias de entidades. Personas, Áreas Jerárquicas, Lugares, Pacientes

122 Solución Escalabilidad Adopciones de estándares globales

123 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.

124 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

125 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.

126 3 Seguridad Firma electrónica embebidas en el documento.

127 Solución HIBA 3 Seguridad

128 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.

129 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=" " codesystem=" " 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=" "/> <!--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=" "/>

130 5 Identificadores globales únicos Obtener una rama de OID

131 5 Identificadores globales únicos

132 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 > <languagecode code="es-ar"/> <!--representa un id que es común a todas las revisiones de los documentos.--> <setid extension="hca23789" root=" "/> <!--representa el número de versión del documento.--> <versionnumber value="1"/>

133 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.

134 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.

135 6 Contenido de los documentos Agrega el problema y registra la evolución

136 6 Contenido de los documentos Le solicita una Radiografía de Tórax

137 6 Contenido de los documentos Pide una interconsulta con el servicio de Neumonología

138 6 Contenido de los documentos Indica un antigripal

139 6 Contenido de los documentos Del relacional al documental

140 6 Contenido de los documentos

141 6 Contenido de los documentos

142 6 Contenido de los documentos

143 6 Contenido de los documentos

144 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)

145 Qué/cuáles vocabulario(s) 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 utilizar?

146 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%)

147 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/

148 Servidor de Terminología Clínica - HIBA Web Service Respuestas del HIBA Oferta de Opciones TEXTO RECONOCIDO TEXTO NO RECONOCIDO DIAGNÓSTICO VÁLIDO DIAGNÓSTICO NO VÁLIDO Salida Código CIE-9-MC Salida Código CIE-10 Código de SNOMED- CT

149 8 Consumo de documentos por las aplicaciones Cómo mostrar el documento al usuario Procesamiento para uso secundario Objetos multimedia

150 8 Consumo de documentos por las aplicaciones

151 8 Consumo de documentos por las aplicaciones CDAs integrado dentro de la HCE Módulo evoluciones CDA

152 8 Consumo de documentos por las aplicaciones PORTABILIDAD INTEROPERABILIDAD!!!! Navegador de CDAs que se entrega al financiador CDA

153 8 Consumo de documentos por las aplicaciones Documentos pendientes de firmar

154 8 Consumo de documentos por las aplicaciones INTEROPERABILIDAD!!!!! Navegador de CDAs de resultados dentro de la HCE

155 8 Consumo de documentos por las aplicaciones INTEROPERABILIDAD!!!!! Navegador de CDAs de resultado de diagnóstico por imágenes

156 8 Consumo de documentos por las aplicaciones Desde el CDA, acceso al visor DICOM

157 8 Consumo de documentos por las aplicaciones CDA desde el Portal Personal de Salud del Paciente.

158 8 Consumo de documentos por las aplicaciones CDA desde el Portal Personal de Salud del Paciente.

159 8 Consumo de documentos por las aplicaciones CDA desde el Portal Personal de Salud del Paciente. eria.v.cs= &mainsearchcriteria.v.c=1668-3&mainsearchcriteria.v.dn=&informationrecipient.languagecode.c=sp

160 8 Consumo de documentos por las aplicaciones Documentos desde dispositivos móviles

161 8 Consumo de documentos por las aplicaciones Imágenes desde dispositivos móviles