Grupo de Trabajo sobre Historia Clínica Informatizada para Unidades de Cuidados Intensivos

Desarrollo de software médico libre

Autor: Antonio Nuñez Reiz. Medico Especialista en Cuidados Intensivos e Ingeniero Informático Superior. Coordinador del Grupo de Trabajo sobre Historia Clínica Informatizada para Unidades de Cuidados Intensivos.

La última frontera

Los informáticos, gente aventurera y ávida de saltar barreras y alcanzar metas, han hecho grandes progresos desde el nacimiento de los ordenadores y la programación. Pertrechados con sus conocimientos y su habilidad han conseguido dotar al ser humano de herramientas potentísimas en prácticamente todos los campos de su actividad. Ultimamente se han adentrado en zonas hasta ahora "prohibidas", consiguiendo que los ordenadores se enfrenten a tareas reservadas según se creía unicamente para la mente humana.
El ajedrez, por ejemplo, paradigma de un juego-ciencia que parecía demasiado complejo para que la simple potencia de cálculo pudiera doblegar a los mejores jugadores humanos, ha sentido en sus carnes el empuje de otro juego-ciencia que ha conseguido desvelar sus secretos: la programación. Quedan pocos aspectos inexplorados, y sólo el reconocimiento del lenguaje natural y algunos otros campos se resisten todavía al poderío de los bits.
Aparte del espectacular desarrollo del hardware, un papel crucial en este progreso lo ha tenido el ingenio de los informáticos y su afán por superar nuevos retos.
Y así, como si del Enterprise se tratará, nuestra nave se va acercando a una de las últimas fronteras: la creación de un software que se convierta en una verdadera herramienta de trabajo en un entorno tan complejo y enmarañado como el sanitario. En resumidas cuentas, el objetivo es que, únicamente por el precio del hardware y quizá un contrato de servicios con una empresa local, y gracias a Linux, y aplicaciones ofimáticas y sanitarias Open Source, cualquier médico, enfermero, hospital o corporación sanitaria, por escasos que sean sus recursos económicos, tenga acceso a herramientas informáticas avanzadas de diagnóstico, gestión de datos clínicos, comunicación con otros profesionales y un largo etcétera.
"Vaya, pero si hay cientos de aplicaciones, bases de datos, software aplicado a Radiología, ultrasonidos, en fin, esto ya está superado", direis probablemente aquellos de vosotros con alguna relación con la informática sanitaria. Sí, pero no es de esto de lo que estamos hablando. Hablamos de de permitir una transacción de conceptos y procesos sanitarios de tal manera que un ordenador entienda y pueda colaborar en el trabajo del médico o enfermero. El salto cualitativo supone pasar de un archivo de documentos, que es lo que actualmente suponen la mayoría de las aplicaciones que se usan en consultas y hospitales, a un entorno de trabajo que maneje síntomas, signos, diagnósticos, etc, de una manera eficiente, y que permita su circulación como conceptos sanitarios de la misma manera que puede circular una canción entre distintas aplicaciones y usuarios en un formato mp3.
"Bueno, esto ya se ha hecho en otros campos". Por qué la sanidad va a ser diferente?. Por qué el desarrollo de la informática sanitaria supone un reto de gran magnitud?. De donde venimos? A donde vamos?. Veamos las causas.
A medida que la informática se adentra en nuestras vidas, se va haciendo evidente que existen algunas áreas de la actividad humana en las que las tecnologías de la información penetran con mayor dificultad. Una de estas áreas es el mundo sanitario, y las razones de ello son varias.
En primer lugar, los conceptos y procesos sanitarios son tradicionalmente difíciles de modelar en un formato manejable por los ordenadores, a pesar de multiples esfuerzos realizados hasta este momento. El esfuerzo económico necesario para que una empresa de desarrollo de software mantenga un equipo multidisciplinar trabajando durante largo tiempo hasta conseguir un punto de partida adecuado es demasiado grande, y hasta ahora nos hemos tenido que conformar con herramientas basadas más en un planteamiento documental que conceptual, con la consiguiente merma de rendimiento y usabilidad de los sistemas informáticos sanitarios.
Parte de la culpa de que la informática no se haya convertido en una ayuda para los sanitarios tan importante como lo es en otros campos de la ciencia es la escasa formación en tecnologías de la información con la que habitualmente cuenta el personal sanitario. La escasa soltura con el ordenador casa muy mal con un paciente que espera para ser atendido, y al que no le gusta que dirijamos la mirada más tiempo a la pantalla que a su persona. Esto obliga a que las herramientas que pongamos a trabajar en este escenario sean un dechado de usabilidad, ergonomía y rapidez de respuesta, ya que en el mundo sanitario se trabaja continuamente contra reloj. El diseño de este tipo de aplicaciones no puede salir de un rato delante de una IDE, unas cuantas tablas en una base de datos y unos formularios bien presentados. Hace falta recurrir en muchas ocasiones a profesionales altamente cualificados que reunan conocimientos de manejo eficiente de bases de datos, programación concurrente, redes y comunicación, seguridad y encriptación, lo que supone un coste todavía superior, con frecuencia inasequible si el proceso de desarrollo debe ser corto para poder ser rentable económicamente. Además, las aplicaciones comerciales disponibles de cierta calidad son tan caras que solo los grandes hospitales o corporaciones sanitarias pueden permitirse siquiera pensar en ellas.
También ha existido tradicionalmente cierta incomprensión entre informáticos y sanitarios, bastante más allá de la que existe habitualmente entre los informáticos y sus clientes en otros campos. El sanitario no entiende la jerga informática y a veces se exaspera porque las aplicaciones no funcionan como el desea, pero es incapaz de trasmitir al informático lo que realmente necesita en un lenguaje que este entienda. Solo un entorno de trabajo común puede hacer que estas distancias se acorten hasta desaparecer.

