Estamos en una época de profundas transformaciones en la manera de ver y gestionar cualquier actividad empresarial, posibilitadas en buena parte por el increíble auge de las Tecnologías de la Información (en adelante TI); esta sacudida llega también al sector sanitario, impulsada por el arcaísmo vigente de los criterios de gestión en boga hasta fechas recientes, por la creciente conciencia y presión social y por las restricciones presupuestarias. Y no creo que nadie en su sano juicio opine que esto es concebible hoy en día sin un Sistema de Información (en adelante SI) que permita ponerlo en marcha. De hecho, las TI ocupan un lugar estratégico en esta nueva visión y es necesario reflexionar sobre ello, tratando de prever sus efectos (positivos y negativos) con sumo cuidado.
La utilización de las TI crea una espiral de sinergias mutuas; una herramienta poderosa como es la Tecnología de la Información permite y sugiere cambios en la manera de hacer las cosas; esto a su vez, obliga a la utilización de nuevas herramientas... son dos interacciones que se retro-alimentan.
Las TI impregnan progresivamente la gestión y operación en todos los ámbitos y a todos los niveles; son elemento facilitador pero, al mismo tiempo, factor de desestabilización progresiva y a veces traumática de todo el entorno como lo han sido ya, y lo están siendo en tantos aspectos de la vida humana.Todo ello mete a nuestras empresas sanitarias –como a las demás- de cabeza en una profunda crisis de renovación. Una solución, de corto alcance, es evitar la ‘tormenta’ y tratar de subsistir por el método clásico, recortando presupuestos y con retoques de maquillaje. No parece éste el mejor camino. Las modificaciones tímidas, que no incluyan una revisión total del ‘negocio’ se asemejan -según Hammer, uno de los padres del BPR- al gesto de cambiar la disposición de las sillas de cubierta en el Titanic. Los cambios que provoca esta tormenta son de tal índole que, probablemente , quien permanezca anclado en la situación anterior se verá sobrepasado y no tendrá futuro.
Los últimos años del milenio están resultando de transición entre los esquemas antiguos y los nuevos entornos : de la tradicional organización jerarquizada y estática hacia una organización abierta, profesional e interconectada, de ‘geometría variable’, orientada al proceso, y donde la infoestructura tiene un papel estratégico. Y las TI que soportan la infoestructura sufren cambios a una velocidad que hace muy difícil seguir su ritmo. Entran en crisis los conceptos y entornos que hace muy poco tiempo parecían nuevos y revolucionarios. Estamos en la encrucijada de nuevas maneras de pensar y actuar en el ámbito de las TI. Conceptos como orientación a objetos, Data Warehouse, PDA, I*net, Web, Java, Router, Frame Relay, OLAP, redes neuronales, Data Mining, nos atacan desde todas las direcciones, cuando no hemos digerido todavía los conceptos de 4GL, SQL, entornos abiertos, cliente-servidor, Windows...
Y mañana...?? Los rumores que nos llegan de las ‘cocinas’ donde hierve el futuro próximo de las TI no auguran precisamente un horizonte de remanso. Es necesario que aprendamos a vivir haciendo ‘surfing’ en un entorno establemente inestable y cambiante. Es la única garantía de sobrevivir. Y para no perecer en el intento de tener alineada muestra realidad con el estado de las TI, necesitamos agarrarnos a una tabla, a un punto de referencia para evolucionar y no tener que partir continuamente de cero. Para esto, proponemos una modelización abstracta de la organización, que sea válida e independiente de los estilos de gestión, de la estructura cambiante, de las tecnologías aplicadas, y que permitirá dar continuidad y viabilidad a nuestros esfuerzos para no perder el control. Las sucesivas oleadas de tecnologías y estilos deberán ir adaptándose al modelo, evitando así bruscas transiciones.
Antes de enfrentarnos al diseño de un Sistema de Información Hospitalaria, es importante una fase previa de reflexión global. No es correcto intentar verlo como una simple agregación de subsistemas independientes y no integrados, debido a la atomización y probable falta de conjunción entre los componentes. Quizá es también un error pretender un análisis ‘top-down’ puro, por difícil, lento y rígido. Utilizando los criterios y la filosofía de las nuevas técnicas de análisis orientado a los objetos, disponemos de una vía alternativa de acercamiento.
Como premisa inicial, hay que considerar el hospital como una empresa de servicios donde se elabora parte de un producto que la trasciende, ya que debe compartirlo con otros agentes del sistema de salud. El interés clínico, la nueva Sociedad de la Información altamente comunicada, y el mismo gestor público de la salud, están pidiendo una visión unitaria del enfermo -siempre en difícil equilibrio con los derechos de intimidad y confidencialidad-. Esto nos lleva a proponer como eje vertebrador del sistema al enfermo y a su problema de salud en vez de las áreas de producción o los productos intermedios. Esta idea-base debe estar presente en todo el trabajo.
Contrariamente a lo que pueda parecer, no hay tanta diferencia entre los distintos acontecimientos, tareas, procesos que se realizan en un hospital (o en cualquier centro sanitario). De hecho, todos ellos comparten una serie de rasgos fundamentales que permiten clasificarlos en unas pocas familias.
Si se realiza el trabajo de buscar el ‘máximo común denominador’ de todos ellos, se obtienen unas células mínimas de información que, debidamente completadas y dotadas de capacidad de ensamblado, van a permitir la construcción de un modelo global de la actividad del centro, homogéneo, simple y consistente.
- Requerimientos del modelo.
- Debe basarse en la propia esencia de la organización, para que mientras nuestra organización tenga la misma meta que ahora, el modelo siga siendo válido.
- Debe contemplar las características de ente vivo y dinámico, para los cambios en el tiempo y en la concepción.
- Debe ser validado y compartido por los distintos actores del centro, para que responda simultáneamente a todos los puntos de vista; no una entelequia informática.
- Pensarlo con idea de CIM (Computer Integrated Manufacturing), como un todo (independientemente del grado de ‘robotización’ viable ahora, ya que es una característica que seguro variará con el tiempo)
- Para conseguir un modelo de geometría variable, más que un modelo terminado nos conviene la identificación y caracterización de las ‘clases’ de objetos que intervienen, y sus mecanismos de interrelación (juego de mecano).
- El macro-sistema
- El producto
- La estructura y la organización
- El proceso
- La Unidad Básica de Información (UBI)
- El Módulo de Elaboración de Producto (MEP)
- Modelización del paciente y el problema de salud. La Historia Clínica
- El árbol del paciente
- El Sistema de soporte a la decisión
Para evitar el error de que los árboles nos impidan ver el bosque; empecemos el análisis desde lejos, buscando la ‘vista de pájaro’ de todo el sistema sanitario.
El macro-sistema contiene un conjunto P con la población de referencia; un conjunto Q con el ‘catálogo’ de problemas de salud qi y un conjunto derivado PQ compuesto por los pares persona-problema de salud [pi, qi] ; este conjunto debería ser tan pequeño como sea posible, y es lo que el grupo de entes gestores de salud (conjunto G) debe tratar de resolver, por encargo de P; para ello utilizará el Sistema Sanitario (S) que tendrá como objetivo, como producto, reducir cada uno de los pares [pi, qi] que se le presenten.
A la entrada del sistema, existe un pedido en la forma ya vista de par [pi, qi] , que, después de la actuación correspondiente, se transformará a la salida en un par [pi, q’i], donde razonablemente el problema se habrá eliminado, o por lo menos disminuido ( 0 £ q’i £ qi ) , aunque a veces desgraciadamente se anule el par de salida por la desaparición del componente humano pi .
La diferencia entre los niveles de déficit de salud a la salida y a la entrada ( q’i - qi ) constituye el producto del sistema sanitario, y por tanto, el punto de partida del modelo, ya que es lo que da sentido a todos los demás elementos.
Definido el producto de una manera suficientemente genérica y precisa, hay que localizar las demás piezas-clave del juego sin perder de vista que deberán configurarse en función del objetivo propuesto, y que pueden diferir mucho según el estilo de cada empresa.
Las nuevas organizaciones tienden a transformarse en estructuras menos jerarquizadas, más planas, y con flujos internos de estilo cliente-proveedor. De todos modos, sea cual sea el estilo de organización habrá siempre unas funciones asociadas al diseño, la ingeniería de producto y de proceso, y otras asociadas a la organización de la producción, independientemente de quién o qué asuma cada papel. En la figura puede apreciarse este esquema, tal como se percibe en HGM, con sus niveles y componentes.
Lo que nos interesa sacar ahora de él es la focalización en los dos ámbitos. A la derecha, reflejamos las funciones asociadas al conocimiento profesional : para el médico serán los protocolos y conocimientos de su especialidad, para el cocinero las recetas y procesos de cocina, para el informático el know-how tecnológico, para el administrativo sus conocimientos de contabilidad... aquí corresponde decidir el qué, el como se va a realizar, se diseñan y utilizan los ‘planos’ o protocolos generales o particulares para cada caso.
A la izquierda tenemos lo que es la organización de la producción: como organizar la cartera de trabajos pendientes, como combinarla y optimizarla...decidir el cuando y el donde y procurar los recursos necesarios. Constituye el ámbito del sistema de operaciones. Son distintos puntos de vista complementarios de lo mismo. En medio, tenemos un flujo circulatorio que representa las interacciones entre todos los agentes involucrados, ya sean jerarquizadas o de diálogo.
Partiendo de estas ideas construimos un tablero de juego, donde en un eje tendremos la estructura del conocimiento (especialidades médicas, profesionales de distintos ámbitos como enfermería, administrativos, cocina, lavandería) y en el otro las distintas unidades de producción o equipos (urgencias, consultas externas, diálisis) , compuestos frecuentemente por grupos multidisciplinares.
Frente al tablero, aparece el ‘pedido’ [pi, qi] , y para conseguir que a la salida se transforme en [pi, qi’] ocurrirán una serie de acontecimientos distribuidos por las casillas del tablero, acontecimientos que además estarán enlazados entre sí en función del desarrollo de cada proceso individual.
Los acontecimientos pueden ser de muy distinta índole: así tendremos estudios radiológicos, urgencias, hospitalizaciones, consumos, órdenes médicas, anotaciones clínicas, visitas en consulta externa, suministros de unidosis, imágenes de TAC, llamadas de teléfono, registros de enfermería, diagnósticos, pedidos , y un muy largo etcétera...; multitud de pequeñas cajitas que podemos imaginar como contenedores de información, como objetos situados dentro de este tablero de juego. El catálogo de tipos de ‘cosas’ que pueden representarse por este medio es muy grande, pero de todos modos pueden reducirse a unas pocas familias o clases de objetos (tareas, mensajes, anotaciones, contenedores, pedidos, resultados, referencias multimedia..)
Además de las clases de objeto principales, y para completar el juego, necesitaremos información accesoria; por ejemplo, para efectuar un estudio radiológico necesitaremos unas placas, que podemos representar como una mochillita colgada de la caja principal. La utilización de este mecanismo puede sobrecargar el modelo, y debemos reservarlo para casos relevantes. Probablemente no nos interesará cargar el modelo con detalles que en este momento no son relevantes o que pueden obtenerse por estimación (norma técnica): por ejemplo, podríamos optar por utilizar una cajita para representar el consumo de electricidad en cada urgencia, pero parece mucho más razonable hacer una distribución estimativa posterior; es otra manera de asignar información dentro del tablero.
Otras informaciones no estarán directamente asociadas al enfermo sino que afectan sólo a la estructura: el agua que se gasta en el laboratorio, la luz que se gasta en radiología, las amortizaciones de una inversión etc., todo cabe aquí dentro, todo entra en el tablero-hospital ..
A esta especie de cajita, ladrillo básico del juego, la llamamos UBI (Unidad Básica de Información). Para poder colocar a una UBI -independientemente de su significado- en el tablero, debemos asociarle una serie de atributos (cuando se ha hecho, quien es el responsable desde el punto de vista del conocimiento, en qué sitio se ha hecho) esto, junto a algún atributo más, como un identificador único para cada UBI que nos permita reconocerlo y referenciarlo de forma no-ambigua, nos permite mantener y gestionar todo el sistema, analizable desde múltiples ángulos, y con información consistente, de estructura fundamental simple y coherente y no-redundante. Cada tipo de UBI, de acuerdo con el análisis orientado a los objetos (OOA), es tratado como una clase, y está dotada de un nombre, unos atributos como los que acabamos de comentar, y una serie de funcionalidades representados por métodos. Para facilitar los mecanismos de herencia, es muy útil especializar las clases de acuerdo a algunas características comunes. De ahí surge el análisis por la duración, que clasifica a las UBI en puntuales y dilatadas, la característica de programabilidad, la característica de contenedor múltiple etc.
Un factor importantísimo es la capacidad de enlace entre UBI’s. (relacionarla con otra UBI para saber quién lo ha pedido, para qué tarea...); habrá enlaces estructurales y enlaces de proceso; el primer tipo de enlace nos proporciona la descomposición del proceso hacia el nivel de detalle que queramos, y el segundo, caracterizado por la incorporación de UBI’s tipo ‘pedido’, nos indica el ‘workflow’ , la dinámica del proceso; la existencia de estos tipos de enlace es la que permite crear un modelo tan complejo como queramos.
Es fundamental el hecho de que cada una de estas UBI sea punto de encuentro de los ejes de conocimiento y realización, para integrar ambos mundos de forma consistente. De aquí se deducen sin mucha dificultad las arquitecturas para la visión de la organización de la producción y para el diseño y seguimiento de los procesos individuales; en la UBI tienen su punto de encuentro. Asimismo, los enlaces entre UBI permiten establecer las relaciones cliente-proveedor asociadas a cada tarea. La aplicación práctica de estos conceptos elementales ha soportado hasta ahora toda la evolución del sistema HGM, y no prevemos problemas en un futuro razonable.
Es importante considerar el hecho de la absoluta libertad a la hora de definir el significado de cada UBI, así como el grado de detalle ya que cada UBI puede subdividirse; esto permite de una lado la incorporación de nuevos tipos de UBI sin alterar en absoluto el funcionamiento de todo lo existente, así como un progresivo refinamiento del modelo sin modificar nada substancial; la estructura de enlaces entre UBI, permite una relación jerárquica entre ellas, para conseguir si se desea un mayor nivel de información; por ejemplo podríamos tener una sola UBI para representar un tratamiento de rehabilitación, o desdoblarlo en una UBI-madre con este significado, raíz de una estructura arborescente dependiente con tantas UBI como sesiones realizadas; podríamos poner otro subárbol para registrar cada uno de los tratamientos a seguir etc...
Alrededor de este núcleo del sistema-de-producción se constituyen los demás subsistemas de recursos humanos, de suministros, de administración, de dirección, de calidad, cada uno con sus especificidades; se establece un sencillo mecanismo para que cualquier átomo de información de estos subsistemas pueda ser asociado a cualquier UBI, y por tanto integrado en la secuencia de cada proceso individual; en todo caso, la totalidad de la información debe poder encajarse en el tablero general definido.
Desarrollando las relaciones cliente-proveedor citadas en el punto anterior, llegamos a la parte del modelo que pretende resolver la organización de la producción. Esto lo conseguimos ampliándolo con unas estructuras virtuales alrededor de las UBI más complejas: las de tipo ‘tarea’, representantes siempre de una dualidad inseparable tarea-producto, célula generadora de todo el sistema de producción. Y no debemos ceñirnos a las tareas propiamente asistenciales o clínicas; cualquier tarea humana sigue unos mismos pasos para su realización, aunque algunos puedan ser no-relevantes. Es la parte donde podemos y debemos aplicar las técnicas y herramientas que nos ofrece la industria para organizar la producción, y hacer una gestión óptima de los recursos. El modelo es válido desde una gestión totalmente manual hasta una implementación CIM totalmente automatizada.
Es fundamental ver el juego de producción como una estrecha interacción entre MEP’s internas o externas al sistema, soportada por un sistema de mensajería, donde es perfectamente pensable una implementación basada en estándares (HL7, protocolos de mensajería CEN TC-251, EDIFACT).
El modelo representa el MEP como una estructura con un buzón a la entrada, capaz de recibir mensajes emitidos por alguna UBI (no sólo por UBI’s); los mensajes serán de distinto significado, pero el que ahora nos interesa más es el que nos lleva un pedido para ‘construir’ una UBI; habrá un elemento, humano, robotizado o como sea, capaz de interpretar el pedido, decidir su aceptación o rechazo, y las condiciones de la aceptación; para ello utilizará un archivo (mental, escrito, informatizado) de protocolos de actuación; hay que notar que habrá dos tipos de decisor: uno, asociado a la dimensión del conocimiento, para ajustar el pedido deseado al procedimiento adecuado de un lado , y otro para ajustar su realización a las restricciones que imponga la organización interna del MEP (normalmente limitaciones de recurso interno / externo escaso o dependencias entre UBI’s componentes).
Ante cualquier cosa que nos pidan, la respuesta (si se acepta el pedido) puede ser: lo haré cuando pueda (lista de espera); lo haré tal día (programado); lo hago ya (inicio) seguido de un final de construcción y la correspondiente entrega; estas son las fases de ‘maduración’ de cada UBI dentro de esta especie de ‘astillero’ que es el MEP e implican unas herramientas genéricas de gestión de listas de espera, de programación, de gestión de UBI’s empezadas o ‘en curso’, censos, mapas de ubicación... Una vez entrado el pedido en el MEP, cada UBI a construir deberá ir pasando por las fases de maduración que le queden hasta el final. Un análisis a nivel más detallado nos llevaría a considerar la especialización de las UBI en función de su comportamiento en la MEP; así hablaríamos de UBI puntual o dilatada en el tiempo, lo que nos llevaría al importantísimo concepto ampliado de censo, hablaríamos de las Ubi programable, con su enlace a las agendas asociadas etc.
El decisor, como responsable de la UBI en construcción, necesitará coordinarse con otros MEP para obtener recursos y actuar a su vez como demandante-emisor de mensajes de pedidos a otro proveedor, con lo que el sistema puede llegar a ser tan complejo como se quiera. Desarrollando la actuación de los protocolos, pueden conseguirse altos niveles de automatización de cada MEP.
La otra gran ‘pata’ es el aspecto del modelo asociado al producto y al proceso, para su utilización desde el punto de vista del clínico y del almacenamiento y gestión de la historia clínica informatizada, es decir mirando más a ver como encaja con el receptor de nuestro producto: el par ya conocido [paciente, problema de salud].
Esta parte del análisis es forzosamente menos estándar con la industria convencional y requiere un tratamiento específico.
Para ello, tratamos de modelizar al paciente como un conjunto inmenso de variables de tipo diverso; teóricamente, podríamos llegar a reducirlo –a efectos de gestión de la salud obviamente- a un vector larguísimo de variables, susceptibles de ser reconocidas o no; este subuniverso de las valorables irá creciendo con el avance de las ciencias de la salud; en cada caso particular, habrá un subconjunto de variables reconocidas por el propio paciente y un subconjunto parcialmente solapado con éste con las reconocidas por el agente del sistema de salud; con la clasificación convencional de síntomas y signos, algunas de estas variables pueden adquirir valores considerados anormales; éste subgrupo nos identificará un problema de salud, y es función del sistema ser capaz de identificarlo, y tratar de modificar el valor de estas variables para devolverlas a la normalidad.
Para expresarlo, añadiremos un eje temporal al vector de variables; con ello dispondremos de una matriz bi-dimensional que nos refleja la evolución en el tiempo de las variables de interés, es decir del proceso que sigue la enfermedad.
Ante este tablero, es donde debe actuar nuestro modelo de UBI’s entrelazadas; en cada actuación podemos -siguiendo el algoritmo de actuación pertinente- recoger valores de las variables (anamnesis, exploración, pruebas diagnósticas..) y/o realizar acciones para tratar de modificar el valor de las variables anómalas. El modelo permite almacenar y gestionar esta interrelación utilizando alguno de los subtipos de UBI (contenedores para valores de, registros individuales de pruebas, anotaciones, referencias multimedia). Todo ello constituirá una excelente historia clínica informatizada, absolutamente encajada además en los mecanismos de producción, sin redundancias, y con la ventaja de permitir una extensión progresiva, de forma paulatina, en función de las posibilidades , del estado de la tecnología y de los criterios organizativos de de cada momento. Los enlaces establecidos entre las múltiples UBI, permiten visualizarlas y gestionarlas desde distintos puntos de vista (por tipos de UBI, por cronología, por paciente, por problema de salud, por pedido, por rama de conocimiento, por producto...). Esta parte del modelo se implementa con las estaciones de trabajo médico y de enfermería, herramientas imprescindibles para obtener y gestionar la historia clínica de forma electrónica.
Esta estructura arborescente de información será un subárbol de la estructura general del paciente, separada en cuatro capas como muestra el dibujo: en la primera habrá toda la información personal, básicamente administrativa ; en la segunda capa habrá la definición y características de los problemas de salud; estas dos capas definen al enfermo y su problema; en la tercera, interfaz entre el paciente y el sistema, habrá cada uno de los pedidos que recibimos para solucionar estos problemas o parte de ellos; y finalmente, en el cuarto nivel, tendremos el subárbol con toda la actividad e información interrelacionada referente a este pedido.
Al utilizar elementos homogéneos, simples, y muy estructurados, que llevan ya implícita o explícitamente las diversas dimensiones y jerarquías que constituyen el esquema de una base de datos OLAP, resulta de una notable simplicidad la generación de una DataWarehouse para la utilización de herramientas estándar de análisis (DSS, EIS). La DataWarehouse de HGM contiene de momento distintos datamarts interrelacionados , orientados a la producción, el consumo, los recursos humanos, a la producción principal (GRD) , y se están construyendo datamarts específicos para áreas complejas. La simplicidad y ‘realismo’ de las piezas utilizadas y sus interrelaciones creemos que deben proveer más adelante un input ideal para utilizar herramientas de ‘data mining’ y de simulación.
El modelo presentado tiene una serie de ventajas (e inconvenientes), que podemos resumir en los siguientes puntos:
