INTRODUCCION A CDA R2 - Congreso Argentino de Informática ... A CDA R2.pdf · Ejemplos Niveles de Interoperabilidad Semántica ... (Epicrisis de Internación)

17/9/13

1

© HL7 Argentina, KERN IT SRL CAIS 2013 [email protected] 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,...).

17/9/13

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.

17/9/13

3


CDA en el mundo


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

17/9/13

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

17/9/13

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.

17/9/13

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.

17/9/13

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

17/9/13

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

17/9/13

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.

17/9/13

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

17/9/13

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



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

17/9/13

12



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



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)

17/9/13

13



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

17/9/13

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”

17/9/13

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

Realizaremos ahora la práctica 1


¿ Preguntas ?