Por qué software libre en el mundo sanitario

No debemos olvidar que las empresas de software son precisamente eso, empresas, y tienen como prioridad fundamental ganar dinero. La competencia entre ellas les obliga a cerrar las puertas a una posible compartición abierta de la información entre las distintas herramientas de distintas casas comerciales, y esto a su vez pone un freno definitivo a la integración, que es la clave de un sistema informático sanitario eficiente. De una manera similar a lo que ocurrió con las redes de comunicación e Internet, hasta que no se imponga la cordura y se facilite el acceso libre y barato a la integración de las herramientas informáticas sanitarias, no se producirá el boom definitivo del software sanitario. Al igual que sucede con Internet, el verdadero negocio estará siempre en la venta de servicios, no en la venta de licencias de software.
A pesar de todo esto, las ventajas de contar con herramientas informáticas adecuadas son tantas, que deberíamos considerar practicamente una obligación el conseguir saltar por encima de las barreras antes mencionadas. Veamos algunas de ellas:

• La calidad de la atención sanitaria depende de la experiencia y habilidad de los profesionales sanitarios, pero también de la cantidad de información que puedan reunir rápidamente sobre los problemas que se les plantean cotidianamente. La calidad asistencial ha mejorado claramente en este sentido en aquellos hospitales cuyo personal dispone de bases de datos bibliográficas informatizadas, o simplemente tienen acceso a Internet en su lugar de trabajo. Un software sanitario extendido y compatible introduciría un salto cualitativo y cuantitativo de varios órdenes de magnitud en este escenario.
• La existencia de un "lenguaje sanitario común" hablado y entendido por las distintas aplicaciones permitirá compartir información sobre los pacientes y sus enfermedades. Si esto se hace correctamente, bajo un marco de seguridad y privacidad adecuado, podrá ser tal el volumen de datos clinicos procesable en poco tiempo, que esto puede suponer para la ciencia médica lo mismo que cientos de miles de ensayos clínicos realizados simultáneamente.
• La existencia de un software sanitario libre y de calidad puede suponer para médicos o instituciones que no cuenten con grandes recursos económicos el acceso y la integración en igualdad de condiciones a información, investigación, y herramientas informáticas punteras. El mercado informático se vería también favorecido, ya que los profesionales sanitarios requerirían recursos y servicios que podrín proporcionar ya no solo las grandes corporaciones, sino pequeñas empresas de servicios a nivel local.

Software libre, sí, pero ...

