La vuelta al mundo sobre CDA r2

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