En el artículo anterior planteamos el problema de la gestión de errores en un escenario con múltiples sistemas.
En este artículo desarrollamos con detalle una posible solución a este problema, basada en Mirth Connect.
En los ejercicios anteriores, resolvimos los típicos problemas relacionados con la implantación de un nuevo HIS y con la necesidad de validar la mensajería HL7.
En el mismo escenario vamos a plantear el último ejercicio para tratar otro problema muy común en el mundo de las integraciones en salud: la gestión de errores.
En el artículo anterior propusimos un sistema para la validación de la mensajería HL7 en un escenario con múltiples sistemas.
En este artículo desarrollamos con detalle una implementación de una posible solución a este problema.
Hemos instalado un nuevo HIS que utiliza mensajería estándar HL7 ¿Cómo afrontamos el problema de la validación de la mensajería HL7?
En el ejercicio anterior vimos una posible solución al problema de la integración de una vieja aplicación con el nuevo HIS en un sistema sanitario.
Partiendo de esa situación, en este caso práctico vamos a plantear otro problema habitual en integraciones sanitarias: la validación de la mensajería HL7.
En este artículo vamos a solucionar el problema planteado en el artículo anterior: nuestro nuevo HIS debe comunicarse con una aplicación que no usa estándares como HL7.
¿Cómo podemos solucionarlo?
La aplicación PharmaCoolX 1.0 está integrada con el viejo sistema de información hospitalario OldPlainHIS de forma no estándar. Con la llegada del nuevo NewModernHIS y su uso de HL7 y estándares se plantea el problema: ¿Cómo mantenemos la interoperabilidad con nuestra vieja aplicación?
Con este artículo completamos la serie sobre SOA. En los anteriores artículos hemos visto una introducción a la estrategia SOA, partiendo del problema de la “arquitectura espagueti”. Ahora ya sabemos que en SOA existe un catálogo de servicios que podemos consumir o producir (o proveer).
Vamos a ver qué relación existe entre estos servicios, los servicios web y los estándares de interoperabilidad en sanidad. Finalizaremos la serie de artículos resumiendo todas las ventajas vistas hasta el momento (¡y alguna más!) que obtendremos si adoptamos una estrategia SOA.
En el artículo anterior hablamos sobre el problema de la “arquitectura espagueti”, y comprobamos que era necesario encontrar una solución al problema de la multiplicación de las conexiones.
La solución es SOA, en este artículo veremos en qué consiste y qué roles puede jugar nuestra aplicación en esta arquitectura.
En artículos anteriores hemos visto las ventajas de integrar en sistemas de sanidad y los principales estándares sanitarios. Ahora conviene que describamos el escenario deseable para integrar nuestra aplicación y esto nos lleva a la Arquitectura Orientada a Servicios: SOA.
En esta serie de artículos hablaremos sobre SOA, su objetivo, su rol en las aplicaciones, su relación con los servicios web y alguna otra cosa interesante más. Veremos por dónde empezar si queremos integrar con SOA y mencionaremos las ventajas que supone adoptar esta estrategia según nuestra propia experiencia.
En 1863, Florence Nightingale, una enfermera y estadística británica dijo:
Necesito hacer notar la urgente necesidad de (…) algún sistema (…) uniforme de los registros estadísticos hospitalarios.
¿Cómo solucionamos hoy un problema de hace más de 150 años?
La fragmentación de la información sanitaria.
Basándonos en nuestra propia experiencia, vamos a ver las ventajas de la interoperabilidad y los estándares sanitarios y de integrar nuestra aplicación con el resto de sistemas.
Después de leerlo, sabrás por qué debes integrar tu aplicación y qué ganas con ello.