Interoperabilidad en el proceso de autorización de servicios de salud basado en HL7-FHIR

Boris González, Helga Duarte
ColSWE
Universidad Nacional de Colombia
Bogotá, Colombia
{bagonzalezr, hduarte}@unal.edu.co

Resumen-La autorización de servicios de salud es un trámite crítico previo a la atención médica que se da entre EPS (Entidad Promotora de Salud) e IPS (Instituciones Prestadoras de Servicios) en Colombia. Para soportar este proceso, cada una de estas instituciones tiene su respectivo sistema de información. La falta de interoperabilidad de estos sistemas para el proceso de autorizaciones médicas, resulta en retrasos importantes en la prestación de los servicios de salud que se le brindan a un Paciente. Lograr que estos sistemas compartan la información de manera adecuada contribuiría a la disminución de trámites para acceder a los servicios de salud y por lo tanto, a una atención médica oportuna y de calidad. En este trabajo se propone un marco de interoperabilidad entre EPS e IPS para el proceso de autorización de servicios en Colombia. El marco está basado en el nuevo estándar de interoperabilidad del HL7 y se propone la implementación de un prototipo usando Procesos de Negocio – BP y una Arquitectura Orientada a Servicios - SOA. Además, el marco también le permite al paciente conocer el estado de sus solicitudes de servicios de salud a través de un aplicativo web y de aplicaciones móviles específicas.

Palabras claves: Sistemas de Información en Salud (Health Information System – HIS); Interoperabilidad; SOA; BPM; HL7; FHIR.

INTRODUCCIÓN

En el sistema de salud colombiano, todos los ciudadanos deben estar afiliados a una aseguradora en salud, llamada EPS. Estas instituciones se encargan del aseguramiento del afiliado, pero no prestan los servicios de salud de manera directa. Para este fin contratan con una Red de prestadores llamadas IPS. Así, cuando un paciente requiere de un servicio de salud, debe dirigirse a una IPS quien se encargará de solicitar la autorización de algunos procedimientos médicos a la respectiva EPS del Paciente de acuerdo a la normatividad vigente.

La interoperabilidad entre los sistemas de estas entidades es vista como una necesidad para garantizar el acceso, oportunidad, calidad y trazabilidad en la atención médica de los pacientes puesto que, contribuye a la mejora de la gestión y el control de los costos de las aseguradoras y en la evaluación de los indicadores de calidad en la atención de salud por parte de los prestadores.

Sin embargo, las organizaciones de salud tienen dificultades para intercambiar esta información tanto en su interior como con otras instituciones. La diversidad de tecnologías y de sistemas de información con los que cuentan estas instituciones, hacen que se requiere de un buen diseño y una correcta arquitectura de interoperabilidad entre sus respectivos SI.

El interés de este trabajo se centra en la necesidad de intercambio de información entre una entidad promotora de salud - EPS y su red de prestadores (IPS) para el proceso de autorización de servicios de salud. Este proceso requiere de la participación de estas entidades para que pueda llevarse a cabo, puesto que de la respuesta oportuna de cada participante, depende la atención y muchas veces, la vida del paciente.

En este trabajo se propone el uso del nuevo enfoque del HL7, el estándar Fast Healthcare Interoperability Resources (FHIR) [1], que combina las características de la Versión 2, Versión 3 y CDA® de HL7. Además, está basado en el estilo arquitectónico REST1 que permite una fácil implementación a bajos costos[1]–[4].

II. MATERIALES Y MÉTODOS

A. Revisión de la literatura

Se realizó una revisión sistemática de literatura seleccionada de soluciones de interoperabilidad en las entidades de salud. Esta revisión se hizo en revistas indexadas nacionales e internacionales, con el fin de obtener conocimiento de diseños de arquitecturas para intercambiar información y algunas soluciones de interoperabilidad propuestas. Los resultados fueron organizados en las siguientes secciones: trabajos en Colombia, trabajos internacionales y análisis de los trabajos relacionados.

B. Entrevista a Entidades de Salud

Se realizó una visita a cada una de las entidades seleccionadas (a una aseguradora y 3 (tres) IPS de su red de prestadores) con el fin de aplicar una entrevista semi- estructurada a los administradores de cada sistema de información. De estas entrevistas se tuvo como resultado: (i) conocimiento del proceso de autorización de servicios, (ii) conocimiento de la normatividad que regula el proceso de autorización.

C. Diseño de la Arquitectura