Bueno, hagamos software sanitario. Qué necesitamos?. Pues primero necesitamos experiencia y conocimiento de la lógica del "negocio" sanitario. Esta es la parte más difícil de obtener. Del mismo modo que Deep Blue no ganó a Kasparov hasta que tuvo detrás a un plantel de grandes maestros que le "enseño a jugar", solamente la colaboración con sanitarios (médicos, enfermeros, etc) con las ideas claras, conceptos informáticos suficientes como para entender lo que estamos haciendo, y ganas de trabajar para desarrollar en el proyecto, nos permitirá obtener resultados de alguna utilidad. En esto es en lo que han tropezado la mayoría de las iniciativas de desarrollo de software de este tipo, y en lo que también tropiezan habitualmente las grandes casas comerciales que desarrollan software para hospitales o grandes consorcios sanitarios.
También necesitamos estandares. Igual que, a pesar de que existín muchas propuestas comerciales de conectividad previas, Internet solo surgió detrás de uno de los hitos del OpenSource, el desarrollo de la API de sockets en Berkeley, estamos necesitados de una biblioteca de objetos que modele el entorno sanitario, y de una arquitectura que permita que todas las aplicaciones sanitarias del mundo puedan un día hablar el mismo idioma y comunicarse entre sí de manera eficaz para sus usuarios.
Y por último hace falta lo de siempre, materia gris en abundancia y una organización adecuada para coordinar los esfuerzos de múltiples profesionales de la sanidad y la informática hasta conseguir una infraestructura informática que multiplique nuestra potencialidad como sanadores. Sin embargo, aunque la filosofía Open Source, Software Libre y todo eso está muy bien, en un proyecto de esta envergadura es necesario otro componente, que ya esta empezando a darse: ayuda oficial. Las Administraciones Públicas deben darse cuenta (y están empezando a hacerlo) que es mucho más rentable fomentar y financiar el desarrollo de software libre que delegar el desarrollo del software sanitario a grandes empresas, por los planteamientos que se expresaron anteriormente.
Está claro que esto no es labor de una persona ni de un grupo únicamente. Es un reto para toda la comunidad informática y sanitaria. Un reto que se ha resistido hasta ahora, pero que debe alcanzarse por el bien de todos los pacientes del mundo. Es, al fin y al cabo, la última frontera, donde el talento y el mérito debe ser compartido entre todos los que colaboren a su logro.

Iniciativas realizadas hasta el momento

Son ya bastantes las iniciativas que han surgido hasta este momento, basadas en los planteamientos antes mencionados. Baste destacar algunas como por ejemplo FreeMed o OpenHealth. El tema ha surgido incluso en el reciente Congreso sobre Software Libre que tuvo lugar en Francia recientemente, y está en auge desde que el gobierno de Gran Bretaña ha propugnado impulsar las iniciativas de software médico libre tras constatar que las propuestas comerciales no consiguen llegar a unos productos adecuados para las necesidades de la sanidad pública. Es muy interesante el debate que ha surgido en torno a este tema y que puede verse en el enlace que incluimos.
Sin embargo, en esta presentación me voy a basar en la experiencia recogida durante el año largo en el que he sido coordinador del Grupo de Trabajo sobre Historia Clinica Informatizada para Unidades de Cuidados Intensivos, una iniciativa sin ánimo de lucro que surgió en junio de 1999 agrupando a un conjunto de profesionales sanitarios y algunos informáticos interesados por el tema, o que compartín ambos campos en su labor profesional. El grupo se formó por una sensación común de sus miembros de que las herramientas actuales no eran suficientes ni accesibles. Durante más de año y medio, con muchos altibajos (como es habitual en la mayoría de los grupos cuya filosofía es el OpenSource pero que acostumbran a comer algo cada día y por tanto tienen que trabajar en algo que produzca dinero), el grupo ha ido desarrollando su actividad, y sus conclusiones hasta el momento pueden verse en los siguientes apartados.

Arquitectura

Si hay una característica común entre los usuarios de la informática dentro de la Sanidad es su heterogeneidad, tanto en conocimientos como en recursos y forma de trabajar.
Aquí no encontramos con uno de los escollos fundamentales para nuestro proyecto: el desarrollo va dirigido a un colectivo de usuarios con unos conocimientos en general medios-bajos, lo que obliga a hacer especial hincapié en aspectos como usabilidad, simplicidad y ergonomía de los interfaces.
Debemos pues concebir el desarrollo como orientado fundamentalmente a tres tipos de escenarios, de los que indicamos algunos ejemplos:

