Nuevo Curso de Interoperabildiad de ACHISA y CaboLabs

III Curso de Interoperabilidad entre Sistemas de Información en Salud

Una aproximación práctica al uso de estándares para interoperabilidad en salud

Desde el 18 de Julio hasta el 28 de Agosto de 2016 (6 semanas)

Objetivos del curso

• Conocer protocolos de comunicación (TCP, MLLP, HTTP, SOAP), formatos de mensajes (JSON, XML, HL7 v2.x) y estándares (HL7, DICOM, openEHR).
• Aprender a utilizar las herramientas y tecnologías de implementación (HAPI, PACS DCM4CHEE, EHRServer).
• Adquirir conocimientos prácticos en comunicación de datos clínicos e integración de sistemas en ambientes sanitarios.

Destinatarios

• Los principales destinatarios del curso son profesionales y estudiantes del área informática (arquitectos de software, programadores, líderes técnicos, gestores de redes, entre otros).

Modalidad

El curso será a distancia / online, con cuatro sesiones sincrónicas de clase vía Adobe Connect (*). Luego de cada clase se planteará un trabajo práctico para realizar de forma individual. Los trabajos prácticos podrán requerir el desarrollo de software orientado a la comunicación de datos clínicos y/o el uso de herramientas para comunicación o testing de comunicaciones entre sistemas hospitalarios, por lo que es necesario tener conocimientos de programación. Se recomendará material de lectura, y se discutirán dudas en el foro del Campus Virtual de ACHISA.

(*) Gentileza del Hospital Italiano de Buenos Aires.

Certificación

ACHISA y CaboLabs emitirán la certificación del curso, con dos tipos de certificados: de aprobación (para quienes hagan las prácticas y sean evaluadas con más del 50%), y de asistencia (para los asistentes que no deseen hacer las prácticas).

Clases

Las clases de brindan en vivo con el docente vía Adobe Connect, y serán los días 18 de Julio, 27 de Julio, 8 de Agosto y 17 de Agosto de 2016, y tendrán una duración aproximada de 1,5 hrs. El horario de clase será a las 17:00 GMT-4 (hora chilena). Puede consultar su horario local aquí.

Todas las clases quedan grabadas, por lo que no es necesario asistir de forma sincrónica.

Inversión

Valor del curso: USD 220 (doscientos veinte dólares americanos)

Valores preferenciales para socios ACHISA, estudiantes y asociaciones científicas:

Categoría	Descuento	Inversión
Socio ACHISA *	30%	154 USD
Socio ACHISA estudiante *	60%	88 USD
Asociado a otra organización científica de Informática en Salud +	20%	176 USD
Estudiante de grado (sin título profesional) +	50%	110 USD

(nota: el pago se realiza al Docente según las indicaciones presentes en el Programa del Curso)

+ Deben presentar documentación que avale la categoría en la que se inscribió.

* Inscríbase como socio de ACHISA para contar con estos y otros beneficios:

http://achisa.org/index.php/membresia/inscripcion-como-socio

Inscripciones y Programa

Formulario de Inscripción

Programa detallado del curso: descargar aquí

Plazo máximo de inscripción y pago: 15 de Julio de 2016

Inicio del curso: 18 de Julio de 2016

Duración: 6 semanas

Organizan

Apoyan

¿Cuando es bueno no usar estandares internacionales?

El título de este post es un poco contradictorio con el trabajo que hago a diario. Mi trabajo consiste en el modelado e integración de distintos sistemas de información, y detectar oportunidades de aplicación de estándares internacionales.

A veces mi tendencia a querer aplicar estándares cansa un poco a mis colegas y proveedores, que quieren hacer las cosas rápido y a medida. Muchas veces, sobresalen los argumentos de las ventajas que tiene utilizar uno o más estándares para implementar determinada funcionalidad, sobre todo ventajas a mediano y largo plazo, como la capacidad de integrar otros sistemas sin tener que trabajar más, o de hacer que el sistema sea más fácil de adaptar a requerimientos futuros, etc.

Pero también me gusta pararme del otro lado y pensar cómo sería la solución si no aplicara tal o cual estándar, porque tampoco soy un fundamentalista de la estandarización (aunque algunos piensen lo contrario jeje).

