ARTÍCULO ESPECIAL

 

Estándares técnicos y funcionales, y proceso de implantación, de un sistema de información clínica en unidades de cuidados intensivos

Technical and functional standards and implementation of a clinical information system in intensive care units

 

 

V. Gómez Tello^a, J. Álvarez Rodríguez^b, A. Núñez Reiz^c, J.A. González Sánchez^d, A. Hernández Abadía de Barbará^e, M. Martínez Fresneda^f, P. Morrondo Valdeolmillos^g, J.M. Nicolás Arfelis^h, I. Pujol Varelaⁱ y M. Calvete Chicharroⁱ, Sociedad Española de Medicina Intensiva Crítica y Unidades Coronarias (SEMICYUC)

^aUnidad de Cuidados Intensivos, Hospital Moncloa, Madrid, España
^bUnidad de Cuidados Intensivos, Hospital Universitario de Fuenlabrada, Madrid, España
^cUnidad de Cuidados Intensivos, Hospital Fundación Alcorcón, Madrid, España
^dUnidad de Cuidados Intensivos, Hospital Clínico San Carlos, Madrid, España
^eUnidad de Cuidados Intensivos, Hospital Central de la Defensa Gómez Ulla, Madrid, España
^fUnidad de Cuidados Intensivos, Hospital Virgen de la Arrixaca, Murcia, España
^gUnidad de Cuidados Intensivos, Complejo Hospitalario Donostia, San Sebastián/Donostia, España
^hUnidad de Cuidados Intensivos, Hospital Clínic, Barcelona, España
ⁱUnidad de Cuidados Intensivos, Hospital MD Anderson, Madrid, España

Dirección para correspondencia

 

 

---

RESUMEN

Introducción: Los sistemas de información clínica están convirtiéndose en una herramienta útil para la gestión de los pacientes en la unidad de cuidados intensivos (UCI). Sin embargo, los sistemas disponibles en el mercado difieren en cuanto a capacidades y requerimientos técnicos. Por tanto, es necesario que los intensivistas, como clientes finales de estas aplicaciones, definan los mínimos para que estas sean operativas y útiles.
Objetivos: La Sociedad de Medicina Intensiva Crítica y Unidades Coronarias, a través de sus Grupos de Trabajo de Internet y Nuevas Tecnologías, y de Organización y Gestión, encargó a un grupo de expertos clínicos e informáticos la redacción de un documento que recogiera los requerimientos técnicos y funcionales mínimos que deberían de reunir los sistemas de información en las UCI.
Métodos: El grupo de expertos estuvo formado por diez personas y contó con la colaboración de representantes e ingenieros de las principales cinco compañías fabricantes de estos sistemas en España. El proyecto presentó las siguientes fases:
a) Realización de una encuesta técnica que recogiera la situación actualizada para cada sistema.
b) Discusión presencial y on-line de los resultados, y formulación de estándares por el grupo de expertos.
Resultados: Los estándares se agruparon en cuatro categorías: técnica, funcional, datos y seguridad. Todos los estándares fueron clasificados en básicos y opcionales para permitir que el usuario final pueda decidir entre diferentes posibilidades, pero asegurando un mínimo básico de características útiles. También se propuso un cronograma de implantación del sistema.

Palabras clave: Sistemas de información clínica. Estándares. Requisitos. Unidades de cuidados intensivos.

---

ABSTRACT

Introduction: Clinical Information Systems (CIS) are becoming a useful tool for managing patients and data in the ICU. However, the existing CIS differ in their capabilities and technical requirements. It is therefore essential for intensivists, as the end clients of these applications, to define the suitable minimum specifications required in order to be operative and helpful.
Objectives: The Spanish Society of Intensive Care Medicine and Coronary Units, through its Organization and Management Workgroup, has designated a group of clinical and software experts to draft a document with the recommendable technical and operating requirements of these systems.
Methods: The group was formed by ten people supported by managers or engineers from the five principal industries producing CIS in Spain. The project involved the following phases:
a) Completion of a check list. This step was considered necessary in order to establish the precise current situation of CIS applications.
b) Discussion of the results by the group of experts in a meeting and in online format.
Results: The requirements were grouped into four sections: technical, functional, safety and data management. All requirements were classified as basic and optional in order to allow the end user to choose among different options according to the existing budget, though ensuring a minimal set of useful characteristics. A chronogram for the installation process was also proposed.

Key words: Clinical information systems. Standards. Requirements. Intensive care units.

---

 

Introducción

El objetivo de un sistema de información en una unidad de cuidados intensivos (UCI) es favorecer la mejora de los procesos asistenciales y la gestión de recursos. Con ello se pretende contribuir al logro de la ventaja competitiva de la UCI, aumentar el valor añadido en la atención a los enfermos críticos, y mejorar la calidad de trabajo de los profesionales.

En los últimos años hemos asistido a un desarrollo espectacular de las Tecnologías de la Información y la Comunicación (TIC) en los entornos sanitarios. Si bien dichos avances se han incorporado de forma cotidiana al quehacer de numerosos campos empresariales, en el ámbito de la sanidad se observa un notorio retraso en su aplicación y explotación como recurso para mejorar los cuidados que reciben los enfermos¹. En el terreno administrativo y de gestión hospitalario es habitual la utilización de TIC, avaladas por estudios que las consideran como una herramienta imprescindible para mejorar el cuidado y disminuir el error en los pacientes^2,3, junto con una mayor adherencia a las guías.

Los servicios de medicina intensiva (SMI) constituyen un área sanitaria muy especializada y con numerosos dispositivos que generan multitud de datos y registros de los pacientes ingresados, llegando hasta más de 1.300 datos por enfermo y día de estancia⁴. Esta peculiaridad les convierte en los entornos naturales para la aplicación de las TIC.