Con el fin de visualizar y comprender la situación actual y futura del proceso seleccionado, se utiliza Business Process Model and Notation (BMPN) puesto que es el estándar 1 REST, Representational State Transfer o Transferencia de Estado Representacional utilizado para diseñar procesos de negocios. Con base en la información obtenida del proceso y la revisión bibliográfica, se propone una Arquitectura Orientada a Servicios (SOA) que permita la interoperabilidad de los sistemas de las organizaciones, soportada en el HL7 FHIR para el intercambio de datos.

Para el diseño de la arquitectura se realizaron los siguientes pasos (i) identificación de servicios (ii) especificación de servicios (iii) Implementación de la solución con FHIR (iv) despliegue de la arquitectura de servicios que se soporta en una solución en la nube.

III. TRABAJOS RELACIONADOS

A continuación se realiza una descripción de trabajos relacionados de interoperabilidad en salud a nivel nacional e internacional.

Aguilar y López [5] en su artículo muestran la problemática de los sistemas de información de salud en Colombia, los cuales han sido desarrollados de manera aislada y no están diseñados para interoperar entre ellos. Además, resalta el uso a nivel internacional del HL7 como la solución más difundida para implementar estándares de comunicación, y presentan una guía para implementar el HL7 v3 en los reportes en el Sistema Nacional de Vigilancia en Salud Pública (SIVIGILA).

López y Blobel [6] describen la complejidad de integrar sistemas de información de salud cuando se deben cumplir los requisitos de interoperabilidad en los niveles de semántica y de lógica de negocio. Presentan una arquitectura basada en un modelo de mediación de mensajes soportada en el estándar HL7 v3 y SOA, con el fin de desarrollar sistemas de salud abiertos, flexibles, reutilizables, semánticamente interoperables, independientes de la plataforma, orientado a servicios y basado en estándares.

Castrillón, González y López [7] mencionan la necesidad de desarrollar sistemas de información que permitan la interoperabilidad para mejorar la colaboración entre los distintos actores del sistema de salud en Colombia. Proponen un modelo de interoperabilidad sustentado en la normatividad y bajo principios orientados a servicios, definen la arquitectura del software y está basado en el estándar HL7 CDA para el intercambio de datos.

Dentro de los trabajos relacionados a nivel internacional se encontró la propuesta de LupSe y Lacramioara [8] que presentan una solución para integrar el área de obstetricia con pediatría. Este artículo propone una solución basada en la nube o Cloud Computing, con principios SOA. Utiliza el HL7v3 (HL7CDA) para el intercambio de información y el CIE-10 como estándar para los códigos de los diagnósticos. Esta propuesta se centra en el manejo de historia clínica entre dos áreas de atención.

Con el objeto de lograr la integración de diferentes prestadores de servicios de salud, Pardamean y Rumanda [9] realizaron un estudio de la aplicación de la computación en la nube en la que se propone un sistema integrado para llevar el registro de la historia clínica basado en HL7 con el estándar CIE-10. El acceso de los sistemas existentes se realiza a través de una API directa, y provee acceso móvil/web para entidades que no posean ningún sistema de información de historia clínica. El sistema está diseñado bajo modalidad SaaS e implementa una arquitectura SOA. Está soportado en servicios web SOAP2 basados en HL7.

Pérez y Framiñán [10] utilizan BPM o Business Process Management con el objeto de diseñar un middleware orientado a servicios que permita la interoperabilidad de las distintas aplicaciones que se encuentran en un Hospital Universitario. El articulo muestra la capacidad que tienen estos modelos para aportar información en el diseño de los componentes a integrar. El middleware diseñado está basado en HL7 CDA y utiliza el CIE10, BPM, BPEL3 y el estándar de sistema de codificación de términos clínicos SNOMED4.

Kawamoto, Honey y Rubin[11] presentan el proyecto de especificación de servicios para la Salud - HSSP, liderado por el HL7 y la OMG5. Este proyecto muestra la importancia de la adopción de arquitecturas orientadas a servicios – SOA, en conjunto con el HL7 para lograr la interoperabilidad semántica en el área de la salud. Proponen un marco para la implementación de SOA, el cual es descrito por el HL7 y la OMG [12] por medio de una guía práctica de implementación.

P. de Toledo et. al [13] proponen el diseño de una interfaz HL7 v2-Message para la comunicación de una aplicación móvil para el monitoreo de pacientes con patologías crónicas con los EHR, como estándar de terminología utiliza el LOINC6®. En este trabajo se resalta el uso de App's móviles para los pacientes, por lo que propone un sistema móvil que se comunique con un sistema externo de historia clínica, usando HL7.