Entonces ¿vale la pena usar estándares para todo, y todo el tiempo?. La experiencia y algunos colegas y amigos, me han demostrado que la estandarización tiene sus límites, y que muchas veces la utilización o no de estándares, depende más del contexto que del problema a resolver.

Por ejemplo, el Dr. Sergio Montenegro, director del Depto. de Informática Médica del Hospital Madariaga de Misiones, Argentina, me contó sobre el proyecto que están llevando a cabo a nivel provincial para tener una Historia Clínica Electrónica única. Mientras él me contaba los pormenores del proyecto, yo me imaginaba una gran cantidad de sistemas, interactuando entre sí, con muchas comunicaciones y muchos estándares en el medio. En ese momento, Sergio me contó que sería un solo sistema en un único datacenter el que daría soporte a la HCE provincial, y toda la complejidad desapareció. Es verdad que el enfoque centralizado tiene sus desventajas, pero son compensables con soluciones técnicas, de procesos o de negocio.
Entonces, para este tipo de proyectos, los estándares de comunicación casi desaparecen, porque toda la comunicación es interna. Igualmente, existen múltiples estándares que son aplicables a la interna del sistema, como estándares de contenidos (CIAP-2, CIE10, Snomed, etc), estándares de modelo/arquitectura (openEHR) o estándares para documentación clínica (HL7 CDA, ASTM CCR, ISO 13606, etc).
También es claro que no en todas las regiones tienen las cosas tan claras como en Misiones, por ejemplo, en Uruguay, aunque solo tenemos 3.5M de habitantes, que haya un solo sistema único sería imposible, tanto a nivel nacional, o incluso departamental con unos cientos de miles de personas.

Otro ejemplo podría ser cuando se tiene una red de hospitales y en cada uno se utiliza un sistema de registro clínico distinto, y desean crear una HCE única para sus pacientes. En este contexto lo que uno gritaría HL7! de entrada, pero dependiendo del proyecto, tal vez HL7 no sea una buena opción. Por ejemplo, si se sabe que solo esos hospitales formarán una red clínica, con su HCE única, es posible desarrollar un estándar para implementar en esa red. Obviamente, un estándar hay que usar, pero no necesariamente debe ser uno internacional. Por ejemplo, el estándar a desarrollar puede estar basado y adaptado a los modelos de negocio, los modelos de atención y los sistemas de información presentes en los hospitales y en la región, con la diferencia de que si se usa HL7 se deberá perfilar el estándar internacional a su uso local. La creación de un estándar local específico para el intercambio de cierta información puede hacerse mucho más rápido que el perfilamiento de un estándar internacional. Igualmente, tener conocimiento de los estándares internacionales puede dar buenas pautas para el desarrollo del estándar local.

Con esto tengo un ejemplo concreto. En el proyecto FEMI Salud Digital donde trabajo ahora, desarrollé un Índice Maestro de Personas (IMP) que guarda un conjunto mínimo de datos patronímicos de pacientes, con el objetivo de poder linkear Historias Clínicas Electrónicas a nivel nacional entre 23 instituciones en distintos departamentos de Uruguay. Los servicios que provee este IMP están basados en los perfiles IHE PIX y PDQ, pero están implementados usando Web Services REST, en lugar de mediante Web Services SOAP, y en lugar de usar mensajería HL7 PA, utilizan mensajería XML a medida. La estructura de la mensajería XML es muy parecida a la estructura de los mensajes HL7v3, pero mucho más simple. En definitiva es mensajería XML sobre HTTP.

Ejemplos pueden haber mil, pero el mensaje es que quiero dejar es: siempre deberíamos tener 4 o 5 estándares internacionales como referencia (p.e. openEHR, HL7, DICOM, CIE10, CIAP-2), pero debemos considerar el contexto de cada proyecto para saber si vale la pena perfilar los estándares internacionales o crear nuevos estándares locales. La segunda opción solo se debería tener en cuenta, si primero se tienen en cuenta los aspectos clave de los estándares internacionales. Desarrollar un estándar local sin una referencia externa es un error conceptual a no ser que realmente no exista la referencia (cosa que no ocurre a menudo, lo que si ocurre mucho es que no se buscan referencias y se quiere reinventar la rueda a cada paso).