El empleo de sistemas de información clínica (SIC) en los SMI persigue mejorar los resultados finales del proceso asistencial, mejorando la seguridad y la calidad, y colaborando en la mejor gestión de los SMI. La atención al enfermo crítico consume alrededor del 30% de los recursos disponibles para el cuidado de enfermos agudos y representa el 8-12% de los costes monetarios hospitalarios, lo que supone en España más de 2.400 millones de € anuales⁵. La adopción de herramientas que ayuden a gestionar los procesos de cuidados de estos enfermos puede generar una distribución más eficiente de los recursos sanitarios, puesto que los SIC facilitan a tiempo la información para optimizar la toma de decisiones clínicas y de gestión para una asistencia más efectiva y segura.

La asociación de todos estos potenciales beneficios derivados de la presencia de sistemas de información cada vez más sofisticados en los SMI busca como objetivo primordial optimizar los cuidados de los pacientes. Sin embargo, su grado de penetración todavía es bajo. En España, según datos actualizados de la industria del sector (comunicación personal mayo de 2011), puede estimarse que cerca del 32% de camas de UCI (1.183 sobre un total de 3.683 recogidas en el último censo de la Sociedad Española de Medicina Intensiva y Unidades Coronarias [SEMICYUC]) tienen instalado, o poseen licencia para próxima instalación, un SIC. En una encuesta publicada por Lapinsky sobre la presencia de TIC en las UCI de Ontario (Canadá), la mayoría de los servicios disponen de algún sistema electrónico de acceso a datos de laboratorio (98%) e imágenes (76%); sin embargo, la existencia de prescripción médica informatizada cae al 22% y la captura directa de datos desde dispositivos de monitorización, perfusión y equipos de ventilación mecánica oscila entre el 14 y el 6%, respectivamente⁶. En EE.UU. en el año 2003, entre un 10 y un 15% de las UCI disponían de SIC; países como Australia⁷ han implantado de forma genérica la utilización de TIC.

Las razones de este retraso son múltiples. En primer lugar, una conflictiva evidencia sobre su utilidad real probada a pie de cama. Algunos trabajos no muestran un impacto positivo^8,9, aunque los motivos de este resultado negativo estriban en una implantación inadecuada, cuando no en la vulneración franca del flujo de trabajo habitual de una unidad. No obstante, otros estudios sí muestran un efecto favorable de los SIC en la optimización de tiempos y recursos. El estudio realizado en el SMI del Hospital Universitario Ospedali Riuniti (Ancona, Italia) revela que la utilización de un sistema informático conlleva una reducción sustancial del tiempo empleado por el personal en el manejo de la documentación, respecto al dedicado mediante el método tradicional en papel (3±2 minutos/día vs 37±7 min/día respectivamente, p<0,001), así como una percepción positiva del personal médico y de enfermería¹⁰. Igualmente, el trabajo desarrollado en el Hospital de San Camillo-Forlanini (Italia) concluye que el empleo de un sistema de información en la UCI genera una reducción significativa en los errores de medicación (del 3,69 a un 0,86%), en particular en aquellos potencialmente fatales (2,34 vs 0%), lo que aumenta la seguridad del enfermo¹¹. En la misma línea, Colpaert et al. señalan que la informatización supone una disminución de la frecuencia y severidad de los errores atribuibles a la medicación. Estos autores refieren que el rango de costes atribuibles a errores de medicación oscila entre 10$ en los errores inocuos, y más de 5.000 dólares en el caso de un efecto adverso¹².

Otras razones que frenan la generalización de estos sistemas son su elevado coste y la oposición de los propios clínicos al cambio¹³. No obstante, un claro factor de incertidumbre sobre la decisión final de implantar un SIC es la falta de estandarización, que impide conocer qué requisitos deben poseer estos sistemas para ser clínicamente útiles, y si un determinado producto comercial los reúne. De hecho, una presentación inadecuada de la información puede sobrecargar al clínico, con datos inútiles, aumentando el tiempo, la dificultad de la tarea de evaluación de un paciente y la posibilidad de error¹⁴. Este hecho prueba que, si bien la tecnología está lo suficientemente desarrollada, existe una fractura entre los creadores de aplicaciones comerciales, los servicios informáticos hospitalarios y las necesidades de la práctica clínica diaria. El flujo de información entre estos sectores es fundamental para el futuro desarrollo de sistemas que permitan conseguir una mejora real en la asistencia clínica e influyan con evidencias sólidas en el cambio cultural, tan preconizado y necesario en el personal sanitario.

A tenor de esta argumentación, y una vez conocidas las ventajas, inconvenientes y barreras para la aplicación de los SIC, se hace absolutamente necesario que los profesionales, como clientes últimos de estas aplicaciones, puedan tener la capacidad de opinar sobre el mínimo idóneo de características útiles requeridas para instalarlas en sus unidades. Para ello, es preciso que existan unos estándares básicos, que permitan al clínico guiar y fundamentar esta opinión. El objetivo de este documento de consenso de expertos es establecer los estándares que debe cumplir un SIC para su uso en un SMI y el proceso idóneo para su implantación.

 

Métodos

Para cubrir el objetivo propuesto, la SEMICYUC, a través de sus Grupos de Trabajo de Internet y Tecnologías de la Información y Comunicación, y de Planificación, Organización y Gestión, reunió a un grupo de expertos con el fin de redactar un documento que recogiera los mínimos técnicos y de funcionamiento aplicados a la clínica que pudieran ser exigibles a estos sistemas. Este grupo de 10 personas (8 médicos, uno de ellos ingeniero informático superior, y 2 enfermeros), reconocidos expertos en el uso y aplicación de los SIC, contó con la colaboración de las 5 principales industrias del ramo instaladas en España (Phillips, Drager, IMD Soft, General Electric, Picis) quienes, a través de sus gestores e ingenieros, han aportado ideas y aclarado dudas al equipo redactor.

El proyecto ha seguido las siguientes fases:

1) Elaboración de una plantilla (modificada de un cuestionario canadiense)¹⁵, de estándares técnicos y funcionales que debería reunir un SIC para su implantación en un SMI, incluida explotación de datos y seguridad. Esta plantilla fue distribuida a un miembro del grupo de expertos, usuario avanzado de cada aplicación, para su cumplimentación junto con un ingeniero asesor de la misma.