Meyer [14] presenta una plataforma Web-SOA abierta para el acceso y gestión de la historia clínica desde dispositivos móviles dirigida a pacientes y profesionales de salud de acuerdo al flujo de trabajo del proceso de atención de salud. La solución utiliza HL7v3, servicios web SOAP.

Bahga y Madisetti [15] proponen un sistema de historia clínica basado en arquitectura de Cloud permitiendo acceso Web y Mobile a los diferentes participantes del proceso como hospitales, laboratorios clínicos, pacientes y otros. Esta solución utiliza los estándares HL7 v2.x, HL7 v3 entre otros. También utiliza oAuth7 como esquema de seguridad.

Lamprinakos et. al [2] proponen una solución de interoperabilidad de historias clínicas a través en un PHR móvil basado en interfaces HL7-FHIR. Define un esquema de seguridad basado en roles, permitiendo compartir información del historial clínico por medio de generación de códigos QR a familiares, médicos o entidades de salud. El acceso a los recursos FHIR es definido por medio de roles de médico, paciente y farmacia.

Franz et. al [16] presentan un sistema integrado de monitorización a través de dispositivos móviles basado en estándares como IHE8 y HL7 FHIR. Resaltan que el uso de FHIR con el enfoque RESTful disminuye el tráfico y consumo de batería de los teléfonos móviles ofreciendo una alternativa más ligera que el uso de servicios web SOAP. Muestran que el mantener un monitoreo en tiempo real permite un mayor ajuste del tratamiento médico para los pacientes.

1) Análisis de los trabajos relacionados

Dentro de las propuestas anteriormente mencionadas se observa que todas están orientadas al intercambio de información de las historias clínicas entre prestadores. La propuesta que se presenta aquí propone apoyar el proceso administrativo de autorización de servicios entre IPS y EPS, por medio de un marco de interoperabilidad que incluye al paciente como su actor principal, lo que marca la diferencia con las propuestas anteriormente presentadas.

En los trabajos relacionados a nivel de interoperabilidad técnica, el protocolo SOAP es ampliamente utilizado. Sin embargo, autores como J. Meyer [14], Bahga et. al [15] Lamprinakos et. al [2] y Franz et. al [16], muestran que SOAP es complejo en comparación con el modelo REST, el cual es más sencillo, con una documentación más fácil de entender y con mejor escalabilidad y rendimiento.

En cuanto a la interoperabilidad semántica, los trabajos relacionados muestran mayor tendencia en el uso del HL7v3, no obstante, FHIR también está incidiendo en las soluciones de interoperabilidad desde el año 2014. Según Lamprinakos et. al [2] y Franz et. al [16], FHIR surge como una solución a las dificultades en la implementación del HL7v3 y a la necesidad de transición del HL7v2x.

Como apoyo a la interoperabilidad de procesos, se ha encontrado la tendencia a utilizar SOA. En los artículos relacionados no se encontró el apoyo a la interoperabilidad de procesos en salud junto con el uso del estándar FHIR para la interoperabilidad semántica. Sin embargo, la segunda versión de DSTU9 del FHIR establece que "FHIR y SOA no son tecnologías competidoras"; más bien son enfoques de aplicación complementarias que proporcionarían soluciones de mayor valor en el escenario de uso.

En cuanto a implementación, los trabajos relacionados muestran una tendencia al uso de Cloud Computing y aplicaciones móviles a partir del año 2011, esto como respuestas a las necesidades de interoperabilidad en el área de la salud. En cuanto a la seguridad, en los trabajos relacionados también se observa el uso de oAuth como estándar de seguridad.

La propuesta que se presenta aquí propone apoyar el proceso administrativo de autorización de servicios entre IPS y 8 IHE: Integrating the Healthcare Enterprise, podría ser traducido como (Integrando las Empresas Sanitarias), es una iniciativa de profesionales de salud (incluyendo colegios profesionales de médicos) y empresas proveedoras cuyo objetivo es mejorar la comunicación entre los sistemas de información que se utilizan en la atención al paciente.

EPS, por medio de un marco de interoperabilidad que incluye al paciente como su actor principal, lo que marca la diferencia con las propuestas anteriormente presentadas. El marco está soportado en Cloud Computing para el acceso ubico a los sistemas. Además, se utilizará FHIR en combinación con una arquitectura orientada a servicios, aplicando el estilo RESTful que es tendencia en las soluciones de interoperabilidad.

