Modelo de Integracin

Modelo de Integracin de la Gerencia Regional de Salud de la Junta de Castilla y Len

Versin 1.6 05/0210/2009

Junta de Castilla y Len Consejera de Sanidad

Coordinacin: Direccin Tcnica de Tecnologas de la Informacin Direccin General De Desarrollo Sanitario Impresin: Imprenta Garca (vila)

Derechos reservados: El material presentado en este documento puede ser distribuido, copiado y exhibido por terceros siempre y cuando se haga una referencia especfica a este material, y no se obtenga ningn beneficio comercial del mismo. Cualquier material basado en este documento deber contener la referencia Guas de Integracin de la Gerencia Regional de Salud , Direccin Tcnica de Tecnologas de la Informacin, Direccin o General De Desarrollo Sanitario, Junta de Castilla y Len Descripcin completa de la licencia: http://creativecommons.org/licenses/by-nc/2.5/es/legalcode.es

2 / 33

1. 2. 3. 4. 5.

INTRODUCCIN. ............................................................................................................................. 5 PLAN DE LA HISTORIA CLNICA ELECTRNICA. ................................................................................ 5 ESCENARIO DE INTEGRACIN. ........................................................................................................ 6 ESTRATEGIA DE INTEGRACIN. ....................................................................................................... 7 ARQUITECTURA DE LA HCE. ............................................................................................................ 8 5.1. ESTRATEGIA EN CENTROS HOSPITALARIOS. .................................................................................. 10

6.

GUAS DE INTEGRACIN. .............................................................................................................. 15 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 6.8. 6.9. 6.10. GESTIN DE PACIENTES. ....................................................................................................................... 15 GESTIN DE AGENDAS Y LISTAS DE ESPERA. ............................................................................................. 17 GESTIN DE PETICIONES RESULTADOS DE PRUEBAS ANALTICAS. ............................................................... 19 GESTIN DE PRUEBAS DE DIAGNSTICO POR IMAGEN. .............................................................................. 20 GESTIN DE BANCO DE SANGRE. ........................................................................................................... 21 GESTIN DE DIETAS. ............................................................................................................................ 22 GESTIN DE FARMACIA HOSPITALARIA. ................................................................................................... 23 GESTIN BASE DE DATOS POBLACIONAL ................................................................................................. 28 DOCUMENTO CLNICO (CDA) ............................................................................................................... 29 GESTIN DOCUMENTAL ................................................................................................................... 29

3 / 33

4 / 33

1. INTRODUCCIN.
El conjunto de documentos conocidos como "Guas de Mensajera" desarrollados en la Gerencia Regional de Salud (SACYL) de la Junta de Castilla y Len, y publicados durante el primer trimestre de 2008, representan un importante hito dentro de la estrategia para la consecucin de la Historia Clnica Electrnica (HCE) de la comunidad. En este documento se describen las lneas generales de la citada estrategia y de un modo particular lo referido a los aspectos de integracin entre aplicaciones sanitarias.

2. PLAN DE LA HISTORIA CLNICA ELECTRNICA.

Desde SACYL, se concibe la HCE no como un objetivo sino como una consecuencia de la mejora continua del sistema de salud en la bsqueda por ofrecer la mejor atencin posible a los ciudadanos. Este proceso de mejora continua, aplicado a los sistemas de informacin sanitarios, se esboza a travs de los siguientes hitos dentro de un ciclo continuo: Realizar un anlisis de la situacin actual, definiendo un Plan de Sistemas en base a los resultados del estudio. Siguiendo las conclusiones del Plan de Sistemas, se escoger una solucin de interoperabilidad plasmada en un conjunto de requisitos a cumplir por cada nueva aplicacin que se incorpore al entorno. En base a la solucin de interoperabilidad escogida, se realizar un diseo de la arquitectura en la que vaya a ser desplegada, y se proveer de los recursos necesarios para que dicha solucin sea operativa (comunicaciones, registros, repositorios, seguridad, etc.). Partiendo de las decisiones alcanzadas en los puntos anteriores, desde SACYL se definirn todas las especificaciones y requisitos, as como herramientas de apoyo que aseguren que las nuevas soluciones puedan adaptarse a la arquitectura de interoperabilidad. Los sistemas heredados sern aadidos a esta arquitectura paulatinamente. Por ltimo, todo el conjunto de decisiones estar sometido a una constante revisin a medida que la experiencia de implantacin exija replantear ciertas soluciones.

5 / 33

3. ESCENARIO DE INTEGRACIN.
Si bien los sistemas de informacin implantados dentro del entorno sanitario suelen ofrecer cierto nivel de integracin, sta suele ser a travs de acceso directo a los recursos (como por ejemplo a la base de datos), o a travs de soluciones especficas. No es posible generalizar, ya que esta situacin vara dependiendo del entorno: por ejemplo, los sistemas de imagen diagnstica y laboratorio suelen incorporar interfaces claramente definidas, mientras que en el resto esta situacin es menos habitual.

Esta situacin es producto de la gran dificultad de encontrar modelos de integracin comunes: el elevado nmero de especialidades y lo especfico de cada una de estas confieren a la gestin de la informacin correspondiente a las mismas un tratamiento concreto y muy diferenciado entre cada mbito.

Con respecto a la comunicacin hacia el exterior, bien sea con otros centros hospitalarios del mismo mbito geo-territorial, bien hacia centros de distinto mbito, o hacia proveedores externos, tambin se sufre una grave carencia de especificaciones que garanticen una homogeneidad tanto en el protocolo de comunicacin como en el tipo de soporte o el sistema de intercambio de la informacin.

Debido a esta situacin se acaba obteniendo un escenario con aplicaciones poco integradas, con procesos dbilmente automatizados en los que es necesario reingresar los datos manualmente varias veces. Las consecuencias son una elevada dispersin de datos, un alto ndice de duplicacin de informacin y un complejo y lento sistema de consulta de datos correspondientes al paciente debido a la prctica inexistencia de una historia clnica homognea y centralizada. Se produce entonces una falta de visin global de los datos clnicos de cada paciente por parte del profesional clnico.