2) Los resultados de esta plantilla fueron tabulados, discutidos y aclarados en una reunión conjunta del Grupo de Expertos e Industria. Allí, cada compañía, por separado, contestó a las dudas y propuestas de los clínicos sobre las carencias, puntos fuertes y desarrollo potencial futuro de cada aplicación. También se discutió la necesidad de que ambas partes, sociedad e industria, colaboren estrechamente para que el clínico pueda concienciarse de la necesidad de implantación de estos sistemas.

3) A continuación el grupo de expertos agrupó los requisitos o estándares relevantes en grupos y decidió realizar una clasificación de los mismos en básicos y opcionales. Esta división obedece a la necesidad de contar, por una parte, con un mínimo de opciones de recomendado cumplimiento para un proceso de selección, implantación y funcionamiento básico de las aplicaciones. Y, por otro lado, ofrecer un paquete de opciones ideales, algunas de ellas ya presentes en algunos sistemas, que permitan decantar la opinión del clínico y de las entidades responsables finales de la compra, por una u otra solución según necesidades y presupuestos. Estos requisitos opcionales están disponibles en algunas soluciones, y técnicamente, como admite la industria, son viables y posibles, aunque algunos precisan desarrollo conjunto con los clínicos. Es evidente que lo opcional ahora será un mínimo en los próximos años y ediciones del documento, dado el interés de los diferentes agentes involucrados en su implantación y desarrollo.

En la elaboración escrita del documento no participaron en modo alguno los representantes de la industria, si bien se les dio la oportunidad de revisarlo una vez finalizado, y realizar sugerencias, no vinculantes, sobre puntos concretos, algunas de las cuales han sido recogidas por el grupo de expertos en el texto final. Una vez realizada la redacción definitiva, el documento fue aprobado por el Comité Científico de la SEMICYUC el 26 de mayo de 2011.

El documento final ha sido dividido en secciones cuyo orden refleja el proceso lógico de implantación de un SIC. Desde la revisión de la estructura informática hospitalaria y los estándares técnicos que el sistema debe ofrecer para integrarse en él, pasando por el proceso de implantación, los requisitos funcionales clasificados según el flujo de trabajo con el enfermo y la explotación final de los datos del sistema.

Este documento no solo va dirigido a profesionales o responsables de SMI, sino a gerentes hospitalarios, responsables de consejerías de salud autonómicas, y a la propia industria. Para el clínico será una guía de iniciación, información y consejo para instalar un SIC y elegir el más conveniente a sus necesidades, comparando los requisitos con la oferta realizada. Para los gestores, la finalidad es similar, pero la visión clínica del documento trata de que tengan en cuenta que un SIC no solo debe elegirse por su precio o su mantenimiento, sino por un conjunto de características que lo hagan amigable al clínico y rentable para su trabajo. Para la industria será un referente, que les permitirá adecuarse a las peticiones del clínico, mejorar sus productos para el inmediato futuro, y avalarse ante los gestores en los concursos de compra.

A continuación se recogen los estándares agrupados por categorías con una breve descripción de cada uno. Una descripción más completa de cada ítem puede verse en el documento completo que puede ser descargado desde la web de la SEMICYUC en el enlace: http://semicyuc.org/temas/semicyuc/documentos/estandares-sistemas-informacion

Especificaciones técnicas

Los requisitos técnicos se resumen en la tabla 1.

Estándares de transmisión de información

Requisitos básicos:

1) El SIC debe ser capaz de interactuar con otros sistemas de información hospitalaria mediante mensajería usando un protocolo HL7, siendo recomendable que la versión de HL7 sea igual o superior a la 2.4.

Requisitos opcionales:

1) Cumplir los estándares Integrating the Healthcare Enterprise; (IHE, http://www.ihe.net/), y que haya pasado un Connectathon con evaluación positiva. El Connectathon es una reunión periódica donde se prueban y certifican las características de integración de distintos productos y dispositivos con respecto a los estándares que la iniciativa IHE promulga.

2) También sería positivo que el SIC pudiera adaptarse el estándar Clinical Document Architecture (CDA; http://hl7book.net/index.php?title=CDA) en la generación de documentos e informes.

3) Posibilidad de parametrización de los mensajes HL7 para adecuarlos a la conexión con otros sistemas que utilicen subversiones o especificaciones de parámetros diferentes.

4) Posibilidad de generar automáticamente en formato XML resúmenes de datos configurables (CMBD, indicadores, etc.) que puedan ser enviados vía web o correo electrónico a registros centralizados para benchmarking, control de calidad, estadísticas de la SEMICYUC, etc.

Motor de integración

Requisitos básicos:

1) Motor de integración propio, o de terceros configurable, que permita la introducción de nuevas conexiones con otros sistemas de manera flexible, utilizando un protocolo de comunicación bien definido y disponible para los encargados de realizar integraciones futuras. Dicho motor de integración debe estar incluido en el soporte técnico.

Requisitos opcionales:

1) Que el motor de integración permita la conexión entrante y saliente mediante HL7 y XML de forma configurable.

Arquitectura

Requisitos básicos:

1) La arquitectura, ya sea cliente-servidor o web, debe permitir la utilización del sistema desde todas las zonas de trabajo y el análisis de datos que sea necesario.

2) Debe permitir la explotación estadística de los datos en paralelo con el funcionamiento normal de la aplicación, sin pérdida alguna de datos a medida que pase el tiempo. Bajo ningún concepto o pretexto podrá el fabricante dejar de proporcionar un acceso a todos los datos almacenados de los pacientes.

Requisitos opcionales:

Sería deseable que el sistema permita su integración en una arquitectura orientada a servicios, bien como productor o como consumidor.

También sería deseable que el sistema permita el acceso transparente a otras aplicaciones departamentales o generales sin requerir nueva introducción de contraseñas.

Módulos funcionales

Requisitos básicos:

1) El fabricante debe proporcionar una especificación clara de los módulos funcionales independientes de los que consta el programa (tanto básicos como opcionales), sus dependencias y la frecuencia esperada de revisión y actualización.