Tabla 1. Resumen de las observaciones a las tecnologías y estándares utilizados en de los trabajos relacionados.

IV. DESCRIPCIÓN DEL PROCESO DE NEGOCIO AS-IS

El proceso de autorización de servicios de salud inicia con la solicitud de una orden de servicio de salud por parte del profesional de salud de una IPS. Esta solicitud de autorización de servicios de salud es registrada en el SI del prestador para luego ser enviada a la aseguradora o EPS. Una vez es enviada esta solicitud, la IPS queda a la espera del acuse de recibo de este envío.

En la EPS el proceso inicia con la recepción de una solicitud de autorización de servicios de salud por parte de una IPS. La EPS debe enviar el acuse de recibo de la solicitud de autorización a la IPS y proceder a auditar la solicitud de autorización para evaluar su pertinencia.

La IPS al ser notificada, registra el acuse de recibido de la solicitud y queda en espera de la respuesta a dicha solicitud. Después de ser auditada por parte de la EPS, la respuesta a la solicitud (Negación o Autorización) es registrada en el SI de autorizaciones de la EPS y también se envía a la IPS solicitante.

Al recibir la respuesta, la IPS debe enviar el acuse de recibo de la respuesta de la solicitud a la EPS y notificar esta respuesta a su respectiva área de atención de salud (y al paciente), con esto se cierra el proceso en la IPS. Una vez la EPS obtiene el acuse de recibo del envío de la respuesta de la solicitud se cierra el proceso en la EPS.

En la Figura 1 se muestra el nivel descriptivo del proceso de negocio colaborativo de autorizaciones de servicios de salud entre EPS y las IPS de su Red de Prestadores. Por esto el Pool IPS tiene en la parte inferior central el símbolo III que indica que son muchas las IPS que interactúan con la EPS.

Figura 1. Esquema general del proceso de autorización de servicios de salud entre EPS e IPS.

D. Análisis del proceso en su estado actual

Como se puede observar, para el proceso de autorización de servicios de salud entre las EPS y las IPS, se necesita de una comunicación efectiva y eficiente entre ellas, puesto que de esta comunicación depende la rapidez de la atención del paciente. Actualmente esta comunicación se lleva a cabo a través del envío de documentos por correspondencia, correo electrónico y fax.

Además de las IPS y la EPS, los usuarios son los más interesados en la agilidad y trazabilidad del proceso. En la actualidad no existe un mecanismo que les permita conocer en tiempo real en dónde se encuentra la solicitud (EPS o IPS) y cuál es su estado. Esta situación les genera angustia a los usuarios obligándolos a estar consultando frecuentemente tanto al personal médico que lo atiende, como a la parte administrativa de la IPS que se encarga del proceso de autorizaciones. En ocasiones, debido a la falta de información y demora del proceso deben trasladarse a las EPS para poder obtener información y tratar de acelerar los trámites con el fin de que se les preste el servicio de manera oportuna.

En los casos en que los servicios son solicitados por consulta externa, los pacientes deben dirigirse a la aseguradora (EPS) para entregar la orden médica con el fin de recibir la autorización de la solicitud del servicio de salud, teniendo que hacer largas colas para este trámite. Por políticas de la EPS, para algunos servicios solicitados la autorización se entrega de manera inmediata, pero hay otros servicios para los cuales la EPS exige un proceso de auditoría, por lo que la respuesta tardará el tiempo que dure dicha auditoría. En estos casos el paciente debe volver a la EPS en el tiempo que ésta lo establezca para recibir la respuesta de la solicitud.

Para el área de Coordinación de Calidad de la EPS es importante mantener el registro de la trazabilidad del proceso de autorización, puesto que esta información es requerida por los organismos de control. Sin embargo, obtener esta información de trazabilidad es un proceso que resulta tedioso, pues se debe consultar información del correo electrónico, del sistema de gestión de autorizaciones y en ocasiones solicitar información complementaria a las IPS. Esta labor no es adecuada y no permite medir de forma real la calidad y oportunidad del servicio brindado tanto por el área de autorizaciones de la EPS como de las IPS.

SOLUCIÓN PROPUESTA

E. Re-diseño del Proceso (to-be)

Para el rediseño del proceso (Figura 1) se propone que la EPS implemente y administre un Sistema Integrado de Autorización de Servicios de Salud (SIASS-EPS). El SIASS- EPS facilitará el intercambio de información con los SI de la red de prestadores de la EPS y la notificación en tiempo real a los pacientes del estado de la solicitud de autorización. Esto permitirá llevar el registro de los tiempos transcurridos entre cada trámite del proceso, monitorear las actividades de dicho proceso y notificar alertas de solicitudes nuevas/vencidas.