Este hecho, junto con la inexistencia de directrices capaces de enfocar y encauzar las implantaciones as como el hecho de no exigirse ningn tipo de estandarizacin ni promover el uso de un grupo reducido de protocolos de comunicacin entre las aplicaciones utilizadas comporta la existencia de una estructura de datos poco cohesionada a nivel interno de cada centro sanitario.

6 / 33

Aunque existen claros protocolos de comunicaciones dentro del rea sanitaria (HL7, DICOM, ASTM, etc.) todos ellos exigen un elevado nivel de configuracin; Sin una estrategia comn, las integraciones existentes seguirn teniendo un elevado nivel de especificidad, siendo muy complicado su reaprovechamiento en otras reas. Es habitual que las pautas que se sigan sean las promovidas por los propios departamentos de informtica de dichos centros o los proveedores de la solucin, sin seguir ningn tipo de gua comn definida en el territorio comunitario.

El panorama reflejado ofrece un nivel de heterogeneidad muy alto, existiendo muy poca coincidencia en el uso de aplicaciones departamentales especficas, siendo estas un conjunto extenso y dispar que depende de procesos de eleccin e implantacin no homogneos que generan escasas sinergias.

4. ESTRATEGIA DE INTEGRACIN.
Del anlisis de la situacin expresado en punto anterior, desde SACYL se extrajeron los siguientes objetivos a solicitar de la arquitectura de integracin: Tecnolgicamente independiente, sin estar ligada a ninguna plataforma ni herramienta. Coste aceptable, los requisitos no deberan obligar a una re-concepcin de las aplicaciones. Escalable. Las necesidades de integracin abarcan tanto los niveles de centros hospitalarios, como el entorno sanitario en general. La solucin debera contemplar ambos escenarios. En funcin de estos objetivos, se plantearon los siguientes requisitos: Plantear una arquitectura SOA, encapsulando cada sistema como un consumidor o servidor de servicios claramente definidos. Escoger un conjunto de protocolos de intercambio, con las siguientes caractersticas: Ser tecnolgicamente neutrales, evitando ligarse a un nico proveedor. Estar ampliamente difundidos y tener una base implantada significativa.

Aportar el conjunto de recursos comunes tanto fsicos (comunicaciones, registros, etc.) como reguladores (polticas, normas, protocolos, etc.) que hagan posible esta arquitectura.

7 / 33

Partiendo de estos objetivos, se defini la siguiente estrategia: Modelar el sistema de informacin sanitario, definiendo para cada sistema, un conjunto de responsabilidades con el resto de sistemas de informacin. No se trata de remodelar el sistema sanitario, sino de formalizar los roles que ya existen. En base al modelo anterior, definir formalmente el conjunto de interacciones que existir ente estos sistemas. Estas interacciones estarn basadas en los protocolos comunes para cada mbito (por ejemplo, LDAP para usuarios, DICOM para imagen diagnstica, HL7 para mensajera entre aplicaciones, etc.). Proporcionar los servicios comunes: Conjuntos de catlogos y mecanismo de actualizacin de los mismos. Proveedores de datos de pacientes (Registros Unificados de Pacientes) as como de Profesionales (Servicio de Pginas Blancas), y mecanismos estandarizados de acceso a los mismos. Esta estrategia, no supone una nueva aventura, sino que se apoya en la experiencia de IHE (Integrating de Healthcare Enterprise) y la gua de implantacin de HL7.

5. ARQUITECTURA DE LA HCE.
Una vez definida la estrategia general, es necesario aplicarla a cada escenario. En base al estudio de la situacin actual, existen varios mbitos bien definidos relativamente independientes entre s, para los cuales se han definido estrategias diferentes (figura 1):

Atencin Primaria (AP), formada por todos los centros de salud, cada uno de ellos con un sistema de informacin independiente, cuya poblacin atendida est relacionada a travs del Cdigo de Identificacin Personal (CIP). ESTRATEGIA: La mayor frecuentacin a la historia clnica se produce desde este entorno, pero es necesario definir una estructura compatible entre la historia clnica definida por AE y AP, que actualmente est siendo gestado por un equipo funcional. AP deber acceder a los datos comunes (tablas maestras, repositorios, receta, visados, etc.) y a los servicios que precise provistos desde la HCE (navegador, historia resumida, alertas, informes de especialistas, etc.). Es indiferente para esta estrategia si los sistemas de informacin continan existiendo de forma distribuida o centralizada.

8 / 33

Centros de Atencin Especializada (AE), donde se acumula la mayor diversidad de aplicaciones de atencin sanitaria. La relacin entre estas aplicaciones y el paciente es a travs de un cdigo local: NHC (Nmero de Historia Clnica). Sin embargo no son entornos aislados, ya que existe una relacin entre el NHC y el cdigo CIP. ESTRATEGIA: Para minimizar los costes de integracin, los centros hospitalarios se vern como un nodo independiente (que proveer y consumir una serie de recursos), de forma que los sistemas de informacin de los departamentos interactuarn exclusivamente entre ellos. La interaccin entre AE y AP se realizar a travs de servicios que encapsularn las complejidades de cada centro hospitalario, ofreciendo un conjunto de prestaciones comn.