Proceso de actualización de las versiones

Requisitos básicos:

1) El fabricante debe especificar claramente el procedimiento de notificación de la aparición de una nueva versión, las condiciones económicas que rigen la actualización de versiones, el procedimiento que se debe seguir durante dicha actualización, el tiempo aproximado de actualización y el impacto sobre el funcionamiento del sistema.

Requisitos opcionales:

1) Sería deseable que el producto tuviera una frecuencia de actualización de versiones mayores de al menos una cada 2 años.

2) Acceso del usuario a conocer planes de mejora y nuevas funcionalidades del fabricante.

3) El proceso de actualización debe estar acompañado de nueva formación si se introducen nuevas funcionalidades o se modifica el uso de las existentes.

Mantenimiento

Requisitos básicos:

1) Las condiciones de mantenimiento deben estar claramente especificadas en el contrato, y debe ser posible incluir mediante acuerdo económico un tiempo de respuesta suficientemente corto para garantizar el funcionamiento continuo del sistema.

2) El fabricante colaborará con el servicio de informática del centro para facilitar las tareas de mantenimiento, realización de copias de seguridad fácilmente configurables a intervalos regulares fijados siempre por cada hospital, e integración del sistema con otras aplicaciones departamentales o generales.

3) El fabricante proporcionará asesoría continuada al administrador o administradores clínicos del SIC.

Formación

Requisitos básicos:

1) La adquisición del sistema comporta el deber de que el proveedor imparta a todo el personal que va a utilizar el sistema una formación suficiente para manejar todas aquellas funcionalidades que requiera en sus labores cotidianas.

2) El periodo de formación debe estar establecido en el contrato.

3) La formación debe incluir tanto las funcionalidades como del SIC como la configuración y parametrización del sistema.

Requisitos opcionales:

Realización, por el fabricante, de cursos de actualización periódica.

Tolerancia a fallos y situaciones de crisis

Requisitos básicos:

1) Protocolo de respuesta a fallos que permita posteriormente la recuperación completa del sistema y de los datos anteriores, así como la inclusión posterior de los datos generados durante el periodo de fallo.

2) Posibilidad de corrección de datos erróneos e introducción de datos previos, manteniendo siempre un registro completo de los cambios para cumplir con las directrices de la legislación vigente (Ley Orgánica de Protección de Datos) sobre este particular.

Requisitos opcionales:

1) Poder reenviar y recibir los mensajes producidos durante el periodo de fallo, desde y hacia otros sistemas del departamento y del centro: monitorización, interfaces con otros dispositivos -respiradores, bombas-, laboratorio, sistema de información hospitalario (HIS), etc.

2) Tras fallos de red, el sistema debería permitir seguir visualizando la información de un determinado paciente mediante caches locales o arquitectura de redundancia de red y servidores, así como almacenar en local la información generada en el cliente para transmitirla al restaurarse el funcionamiento correcto.

Rendimiento

Requisitos básicos:

1) El tiempo de respuesta del sistema debe ser lo suficientemente corto para que no interrumpa el ritmo de trabajo normal del usuario. Esto supone una respuesta inmediata del sistema, o a lo más de unos pocos segundos en caso de labores algo más complejas.

2) El hospital garantizará que el hardware disponible en clientes y servidores, y la capacidad de red son suficientes para asegurar un funcionamiento correcto del sistema para cumplir el punto anterior.

3) El hospital también debe asegurar que el ancho de banda es el adecuado.

4) La realización de labores administrativas y de mantenimiento dentro del sistema no debe suponer una ralentización excesiva del mismo.

Requisitos opcionales:

Sería deseable la utilización de servidores en espejo, cluster, balanceo de cargas, virtualización u otros mecanismos de potenciación de los servidores y equipos clientes que garanticen una mayor seguridad y eficiencia en el funcionamiento del sistema.

Almacenamiento

Requisitos básicos:

1) La capacidad de almacenamiento de datos de pacientes debe ser suficiente para evitar su pérdida a medida que transcurra el tiempo tras el alta del paciente. La información clínica almacenada en la base de datos del SIC debe estar disponible durante al menos 5 años desde la última visita o ingreso del paciente, según marca la Ley de Protección de Datos.

2) Debe ser posible recuperar los datos de pacientes dados de alta previamente para incorporar, o al menos visualizar, la información durante el nuevo ingreso.

Requisitos opcionales:

Posibilidad de importar datos de otras aplicaciones previas en el caso de que se trate de un cambio de producto.

Proceso de implantación del sistema de información clínica

La implantación de un SIC en una UCI es un proceso complejo que supone la colaboración estrecha entre el equipo técnico del proveedor del sistema y el equipo que la unidad y el hospital encarguen para la misma. En este proceso intervienen diferentes factores que se especifican en la tabla 2.

Tiempo

El tiempo necesario para llevar a cabo la implantación del SIC depende de la complejidad del mismo y de las integraciones que se deben realizar. Se aconseja seguir las recomendaciones del proveedor.

Equipo del proyecto

a) Se recomienda nombrar un director de proyecto, quien será el responsable máximo de la implantación del SIC en la UCI. El director de proyecto será un técnico de la empresa proveedora del SIC o una persona capacitada nombrada por el Hospital, y estará acompañado y asesorado por cuantos técnicos se necesiten para la completa implantación del mismo según los productos adquiridos.

b) Por parte del hospital se recomienda nombrar un equipo de proyecto que estará integrado por un líder técnico y un líder clínico, el primero responsable de los aspectos técnicos del proyecto y el segundo de la configuración clínica del producto. Ambos líderes estarán asesorados por los profesionales del hospital que se consideren. Se recomienda que el líder clínico cuente con el apoyo de médicos y enfermeras dispuestos a liderar la implantación del SIC en la unidad y mantenerlo actualizado desde el punto de vista clínico. Es muy recomendable que los profesionales que participen en la implantación del SIC dispongan del tiempo necesario para cumplir con su función, descargándoles o liberándoles, total o parcialmente, de la actividad asistencial que les pudiera corresponder durante el periodo de implantación.

