Introducción a CDA R2

TALLER DE INTEROPERABILIDAD CDA R2 Introducción a CDA R2 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.- 1.3 2013 HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 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 CAIS 2013 diego.kaminker@kern-it.com.ar 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 CAIS 2013 diego.kaminker@kern-it.com.ar 3 1

Historia Enero 1997: Primera reunión del grupo de interés de HL7 SGML (Standard Generalized Markup Language). Enero 1998: Kona Editorial Group (KEG) inicia el desarrollo. Septiembre 1998: Presentación del (renombrado y ahora basado en el RIM) Patient Record Architecture (PRA) Enero 2000: Primer ballot a nivel de comité pasado Septiembre 2000: Ballot general pasa de forma unánime. Noviembre 2000: Publicación ANSI/HL7 CDA R1.0-2000 Julio 2003: Primer ballot a nivel comité de CDA R2 Enero 2005: Aprobación en ballot general CDA R2 HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 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 CAIS 2013 diego.kaminker@kern-it.com.ar 5 Basado en, pero no limitado a XML. Qué es CDA? Puede contener contenidos multimedia imágenes, vídeo, etc. Puede ser presentado en múltiples formas mediante tecnologías estándar XML cascading style sheets, XSL-FO, etc. La FDA en USA está evaluando exigir a los laboratorios americanos el uso de este estándar al final de los procesos documentales para su almacenaje. Por ley los documentos deben ser guardados 10 o 20 años. Los sistemas cambian en este periodo de tiempo, y la capacidad de lectura de los formatos de documentos cambia. Buscan un estándar basado en XML que se pueda leer en cualquier sistema en el futuro fácilmente. HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 6 2

CDA en el mundo HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 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 CAIS 2013 diego.kaminker@kern-it.com.ar 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 CAIS 2013 diego.kaminker@kern-it.com.ar 9 3

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) USA HITSP Summary Documents using CCD 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 CAIS 2013 diego.kaminker@kern-it.com.ar 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 CAIS 2013 diego.kaminker@kern-it.com.ar 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 CAIS 2013 diego.kaminker@kern-it.com.ar 12 4

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

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 CAIS 2013 diego.kaminker@kern-it.com.ar 16 Especificación de CDA R2 La documentación sigue el mismo formato que el resto de HL7 V3 y se encuentra en el mismo lugar. Tiene su propio RMIM como cualquier dominio: Se deriva del RIM Está disponible en Visio Contiene los HMD s necesarios. Formatos tabla Formato excel Esquemas para creación y validación Tipos de datos idénticos Definidos de forma rigurosa, preparados para XML HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 17 Integración con v3 Ubicación de documentación: La documentación sobre CDA está incluida en todos los ballots de HL7 V3 y en las ediciones normativas 2005 y 2006. HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 18 6

Integración con v3 - RMIM Este es el RMIM (no asustarse por el tamaño, es más sencillo de lo que parece) Cabecera Cuerpo Entradas Referencias Externas HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 19 Integración con v3 - Utilización Se sigue el mismo método para llegar a los esquemas usados para producir los documentos (no mensajes!!). RIM v3 Es derivado de Agrega constraints RMIM CDA Linearización Agrega constraints XML Schema Algoritmo HMD HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 20 Escenario, evento, interacción No están definidos para CDA R2. Son documentos, el evento que los ha generado nos es indiferente por ello no se definen. HL7 v3 define mensajes en base a un escenario documental. Ver en el estándar: Domain Medical Records Document Topic HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 21 7

