Los sistemas de información clínica tienen 50 años de historia, vinculados a la evolución de los sistemas de información -la informática- en general. Analizar su evolución permite entender como están construidos, sus posibilidades y limitaciones y sus retos.
Para entender la evolución de los sistemas informáticos hay que recordar que requieren de hardware y software. Sus desarrollos están interrelacionados evolucionando de manera conjunta: a mayor capacidad de cálculo, más funcionalidad puede desplegarse. Asimismo podríamos afirmar que la capacidad del software ha condicionado la evolución de la forma de relación (por ejemplo, los sistemas de pato) entre los distintos agentes que intervienen en el sistema sanitario (pacientes, proveedores, financiadores, aseguradores): del pago por acto a la transferencia de riesgo poblacional.
Cuando los hospitales empezaron a informatizarse en los años 1950 en Estados Unidos, el hardware disponible eran los llamados main frames, grandes máquinas que interactuaban con los usuarios a través de tarjetas perforadas. Solo las grandes instituciones, los hospitales, podían permitírselos y los utilizaban para la gestión financiera. La facturación se realizaba en base al pago por acto (fee-for-Service). Así los sistemas de información sanitaria tienen en su base un enfoque básicamente económico y financiero este origen sigue todavía presente en algunos de los sistemas que actualmente se están utilizando.
La segunda capa que se desarrolló fue la que permitía la agenda de los pacientes: los sistemas de citación y admisiones. Lógicamente estaban altamente vinculados a la generación de las facturas que se devengan por los actos médicos entendidos como los encuentros o episodios de atención, ya sean consultas o estancias de hospitalización. En España, esto se tradujo en la implantación del HIS de Hewlett Packard en los hospitales del Insalud en los años 1980, tardíamente en relación con los Estados Unidos.
La siguiente etapa en la evolución de los sistemas fue la creación de sistemas de información asociados a los llamados servicios de apoyo, como el laboratorio, la radiología y la farmacia. Estos sistemas fueron generalmente desarrollados por los fabricantes de equipos a los que daban servicio.
Los sistemas de información de laboratorio, llamados LIS (Laboratory Information Systems) eran capaces de trazar las peticiones realizadas a los pacientes y devolver los resultados de las analíticas que los auto- analizadores empezaban a ser capaces de producir de una forma automática. Los Sistemas de radiología los RIS (Radiology Information System) en ese momento eran solo capaces de gestionar las agendas con las distintas pruebas en los distintos equipos (llamados modalidades). No tenían capacidad para el almacenaje ni mucho menos para el tratamiento de las imágenes, todavía analógicas en soporte físico de película. Los sistemas de almacenaje de imágenes radiológicas llamados PACS (picture archiving and communication system) no aparecieron hasta que fue posible contar con sistemas de radiología digitales o sistemas de digitalización de imágenes y almacenamiento a costes asequibles hasta principios de los años 90.
Los sistemas de farmacia empezaron como un medio para asegurar la facturación de toda la medicación administrada a los pacientes (en un contexto de pago por acto) así como de apoyo al proceso logístico de aprovisionamiento y compra de medicación.
El flujo de trabajo se basaba en un prescripción de una prueba complementaria o de medicación en papel, y generalmente a mano, que llegaba físicamente a los servicios destinatarios (laboratorio, radiología, farmacia), dónde la solicitud era introducida en el sistema y gestionada a partir de ahí.
La siguiente fase evolutiva se dio cuando fue posible poner a disposición de los clínicos en las distintas unidades de hospitalización “terminales” que permitían hacer las peticiones a los pacientes a pie de cama. Con ello se ganaba en inmediatez y se disminuían los errores de transcripción. Este sistema es el llamado CPOE (Computerized provider order entry) sistema de peticiones electrónicas.
Raramente, estos sistemas de peticiones electrónicas, contaban con sistemas de ayuda a la decisión clínica. Sin embargo, el Dr Homer Warner ,considerado el padre de la informática médica, ya en 1968, en el hospital de los Santos de los Últimos Dias (Salt Lake City, Nevada, Estados Unidos) presentó y empezó a utilizar el embrión de la primera historia clínica con capacidad para dar soporte a la decisión clínica. Llamado HELP (en inglés acrónimo de evaluación de la salud a través de procesamiento lógico), era capaz de proponer a los clínicos las pruebas complementarias más adecuadas en la presencia de unos determinados síntomas, estuvo en funcionamiento durante 40 años.
Llegados a este momento de la evolución de los sistemas de información clínica, se produjeron dos grandes tendencias de desarrollo: la llamada best of breed (“lo mejor de cada casa”) o los sistemas integrados. Esta dicotomía continúa hasta la actualidad y la facilidad para crear apps que el debate esté más vivo que nunca.
El best of breed es el resultado del desarrollo de sistemas específicos para cada uno de los servicios o departamentos a medida que se van incorporando a la digitalización y a la oferta de sistemas vinculados a equipos de diagnóstico por parte de los fabricantes (por ejemplo, endoscopia, espirometría..). Este enfoque hace que los sistemas disponibles sean más eficientes en relación con las necesidades concretas de los flujos de trabajo y orientados a la práctica clínica específica de la especialidad, pero difícilmente interoperables. El otro enfoque fue el de los sistemas integrados dónde lo que sé primaba era que fuese un único sistema transversal a través de todo el hospital, sobre la adaptación específica a cada uno de los servicios.
Cómo es lógico la satisfacción de los profesionales implicados es mayor cuando disponen de sistemas a medida, pero es a costa de que la información del pacinte quede compartimentada y fluya difícilmente a través del continuo de la asistencial.
La otra gran división que se produjo en este momento fue entre los desarrollos a medida para y por cada uno de los centros y la adquisición de soluciones estándar o off the shelf . Los primeros permitían dar respuesta a las necesidades específicas de cada organización, tanto en cuanto a la adaptación de flujos de trabajo como en ritmo de despliegue. Los segundos facilitaban unos tiempos de implantación más rápidos y poder contar con versiones actualizadas más fácilmente.
Solo los grandes sistemas hospitalarios eran capaces de financiar un sistema integrado mientras que la aparición de los ordenadores personales permitió el desarrollo mucho más sencillo de soluciones a medida departamentales pero que difícilmente eran escalables y mucho menos ínter operables. También se dieron situaciones intermedias, donde, a partir de un sistema de un fabricante, se hacían desarrollos a medida, que alejaban la solución del estándar original. En España esta situación es muy común. Ejemplos de ello son las distintas versiones de Selene ©, producto orignialmente estandar de Siemens, de ish.med © -producto vinculado a SAP- o del HIS © de Hewlett Packard, con múltiples versiones en varias autonomias. Este pasivo todavía se está arrastrando, y es uno de los mayores escollos en el objetivo de la interoperabilidad.
La invención de los ordenadores personales (PC), con capacidad de proceso distribuida, la disponibilidad de interfaces de usuario más amigables, como el Windows © y la aparición de programas de tratamiento de textos como el WordPress o Word permitieron que se pudiese empezar utilizar los sistemas para registrar documentos clínicos en formato electrónico. La Historia clínica electrónica empezaba a contener documentos clínicos, con texto libre, más allá de las peticiones con informes y breves notas de evolución.
Pero ¿Cómo se hacía eso compatible con una recogida de datos estructurada capaz de ser utilizados para ser procesados automáticamente, ya sea a nivel estadístico o para sistemas de ayuda a la decisión clínica? Con los formularios y los repositorios de datos clínicos (CDR Clinical data repository).
Este es otro debate sigue latente y pendiente, y es donde el rol del Chief Clinical Information Officer es fundamental. En muchos casos tiene sentido recoger los datos de una manera estructurada (en formularios y CDR) para su posterior análisis, mientras que otros lo relevante es la narrativa de la situación clínica descrita en un texto con formato más o menos libre. Por otro lado, existe la tentación de recoger el máximo datos posibles lo que genera una sobrecarga en los profesionales asistenciales. Finalmente existe el riesgo de que se suponga qué por qué una casilla ha sido validada, ese acto clínico ha sido efectivamente realizado, dando una falsa sensación de seguridad asistencial basada en la documentación de procesos y el cumplimiento de criterios de calidad.
Sin lugar a duda la recogida estructurada de datos a permitió el desarrollo de los sistemas de ayuda a la decisión clínica a que son el siguiente paso en la evolución de la historia clínica electrónica. Estás sistemas de ayuda a la decisión clínica son básicamente sistemas de alerta y los llamados care sets o conjuntos de indicaciones.
Al recoger los datos de forma estructurada en formularios o en peticionarios el sistema es capaz de hacer verificaciones comprobando por ejemplo de que una medicación o prueba complementaria no ha sido prescrita dos veces (duplicados) o que no ha sido prescrita a un paciente con una alergia registrada a ella. También es posible señalar aquellos rangos de resultados fuera de la normalidad. La sofisticación (complejidad de las reglas lógicas) y amplitud (cantidad de variables que tienen en cuenta) de estas alertas depende en gran medida del diseño del sistema, y, sobre todo de su tecnología.
En estos momentos la principal preocupación no es tanto la generación de alertas sino la llamada fatiga de alertas, por exceso. Alertas que parecen lógicas en el momento del diseño pueden llegar a ser altamente intrusivas en la práctica asistencial si no se diseñan de una teniendo en cuenta la realidad del entorno asistencial donde se desplegarán, llegando a producir problemas no deseados como consecuencia de la propia informatización. En el mundo anglosajón se habla del clinical risk management (CRM) al esfuerzo sistemático para prevenir y minimizar en lo posible el impacto negativo de los sistemas de información clínica: primun non nocere.
Vamos a ver un par de ejemplos. En el primero, tenemos un sistema que nos alerte cuándo unas las constantes vitales de un paciente exceden un determinado rango, por ejemplo la temperatura, para indicar que el paciente tenga fiebre. En principio, esto es deseable, pero ¿Qué sucede cuando la alerta se dispara justo en el momento que la enfermera está realizando un proceso complejo (como preparar una bomba de infusión de medicación cardiotónica)? La alerta, ¿puede suponer una distracción y facilitar un error en la administración de la medicación? Imaginemos esta situación en una unidad con pacientes críticos. En el mismo entorno, ¿pueden los clínicos confiar en que una alerta les advertirá, dejando en segundo término la observación de los pacientes (quizás por una sobre carga de trabajo)? ¿Qué sucede si el monitor se desconectó inadvertidamente? ¿y si los datos, (por la presión asistencial), no son introducidos en el sistema en tiempo real, hacen que la alerta se active con horas de demora?
Como podemos ver se trata de situaciones complejas que requieren análisis no solo de las capacidades del sistema de información sino de múltiples aspectos como los flujos y cargas de trabajo, la infraestructura disponible (por ejemplo, ordenadores cerca del paciente), la capacidad de la red, la formación de los profesionales, etc.Una metodologia ampliamente usada para estos análisis es la que se resumen en People, Process, Technology , Environment (PPTE)
En este punto hemos visto cómo los datos pueden ser recogidos de dos grandes maneras: estructurados o no estructurados. Como hemos visto los datos estructurados presentan una serie de ventajas como su recogida de manera sistemática, reduciendo la variabilidad, y su explotación posterior. Por otro lado, los datos no estructurados permiten una narrativa más rica y acorde con la evolución de los pacientes y la tradición clínica, pero dificultan los análisis estadísticos y la utilización de sistemas de alerta y ayuda a la decisión clínica.
Es cierto que en los últimos años se están desarrollando sistemas capaces de convertir textos no estructurados en estructurados a través del Procesado de Lenguaje Natural (Natural Language Processing NPL). Pero estos sistemas aún requieren una capacidad de computación muy elevada, lo que hace que en la mayoría de los casos no sea posible su utilización en tiempo real. Los ejemplos que vemos en el mercado actualmente (Savanamed, IOMED) permiten el análisis de datos a posteriori o, en el mejor de los casos de manera no síncrona. La tendencia es que será posible registrar los datos de manera no estructurada, directamente a través de la voz, y que los propios sistemas sean capaces de convertirlos en datos estructurados de en tiempo real. La tecnología ya está disponible (sobre todo en inglés), pero es costosa y compleja. La compra de Nuance por Microsoft es una clara señal de ello.
Retos del sistema sanitario 