Fases del proyecto: inicio, desarrollo, pruebas y activación

Fase de inicio. Es fundamental analizar, antes de adquirir o instalar un SIC, la operatividad bidireccional con otros sistemas hospitalarios, fundamentalmente el HIS, o departamentales específicos (farmacia, laboratorio, radiología, etc.), especificando los componentes necesarios para cubrirlas (tanto de hardware como de software).

Fase de desarrollo. El proveedor instalará el o los productos adquiridos y será responsable de las integraciones con otras aplicaciones y conexiones con los dispositivos médicos según se haya acordado. La fase de desarrollo comprende la modificación de la configuración estándar y las modificaciones específicas para el hospital de tablas y archivos que guiarán el funcionamiento de la aplicación. El equipo del proyecto del hospital construirá la aplicación con el asesoramiento y la formación del equipo del proyecto del proveedor.

Fase de pruebas. Durante esta fase se probarán las integraciones hechas, las conexiones con dispositivos realizadas y todas las configuraciones clínicas. Aquellos puntos que no funcionen según lo esperado o sobre los que se sugieran nuevos cambios se corregirán o se realizarán en esta fase. Posteriormente, se iniciará la formación de todo el personal de la UCI siendo responsable de ella el equipo clínico formado previamente.

Fase de activación. Después de haber probado todo el sistema (componentes, integración y validación paralela), y de haber formado a los usuarios, la decisión de la activación o no activación se toma conjuntamente por el proveedor y el hospital. Se recomienda que el inicio de la actividad con el SIC sea simultáneo al cese de la actividad con papel.

Fase de mantenimiento. Una vez que el SIC esté en funcionamiento, el equipo técnico y clínico del hospital se encargará del mantenimiento clínico de la aplicación, modificando las plantillas y la configuración según sea necesario. Se recomienda que el SMI tenga al menos un médico y una enfermera que escuchen las sugerencias de los usuarios y se encarguen de proponer cambios en la configuración.

Actualizaciones del sistema de información clínica. Las actualizaciones de la aplicación se programarán en tiempo y recursos por parte del hospital y del proveedor de la forma que suponga la menor interrupción para la práctica clínica. En esta fase se hace más necesaria la existencia de un sistema de pruebas donde se puedan probar las actualizaciones antes de introducirlas en la clínica.

Estándares funcionales

Una vez revisados los requisitos técnicos y de formación para que un SIC pueda ser instalado, abordaremos la parte fundamental, o core, de su funcionamiento. Esto es, los estándares funcionales que permiten la labor clínica fundamental que un sistema debe realizar amigablemente, con rapidez y fiabilidad. Los requisitos incluidos en este punto son, a nuestro juicio, los más importantes, ya que hablan de la misión básica actual de estas aplicaciones.

Para describir los estándares de una manera lógica y ordenada, hemos seguido el criterio de seguir el flujo básico de trabajo con el enfermo desde que se le ingresa hasta que se le da de alta. Cada uno de estos pasos tiene un grupo de requisitos específicos que se recogen en las tablas 3 y 4.

Los epígrafes tratados serán:

Datos del paciente.

Elaboración del informe de ingreso y planificación.

Prescripción.

Conexión a sistemas de monitorización.

Modelización del curso de los pacientes. Técnicas y cuidados específicos

Escalas, informes y codificación.

Datos del paciente

Requisitos básicos:

1) Datos demográficos del paciente (datos de filiación: nombre, apellidos, fecha de nacimiento, sexo, dirección, teléfono; número de historia; número de admisión) adquiridos mediante importación directa del HIS mediante ADT.

2) Importación de alergias.

Requisitos opcionales:

1) Historia clínica: importación de datos de la historia más relevantes para evitar duplicidades con la información del HIS.

2) Diagnósticos de enfermería (NANDA) y planificación de cuidados mediante el uso de intervenciones (NIC o Nursing Interventions Classification) y objetivos de enfermería (NOC o Nursing Outcomes Classification).

3) Integración, o acceso rápido, a resultados de laboratorio y radiología.

4) Fármacos recibidos en planta previamente a su ingreso en UCI mediante XML o HL7 indicando principio activo, dosis, horario e inicio (esto idealmente).

5) Se deberían poder incorporar datos de un ingreso anterior reciente en UCI, especialmente cuando el enfermo no ha abandonado el hospital.

Elaboración de informe de ingreso y planificación

Requisitos básicos:

Herramienta para realizar informes de ingreso. Esta herramienta debe ser capaz de generar texto en diferentes formatos y soportar el uso de macros, abreviaturas u otros elementos de ayuda a la escritura. Esta funcionalidad debe ser sencilla de utilizar por los administradores clínicos. En algunos casos, podría ser suplida por las herramientas de informe propias del HIS.

Requisitos opcionales:

Hoja de objetivos diarios.

Prescripción

Prescripción farmacológica. Requisitos básicos:

1) Librería de fármacos fácilmente configurable y ampliable por el administrador clínico de la aplicación.

Requisitos opcionales:

1) Facilidad de edición y cambio de dosis, horario y frecuencia sin tener que prescribir el fármaco de nuevo, aunque dejando una reseña de que se ha producido un cambio a efectos de control clínico.

2) Posibilidad de generar avisos configurables en caso de interacción, o posible efecto secundario, de acuerdo con criterios farmacológicos, clínicos o analíticos.

Prescripción de planes de cuidados, protocolos y guías

Requisitos básicos:

El sistema debe incorporar la posibilidad de programar por un usuario avanzado:

1) Protocolos clínicos de acuerdo con las guías clínicas: por tipo de paciente, incluidas medidas generales, fármacos y valoraciones (escalas).

2) Planes de cuidados de enfermería: individualizados y/o estandarizados, con programación y correspondencia horaria y evaluación de los mismos.

Conexión a sistemas de monitorización

Requisitos básicos:

1) Monitores: idealmente deberían capturar todas las señales de monitorización que el dispositivo pudiera registrar en todos sus canales.