Integración con v3 El resultado son esquemas de XML que fácilitan la creación y validación de documentos y sus componentes. HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 22 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 CAIS 2013 diego.kaminker@kern-it.com.ar 23 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 CAIS 2013 diego.kaminker@kern-it.com.ar 24 8

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 CAIS 2013 diego.kaminker@kern-it.com.ar 25 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 CAIS 2013 diego.kaminker@kern-it.com.ar 26 Transmisión CDA no establece como se puede enviar el documento. Se puede enviar usando un web service, RPC, IPC, rtc. Se pueden enviar como ficheros (FTP, email, etc). Se puede enviar empaquetado dentro de un mensaje HL7 v2 o v3, codificado en un tipo de dato ED Pero: Todos los componentes deben ser enviados en el mismo paquete (imagenes multimedia, etc.). Recomendación: RFC2557. No debe haber necesidad de cambiar la referencias dentro del CDA. No debe haber restricciones en la estructura de carpetas usadas por los sistemas receptores Los metadatos sobre el documento (estado, ubicacion de archivo, etc.) pueden ser enviados en el paquete donde se envia el documento. HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 27 9

Niveles La especificación es genérica, expresiva y flexible. La noción de nivel como estaba descripta en CDA R1 se transformó por una en la cual el nivel de restricción depende del template que se defina para la validación. Básicamente se pueden definir tres niveles, de todas maneras: Nivel 1: la especificación de CDA tal como está, puede incluir secciones, contenedores, etc. Nivel 2: la especificación de CDA restringida con secciones obligatorias (Ejemplo: EXAMEN FISICO, HISTORIA DE LA ENFERMEDAD ACTUAL, ETC). Nivel 3: la especificación de CDA con determinadas entradas codificadas obligatorias, además del texto narrativo. La plantilla estará representada por una guía de implementación y un schematron y/o una hoja de estilo XML de validación HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 28 Niveles Interoperabilidad Semántica HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 29 Niveles de Interoperabilidad Semántica FASE 0 - PRE CDA Nivel 0 : Legible, pero sin potencial para reusar: Fax, bitmaps Nivel 1: Se pueden hacer búsquedas de texto Word, PDF, ASCII HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 30 10

Niveles de Interoperabilidad Semántica FASE 1 -> CDA R1 Nivel 2 CDA Header + Cuerpo NO Estructurado Nivel 3 CDA Header + Cuerpo NO Estructurado + Guía de Implementación Nivel 4 CDA Header + Cuerpo Estructurado Nivel 5 CDA Header + Cuerpo Estructurado + Guia de Implementación HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 31 Niveles de interoperabilidad semántica FASE 2 -> CDA R2 Nivel 6: Codificación de secciones, títulos y subsecciones Nivel 7: Codificación de secciones, títulos y subsecciones + Guía de Implementación (Ejemplos: CDA R2 CRS, CDA R2 H&P, etc.) HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 32 Niveles de interoperabilidad semántica FASE 3 -> CDA level 3 Nivel 8: Codificación de actos a partir del modelo de referencia con vocabulario controlado CDA R2 c/entries Nivel 9: Codificación de actos a partir del modelo de referencia con vocabulario controlado y guía de implementación CDA CCD HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 33 11

Niveles de interoperabilidad semántica FASE 4 -> Mensajería V3 (eventos + workflow) Nivel 10: Datos completamente estructurados y codificados Mensajes HL7 V3 Nivel 11: Datos completamente estructurados y codificados + Guia de Implementación Mensajes HL7 V3+G.Implem. HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 34 Tipos de Integración de Aplicaciones 1-API: el nivel más integrado. La integración es a través de una biblioteca de clases. En general, reside en la misma PC (comparte entorno, arquitectura, etc.) 2-BD: A nivel de base de datos. La integración es a través de consultas a una base de datos compartida HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 35 Tipos de Integración de Aplicaciones 3-IHE: Integración a través de perfiles de integración. Identifica conjuntos de mensajes a intercambiar, vocabularios, etc. 4-MSG: Integración por mensajería (V2.x, V3 por ejemplo, DICOM) HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 36 12