De esta manera se busca mejorar la relación con las IPS habilitando el acceso a través de interfaces de servicios para la integración de los sistemas de información y la relación con los pacientes, a los cuales se les habilitará un acceso móvil para que reciban sus notificaciones.

Los pacientes podrán conocer el avance de los trámites de las autorizaciones de servicios de salud y tener las herramientas necesarias para que puedan reportar demoras o inconvenientes presentados en la atención de salud a los organismos de control. Esta implementación sería un paso clave para la transparencia en los trámites administrativos y contribuiría a que los ciudadanos colombianos también puedan ser supervisores de sus procesos de autorizaciones.

F. Identificación y Especificación de servicios

Con base en el modelo BPMN del proceso de negocio de autorización de servicios de salud se realiza el mapeo a un modelado SoaML para la especificación de la arquitectura del sistema [17]–[19]. La Tabla 2 presenta el mapeo entre los elementos del modelo BPMN al modelo SoaML.

Tabla 2. Mapeo entre elementos BPMN. Elaboración propia con base en [17]– [19].

Los participantes identificados son: IPS, EPS, Paciente y SIASS (el SI de la EPS). Teniendo en cuenta que las IPS pueden tener dos roles como lo son IPS Solicitante e IPS Autorizada, el Pool de IPS se mapea a dos participantes del tipo IPS.

Figura 2 Modelo BPMN 2.0 del proceso de negocio propuesto. Elaboración Propia.

La Figura 3 presenta una diagrama SoaML para mostrar la relación de los servicios que se identificaron en la solución. En este diagrama se visualizan cinco participantes conectados entre sí por cinco serviceContract (Colaboraciones). Los Contratos de Servicios que hay entre IPS y SIASS son los mismas que hay entre el participante SIASS y la EPS, esto se debe a que el participante SIASS es un sistema intermediario entre el participante EPS, los participantes IPS y el paciente.

Los Contratos de Servicios representan el acuerdo entre los participantes, en el cual se determina cómo el servicio va a hacer proporcionado y consumido [17]. A partir del análisis se especifican los siguientes contratos de servicios: SolicitudAutorización, RespuestaAutorización y Notificaciones.

G. Implementación: Solución con HL7-FHIR

Para desarrollar una solución FHIR, se realizó una revisión de especificación FHIR. donde se obtuvo:(i) la documentación general que es un material que describe y definen los recursos, los tipos de datos, las extensiones, códigos y los formatos XML y JSON que son utilizados por el estándar. (ii) La lista de recursos disponibles del estándar FHIR (iii) Las implementaciones de referencias en las que se describe cómo se puede utilizar cada recurso usando REST a través de mensajería, documentos clínicos o mediante una arquitectura basada en servicios.

A partir de las implementaciones de referencias ofrecidas por la especificación FHIR es posible realizar las pruebas del uso del estándar. Para este trabajo se selecciona la implementación de referencia HAPI-FHIR principalmente por tener una mejor documentación y ejemplos para llevar a cabo las pruebas al estándar.

Figura 3. Diagrama SoaML de la Autorización de Servicios de Salud.

Luego de realizar la revisión a la especificación FHIR, se procede a realizar el mapeo de la Arquitectura de Servicios SoaML de acuerdo a la especificación, realizando los siguientes pasos: (i) Mapear el modelo de datos de la arquitectura de servicios propuesta a Recursos y elementos FHIR. (ii) Mapear los servicios identificados a operaciones de la API RESTful FHIR y (iii) Especificar la arquitectura de referencia para las aplicaciones que soportaran FHIR. Para realizar este mapeo, es necesario la selección de los recursos FHIR que serán utilizados. Los recursos son representaciones de conceptos empleados en el contexto de salud (paciente, medicación, observación, etc), que serán utilizados para el intercambio y/o almacenamiento de datos. Los recursos tienen un conjunto de tipos de datos que son utilizados por los elementos que conforman el recurso, estos tipos de datos puede ser simples o compuestos.

En algunos casos, los recursos disponibles de FHIR tienen una similitud semántica con el elemento al que se mapea, sin embargo es posible que no cumpla con todo los requerimientos del elemento mapeado, por lo que será necesario adicionarle datos al recurso. FHIR provee una forma estándar de realizar esta adición de datos a través de extensiones y perfiles.