2) Ventiladores: captación de toda la información que el protocolo de comunicación y salida de datos de cada aparato permita.

3) Monitores de gasto cardiaco.

4) Bombas de perfusión: ritmo de goteo.

Requisitos opcionales:

1) Bombas de perfusión: importar librería de fármacos, dosis y volúmenes acumulados.

2) Conexión con máquinas de depuración extrarrenal.

3) Sistemas lectores de código de barras.

4) Discriminación, mediante reglas preestablecidas, de posibles datos anómalos bien por error del dispositivo de monitorización, o bien porque realmente el enfermo presente este valor.

5) Avisos y alarmas de estas desviaciones para su verificación, y ulterior corrección si es preciso.

Modelización del curso de los pacientes. Técnicas y cuidados específicos

Guías y planes de cuidados. Requisitos básicos:

El SIC debería permitir la incorporación de guías clínicas y planes de cuidados, tanto médicos como de enfermería. El sistema debería incorporar la posibilidad de programar protocolos clínicos de acuerdo con guías clínicas según:

i. Tipo de paciente.

ii. Contenidos: medidas generales, fármacos, fluidos y valoraciones (escalas).

Requisitos opcionales:

1) Hoja de objetivos y problemas diarios (a incluir como nota médica y de enfermería editable).

2) Integración relacional entre la planificación de cuidados que realiza la enfermera y la gráfica. Implica la relación interna entre la información que aparece en ambos apartados del registro (gráfica-planes de cuidado).

Avisos y notificaciones (metaalarmas). Requisitos básicos:

El uso de los sistemas de alarma en los SIC es necesario para mantener unos criterios de seguridad y de calidad con el paciente. Con ellos, los profesionales podrían disminuir los eventos adversos más frecuentes.

1) El SIC debería generar avisos de datos anómalos de monitorización.

2) Debería indicar, mediante notificaciones o avisos, la posibilidad de reacciones adversas (alergias) a medicamentos en la prescripción, aunque no sería imprescindible si el HIS cumpliera este requisito en un módulo de prescripción.

Requisitos opcionales:

1) Valores críticos clínicos o de laboratorio en función de las enfermedades.

2) Parámetros (indicadores centinelas) que presenten desviaciones de protocolos, o guías clínicas.

3) Desviaciones sobre indicadores de calidad relevantes.

4) Potenciales efectos adversos en función de información clínica o de laboratorio que modifiquen tratamientos (por ejemplo, suspensión de un antiagregante con trombocitopenia grave).

5) Estas alarmas y avisos, en su versión más sencilla, deberían programarse mediante reglas de programación del tipo «Si… entonces…» incluidas en módulos al efecto.

6) Transmisión de información de alarmas críticas a dispositivos inalámbricos, buscas o teléfonos móviles.

Gráficas. Requisitos básicos:

1) Visualización de enfermos mediante tabla (parrilla de enfermos).

2) El SIC permitirá ver cualesquiera datos clínicos, de laboratorio, y fluidos en formato gráfico y/o tabular.

3) Deberán poderse configurar diferentes tipos de gráficas y sus valores -rangos, disposición, etc.- para diferentes parámetros y tipos de enfermos (por patología o edad).

4) Los fármacos pautados y administrados deberían figurar en las gráficas.

5) Debería poderse configurar tendencias gráficas y tabulares configurables por el usuario.

6) Debe permitir introducir eventos y marcas de tiempo.

Requisitos opcionales:

1) Realización de peticiones desde el sistema o capacidad de enlace al sistema de peticiones del HIS.

2) Todo el tratamiento pautado, así como los cuidados de enfermería, figurarán en la gráfica para poder unir en la misma línea temporal los datos del paciente (monitorización, analíticas, etc.) con la terapia y los cuidados que se le prestan.

3) En la parrilla, configurar un panel de avisos sobre datos anómalos, desviaciones de cuidados (no realización de una valoración), escalas (incremento marcado de una puntuación) y protocolos.

Técnicas. Requisitos básicos:

1) El SIC debería contar con un módulo de técnicas más comunes en UCI.

Requisitos opcionales:

1) En el menú de técnicas posibilidad de incluir fecha de realización y contador diario de duración (por ejemplo, días de inserción de catéter o vía).

2) El sistema informará de cuántas y qué tipo de técnicas realiza un usuario.

Notas clínicas. Requisitos básicos:

1) El SIC debería permitir elaborar notas médicas y de enfermería de acuerdo con plantillas previamente acordadas.

2) La elaboración de estas plantillas debería ser realizada con una herramienta de uso sencillo por un administrador.

Escalas, informes y codificación

Escalas. Requisitos básicos:

1) El sistema debería incluir escalas de gravedad y valoración por órgano, situación (dolor, sedación, riesgo de ulceración, etc.) o proceso patológico (sepsis, traumatismo, pancreatitis, coronario, enfermo posquirúrgico, fracaso multiorgánico, etc.) para facilitar su cálculo y analizar sus resultados. El sistema debería importar datos demográficos y clínicos para completar cálculos.

2) Incluirá escalas de cálculo de cargas de enfermería (TISS, NAS, NEMS).

3) El módulo de programación de escalas debería permitir elaborar escalas propias de la unidad, o las publicadas en el futuro.

4) Este módulo debe ser amigable para un usuario avanzado.

Informes. Requisitos básicos:

1) Disponer de una herramienta de elaboración de informes que permita configurar diferentes formatos (técnicas, procedimientos, alta).

2) Esta herramienta debería ser fácilmente utilizable por un administrador con un mínimo entrenamiento.

3) El SIC debería permitir la exportación de información relevante sobre el ingreso del paciente en UCI al HIS.

Requisitos opcionales:

1) Importación automática de campos del SIC (procedimientos, diagnósticos, fármacos, complicaciones, etc.) a la plantilla de informe exportable.

2) Capacidad de exportación de datos a bases de datos externas mediante formatos específicos (XML, Excel, valores definidos por comas [CVS], etc.).

Codificación. Requisitos básicos:

