Un sistema de salud cubano conectado. Arquitectura de Referencia

Lograr un sistema de salud cubano, donde todos los componentes de software estén conectados correctamente debe ser un objetivo trazado en cualquier plan de informatización que exista hoy a nivel de país.

Si no se ha definido aún una arquitectura de referencia en este sentido ni se tiene como objetivo tener un gran sistema integrado, poco se podrá avanzar en la informatización del sector salud, tan importante a todos los niveles.

Internacionalmente existen varias arquitecturas de referencia que soportan un objetivo como el que se menciona anteriormente. Usaré una que se adapta muy bien a una de las principales tecnologías que domino, que es gratis y bajo licencia Apache v2.

Lograr definir una arquitectura de referencia e implantarla no es un proceso sencillo. De ahí que se parta de varios elementos que al combinarlos tributen a lograr una interconexión global con todos los requerimientos no funcionales requeridos.

Lo primero es tener un BUS de integración que garantice dicha interconexión entre los actuales y futuros sistemas de información a todos los niveles.

Para lograr este BUS de integración y que funcione correctamente es necesario definir y estandarizar un modelo cánonico de datos a nivel de todo el sector de la salud para tener en lenguaje común que permita el diálogo entre los sistemas.

Lo siguiente es tener un BUS de datos, capaz de extraer la información necesaria de cualquier base de datos o ficheros donde se tenga. En nuestro país es muy común manejar las bases de datos en hojas de cálculo de Excel, así que esta solución debe ser capaz de capturar dicha información.

Además dicha información debe ser expuesta a través de diferentes estándares y ser consumida desde el BUS de integración principalmente.

Lo siguiente sería garantizar la completa seguridad de la solución arquitectónica, a través de la implementación de múltiples mecanismos de autenticación y autorización  a diferentes niveles, usando diferentes estándares y protocolos de seguridad.

Con este nuevo componente se garantizaría el poder distribuir la información de manera segura y que solo pudiera tener acceso a ella quien esté correctamente autorizado.

Lo siguiente sería una solución para la comunicación asincrónica. Para todos es sabido que nuestras redes tienden a saturarse y a veces a mostrar intermitencias en la conexión. Así que es necesario garantizar que aun en un ambiente desconectado no se pierdan los eventos y mensajes enviados y que tan pronto se restablezca la comunicación todo volverá a sincronizarse.

Por eso el uso de colas de mensajería es de vital importancia para gantizar la integridad de todos los datos. Además se incluye un tema de manejo de eventos complejos y su procesamiento, pues en este tipo de sistemas de salud es necesario ser capaz de reaccionar ante eventos simples y eventos complejos, además de ser capaces de aplicar algortimos de máquina de aprendizaje a partir de todo el flujo de eventos generados.

Con el volumen de información de eventos que se puede recopilar tanto de forma síncrona como asincrónica, se pueden elaborar diversos dashboard con gráficas de todo tipo así como ser capaces de enviar notificaciones y alertas a los interesados.

Si logramos que todas estas piezas de software se integren correctamente entre si tendríamos algo como lo siguiente:

Llegados a este punto sería un error garrafal y muy malo tecnológicamente aspirar a:

  1. Implementar todo esto desde 0. Algo que nos encanta a los cubanos por temas de soberanía tecnológica y demás palabritas interesantes, pero que conducen a un desgaste enorme, pérdidas económicas y años y años de desarrollo sin saber si finalmente se logrará el objetivo final.
  2. Comprar soluciones por separado, sin saber si se podrán interconectar entre sí o sin evaluar correctamente el grado de adaptación de las mismas.
  3. Usar un lenguaje de programación con pocas capacidades para implementar soluciones de integración e interoperabilidad. No hay que ir muy lejos para entender que me estoy refiriendo a PHP. Un lenguaje que ha causado destrozos al desarrollo de software a nivel de país y hacia lo interno de las universidades. No porque sea malo, que no lo es, si no por haber sido usado para cosas que no se tenía que haber usado.