Para el mapeo de esta solución se tuvo en cuenta por cada recurso seleccionado la descripción de su contenido, la definición de la estructura del recurso, su alcance, uso, limites, relaciones, ejemplos y demás información documentada en la especificación del FHIR. A continuación se describe la asociación realizada a algunos elementos del modelo de datos que fue mapeado.

1) Mapeo de MessageType de SoaML a Recursos FHIR

Los MessageType representan la información intercambiada entre los participantes de la arquitectura de servicios. Para realizar el mapeo de los MessageType se identificaron los recursos y perfiles FHIR que representan semánticamente dicha información. Teniendo en cuenta que el proceso de autorización de servicios de salud es un proceso administrativo entre diferentes entidades, se seleccionó el recurso Communication 10 (Recurso clasificado como administrativo y de flujo de trabajo) para representar los MessageType. Este recurso es recomendado para estandarizar las comunicaciones SOA en la especificación del FHIR. Los recursos Communication brindan los elementos bases que requieren la Solicitud de Servicios, la Autorización de Servicios y la Negación del Servicio. En la Tabla 3 se muestra el mapeo realizado de los MessageType, Solicitud de autorización y recuso Communication de FHIR.

Para el mapeo de las entidades se emplearan los recursos: Organization para representar a las EPS e IPS, el recurso Patient para representar a los pacientes y el recurso Person para representar las personas. Como un resumen de los elementos SoaML que fueron mapeados a la especificación FHIR para la solución propuesta se elaboró la Tabla 4.

A partir de las operaciones definidas en la Arquitectura de Servicios propuesta, se realizó la definición de las operaciones del API RESTful que se implementarán sobre los recursos. La Tabla 3 muestra un listado de las interfaces de servicios, los métodos Http a utilizar de algunos de los recursos al que será mapeado y el perfil que proporciona las reglas adicionales sobre cómo se utilizarán los recursos.

Tabla 3. Mapeo de cada MessageType al recurso Communication de la especificación FHIR.

Tabla 4. Modelo de datos de servicios mapeado a recursos o elementos de FHIR.

H. Despliegue de la solución

Para el despliegue de la arquitectura propuesta con posibilidad de acceso desde cualquier lugar y en cualquier momento para los distintos participantes [20] [8] [15] [16], se propone utilizar Cloud Computing para desplegar la plataforma de integración en forma de Software como Servicio. Esta arquitectura se muestra en la Figura 4.

Con el fin de llevar a cabo la arquitectura propuesta se desarrollarán cuatro estrategias o acciones para lograr su correcta implementación. A continuación se explica cada una de estas estrategias.

I. Estrategias de Tipos de Acceso

Se debe permitir el acceso a los usuarios desde distintos tipos de dispositivos (PC y dispositivos móviles). Con este fin se dispone de tres tipos de acceso: acceso directo a API de servicios para IPS que tienen sus propios sistemas de gestión de autorizaciones y tienen la necesidad de integrarse al SIASS propuesto. El acceso API para aplicaciones móviles para los pacientes que requieren realizar consultas del estado de sus solicitudes de servicios de salud a través de dispositivos móviles. El acceso a través de la aplicación web para las IPS que no cuentan con sistema para la gestión de la autorización de servicios de salud.

2. Estrategia de Seguridad

El SIASS permitirá a la EPS la habilitación de las IPS de su red de prestadores y Pacientes, otorgándoles credenciales de acceso de acuerdo a sus respectivos roles. El grupo HL7 en la especificación FHIR recomienda el uso de SSL 11 para el intercambio de datos en producción y el uso de oAuth para autenticar y autorizar a usuarios. oAuth (Open Authorization) es un estándar que permite que una aplicación acceda a los datos de los usuarios en otro servidor sin la necesidad de tener una copia de las credenciales de los usuarios de ese sistema [21].

Las IPS que requieran la integración de sus sistemas de información con el SIASS, deberán: implementar un servidor FHIR que cumpla con las interfaces de servicios especificadas en la arquitectura de servicios propuesta, suscribir el EndPoint (URI) del Servidor FHIR implementado en el SIASS y suscribir el EndPoint (URI) del Servidor FHIR del SIASS en su sistema de información, el cual debe implementar un cliente FHIR para comunicarse con el SIASS.

Figura 4. Modelo de despliegue del SIASS.

3) Estrategia de Datos

La solución SIASS deberá mantener el registro de los procesos de solicitud de autorización de servicios realizados a la EPS, permitiendo registrar la trazabilidad de cada trámite efectuado dentro del proceso.