1) El sistema debería permitir clasificar a los pacientes mediante un conjunto mínimo básico de datos (CMBD) adecuado al entorno de UCI.

2) El sistema deberá permitir la codificación en versiones CIE 9-10 de diagnósticos, procedimientos y complicaciones.

Requisitos opcionales:

Posibilidad de incluir clasificación SNOMED (Systematized Nomenclature of Medicine-Clinical Terms) de diagnósticos, procedimientos, resultados.

 

Enfermería

Para conseguir la operatividad del SIC desde una perspectiva de enfermería en cuidados intensivos son necesarios que estos cuenten con requisitos esenciales para adecuar la actividad que se lleve a cabo. Específicamente en enfermería el SIC debería incluir herramientas para la planificación de cuidados, que proporcionen informes de actividad sobre los mismos. Estas, preferentemente, deben utilizar estándares metodológicos basados en taxonomía validada (lenguaje NANDA, NIC y NOC), y en la manera en que se estructura o presenta la información (criterios de relación). Además, las aplicaciones deben permitir la codificación nueva o autónoma, lo que posibilita el desarrollo profesional, y el trabajo con procedimientos de enfermería y los oportunos informes de indicadores (tabla 5).

 

Datos y seguridad

Análisis de datos

Los requisitos de estos apartados se resumen en la tabla 5.

Requisitos básicos:

1) Todo SIC que se instale en un servicio de medicina intensiva, debe disponer de una herramienta que permita realizar búsquedas y análisis de los datos registrados en su repositorio.

2) Si esta herramienta no está incluida en el paquete del SIC, el proveedor puede ofertar realizar la tarea de gestión de datos con una aplicación externa, pero validada para el citado sistema e instalada por el proveedor, previa oferta.

3) Con estas herramientas los SIC elaborarán informes sobre las variables que conforman el propio cuadro de mandos de la unidad. Además generarán búsquedas para trabajos de investigación o informes de actividad de determinados grupos de usuarios.

Requisitos opcionales:

1) Los SIC generarán informes estadísticos sobre eventos e indicadores relevantes en la actividad de la UCI.

2) Almacenamiento, explotación y gestión de datos en bases de datos tipo Data Warehouse, bien propia, bien integrada en el HIS, a la que el SIC envía la información. Esta base de datos se define por las siguientes características:

a) Orientada a temas. Los datos están organizados de manera que todos los datos relativos al mismo evento u objeto del mundo real (por ejemplo, un indicador clínico) queden unidos entre sí.

b) Variable en el tiempo. Los cambios temporales en los datos son registrados para que los futuros informes reflejen esas variaciones.

c) No volátil. La información no se modifica ni se elimina, una vez almacenado un dato, este se convierte en información de solo lectura, y se mantiene para futuras consultas.

d) Integrado. La base de datos comprende todos los datos introducidos en el SIC para cada paciente, tanto los importados (demográficos, CMBD, de monitorización), como los de entrada manual (códigos, escalas, técnicas). El Data Warehouse del SIC puede relacionarse con la base de datos (Data Warehouse, o no, del HIS) para consultas específicas sobre temas de costes u otros.

Las ventajas de este tipo de bases de datos son un mejor y más fácil acceso a los datos por los usuarios finales, una ayuda importante a la toma de decisiones, basada en información integrada y consistente sobre indicadores piloto, generar tendencias y relaciones ocultas entre datos para idear hipótesis clínicas o de gestión que permitan comprender errores pasados y predecir el futuro según los escenarios. Su principal desventaja es el alto coste, aunque su adecuada explotación y diseño pueda generar un retorno de inversión importante.

3) Para apoyar la gestión clínica, con este tipo u otro de base de datos, se ha contar con las siguientes capacidades:

i. Extracción de la información relevante, transformación y limpieza de datos.

ii. Almacenamiento de datos de la información en bruto y agregada que pueda ser explotada.

iii. Generación del modelo de datos más adecuado a la explotación que se quiera realizar y que deberá ser definido e implantado previamente.

iv. Elaboración y presentación de la información en forma de cuadros de mando que contengan tablas, indicadores y gráficos que presenten aspectos clave del sistema en su conjunto, con definición de alarmas y basados en una estructura navegable.

v. Generación de las estadísticas necesarias para el seguimiento de la actividad.

vi. Extrapolación de datos e identificación de incidencias.

Seguridad del sistema

Control de acceso

Requisitos básicos:

1) Todos los sistemas deben tener al menos identificación del usuario mediante nombre y contraseña con fecha de expiración.

2) Es recomendable que se disponga de un subsistema que asegure la fortaleza de la contraseña.

3) El acceso al sistema debe ser configurable mediante niveles de acceso o permisos, dadas las diferentes funciones a realizar por los estamentos que componen el equipo asistencial de UCI. Concretamente, en enfermería, si se le faculta para prescribir fármacos (circunstancia habitual en el entorno de UCI) tiene que contemplarse la posibilidad de prescripción de tratamiento farmacológico regulado en Ley 28/2009 13.

Requisitos opcionales:

1) Registro de accesos fallidos, así como un bloqueo de acceso a la aplicación tras repetidos intentos sin éxito.

2) Autentificar el acceso a estos sistemas no solo por medio de nombre (login) y contraseña (password), sino con el uso de PKI (Personal Key Identifier).

Aplicación

Requisitos básicos:

1) Es necesario un sistema de bloqueo para puertas traseras (acceso a la aplicación o a sus bases de datos de forma alternativa a la que exige un nombre de usuario y su correspondiente contraseña) u otras formas de intrusismo.

2) Asegurar la confidencialidad de los datos durante el mantenimiento técnico o verificación del sistema por personal técnico.

3) Asegurar que solo los clínicos administradores de los sistemas puedan realizar actualizaciones o mantenimiento de las bases de datos.

Requisitos opcionales:

Encriptación de datos, sin implicar nunca una limitación a la explotación de los mismos.

Acceso remoto

Requisitos básicos:

Por medio de redes privadas virtuales o entorno web. La seguridad de estas redes debe ser comprobada y su acceso realizado mediante contraseñas de alta fortaleza.

