SciELO - Scientific Electronic Library Online

 
vol.11 número10Validez de los métodos diagnósticos para la detección de vasculopatía periférica en diabéticos tipo-2La mediación familiar: una intervención para abordar la ruptura de pareja índice de autoresíndice de materiabúsqueda de artículos
Home Pagelista alfabética de revistas  

Medifam

versión impresa ISSN 1131-5768

Medifam vol.11 no.10  dic. 2001

 

HABLEMOS DE ...

Sistemas de información

Desarrollo informático de los niveles de integración de información entre

 diferentes unidades de provisión desde una perspectiva de Atención Primaria 

F.A. Alonso López, J. Custodi i Canosa*

Especialista en Medicina Familiar y Comunitaria. Doctor en Medicina y Cirugía. 

*Especialista en Medicina Familiar y Comunitaria. Subdirección General de Atención Primaria. INSALUD. Madrid

 


RESUMEN 

La informatización de la historia clínica es una realidad en Atención Primaria. En la medida en que mayor número de centros y personas disponen de registros informatizados, resulta una necesidad cada vez más acuciante el intercambio de información clínica entre distintos centros, ya sea entre centros de salud, entre éstos y hospitales, consultorios periféricos o unidades de apoyo. Esta necesidad viene determinada básicamente por garantizar la continuidad de la atención y la comunicación entre profesionales, habitualmente entre sistemas informáticos distintos. 
En este artículo se describen cuatro niveles posibles de intercambio de información y se aportan soluciones técnicamente sencillas y factibles de poner en práctica partiendo de unas mínimas condiciones: la propia existencia de registros informatizados, la existencia de una red de comunicaciones (tipo Intranet o Internet) y un identificador común, el código de identificación personal de la Tarjeta Sanitaria. Ésta se convierte así en un elemento clave y estratégico de primer orden para el Sistema Nacional de Salud (SNS) cuya integridad habría que salvaguardar ante las futuras transferencias del INSALUD a las Comunidades Autónomas y a ser posible avanzar hacia una tarjeta sanitaria para todo el SNS, ya sea única o habilitando mecanismos que hagan compatibles las actuales. 

Palabras clave: Tecnología de la información y comunicación. Informatización. Historia clínica electrónica. Internet. 

Computing development of information integration levels between different provision 
units from the Primary Health Care perspective 

ABSTRACT 

Medical records are already computerized in primary health care. Insofar as electronic medical records are increasingly available to more centers and staff, the exchange of clinical information between different centers becomes an even more urgent need, either between health centers, or between health centers and hospitals, peripheral outpatient departments or support units. The main goal is to ensure the continuity of health care and the communication between professionals, most of which are using different computing systems. 
This paper describes four possible levels of information exchange and suggests technically easy and feasible solutions provided some minimum conditions are met: existence of electronic medical records, existence of a communications network (such as Intranet or Internet) and a common identifier: the individual identification code of the Health Card. Consequently, this card becomes a key and major strategic element of the National Health System (SNS), whose integrity should be safeguarded in the face of the future transfers of the Insalud to the Autonomous Communities and, if possible, progress should be made towards a health card for all the SNS, either through a unique card or through mechanisms for making compatible the ones that are currently in use. 

Key words: Information and comunication technology. Computerisation. Electronic medical records. Internet.


INTRODUCCIÓN 

La informatización de los registros clínicos e implantación de distintos sistemas de información de Centros de Salud y Hospitales en nuestro país, es una realidad institucionalizada y creciente para muchas administraciones sanitarias. 
Si bien las posiciones estratégicas de los diferentes responsables pueden no coincidir, no deja de ser un hecho cierto que su planteamiento final declarado no trata, en general, de construir Sistemas de Información estancos. 
Antes bien, el enfoque que presentan hacia el exterior enfatiza que las soluciones deben aportar, para el sistema sanitario y para el ciudadano como sujeto último de la prestación, la garantía de que la información sanitaria se encuentre disponible donde, cuando y por quien la precise. 
De todas formas, y con ser esta necesidad de tremenda importancia, conviene no olvidar que más del 90% de los contactos con el sistema sanitario no precisan información externa para su solución y, en el caso concreto de la Atención Primaria, más del 95% de la información es útil únicamente en el punto en que se genera, por lo que su trasiego sólo conduce a potenciales fugas de seguridad e innecesarios incrementos de coste. 
Pretendemos, a través de este artículo, plantear un esquema de desarrollo de integración de información, posibilista, basado en modelos ya probados total o parcialmente en diferentes países que de una u otra forma nos han precedido en este camino, y de cuyas experiencias sería preciso extraer consecuencias. 