Tipos de Integración de Aplicaciones 5 CCOW: Integración de contexto Los sistemas detectan sobre qué paciente se está trabajando y qué usuario usa el sistema. 6 Física: El usuario corre en la misma PC dos sistemas disjuntos HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 37 Documentos vs. Mensajes (I) CARACTERISTICA DOCUMENTOS MENSAJES Ciclo de Vida Persistente Temporal Comunicación Entre Personas Entre Aplicaciones Relación con los prestadores Están entrenados para crearlos No entienden bien qué significan Aspecto Legal Tienen status legal Ni firma ni validez legal Origen Usos y costumbres Ad-Hoc según casos de uso Contexto A nivel de documento Segmentado Completitud Completo Fragmentado HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 38 Otras diferencias Documentos vs. Mensajes (II) El mensaje se utiliza cuando se quiere granular a nivel de objeto la información y transmitir los diversos estados por los que pasan los distintos objetos. El documento se utiliza cuando se desea enviar solamente el estado/resultado final del acto (o los actos) en cuestión. Veamos ahora un ejemplo en laboratorio HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 39 13

Documentos vs Mensajes (III) 20-Abr-07 18:30 20-Abr-07 18:31 20-Abr-07 22:00 21-Abr-07 07:35 21-Abr-07 08:00 Petición analitica: Glucosa en Sangre realizada por el Dr. Amado Pérez para el paciente Alberto Soria, internado en Cama 10 del Servicio de Clínica Médica. Diagnóstico presuntivo : diabetes. Solicitud de realizar la petición dia 21/04/07 como rutina Confirmación electrónica de recepción del pedido Aviso electrónico de agendamiento de la extracción: será realizada por la extraccionista Carolina Sanchez a las 07:30 hs del día 21/04/07 Muestra tomada por la enfermera Carolina Sanchez de la Hoz: sin novedades. Muestra recibida en el laboratorio por el técnico Joaquín Perdomo. Colocada en gradilla temporaria Q45 para su análisis rutinario. Aviso electrónico de petición en proceso. 21-Abr-07 08:45 Muestra programada en Analizador T45 en posición 43 21-Abr-07 08:55 Interoperabilidad Resultado generado por a Analizador través de T45: mensajería 75 mg/dl (HL7 V2, V3, 21-Abr-07 09:20 etc.) Resultado damos de glucosa cuenta Sangre del workflow: : 75 mg/dl, revisado los cambios y firmado por de el Dr. Mario Antares. Aviso electrónico de petición cumplida a sistema administrativo. Mensaje estado conteniendo de cada resultado objeto enviado en electrónicamente un sistema a sistema son enviados de historia clínica a otro electrónica sistema para sincronización. HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 40 Documentos vs. Mensajes (IV) Pero de todo este cúmulo de información, lo más relevante para el médico: 21-Abr-07 09:20 Resultado de Glucosa en Sangre : 75 mg/dl, revisado y firmado por el Dr. Mario Antares, a partir de una muestra tomada el 21-Abr-07 a las 07:35. HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 41 Entonces, Documentos vs. Mensajes (V) A. documentos y mensajes son excluyentes? B. Es mejor utilizar documentos que mensajes? Mejor preguntarse Cuándo utilizar documentos Cuándo utilizar mensajes HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 42 14

Documentos vs Mensajes (VI) Los otros ejes para considerar son Relación entre los sistemas (interhospitalario intrahospitalario, hospital gobierno, etc.) El eje temporal (el receptor necesita conocer la información on-line o puede esperar para recibir el informe final o una relacion de actuaciones al final del episodio) Consideraciones de seguridad (intrínseca o dada por el entorno) / legislación Debo notificar algo o estoy haciendo una consulta? HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 43 Documentos vs. Mensajes (VII) Y la respuesta solo puede darse comparando vuestros requerimientos puntuales con la tabla presentada en (I) Veamos ahora esto en la práctica Realizaremos ahora la práctica 1 HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 44 Preguntas? HL7 Argentina, KERN IT SRL CAIS 2013 diego.kaminker@kern-it.com.ar 45 15