Auditorías

Requisitos básicos:

Los SIC deben generar informes (auditorías) sobre los usuarios, indicando el tiempo y el tipo de actividad. Y también sobre cambios de contraseña e intentos fallidos de acceso a la aplicación, denegación de servicios o campos críticos que hayan sido editados.

Base de datos

Requisitos básicos:

Los controles que se aplicarán para acceder a la base de datos pueden variar desde la validación de usuario y contraseña (pero limitando la posibilidad del borrado de los datos), hasta otorgar distintos niveles (permisos) de acceso a la herramienta de explotación de datos (solo lectura, etc.).

 

Conflicto de intereses

El Dr. Vicente Gómez Tello ha sido invitado a 2 reuniones organizadas por Dräger Medical sin recibir remuneración por ello.

El Dr. Joaquín Álvarez Rodríguez ha sido ponente invitado a diversas reuniones organizadas por PICIS, y pertenece al Advisory Board de PICIS sin recibir remuneración por ninguno de estos conceptos.

El Dr. Pedro Morrondo ha sido invitado a una reunión europea de usuarios de Centricity™ (General Electric) sin recibir remuneración por ello.

El Dr. José María Nicolás ha sido invitado a varias reuniones organizadas por Dräger Medical sin recibir remuneración por ello.

Dra. María Calvete Chicharro ha sido colaboradora clínica remunerada por IMD Soft hasta el año 2010.

El resto de autores declara no tener ningún conflicto de intereses.

 

Agradecimientos

Los autores quieren destacar el apoyo organizativo y económico de la SEMICYUC, agradeciendo especialmente al ex presidente de su Comité Científico, el Dr. José Ángel Lorente Balanza, y al Dr. Cristobal León, anterior presidente de la Sociedad, su indispensable ayuda y estímulo para la realización de este proyecto.

Asimismo, los autores agradecen la decidida colaboración y apoyo de sus asesores pertenecientes a la Industria.

Ignacio Rodríguez. Jefe de producto de Innovian Drager Medical.

Luis Cuevas Sempere. Responsable de Sistemas de Información Clínicos, Cardiología y Cuidados Críticos de Philips Healthcare.

Juan José Rubio. Director de sinapsis.healthcare y ex distribuidor de MetaVision.

Beatriz Domínguez. Responsable de Sistemas de Información Clínicos de GE Healthcare.

Alan Suárez. Client Manager de PICIS.

 

Bibliografía

1. Jha AK, DesRoches CM, Campbell EG, Donelan K, Rao SR, Ferris TG, et al. Use of electronic health records in U.S. hospitals. N Engl J Med. 2009; 360:1628-38.         [ Links ]

2. Chaudhry B, Wang J, Wu S, Maglione M, Mojica W, Roth E, et al. Systematic review: impact of health information technology on quality, efficiency, and costs of medical care. Ann Intern Med. 2006; 144:742-52.         [ Links ]

3. Bates DW, Gawande AA. Improving safety with information technology. N Engl J Med. 2003; 348:2526-34.         [ Links ]

4. Manor-Shulman O, Beyene J, Frndova H, Parshuram CS. Quantifying the volume of documented clinical information in critical illness. J Crit Care. 2008; 23:245-50.         [ Links ]

5. Carrasco G, Pallares A, Cabre L. Cost of quality in Intensive Medicine. Guidelines for clinical management. Med Intensiva. 2006; 30:167-79.         [ Links ]

6. Lapinsky SE, Holt D, Hallett D, Abdolell M, Adhikari NK. Survey of information technology in Intensive Care Units in Ontario, Canada. BMC Med Inform Decis Mak. 2008; 8:5.         [ Links ]

7. Western MC, Dwan KM, Western JS, Makkai T, Del Mar C. Computerisation in Australian general practice. Aust Fam Physician. 2003; 32:180-5.         [ Links ]

8. Cheng CH, Goldstein MK, Geller E, Levitt RE. The Effects of CPOE on ICU workflow: an observational study. AMIA Annu Symp Proc. 2003; 150-4.         [ Links ]

9. Han YY, Carcillo JA, Venkataraman ST, Clark RS, Watson RS, Nguyen TC, et al. Unexpected increased mortality after implementation of a commercially sold computerized physician order entry system. Pediatrics. 2005; 116:1506-12.         [ Links ]

10. Donati A, Gabbanelli V, Pantanetti S, Carletti P, Principi T, Marini B, et al. The impact of a clinical information system in an intensive care unit. J Clin Monit Comput. 2008; 22:31-6.         [ Links ]

11. Cingolani ENG, Giattino M, Orazi D, Freni C. Patients information management systems may bring to a significant reduction in medication errors. Abstracts of the 21th Annual Congress of European Society of Intensive Care Medicine. Intens Care Med. 2008; 34 Suppl 1:S199.         [ Links ]

12. Colpaert K, Claus B, Somers A, Vandewoude K, Robays H, Decruyenaere J. Impact of computerized physician order entry on medication prescription errors in the intensive care unit: a controlled cross-sectional trial. Crit Care. 2006; 10:R21.         [ Links ]

13. Garland A. Improving the ICU: part 2. Chest. 2005; 127:2165-79.         [ Links ]

14. Ahmed A, Chandra S, Herasevich V, Gajic O, Pickering BW. The effect of two different electronic health record user interfaces on intensive care provider task load, errors of cognition, and performance. Crit Care Med. 2011; 39:1626-34.         [ Links ]

15. Department of Critical Care Medicine (Adult Intensive Care Units) DoPPIC. Request for proposals Critical Care Clinical Information System Calgary Health Region. 2007 [consultado 13 Feb 2011]. Disponible en: http://www.calgaryhealthregion.ca/ccm/rfp_sept_6_07.pdf.         [ Links ]

 

 

Dirección para correspondencia:
Correos electrónicos: vgomezte@hospitalmoncloa.es,
vgtello@gmail.com
(V. Gómez Tello).

Recibido el 26 de junio de 2011
Aceptado el 7 de julio de 2011