NIVELES DE INTEGRACIÓN DE INFORMACIÓN SANITARIA 

El desarrollo de Redes Corporativas de Comunicación, que permitan que bases de datos distribuidas se comporten en realidad como si físicamente se encontrasen en un único punto, es la premisa necesaria para posibilitar la integración. 
El paradigma de este hecho es la red de Internet, en la que diferentes bases de información descentralizada, repartidas por todo el mundo, se comportan de cara al usuario como una base única, argumento que por sí mismo ya prueba la posibilidad de manejo integrado de datos descentralizados en todos los órdenes del conocimiento. 
Conviene resaltar en este punto que la conexión es un hecho físico, mientras que la comunicación es una actitud intelectual. De nada vale poseer redes de comunicación si no inculcamos o facilitamos a los profesionales las actitudes y mecanismos necesarios para que las conexiones trasladen contenido cualitativamente correcto. 
El esquema que se presenta no ha de ser entendido como algo rígido y necesariamente escalonado, sino que su implementación ha de ser posibilista y adaptada a la realidad ya existente en cada una de las diferentes Zonas/Áreas de Salud de forma que, en muchos casos, será factible implementar soluciones avanzadas aún antes que otras aparentemente más sencillas, cuestión que ha de estar siempre supeditada al entorno de campo en el que nos movemos. 
Por otra parte, para no dispersar el argumento central del documento, orientado más hacia los aspectos estratégicos que a su desarrollo operativo, se obvia tratar en profundidad ciertos aspectos del proceso como circuitos específicos, elementos de seguridad y confidencialidad que, en cualquier caso, pueden consultarse en varias de las referencias bibliográficas aportadas. 

