Introducción a CDA R2

(1)

Introducción a CDA R2

Rev.- 1.3 2013

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

TALLER DE INTEROPERABILIDAD CDA R2

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

¿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,...).

(2)

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

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

¿Qué es CDA?



Basado en, pero no limitado a XML.

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

(3)

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

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

(4)

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

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



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

Objetivos



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

Utilización

(5)



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.

Casos de Uso

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

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

(6)

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

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

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.

(7)

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

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

HMD

Linearización Agrega constraints

XML Schema

Algoritmo

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

(8)

Integración con v3



El resultado son esquemas de XML que fácilitan la creación y validación de documentos y sus componentes.

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

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

(9)

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.

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)

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.

(10)

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

Niveles Interoperabilidad Semántica

Niveles de Interoperabilidad Semántica

Nivel 0 : Legible, pero sin potencial para reusar:

Fax, bitmaps

Nivel 1: Se pueden hacer búsquedas de texto Word, PDF, ASCII

FASE 0 - PRE CDA

(11)

Niveles de Interoperabilidad Semántica

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

FASE 1 -> CDA R1

Niveles de interoperabilidad semántica

 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.)

FASE 2 -> CDA R2

Niveles de interoperabilidad semántica

 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

FASE 3 -> CDA level 3

(12)

Niveles de interoperabilidad semántica

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

FASE 4 -> Mensajería V3 (eventos + workflow)

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

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)

(13)

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

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

Documentos vs. Mensajes (II)

 Otras diferencias



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

(14)

Documentos vs Mensajes (III)

20-Abr-07 18:30 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

20-Abr-07 18:31 Confirmación electrónica de recepción del pedido

20-Abr-07 22:00 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 21-Abr-07 07:35 Muestra tomada por la enfermera Carolina Sanchez de la Hoz: sin novedades.

21-Abr-07 08:00 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 Resultado generado por Analizador T45: 75 mg/dl

21-Abr-07 09:20 Resultado de glucosa en Sangre : 75 mg/dl, revisado y firmado por el Dr. Mario Antares. Aviso electrónico de petición cumplida a sistema administrativo. Mensaje conteniendo resultado enviado electrónicamente a sistema de historia clínica electrónica

Interoperabilidad a través de mensajería (HL7 V2, V3, etc.) damos cuenta del workflow: los cambios de estado de cada objeto en un sistema son enviados a otro sistema para sincronización.

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.

Documentos vs. Mensajes (V)

 Entonces,



A. ¿documentos y mensajes son excluyentes?



B. ¿Es “mejor” utilizar documentos que mensajes?

 Mejor preguntarse



“Cuándo utilizar documentos”



“Cuándo utilizar mensajes”

(15)

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?

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