En el caso de las IPS integradas al SIASS, cuando la EPS realice algún trámite en el SIASS, el sistema deberá enviar de manera automática el trámite realizado al EndPoint de la IPS respectiva. Cuando la IPS realice algún trámite de un proceso de autorización, su sistema deberá enviar la información al EndPoint del SIASS y este deberá actualizar la base de datos central. Esta estrategia está representada en la Figura 5.

Figura 5. Estrategia de Datos.

Cada entidad participante requiere el manejo de su información de forma autónoma. Por lo tanto aunque se tiene una base de datos central, cada participante debe mantener su propia información actualizada, que sirva de soporte de otros procesos internos.

4) Estrategia de Notificación Push

La tecnología Push es útil para la notificación de alertas o hitos durante el trámite de un proceso en tiempo real. Por ejemplo al darle recibido a una solicitud de autorización por parte de la aseguradora, el SIASS puede notificar de manera automática a la IPS solicitante la recepción de la solicitud. De igual forma, cuando la aseguradora autorice un servicio, se enviará una notificación de manera automática a la aplicación móvil del paciente.

Estas notificaciones Push se pueden implementar con servidores de notificaciones externos como APNS12, GCM13 MPNS 14 o con desarrollos propios soportados con socket, websocket o signalR en .Net.

V. CONCLUSIONES Y TRABAJOS FUTUROS

El diseño del marco de interoperabilidad propuesto para la comunicación entre las aseguradoras y su red de prestadores, propone una alternativa para alinear el proceso de solicitud de autorización de servicios de salud con las metas del sistema de salud colombiano, puesto que permite un mayor control y gestión del proceso de autorizaciones, reduciendo el re-trabajo en la transcripción de la información y manteniendo la trazabilidad del proceso,con lo cual es posible llevar el control del responsable del proceso en un momento dado.

También provee una herramienta a la EPS para la supervisión en tiempo real de las solicitudes de autorización pendientes y el control de costos de servicios prestados por las IPS. Además, permite la generación de informes de medición de la calidad de los servicios provistos a los pacientes.

La interoperabilidad en los sistemas de salud es vista como una necesidad para garantizar el acceso, oportunidad, calidad y trazabilidad en la atención médica de los pacientes. Los principales aportes de este trabajo son: La inclusión del paciente al proceso de negocio, y el diseño de un prototipo de interoperabilidad realizable basado en estándares internacionales que facilitan la implementación de la interoperabilidad entre los HIS de las entidades participantes.

El diseño propuesto permitiría a los Pacientes conocer sus trámites y el estado de los mismos entre IPS y EPS. Para las solicitudes de servicios de consulta externa, el paciente no tendrá que desplazarse hasta los puntos de atención de la EPS para hacer transcribir la orden médica, sino que la IPS le enviará la solicitud directamente a la EPS a través del SIASS. Esto brindará un valor agregado dentro de los servicios que ofrece la EPS a sus afiliados.

El uso del estándar FHIR en este trabajo es el resultado de un diseño para la interoperabilidad semántica entre los sistemas de información de salud de la EPS y su red de prestadores - IPS, con el fin de permitir que estos sistemas interpreten correctamente la información generada desde cada aplicación.

Para esto se hace la selección de los recursos, la creación de los perfiles y otros elementos FHIR que se requieren para el caso particular del proceso de autorización de servicios de salud.

Trabajos futuros

Se propone el diseño de una arquitectura Federada que combine las plataformas de varias EPS, basada en el marco de interoperabilidad propuesto. Esta arquitectura serviría al Estado Colombiano para realizar la evaluación de los indicadores de oportunidad en la prestación de servicios de salud entre EPS e IPS. Además, con el acceso que el SIASS ofrece al paciente, se podrían realizar encuestas en tiempo real que permitan medir la satisfacción de los usuarios con los servicios de salud prestados con el fin de mejorar la calidad del servicio.

Se recomienda al Estado Colombiano diseñar un marco de interoperabilidad que esté regulado y reglamentado a nivel nacional, soportado bajo estándares de comunicación entre las instituciones de salud. Este modelo permitirá a los proveedores de software, las aseguradoras y los prestadores mejorar los sistemas de información con los que cuenta e implementar un acceso e intercambio oportuno de la información.

Por último se propone que se realicen otros trabajos de interoperabilidad soportados con el estándar FHIR para realizar su evaluación como un estándar semántico para Colombia. Esto con el fin de mejorar los diferentes procesos interorganizacionales entre las distintas entidades de salud.