1. Un médico tiene un ordenador en su consulta privada. La versión de la aplicación que emplea utiliza ficheros para guardar los datos encriptados de sus pacientes. Puede conectarse a Internet a través de un modem y participar en estudios clínicos compartiendo sus datos con otros compañeros o acceder a grandes bases de datos para plantear preguntas concretas como "¿cuáles son los diagnósticos más probables para este paciente?", o "¿cuál es la Clínica privada de Madrid con mejores resultados en revascularización coronaria?". El facultativo tiene también la posibilidad de almacenar los datos clínicos encriptados de ese paciente en un soporte tipo disquete, CD y otro para remitirlos a un Centro al que envía al paciente, o hacerlo por correo electrónico. La herramienta también le permitirá introducir sus propios protocolos de trabajo (u otros obtenidos de otros colegas o instituciones) como ayuda en su labor cotidiana.
2. Un Centro de Salud tiene una pequeña red local con diez puestos que conectan los distintos consultorios médicos y de enfermería, así como a los administrativos encargados de las citas, etc. Existe un servidor que contiene la base de datos administrativa y de datos clínicos de los pacientes. Además de las funcionalidades descritas en el primer escenario, el sistema permite la gestión de las citas, la precarga de los datos de los pacientes que vayan a ser vistos ese día en las consultas, y la obtención automática de estadísticas de funcionamiento global y de cada consulta. Una pequeña aplicación Web permite la autocita de los pacientes a través, así como la realización de consultas telemáticas a través de la red.
3. Un gran centro hospitalario mantiene una intranet con seiscientos puestos que incluyen todos los departamentos del hospital. A través de un sistema de servidores se gestiona toda la información, y las distintas aplicaciones, desarrolladas cada una de ellas por una casa comercial distinta, se comunican entre ellas a través de interfaces estándar compatibles entre sí y con las aplicaciones referidas en los dos escenarios anteriores, lo que permite compartir los datos de manera eficiente dentro y fuera del hospital. Dependiendo de las necesidades de cada aplicación, alguna de ellas son aplicaciones Web, y otras utilizan clientes locales con cierto grado de funcionalidad y sistemas de cache regional y local para prevenir por ejemplo que las consultas se detengan por una caida de un servidor o de la red. Cada puesto dispone de un escritorio configurable por el usuario donde puede incluir todas las aplicaciones que necesite, siempre dependiendo de sus privilegios dentro del sistema. De puertas afuera, el hospital gestiona sus citas, entrega de resultados de pruebas e informes, etc, a través de aplicaciones Web o específicas en determinados contextos. Existen una serie de agentes en el sistema que monitorizan la evolución de determinados parámetros que se consideran importantes para aspectos de control de calidad, económico, apoyo a la decisión, alarmas inteligentes, recordatorio de protocolos, etc.

Esta claro que en un primer paso no nos podemos plantear implementar todas estas funcionalidades, pero nuestra arquitectura tiene que ser capaz en el futuro de soportarlas.
Hay que tener en cuenta que la clave del éxito de un sistema concebido con iniciativa de este tipo es cumplir conjunto de tres cosas:

1. Que resuelva de manera eficiente y amigable para el usuario la especificación con la que se ha concebido, y evolucione acorde con las necesidades que se vayan presentando.
2. Que sea accesible para la mayor cantidad de usuarios posibles: en resumen, gratis y disponible a través de Internet.
3. Que la aplicación se pueda instalar y mantener con un bajo presupuesto gracias a un contrato de servicios con una empresa informática local, o bien que el usuario posea los conocimientos y recursos informáticos suficientes para hacerlo (digamos de usuario avanzado).

En el gráfico puede verse un esquema de la arquitectura concebida para el sistema. Se trata de un modelo distribuido, con un planteamiento MVC (model-view-controller) ligeramente modificado. Empezando por arriba, tenemos la aplicación cliente, que puede ser una aplicación "stand-alone", en el caso del escenario más sencillo, un browser ligeramente modificado o un cliente con funcionalidad propia. En los dos últimos casos, en los que el cliente se relaciona con otras aplicaciones en funcionamiento en el sistema, los rectángulos de colores representan las distintas caches que utiliza el cliente para agilizar su funcionamiento. En el caso de la aplicación aislada, representa el sistema de archivo de los datos en ficheros. Como vemos, el cliente puede relacionarse con varias aplicaciones, algunas de ellas "comerciales", a través de interfaces estandares que permiten hacer independiente su desarrollo del de las aplicaciones que implementan esos interfaces.

En cuanto a los aspectos "logísticos" del proyecto, podemos resumirlos en la siguiente tabla:

Representación de los conceptos sanitarios

Independientemente de las aplicaciones que funcionen por debajo, la idea es utilizar una biblioteca de objetos común, constituida por clases e interfaces Java, para modelar a nivel informático los conceptos sanitarios. Ello permite que las distintas aplicaciones utilicen su propio formato de datos, de manera transparente al sistema.Un ejemplo de una clase de este tipo la vemos reflejada en el gráfico.

Los enlaces de este párrafo permiten ver una versión preliminar de la biblioteca de objetos y de algunos de los prototipos (todavía muy primitivos) que se han tomado como base para el diseño.

Trabajo cooperativo entre sanitarios e informáticos

Bueno, pues ya están puestos más o menos los cimientos. Ahora hace falta un esfuerzo cooperativo entre un equipo de sanitarios e informáticos que trabajen comunicándose mediante Internet. Nuestro grupo está precisa de personas que compartan nuestras ideas, tengan o deseen aprender los conocimientos necesarios, y les atraiga el reto que supone derribar una de las últimas fronteras con las que se enfrenta la ingeniería del software en la actualidad.

Webmaster

Volver a la pagina principal

© Copyright