Nivel 1: Interconsulta (PIC) (Fig. 1

Consiste básicamente en peticiones activas de información y respuestas a las mismas entre proveedores de servicios que se conocen, mantienen una relación habitual y están localizados en ubicaciones diferentes. 
El ejemplo típico lo constituye la circulación del Parte de Interconsulta entre Atención Primaria (AP) y Atención Especializada (AE), ya en funcionamiento en diferentes Centros y asociada a la gestión integrada de citas. 
Dado que el destino es conocido a priori en la propia configuración del sistema, el "direccionamiento" (determinación de la dirección en la que viaja la información) no precisa de información adicional de bases externas y, por tanto, es en teoría el nivel más sencillo de implementar. 
En un primer momento el formato transferido puede ser estándar, así es en la actualidad entre los Centros que lo tienen en funcionamiento, donde los informes viajan con información textual encriptada asociada al proceso de gestión de agendas. Dado que dichas acciones se producen contra una demanda concreta de información "motivo de consulta", la configuración de la información aportada y devuelta podría ser definible en cada situación, constituyendo éste un momento idóneo para la inclusión de elementos anejos a la petición o a la respuesta (fotografía digital, imágenes radiológicas, vídeo, etc.). 

 



Nivel 2: Resumen Estructurado de Información Sanitaria (REIS) (Fig. 2

A diferencia del caso anterior, no existe una relación estable y predefinida entre el origen o destino de la información. Precisa por tanto direccionamiento externo, fácilmente construible a través de las tablas asociadas a los códigos de asistencia de la Tarjeta Sanitaria Individual. 
Para ilustrarlo, pongamos el caso de dos centros de salud remotos, el cabecera donde es atendido habitualmente el paciente y un segundo centro donde es atendido ocasionalmente. Este último puede requerir información clínica del paciente ubicada en el primero y a su vez informarle de las actuaciones que ha llevado a cabo. En este caso los dos centros no están conectados de forma estable e incluso pueden no conocerse. Es necesario por tanto un identificador que permita a través de él poner en contacto los dos puntos. 

La vinculación al Código de Identificación del Paciente (CIP), de la Tarjeta Sanitaria Individual (TSI), de un número de historia único por paciente para todo el Estado, secuencial, irrepetible, no calculable, e incluso desconocido para el operador, favorecería el desarrollo de seguimientos anónimos integrados, independientes de la Administración emisora de su tarjeta, y la construcción del Conjunto Mínimo Básico de Datos (CMBD) del paciente con clara trascendencia epidemiológica e investigadora. 
Esta cuestión, clave en un país que persigue el mantenimiento de unas prestaciones comunes en un entorno transferido a Comunidades Autónomas, provocará un retraso de años si no es abordada con amplitud de miras, y consensuado por parte de las autoridades políticas. 
Se propone, por tanto, la identificación del nivel de informatización de los registros clínicos del paciente, asociando al CIP un código que especifique este nivel: no informatización; Informatización de registros administrativos; Informatización Clínica. Estos valores son los que informarán de la existencia de información traspasable y su tipo (Clínica o Admistrativa). 

La información, en este caso, viajaría encriptada y se encadenaría en la gestión de actividades pendientes y en el propio curso descriptivo del registro solicitante, dejando a su vez constancia de la solicitud en el emisor. 
Es factible con este tipo de diseño, prácticamente sin coste y sin necesidad de herramientas específicas para su manejo (utilizando los populares "navegadores" de Internet), la creación de una Historia Electrónica Virtual Autocompuesta (HEVA) para su transmisión hacia servidores seguros. Este tipo de historia, a modo de página web, puede ser recreada on-line por el clínico que recaba la información y, desde allí, ser incorporada en sus registros, si los posee, o simplemente utilizada como elemento de consulta, actualización o respuesta, mediante protocolos específicos. 
Los ejemplos típicos de este nivel son la demanda de información de un paciente para su atención en Servicios de Urgencia o de un paciente desplazado, y la entrega automatizada de informes de alta desde un Servicio (Urgencias, Consultas Externas, etc.) o Unidad de Hospitalización. 

 



Nivel 3: Información Sanitaria Compartida (ISC) 

El nivel de dificultad viene dado por la posibilidad de integrar datos aportados desde uno u otro nivel, como información que actualiza campos de modo automático en el interior del registro de proceso clínico de uno o ambos interlocutores. La integración de los datos puede ser parcial en un inicio (pasando por diferentes estadios) o "completa" en función de la evolución del sistema. Esta integración dependerá en buena parte del uso de estándares de modelos de información, de terminología, clasificaciones y de niveles de seguridad, así como de la progresiva implantación de sistemas intermedios de integración (middleware), la definición de interfaces de comunicación y mensajería con formatos normalizados.
La necesidad, o no, de direccionamiento externo vendrá dada por el tipo de proveedor que vehicule la demanda o envío, de forma que en algunos casos, por ser éste conocido a priori (laboratorio,...), será innecesario. 

Existen una serie de ejemplos típicos que condicionan diferentes necesidades de desarrollo para este nivel: 
A. Laboratorio: esta posibilidad ya está en la actualidad funcionante entre diversos Centros de Salud y sus laboratorios de referencia. Consiste en la eliminación del papel en el circuito de la analítica y, en el caso más eficiente, la petición desde el gestor de órdenes del aplicativo clínico, y la incorporación al completo de los resultados como información (no como dato) en el registro clínico del solicitante. Estadios intermedios, cuya eficiencia es claramente menor, consisten en la eliminación del papel manteniendo la petición en un gestor externo a la historia (lo que a un Centro de Salud con informatización del proceso clínico le supone teclear dos veces la petición y teclear los resultados si quiere poseer éstos como información), y la recepción vía web de resultados para su consulta pero no integrados como información (sólo como dato) en la historia solicitante. 

B. Unidades de Apoyo: la existencia de Unidades de Apoyo a la Atención Primaria (UAAP), con diferente grado de integración geográfica y física en los EAPs, precisa del desarrollo ocasional de elementos de aplicación específicos para este fin. En efecto, no tiene las mismas necesidades una matrona o un asistente social que, en general, se desplaza fisicamente por la mayoría de los Centros, que un odontoestomatólogo que atiende a los niños de varias zonas en un único centro, o incluso que un Equipo de Apoyo de Atención Domiciliaria que, en más de una ocasión, no se localiza ni siquiera en edificios de atención sanitaria directa. 

Las soluciones, por dicho motivo, pueden tener que matizarse en cuanto a la forma de acceso a la información, pero es evidente que son necesarias dos cosas: 
1. Que el nivel de EAP, y por ende cualquiera que recupere la historia a través de él, conozca las actuaciones que estos profesionales han llevado a cabo sobre sus pacientes y, por tanto, que éstas queden reflejadas en el historial de los mismos. 

2. Que estos profesionales, si físicamente no comparten ubicación, puedan obtener la situación del historial de los pacientes atendidos para una correcta prestación. 
La solución inicial, más sencilla y acaso eficiente con las salvaguardas precisas, es la consideración de las UAAP como un proveedor interno más de la Unidad y el trabajo mediante herramientas remotas como las ya implementadas para la conexión de Consultorios rurales a sus Centros de Salud cabecera (arquitectura cliente servidor a través de líneas RDSI o Frame Relay). Esta solución plantea dos problemas principales: por un lado la complejidad de interconexiones entre distintas redes locales de zonas básicas de salud y acceso a tiempo real, y por otro lado la dificultad para el trabajo de investigación y evaluación de ese tipo de Unidades cuya información se encontrará dispersa en el interior de cada una de las bases de datos locales (que obligará o bien al diseño de herramientas específicas para su recolección automatizada, o bien la intervención de un recurso humano en el proceso). La solución de historia electrónica virtual autocompuesta, también sería aplicable en este nivel mediante el desarrollo de protocolos estándar de respuesta que posteriormente puedan incorporar los datos en el registro real.

La solución avanzada a implementar pasa por el desarrollo de un módulo de trabajo que haga innecesaria la conexión directa a tiempo real sobre el registro, permitiendo el traspaso bidireccional de la información de ese paciente concreto, tanto hacia la base de datos del médico de cabecera, una vez efectuada la actuación, como hacia la base de datos operativa de la Unidad de Apoyo (Fig. 3). La base de datos del Centro estaría actualizada con las actuaciones realizadas sobre sus pacientes (tanto por el EAP como remotamente por la Unidad de Apoyo) y, de otro lado, la base de datos de la Unidad de Apoyo contaría con la información completa de su actividad y pacientes atendidos. 

 



C. Otros niveles, o entornos, de Atención: el desarrollo de la solución avanzada para las Unidades de Apoyo prácticamente es aplicable al 100% al referirnos a otros Niveles de Atención, no siendo en este caso deseable que en éstos se implemente la solución de conexión directa a las bases, pareciendo más adecuado decantarse desde el principio por las conexiones a través de historia virtual o la solución de integración avanzada. La dificultad principal viene dada por la posible existencia de múltiples plataformas y campos no compatibles que precisarían profundizar en los conceptos de Información No Redundante (INR) -aquélla que registrada en un único punto del proceso está disponible desde todos los que la precisen- y su definición para el conjunto del Sistema que, en buena lógica, debería contemplar los diferentes estándares internacionales sobre conectividad y contenido de la información transmisible (como los derivados del estándar HL-7, o del grupo de trabajo europeo CEN/TC 251). Básicamente, con la solución avanzada, la información tipo INR de historia clínica de AP se incorporaría a los registros de base de datos del solicitante, y a su vez éste retroinformaría al remisor que dicha información ha sido requerida y por quién. 

Nivel 4: Traspaso General de Informacion Sanitaria (TGIS) 

Debería poder implementarse esta solución para aquellos casos en que se produzca cambio de residencia del paciente que implique cambio de Zona de Salud y, por tanto, de proveedor responsable de la atención -cambio de médico de cabecera-, y también en aquellos casos en que, produciéndose el cambio dentro de la misma zona, el profesional no contase con puesto de trabajo clínico informatizado. 
El disparo de la actividad podría automatizarse a través de una orden específica mediada a través de la base de datos de TSI, y la información traspasada sería en principio la misma que en el caso de la solución avanzada del nivel 3. En una segunda fase sería preciso estructurar la información de la historia clínica a través de planes o protocolos de seguimiento consensuados de tal forma que a partir de la unificación de pautas de actuación fuera posible continuar con la misma estructura la historia clínica iniciada en el centro de origen (Fig. 4). 

 



Es conveniente sin embargo resaltar que, en gran parte de los casos, esta opción es poco operativa, tanto por la información enviada - los árboles no dejan ver el bosque - como por la costumbre organizativa propia de los profesionales que, en general, construyen la historia clínica en la forma que les aporte la mayor comodidad en su práctica diaria. Por esta razón, en la transmisión habitual de historias, podría ser pertinente comenzar enviando de forma automatizada una HEVA, cuyo volumen de transmisión es pequeño y, en función de su contenido, dejar a criterio del profesional solicitar o no la información de historia completa, o partes específicas de la misma como laboratorio, prescripciones, alergias, episodios, última visita, protocolos, o cualquier otro tipo de combinación, mediante ordenes específicas. 
Si el traspaso se realiza hacia un profesional sin informatización clínica, el formato de la información sería estructurado en modo texto para su impresión e incorporación a su historial habitual, bien a través de las soluciones de historia virtual que ya estuviesen presentes en el Centro destino, o bien a través de los tradicionales circuitos de remisión de historias en papel. 

CONCLUSIONES 

La movilidad de los ciudadanos, la necesidad de garantizar la continuidad de la atención, tanto entre niveles como fuera del lugar de residencia habitual de las personas, justifica diseñar sistemas de comunicación que hagan factible el trasvase de información clínica de manera segura y rápida. Aunque se está avanzando en la normalización de los sistemas informáticos de manera que sea posible esta comunicación (modelos de datos comunes, terminologías y clasificaciones compatibles, normas de seguridad y confidencialidad, tecnología de la interoperatividad), es factible en este momento poner en marcha, aprovechando las infraestructuras actuales, modelos de trasvase de la información que cubran perfectamente las necesidades actuales. 
La Tarjeta Sanitaria Individual, es el elemento clave para posibilitar los modelos expuestos de intercambio de información o cualesquiera otros. El Código de Identificación Personal de la TSI es el que posibilita la comunicación e integración de la información, como identificador único dentro del SNS, al permitir generar y mantener una tabla con los accesos a las distintas ubicaciones de la información clínica. Es por tanto imprescindible evitar la fragmentación de las bases actuales y avanzar hacia una unificación o coordinación de las existentes. De no ser así, se perderá una oportunidad histórica difícilmente repetible. 


CORRESPONDENCIA: 

Fernando Alonso López 
Dirección General del INSALUD 
C/ Alcalá, 56, despacho 602 
28014 Madrid 
E-mail: alfa58@nexo.es 

 

Bibliografía recomendada 

1. Alonso López FA, coordinador. Informatización en la Atención Primaria. Documento semFYC nº 13. Barcelona: Sociedad Española de Medicina Familiar y Comunitaria, 1999.          [ Links ]

2. Directiva 95/46/CE del Parlamento Europeo y del Consejo, de 24 de octubre de 1995, relativa a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos. Diario Oficial n° L281 de 23 de noviembre 1995; 31-50.          [ Links ]

3. Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal. BOE de 14 de diciembre 1999; 43088-99.          [ Links ]

4. California Healthcare Foundation. Promoting Health. Protecting Privacy: A Primer. Los Angeles: California Healthcare Foundation and Consumers Union, 1999.         [ Links ]

5. Kibbe D, Bard MR. How safe are Computerized Patient records? Family Practice Management 1997; 4: 5.          [ Links ]

6. Rehms S, Kraft S. Electronic Medical Records: The FPM Vendor Survey. Family Practice Management 2001; 8: 45-54.          [ Links ]

7. Burton Community: Pilot Electronic Health Record 1998-1999, Final Overview Report. http://www.schin.ncl.ac.uk/ mig/burton.pdf (documento íntegro en internet).          [ Links ]

8. Good Practice Guidelines for General Practice Electronic Patient Records. The Joint Computing Group of the General Practitioners' Comittee and the Royal College of General Practitioners. Londres: The NHS Executive General and Personal Medical Services Branch, 2000.          [ Links ]

9. Goh A, Kum YL, Mak SY, Ouek YT. An XML-Java system for HL7-based healthcare informatics. Stud Health Technol Inform 2000; 77: 1051-5.          [ Links ]

10. Klimczak JC, Witten DM 2nd, Ruiz M, Mitchell JA, Brilhart JG, Frankenberger ML. Providing location-independent access to patient clinical narratives using Web browsers and a tiered server approach. Proc AMIA Annu Fall Symp 1996; 623-7.          [ Links ]

11. Proyecto Europeo C-CARE. Disponible en Internet: http://www.telepolis.be/c-care.          [ Links ]

12. CEN/TC 251. European Standardization of Health Informatics. Disponible en internet: http://www.centc251.org.          [ Links ]

13. Monteagudo Peña JL. La estandarización en Tecnologías de la Información y las Comunicaciones para Sanidad. Disponible en internet: http://www.isciii.es/unidad/DG/API/capi.html.
        [ Links ]

Creative Commons License Todo el contenido de esta revista, excepto dónde está identificado, está bajo una Licencia Creative Commons