REFERENCIAS

[1] D. Bender and K. Sartipi, “HL7 FHIR: An Agile and RESTful approach to healthcare information exchange,” Computer-Based Medical Systems (CBMS), 2013 IEEE 26th International Symposium on. pp. 326–331, 2013.

[28] G. C. Lamprinakos, A. S. Mousas, P. Kapsalis, D. I. Kaklamani, and S. Iakovos, “Using FHIR to develop a healthcare mobile application.”

[29] B. Franz, A. Schuler, and O. Krauss, “Applying FHIR in an Integrated Health Monitoring System,” vol. 11, no. 2, pp. 51–56, 2015.

[30] R. T. Fielding, “Architectural styles and the design of network-based software architectures,” University of California, Irvine, 2000.

[31] R. A. Aguilar Bolaños and D. M. López Gutiérrez, “Guía de implementación HL7 para sistemas de notificación obligatoria en salud pública en Colombia,” in Sistemas & Telemática, 2009, vol. 7, no. 14.

[32] D. M. López and B. Blobel, “Architectural approaches for HL7-based health information systems implementation,” Methods Inf. Med., vol. 49, no. 2, pp. 196–204, 2010.

[33] Castrillón Helder Y., González Carolina, and López Diego M., “Modelo Arquitectónico para Interoperabilidad entre Instituciones Prestadoras de Salud en Colombia,” Rev. Ing. Biomédica, vol. 6, no. 12, p. 12, 2012.

[34] O.-S. Lupse, M. M. Vida, and S.-T. Lacramioara, “Cloud Computing and Interoperability in Healthcare Information Systems,” in INTELLI 2012 : TheThe First International Conference on Intelligent Systems and Applications Cloud Computing and Interoperability in Health, 2012, p. 81 to 85.

[35] B. Pardamean and R. R. Rumanda, “Integrated model of cloud-based E- medical record for health care organizations,” in 10th WSEAS International Conference on E-Activities, 2011, pp. 157–162.

[36] [P. Pérez González, J. M. Framiñán Torres, C. L. Parra, P. L. González Rodríguez, and J. M. León Blanco, “Interoperabilidad de sistemas guiado por modelos de procesos de negocios: una aplicación en el sector sanitario,” X Congr. Ing. Organ. Val., 2006.

[37] [K. Kawamoto, A. Honey, and K. Rubin, “The HL7-OMG Healthcare Services Specification Project: motivation, methodology, and deliverables for enabling a semantically interoperable service-oriented architecture for healthcare.,” J. Am. Med. Inform. Assoc., vol. 16, no. 6, pp. 874–81, 2009.

[38] Hl7 and OMG, “The Practical Guide for SOA in Health Care,” 2008.

[39] P. De Toledo, W. Lalinde, F. Del Pozo, S. Member, and D. Thurber, “Interoperability of a Mobile Health Care Solution with Electronic Healthcare Record Systems,” pp. 5214–5217, 2006.

[40] J.-U. Meyer, “Open SOA health web platform for mobile medical apps: Connecting securely mobile devices with distributed electronic health records and medical systems,” in Proceedings of the 2014 IEEE Emerging Technology and Factory Automation (ETFA), 2014, pp. 1–6.

[41] A. Bahga and V. K. Madisetti, “A Cloud-based Approach for Interoperable Electronic Health Records ( EHRs ),” vol. 17, no. 5, pp. 894–906, 2013.

[42] B. Franz, A. Schuler, and O. Krauss, “Applying FHIR in an Integrated Health Monitoring System,” EJBI, vol. 11, no. 2, 2015.

[43] A. Delgado and F. Ruiz, “Business process service oriented methodology (BPSOM) with service generation in SoaML,” Adv. Inf. …, pp. 672–680, 2011.

[44] V. M. Medina Cardona and H. Duarte, “BplSoa: framework para el desarrollo de líneas de procesos de negocios orientadas a servicios,” 2014.

[45] B. Elvesæter, C. Carrez, and P. Mohagheghi, Model-driven service engineering with SoaML, no. 25. 2011.

[46] J. Lawler, “The Potential Reality of Service-Oriented Architecture (SOA) in a Cloud Computing Strategy,” J. Inf. Syst. Appl. Res., vol. 4, p. 6, 2011.

[47] AOUTH, “User Authentication with OAuth 2.0,” 2015. [Online]. Available: http://oauth.net/articles/authentication/. [Accessed: 04-May- 2015].