Gerencia de Salud, donde estn los sistemas de gestin y control administrativa (gestin de Incapacidad temporal, Visado de tratamientos farmacolgicos, etc., as como los recursos comunes: Base de datos de Pacientes (Tarjeta Sanitaria), Tablas maestras (Centros, servicios, etc.), Profesionales (Directorio LDAP), Catlogos (CIE, medicamentos, etc.) ESTRATEGIA: Se completar el conjunto de catlogos y tablas maestras a nivel centralizado, as como de un mecanismo de notificacin de los cambios a los sistemas consumidores, asegurando la correcta sincronizacin de los mismos. Se adaptar la interface del resto de sistemas asegurando su compatibilidad con el conjunto de protocolos escogidos. Por ltimo, se proveer del conjunto de sistemas de registros necesarios a medida que sea necesario para la creacin de la historia clnica comn.

Resto Comunidades y pases, donde residir la informacin de los encuentros del paciente con otros sistemas de salud. ESTRATEGIA: La interrelacin con otras Comunidades se da a travs del Sistema nacional de Salud (SNS), que define un escenario para el intercambio de informacin de identificadores de pacientes, as como informacin de historia. Es a travs de este punto donde se construir el intercambio de informacin con otros pases. 0

9 / 33

Servicios Centrales
Gestin Cartera de Gestin Tarjeta RRHH Servicios Sanitaria Visado

Servicios Comunes Comunitarios

Servicios Comunes Hospitalarios

Catlogos ndice Maestro ndice de Pacientes documental

Receta

Centros Hospialarios HCE

Banco Sangre RIS HIS (Admisin)

Sistema Nacional de Salud

Servicios Comunes SNS

@Firma Gestin Peticiones HCE Receta Documentos Citacin Pruebas analticas Pruebas imagen Citas CIP
HCE Citacin Cuidados

SIFCO

EAI Hospital

Urgencias

LIS

Digestivo

Servicios Comunes Primaria

Centros de Salud

Figura 1. Arquitectura de SI regionales.

5.1.

ESTRATEGIA EN CENTROS HOSPITALARIOS.

Dentro de los centros hospitalarios, se ha optado por la aplicacin del mismo modelo que el general: la definicin de un conjunto de obligado cumplimiento por cada una de las aplicaciones, de rango general para todos los hospitales en SACYL. Esta estrategia permitir crear un conjunto de herramientas y conocimiento comunes a toda la integracin, evitando la aparicin de soluciones locales de difcil propagacin.

La comunicacin dentro de los centros hospitalarios se organizara en base a bloques de interacciones agrupados por funcionalidad, especificado cada una de ellos en un Perfil de mensajera . Inicialmente se han definido los siguientes perfiles: pacientes, agendas,

laboratorios, imagen mdica, banco de sangre, dietas, farmacia, cuidados y atencin primaria.

Estos perfiles definen una serie de eventos para los que se deben enviar mensajes, y as como su composicin. En el ltimo punto de este documento se describen los perfiles desarrollados hasta la fecha.

Junto a estos perfiles, es necesario definir las responsabilidades de cada uno de los sistemas del hospital (qu transacciones deben recibir, y cuales enviar), de una manera similar a la que propone la gua de HL7, reflejada en el siguiente dibujo (figura 2):
10 / 33

Figura 2. Contrato de comunicaciones entre aplicaciones propuesto por la gua de integracin de HL7.

5.1.1.

Motor de mensajera HL7 de los centros hospitalarios

La comunicacin entre aplicaciones hospitalarias ser controlada por un broker de mensajes, cuya responsabilidad ser la distribucin de mensajes entre aplicaciones. De esta manera las aplicaciones slo debern tratar con dicho sistema y ste, en funcin del mensaje, se encargar de distribuirlo slo a las aplicaciones suscritas, centralizando la administracin de cualquier incidencia.

El motor, cumplir la especificacin de capa intermedia definida por HL7, soportando el modo ampliado de ACK HL7 (respondiendo con ACK de aceptacin una vez asegurada la recogida del mensaje).

La labor de este motor, por tanto es slo la de distribuir mensajes, siendo cada una de las aplicaciones responsables de generar/consumir los mensajes tal y como estn definidos en la guas.

En base al estudio realizado, las exigencias tcnicas del motor son: Capacidad de trabajar con la sintaxis y protocolos de transporte ms comunes de HL7. El motor debera ser capaz de forma natural de enviar/recibir mensajes tanto en XML como en ER7, y gestionar su envo por los mecanismos de transporte MLLP, HTTP y Web Services. Ofrecer una capa administrativa de fcil manejo. Dada la relativa sencillez de tareas a realizar con l (flujo de mensajes), no deber exigir una curva de aprendizaje demasiado grande.
11 / 33

Ofrecer un apoyo al mantenimiento y gestin de incidencias. En este sentido, el motor: Deber ofrecer un registro de mensajes enviados/recibidos tanto a travs de una interface visual como de un registro en base de datos. Deber poder emitir avisos en caso de error en la transmisin de algn mensaje (por ejemplo, a travs de correo electrnico). Deber permitir reenviar o modificar y reenviar mensajes asncronos.

El motor debe permitir tanto el envi y la distribucin en los siguientes modos: Distribucin asncrona de mensajes: no se espera una respuesta del sistema remoto ms all de una confirmacin. Consultas sncronas: cuando la respuesta del sistema remoto contiene informacin a transmitir al que inicia la transaccin. Para el modo asncrono, el motor debe cumplir las siguientes condiciones: Gestin de ACK de aplicacin (figura 3). Dado que el motor se encargar de la distribucin de los mensajes, es necesario que ste indique a las aplicaciones de las que recibe mensajera que se ha podido hacer cargo del mensaje con un ACK de aceptacin. Tambin deber esperar el ACK de confirmacin cuando entrega mensajes a otras aplicaciones (o reintentar hasta que por fin se retorna). Los detalles de gestin de ACK se detallan a continuacin en el documento. Dado que para el funcionamiento de muchas aplicaciones es crtico el orden de los mensajes, deber habilitar la posibilidad de envo en colas, de forma que: Los mensajes se distribuyan en el mismo orden que se han recibido. No se enve el siguiente hasta que el anterior haya sido entregado correctamente.

Sin embargo, esta configuracin no debera ser aplicable a todos los canales, pues hay entornos donde prima la velocidad de procesado en picos, y no existe tanta criticidad a la hora del orden de entrega de mensajes. Debe asegurar que nunca se pierda un mensaje, independientemente de si las aplicaciones destino estn activas o no. En caso que la aplicacin destino est fuera de servicio, debe ser capaz de almacenar internamente los mensajes, y enviarlos cuando sta est finalmente disponible.

12 / 33

Figura 3. Tratamiento de mensaje asncronos.

Para el modo sncrono, las condiciones son las siguientes: El motor ser capaz de localizar y dirigir el mensaje a su destinatario correcto. El motor deber ser capaz de recuperar la respuesta de un sistema externo y retornarla sobre la misma conexin de entrada.

Figura 4. Modo sncrono de gestin de mensajes.

5.1.2.

Gestin de ACK.

Dado el alto nmero de mensajes a gestionar, as como los mltiples escenarios, se ha optado por el uso del modelo ampliado de ACK de HL7. En base a este modelo, el comportamiento de las aplicaciones con respecto a los ACK se refleja en el siguiente diagrama de actividad; figura 4:

13 / 33

Aplicacin emisora ( MPI)

Aplicacin Receptora (Satlite)

Nueva informacin de paciente

Envo ADT

Recepcin ADT

Mensaje invlido. ACK "CE"

Mensaje vlido ACK "CA"

Fallo interno -no asociado al mensaje-. ACK "CR" Almacenamiento intermedio

Timeout en Recepcin ACK

Procesado Recepcin ACK Envo ACK (aceptacin)

CR: Reenvo FALLO OK

CA: OK

CE: Aviso mantenimiento

Recepcin ACK aplicacin

Envo ACK (aplicacin), MSA.1=AE

Envio ACK aceptacin

Recepcin ACK aceptacin

AE: Aviso mantenimiento

El tratamiento del ACK de aceptacin para el ACK de aplicacin debe ser igual que en el envo de mensaje normal (reenvo hasta contestacin o CR, fallo si CE)

Figura 4. Tratamiento de ACK segn el modelo ampliado.

14 / 33

Un ACK de aceptacin, inmediato a la entrega del mensaje, donde la aplicacin receptora acepta hacerse cargo del mensaje. Este mensaje es de obligatoria entrega. En funcin de su recepcin, la aplicacin emisora se comporta de la siguiente manera:

a. Si la aplicacin emisora no responde con un ACK, se entiende que no ha recibido el mensaje y ser necesario reenviarlo. Se esperar un tiempo prudencial y se reintentar. No se enviarn ms mensajes hasta que ste sea aceptado. b. Si la aplicacin emisora responde con un ACK con el valor de MSA.1 a CE, se marca el mensaje como errneo. Ningn nuevo mensaje ser enviado hasta que la situacin se resuelva. c. Si la aplicacin emisora responde con un ACK con el valor de MSA.1 a CR, se debe proceder como el caso (a).

Un ACK de aplicacin que se enviar en caso que, una vez ejecutado el proceso por la aplicacin receptora, ste genere una situacin de error. No se enviar en caso que el proceso sea ejecutado normalmente. Este ACK de aplicacin debe contestarse con un ACK de aceptacin, repitindose la misma operativa que en el caso anterior (que no se ha reflejado en el diagrama para no complicarlo excesivamente).

6. GUAS DE INTEGRACIN.

6.1.

Gestin de Pacientes.
Referidos a la notificacin de datos administrativos de pacientes (nuevos ingresos, altas, bajas, xitos), as como a los datos de su ubicacin dentro del hospital (cama de ingreso, traslado de cama). Este perfil ser de utilidad para todas las aplicaciones departamentales, ya que el acceso a los datos de pacientes se realizar exclusivamente a travs de ste conjunto de interacciones.

Estas interacciones estn basadas en mensajera HL7.

15 / 33

6.1.1.

Actores
ACTOR DESCRIPCIN Sistema donde se originan todos los cambios de informacin acerca de los pacientes. Su responsabilidad ser la de comunicar esta informacin al resto de sistemas. En un hospital se tratar de la parte administrativa del HIS, pero puede ser una Base de Datos de Pacientes, etc.

ADMISIN (Sistema de gestin de pacientes y camas)

APLICACIN SATLITE (Estacin)

Sistema que necesita estar informado de los cambios de situacin de un paciente.

6.1.2.

Mensajes.
EVENTO Admisin paciente hospitalizado. Traslado de pacientes. Alta o fallecimiento de un paciente Admisin de pacientes en urgencias Actualizacin datos de paciente. Cancelacin admisin pacientes. Cancelacin traslado de un paciente. Cancelacin alta de pacientes. Reserva de cama. Intercambio de pacientes. Gestin y mantenimiento de camas. Alta de fin de semana Regreso alta de fin de semana Cancelacin reserva de cama. ORIGEN ADMISIN ADMISIN ADMISIN ADMISIN ADMISIN ADMISIN ADMISIN ADMISIN ADMISIN ADMISIN ADMISIN ADMISIN ADMISIN ADMISIN ADMISIN DESTINO ESTACIN ESTACIN ESTACIN ESTACIN ESTACIN ESTACIN ESTACIN ESTACIN ESTACIN ESTACIN ESTACIN ESTACIN ESTACIN ESTACIN ESTACIN ADMISIN ADMISIN ESTACIN ESTACIN ESTACIN ESTACIN ADT^A52 ADT^A53 ADT^A27 ADT^A17 MENSAJE DE CANCELACIN ADT^A11 ADT^A12 ADT^A13 ADT^A11

MENSAJE ADT^A01 ADT^A02 ADT^A03 ADT^A04 ADT^A08 ADT^A11 ADT^A12 ADT^A13 ADT^A14 ADT^A17 ADT^A20 ADT^A21 ADT^A22 ADT^A27

ADT^A28

Nueva filiacin de paciente ESTACIN

ADT^A31 ADT^A40 ADT^A45 ADT^A52 ADT^A53

Actualizacin datos de paciente Fusin de pacientes. Traspaso de episodio. Cancelacin alta de fin de semana Cancelacin de un regreso de fin de
16 / 33

ESTACIN ADMISIN ADMISIN ADMISIN ADMISIN

semana

Tambin se han definido las siguientes consultas:

MENSAJE QBP^Q21 RSP^K22 QBP^Q32 RSP^K32 EVENTO Consulta datos administrativos Respuesta consulta datos administrativos Consulta datos episodio Respuesta consulta datos episodio ORIGEN ESTACIN ADMISION ESTACIN ADMISION DESTINO ADMISION ESTACIN ADMISION ESTACIN RSP^K32 MENSAJE DE RESPUESTA RSP^K22

6.2.

Gestin de Agendas y listas de espera.

Que comprende todo el conjunto de notificaciones, solicitudes, etc. Relativo a la reserva de recursos (profesionales, salas, etc.) para la realizacin de distintas actividades en el hospital. Estas interacciones estn basadas en mensajera HL7

6.2.1.

Actores.
ACTOR DESCRIPCIN Sistema de gestin de agendas donde se acuerdan las citas con el paciente en funcin de la ocupacin de los recursos. El sistema emite notificaciones cada vez que la ocupacin de un recurso se

SISTEMA DE CITACIN

modifica. Dentro del modelo de actores propuesto en el captulo 10 de la gua de HL7, esta aplicacin cumple el perfil de filler al ser la nica responsable de las agendas que gestiona. Sistema que no tiene el control de los recursos, pero que necesita estar

ESTACIN CLNICA

informado de las listas de trabajo de cada recurso. Dentro del modelo de actores propuesto en el captulo 10 de la gua de HL7, esta aplicacin cumple el perfil del Auxiliary Application

SISTEMA DE CODIFICACIN

Sistema que permite la codificacin de episodios por profesionales expertos.

6.2.2.

Mensajes.

(Listas de espera)

17 / 33

MENSAJE SRM^Z01

EVENTO Solicitud de ingreso en lista de espera Respuesta a un SRM^Z01 con el id de la

ORIGEN Estacin

DESTINO Gestor LIE

SRR^Z01

solicitud en el gestor, o indicando un error. (Indica que se acepta la solicitud, no que el paciente est en la lista de espera)

Gestor LIE

Estacin

SRM^Z03

Modificacin de una solicitud de ingreso en lista de espera. Respuesta a un SRM^Z03 con la aceptacind e la modificacin o indicando un error. Cancelacin de una solicitud de ingreso en lista de espera. Respuesta a un SRM^Z04 con la aceptacind e la cancelacin o indicando un error. Notificacin del ingreso de un paciente en la lista de espera. Notificacin de la modificacin de un paciente en lista de espera Notificacin de la salida de un paciente en la lista de espera. Cancelacin de una notificacin de salida de la lista de espera de un paciente.

Estacin

Gestor LIE

SRR^Z03

Gestor LIE Estacin Gestor LIE Gestor LIE

Estacin Gestor LIE Estacin Estacin

SRM^Z04

SRR^Z04

SIU^Z12

Gestor LIE

Estacin

SIU^Z14

Gestor LIE

Estacin

SIU^Z15

Gestor LIE

Estacin

SIU^Z25

Gestor LIE

Estacin

(Gestin de agendas)

MENSAJE SRM^S01 Solicitud de cita

EVENTO

ORIGEN Estacin

DESTINO Gestor Agendas

Respuesta a un SRM^S01 con el id de la SRR^S01 solicitud en el gestor, o indicando un error. (Indica que se acepta la solicitud, no que el paciente citado) SRM^S03 Modificacin de una solicitud de cita. Estacin Gestor Agendas Gestor Agendas Estacin

18 / 33

SRR^S03

Respuesta a un SRM^S03 con la aceptacind e la modificacin o indicando un error.

Gestor Agendas Estacin

Estacin Gestor Agendas Estacin

SRM^S04

Cancelacin de una solicitud de cita. Gestor Agendas

SRR^S04

Respuesta a un SRM^S04 con la aceptacind e la cancelacin o indicando un error. Notificacin de un nuevo encuentro programado. Notificacin de reprogramacin de un encuentro (cambio de fecha y/o hora) Notificacin de modificacin de un encuentro (otras que reprogramacin) Notificacin de cancelacin de encuentro previamente programado El paciente no acudi a la cita Consulta sobre Cons Procedimiento quirrgico completado

Gestor Agendas Citacin

Estacin

SIU^S12

Estacin

SIU^S13

Citacin

Estacin

SIU^S14

Citacin

Estacin

SIU^S15

Citacin

Estacin

SIU^S26 SQM^S25 SQR^S25

Citacin

Estacin

BAR^Z22

Actualizacin de la codificacin de un procedimiento. Actualizacin de los procedimientos o

Codificacin

Estacin

BAR^P12

diagnsticos asociados a una actuacin sobre un paciente

Codificacin

Estacin

6.3.

Gestin de Peticiones Resultados de Pruebas Analticas.

Corresponde al conjunto de interacciones sobre peticiones de pruebas de laboratorio y los resultados obtenidos. Ser utilizado por los sistemas de informacin de laboratorio y los gestores de peticiones. Estas interacciones estn basadas en mensajera HL7.

19 / 33

6.3.1.

Actores.
ACTOR DESCRIPCIN Sistema a travs del cual, los profesionales clnicos ordenan las peticiones a realizar, y controlan el estado de las mismas. Sistema que controla los autonalizadores del laboratorio. Gestiona el estado de las peticiones recibidas, permite supervisar el estado de los resultados de laboratorio. Mantiene una relacin con todos los resultados obtenidos.

SISTEMA PETICIONARIO

SISTEMA GESTIN DE LABORATORIO (SIL) REPOSITORIO DE RESULTADOS

6.3.2.

Mensajes.

MENSAJE

EVENTO Solicitud de pruebas analticas Cancelacin de una peticin anterior

ORIGEN PETICIONARIO PETICIONARIO SIL SIL SIL SIL

DESTINO SIL SIL PETICIONARIO PETICIONARIO PETICIONARIO REPOSITORIO

OML^O21 Cancelacin de una peticin anterior Peticin ejecutada en su totalidad ORL^O22 ORU^R01 Imposible realizar peticin Resultados listos

6.4.

Gestin de Pruebas de Diagnstico por Imagen.

De forma similar a las pruebas analticas, este conjunto de interacciones regulan la solicitud de pruebas en el departamento de diagnstico por imagen, as como la obtencin de una relacin por cada resultado obtenido.

Estas interacciones estn basadas en mensajera HL7 y DICOM.

20 / 33

6.4.1.

Actores.

ACTOR SISTEMA PETICIONARIO SISTEMA GESTIN DE IMAGEN DIAGNSTICA (SIID) REPOSITORIO DE RESULTADOS

DESCRIPCIN Sistema a travs del cual, los profesionales clnicos ordenan las peticiones a realizar, y controlan el estado de las mismas. Sistema que controla la organizacin del trabajo en el departamento de radiologa. Normalmente ser el RIS aunque en esta gua no se especifica. El SIID engloba tanto al RIS como al PACS. Mantiene una relacin con los resultados disponibles: pero slo a nivel de referencia, no es una copia del PACS.

6.4.2.

Mensajes.

MENSAJE

EVENTO Nueva solicitud de pruebas diagnsticas Cambios en una solicitud previa (nuevo horario, diferente prestacin, etc.)

ORIGEN PETICIONARIO PETICIONARIO

DESTINO SIID SIID

OMG^O19

Solicitud de cancelacin de una peticin anterior Solicitud cancelada por consideracin del departamento. Peticin ejecutada en su totalidad

PETICIONARIO

SIID

SIID SIID SIID

PETICIONARIO PETICIONARIO PETICIONARIO REPOSITORIO

ORG^020 ORU^R01

Imposible programar prueba Resultados listos (nuevas evidencias:

informes, imgenes, etc.)

SIID

(Para pruebas citadas desde admisin este perfil incluira los mensajes de citacin SIU)

6.5.

Gestin de Banco de Sangre.

Este perfil agrupa las solicitudes de transfusin, la notificacin de reserva de bolsas, la medicin de datos de pacientes durante la transfusin, los informes de transfusin e incidencias transfusionales, etc.

Estas interacciones estn basadas en mensajera HL7

21 / 33

6.5.1.

Actores.
ACTOR DESCRIPCIN Sistema de gestin de la Historia Clnica. Es el sistema que registra los procesos

ESTACIN CLNICA (EC)

de la transfusin a travs del personal clnico y de enfermera (donde se inicia la peticin, se informa de las mediciones al paciente, estado y efecto de la transfusin de las bolsas, y cierre de transfusin). Sistema que gestiona todo el stock de componentes hemoderivados, as como el conjunto de procesos y solicitudes de dichos componentes. Asimismo, se ocupa

BANCO DE SANGRE (BDS)

tambin de gestionar toda la informacin de los pacientes relacionada con la transfusin y donacin (tipo de sangre, fenotipos, anticuerpos detectados, alergias, reacciones adversas, etc.). Este sistema es donde se generan los informes con el resultado de la transfusin.

6.5.2.

Mensajes.

MENSAJE Nueva peticin

EVENTO

ORIGEN EC EC BDS EC BDS BDS EC EC

DESTINO BDS BDS EC BDS EC EC BDS BDS

Envo de datos de estado de paciente OMB^027 Envo de informe final Cancelacin de la peticin ORB^028 BPS^031 Imposible ejecutar la peticin Bolsa reservada Bolsa consumida (transfundida o perdida) BTS^O29 Fin transfusin

6.6.

Gestin de Dietas.
Este conjunto de interacciones regula la programacin de dietas para los pacientes ingresados. Estas interacciones estn basadas en mensajera HL7.

22 / 33

6.6.1.

Actores.

ACTOR SISTEMA GESTIN DE CONTROL DIETTICA (SICD) ESTACIN CLNICA (EC)

DESCRIPCIN Sistema a travs del cual, los dietistas programacin alimentaria de un paciente. pueden organizar la

Cualquier sistema que deba ofrecer informacin sobre la programacin de dietas de un paciente.

6.6.2.

Mensajes.
EVENTO Nueva programacin de dietas ORIGEN SICD SICD SICD EC DESTINO EC EC EC SICD

MENSAJE

OMD^O03 Reprogramacin de dietas OMD^Z03 ORD^O04 Propuesta de programacin de dietas Imposible programar dieta

6.7.

Gestin de Farmacia hospitalaria.

Este conjunto de interacciones regula el ciclo de vida de las rdenes de farmacia. Estas interacciones estn basadas en mensajera HL7.

23 / 33

6.7.1.

Actores.

ACTOR SISTEMA PRESCRIPTOR /ESTACIN CLNICA (ESTACIN)

DESCRIPCIN Sistema de informacin donde un profesional sanitario realiza las prescripciones al paciente. Habitualmente este sistema est integrado en una estacin clnica, donde adems de prescribir se puede conocer el estado de los tratamientos administrados y posibles reacciones a los mismos.

SISTEMA GESTIN DE FARMACIA (FARMACIA)

Sistema de informacin de la oficina de farmacia de un hospital responsable de codificar las prescripciones recibidas (ya que normalmente stas slo contienen el principio activo), y coordinar la distribucin de frmacos ya sea en forma de carros o de sistemas automticos de dispensacin.

SISTEMA DE CONTROL DE DISPENSACIONES (DISPENSACION) SISTEMA DE GESTIN DE CUIDADOS DE PACIENTE (CUIDADOS) SISTEMA DE CATLOGO DE PRODUCTOS FARMACUTICOS (CATLOGO)

En algunos centros se dispone de unos dispositivos de dispensacin que permiten controlar las unidades dispensadas y/o limitar su dispensacin en funcin del paciente y profesional. Sistema de informacin que entre otras tareas supervisa la administracin de cuidados a un paciente. Habitualmente es la aplicacin de enfermera. Sistema que mantiene un listado de todos los productos farmacuticos que pueden administrarse al paciente

6.7.1.

Mensajes.

MENSAJE

EVENTO Nueva orden de prescripcin

ORIGEN ESTACIN ESTACIN FARMACIA

DESTINO FARMACIA FARMACIA

OMP^O09 Modificacin orden de prescripcin

ORP^010

Imposible asumir prescripcin

DISPENSACIN CUIDADOS

ESTACIN

RDE^O11

Orden

de

tratamiento

codificada

(prescripcin completa)
24 / 33

FARMACIA

ESTACIN, DISPENSACION,

CUIDADOS Imposible asumir orden de tratamiento codificada Notificacin de Dispensacin Imposible procesar Notificacin de ESTACIN, DISPENSACION, CUIDADOS DISPENSACION FARMACIA FARMACIA CUIDADOS CUIDADOS de FARMACIA ESTACIN FARMACIA DISPENSACION CUIDADOS FARMACIA FARMACIA ESTACIN CUIDADOS ESTACIN MFM^ZPH Actualizacin de productos en el catlogo CATALOGO FARMACIA DISPENSACION Imposible procesar una actualizacin de catlogo ESTACIN FARMACIA DISPENSACION CATALOGO FARMACIA

RRE^O12

RDS^013 RRD^014 RGV^O15 RRG^O16 RAS^017

Dispensacin Orden de administracin (toma) Imposible asumir orden de administracin Notificacin Administracin Tratamiento Imposible procesar Notificacin

RRA^018

Administracin de Tratamiento

MFK^M14

6.8.

Gestin de Stocks
Este permite mantener sincronizados distintos sistemas de almacenaje y dispensacin respecto al sistema central de gestin del hospital.

6.8.1.
ACTOR

Actores
DESCRIPCIN Sistema que controla el stock de los distintos almacenes, los consumos y devoluciones por los grupos funcionales, as como los ingresos y devoluciones a los proveedores. En los hospitales de SACYL este papel es realizado por el HISGESTIN

SISTEMA DE GESTIN DE INVENTARIO (SGM)

SISTEMA DE GESTIN DE SUBALMACN

Sistema de informacin que gestiona los materiales almacenados en una seccin de un centro.
25 / 33

(SGS)

Es el caso de los carruseles automatizados o los sistemas de dispensacin de planta.

Sistema de Gestin de Catlogo SGC

Sistema que mantiene el catlogo de los tipos de materiales sanitarios. Aunque en los hospitales de SACYL este papel es realizado por el HISGESTIN, por lo que coincide con el SGM, en esta gui se indica como un actor separado.

6.8.2. Mensajes.
Bajo este modelo, el sistema de gestin central es el que informa a los distintos sistemas de almacenaje de movimientos de materiales (entrada de material proveniente de los almacenes del centro, o salida de material a otro destino).

MENSAJE

EVENTO Orden de movimiento: orden de traslado de material desde un elemento a otro. Cada elemento puede ser: Un almacn o sub-almacn. Un GFH o centro de consumo. Un proveedor externo. El tipo de movimiento vendr definido en funcin del origen y destino indicados en el mensaje. Una notificacin de un sistema de informacin de almacn al SGM (HIS-Gestin): Notificacin de ejecucin de una orden de movimiento

ORIGEN

DESTINO

SGM

SGS

OMS^O05

recibida del SGM previamente (slo desde sistemas configurados como almacn en el SGM). Notificacin de regularizacin de un producto. Un almacn notifica de un consumo o aprovisionamiento no asociado a una orden previa del SGM (slo desde sistemas configurados como almacn en el SGM). Peticin de material (cuando el sistema ha detectado que necesita material y enva una solicitud de aprovisionamiento al SGM) (slo desde sistemas configurados como almacn o GFH en el SGM). El tipo de movimiento vendr definido en funcin del origen y destino indicados en el mensaje.
26 / 33

SGS

SGM

ORS^O06

Indicacin de error en una orden OMS^O05 recibida. Notificacin sobre el inventario de un producto al

SGS

SGM

MFN^Z16

sistema central (Slo para sistemas configurados como almacn en el SGM).

SGS

SGM

MFN^M15 MFK^M15

Actualizacin de catlogo. Creacin de un nuevo producto en el catlogo central, Mensaje de error al intentar actualizar el catlogo

SGC SGM,SGS

SGM,SGS SGC

6.9.

Gestin de maestros
Este perfil detalla la mensajera para todos los mensajes que tengan que ver con informacin relativa al mantenimiento de catlogos en los sistemas de informacin sanitarios en SACYL.

6.9.1.

Actores
ACTOR DESCRIPCIN Sistema de informacin que gestiona de forma absoluta la estructura y composicin de cada registro en un catlogo. Sistema que desea conocoer la estructura de una agenda

SISTEMA GESTOR DE CATLOGO SISTEMA USUARIO DE CATLOGO

6.9.2.

Mensjaes

MENSAJE MFM^Z10

EVENTO Actualizacin de un registro asociado a una agenda o a un horario Actualizacin de datos de una ubicacin de un centro asistencial Actualizacin de datos de una material

ORIGEN GESTOR AGENDAS GESTOR UBICACIONES GESTOR UBICACIONES USUARIO

DESTINO USUARIO

MFN^Z05

USUARIO

MFN^Z15

(Detallado en la gua de rdenes de material)

USUARIO

MFK^xxx

Imposible procesar una actualizacin de

27 / 33

GESTOR

catlogo

CATLOGO

6.10.

Gestin de signos vitales

Este perfil detalla la mensajera para todos los mensajes que tengan que ver con gestin de observaciones y signos vitales de pacientes en el SACYL.

6.10.1.

Actores
ACTOR DESCRIPCIN Sistema capaz de medir u obtener datos clnicos asociado a un paciente, asociarlo a sus datos identificativos (de la persona y de la estancia) y comunicarlo a otros sistemas. Sistema que permite el anlisis de la historia clnica de un paciente, relacionando todos los datos obtenidos.

SISTEMA DE CAPTURA DE DATOS CLNICOS (SCDC) VISOR DE HISTORIA CLNICA (VISOR)

6.10.2.

Mensajes

MENSAJE ORU^R01 Resultados listos

EVENTO

ORIGEN SCDC

DESTINO VISOR

6.11.

Gestin Base de Datos Poblacional

Este conjunto de interacciones describe el intercambio de informacin con un gestor de identidades de personas con contacto en el sistema sanitario de la comunidad. Estas interacciones estn basadas en mensajera HL7 V3.

6.11.1.

Actores

ACTOR ORIGEN DATOS PERSONAS

DESCRIPCIN Sistema que es capaz de asignar los identificadores de un mbito.

28 / 33

[FUENTE]

Es el caso de los centros hospitalarios -que asignan el NHC-, o del sistema de Tarjeta Sanitaria con la asignacin del CIP.

CONSUMIDOR DATOS PERSONAS [CONSUMIDOR] REGISTRO MAESTRO DE DATOS DE PERSONAS DE MLTIPLES IDENTIDADES [RXP]

Sistema que requiere consultar datos de una persona, en funcin de un subconjunto de datos personales Sistema que registra los datos administrativos de personas, as como cada uno de los distintos identificadores que una persona tiene en los diferentes mbitos de identificacin en el sistema sanitario. El sistema recibe el acrnimo de RXP (Registro Cruzado de Pacientes)

6.11.1.

Mensajes.

MENSAJE PRPA_IN201305

EVENTO Consulta de lista de pacientes que cumplan criterios en sus datos administrativos Respuesta con la lista de pacientes que cumplen

ORIGEN Fuente

DESTINO RXP

PRPA_IN201306

una

serie

de

criterios

en

sus

datos

RXP

Fuente

administrativos PRPA_IN201301 Alta de paciente dentro de un dominio de identificacin. Actualizacin de los datos de un paciente en un dominio de identificacin Fusin de pacientes: Deteccin de duplicados. PRPA_IN201302 Notificacin que la persona asignada a dos grupos de identificaodores es la misma PRPA_IN201311 PRPA_IN201312 PRPA_IN201313 Solicitud alta paciente Peticin alta aceptada Peticin alta rechazada RXP Peticionario RXP Peticionario Fuente RXP Peticionario RXP Fuente Fuente RXP Fuente RXP RXP Fuente RXP

PRPA_IN201302

6.12.

Documento Clnico (CDA)

Esta gua describe el formato de un Documento Clnico basado en la especificacin CDA de HL7.

6.13.

Gestin Documental
Este conjunto de interacciones describe el intercambio de informacin con un gestor de
29 / 33

documentos clnicos finales y se apoya en la especificacin de documento clnico CDA. Estas interacciones estn basadas en mensajera HL7 V3.

6.13.1.

Actores

ACTOR ORIGEN DOCUMENTAL [FUDOC]

DESCRIPCIN Sistema que genera documentos clnicos. Es el responsable ltimo de dichos documentos, por lo que debe tener capacidad de almacenamiento de los mismos. Es el

REPOSITORIO CENTRAL DE DOCUMENTOS [REDO]

Sistema central que contiene una copia de todos los documentos generados por los distintos orgenes documentales.

6.13.2.

Mensajes.

MENSAJE

EVENTO Nuevo documento

ORIGEN FUDOC

DESTINO REDO

RCMR_IN000002UV02 RCMR_IN000008UV02 RCMR_IN000016UV02 RCMR_IN000023UV02 RCMR_IN000029UV01 RCMR_IN000030UV01 RCMR_IN000031UV01 RCMR_IN000032UV01

Documento Adenda

FUDOC

REDO

Documento de reemplazo

FUDOC

REDO

Repudio de documento Consulta de documentos en base a metatados Respuesta a la consulta de

FUDOC

REDO

FUDOC

REDO

documentos en base a metatados Solicitud documentos Respuesta a la solicitud de de recuperacin de

REDO

FUDOC

FUDOC

REDO

recuperacin de documentos

REDO

FUDOC

6.14.

Intercambio de Historia Clnica

Este conjunto de interacciones describe el conjunto de transacciones que permiten la consulta
30 / 33

de informacin clnica en los centros de atencin primaria.

6.14.1.

Actores

ACTOR ORIGEN DATOS HC [REPOSITORIO HC]

DESCRIPCIN Sistema que almacena todos los datos relativos a la atencin de un paciente. El sistema es capaz de: Resumir esta informacin y generar un resumen de historia clnica del paciente. Recibir informacin de actos clnicos realizados sobre el paciente desde otros sistemas

CONSUMIDOR DATOS HC [CONSUMIDOR] NOTIFICADOR [NOTIFICADOR]

Sistema que requiere consultar datos de historia clnica de una persona, (en base a un identificador principal del paciente). Sistema que requiere registra una a actuacin clnica sobre el paciente, y que la comunica al sistema repositorio.

6.14.2.
MENSAJE

Mensajes.
EVENTO Consulta de lista de en pacientes sus que datos CONSUMIDOR REPOSITORIO ORIGEN DESTINO

QUPC_IN043100UV01

cumplan

criterios

administrativos Respuesta con la lista de pacientes que QUPC_IN043200UV01 cumplen una serie de criterios en sus datos administrativos REPC_IN004014UV01 Notificacin paciente de actuacin sobre un NOTIFICADOR REPOSITORIO REPOSITORIO CONSUMIDOR

6.15.

Receta Electrnica
Este conjunto de interacciones describe el conjunto de transacciones que permiten el intercambio de informacin relativa a prescripciones, dispensaciones y productos farmacuticos a que intervienen en el circuito de recta electrnica.

31 / 33

6.15.1.

Actores

ACTOR SISTEMA DE PRESCRIPCIN [PRES]

DESCRIPCIN Sistema responsable de la generacin de prescripciones a travs de un sistema de apoyo a la prescripcin. En Sacyl, este sistema est integrado con la Receta Electrnica.

SISTEMA DE GESTIN DE DISPENSACIN [SGD] ESTACIN DISPENSADORA [DIS] VISADO [VIS] CATLOGO REMEDIOS [RMD] REPOSITORIO [RECYL]

Sistema responsable de validar las dispensaciones realizadas por los sistemas dispensadores (sistemas de las oficionas de farmacia) Sistemas de informacin de las oficinas de farmacia, que notifican de las dispensaciones al sistema de gestin de dispensacin. Sistema de informacin que gestiona el visado de recetas. Sistema responsable del catlogo de productos que intervienen en el circuito de receta electrnica. Sistema de informacin que registra todo el historial de prescripciones, dispensaciones, y cualquier evento asistencial relacionado con los tratamientos frmaco-teraputicos.

6.15.2.
MENSAJE

Mensajes.
EVENTO Consulta de tratamiento activo Respuesta consulta tratamiento activo Consulta de una prescripcin Respuesta consulta de una prescripcin ORIGEN * RECYL * RECYL DIS DESTINO RECYL * RECYL * SGD RECYL RECYL * RECYL * SGD RECYL

PORX_IN060350UV PORX_IN060380UV PORX_IN060250UV PORX_IN060260UV

PORX_IN020160UV

Notificacin de dispensacin SGD

PORX_IN060210SACYL PORX_IN060220UV PORX_IN060230SACYL PORX_IN060240SACY

Consulta dispensaciones (para facturacin) Respuesta consulta dispensaciones (para facturacin) Consulta dispensaciones Respuesta consulta de dispensaciones

* RECYL * RECYL DIS

PORX_IN020150UV

Notificacin anulacin dispensacin SGD

32 / 33

POME_IN010050UV POME_IN010060UV POME_IN010070SACYL POME_IN010080SACYL POME_IN05010SACYL POME_IN010080SACYL PORX_IN010370UV

Consulta de un producto Respuesta de un producto Consulta de productos por familia Respuesta de productos por familia Consulta de validez de dispensacin Nivel de validez de la dispensacin Notificacin tratamiento nuevo/ modificacin

* RMD * RMD SGD RMD PRES

RMD * RMD * RMD SGD RECYL

33 / 33