La propuesta tecnológica que hago partiendo de la experiencia práctica en este tipo de soluciones y los años de trabajo en diversas soluciones para otros sectores usando tecnologías propietarias y open source, consta de los siguientes elementos:

  1. Libre de costo para el país.
  2. Open Source completamente distribuida bajo licencia Apache v2 y con acceso a los fuentes en todo momento, disponibles en github.
  3. Preparada para docker y otros ambientes de contenedores.
  4. Tener una comunidad activa, que responde rápido y que ante cualquier bug es capaz de brindar un fix rapidamente.
  5. Tener personal con conocimientos suficientes como para realizar una inducción y adiestramiento de un equipo de trabajo de analistas, diseñadores, desarrolladores, probadores y arquitectos.
  6. Evolucionar constantemente adoptando las mejores prácticas de la industria, compliendo con los estándares y protocolos de comunicación.
  7. Y lo fundamental, que ya tenga implementada la mayor cantidad de funcionalidades vistas anteriormente y que se pueda conectar con cualquier otra solución.

En la siguiente imagen se muestra como la suite de WSO2, ampliamente abordada en este otro blog  también de mi autoría, se ajusta a los requerimientos y necesidades para implementar un sistema de salud cubano conectado.

 

 

 

4 opiniones en “Un sistema de salud cubano conectado. Arquitectura de Referencia”

  1. Me parece muy coherente tu propuesta, ahora me parece que en el punto 3 donde refieres los lenguajes no creo que php sea el culpable de los destrozos que mencionas. A pesar de gustos y preferencias el problema siempre ha estado en el uso que se le dio, y más que eso fue en quien le dio el uso. En cuba existen arquitecturas de referencia precisamente desarrolladas en php que en términos de estándares de seguridad y específicamente en el proceso de autorización tiene de las mejores y reconocidas investigaciones. Ahora que no podamos usarlas todos los desarrolladores es otra cosa. Defiendo tu arquitectura porque precisamente creo que nuestro problema es arquitectónico y de interoperabilidad, dejemos los temas de lenguajes para los fanatismos.

    1. Imagino te refieras a la famosa AAA hecha en la UCI. A mí entender innecesaria totalmente cuando a nivel de herramientas ya existían soluciones open source y libres con una comunidad de desarrollo por detrás. El esfuerzo invertido en desarrollar esa solución si se hubiera volcado en extender una existente y probada nos habría posicionado en el mercado internacional.

      Hoy se usa porque existe e “indican” que hay que usarla.

      Sobre PHP no leíste bien el punto 3, no digo que sea malo, digo que fue mal utilizado en cosas que le quedaban grandes. Sin ir más allá el “ERP cubano” con años de desarrollo, cientos de desarrolladores y no muy buenos resultados aún. Teniendo una solución como openERP a la mano.

      Y todo por decir que esas cosas fueron hechas en Cuba.

  2. Y concuerdo contigo, creo que las ideas y propuestas son válidas y deben ser debatidas como la que plateas del openERP. Fui testigo desde muy dentro en el Departamento TI y puedo decir que ni una ni la otra, con openERP duró menos aún el proyecto (cosa rara). Donde si vi el avance fue cuando XETID creó su linea basado en el proyecto inicial, así que la experiencia aparentemente indica que el problema nunca radicó en la tecnología en sí, sino en como se ejecutó. El problema en mi consideración creo que es más humano que tecnológico, pero bueno de eso estamos plagados.
    Saludos y muy buen blog

    1. Si con OpenERP avanzó menos ahí si te puedo decir que fue un tema de mucho desconocimiento y poca colaboración con la comunidad. Es imposible que se avance más con PHP, y sin nada haciéndolo desde 0, que con un framework ya hecho y probado por la comunidad. Claro que en este último caso tienes que asimilar una curva de aprendizaje y socializar mucho con gente que ya sabe.
      En la concreta, se puede usar PHP?, claro que si, pero tienes que pasarte años construyendo herramientas y frameworks para poder avanzar con PHP y hacer cosas que hacen falta, y eso fue lo que pasó.
      Lo importante sería preguntarnos: ¿Dónde están escritas y publicadas las lecciones aprendidas de este megaproyecto, para no volver a cometer los mismos errores? Ummm, alguien lo sabe?

      Yo lo sigo diciendo, cada cual a lo suyo. PHP es genial para aplicaciones web estilo portal, mucho front-end. Pero cuando te metes en temas empresariales busca otro lenguaje, que tenga frameworks con años de bagaje en desarrollos similares al que quieres hacer, con una comunidad que lo respalde y no empieces desde 0. Si no sabes pide una consultoría, un entrenamiento, algo que te de una base más sólida que la que ya tienes. No le pidas a los desarrolladores que estudien y que en una semana ya deben estar PRO a nivel internacional.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *