Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR

INTERNAL Equation Chapter 1 Section 1 Trabajo Fin de Grado Ingeniería de Telecomunicación Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR Autor: Mario Martín Casanova Tutor: Jorge Calvillo Arbizu Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2022 iii Proyecto Fin de Grado Ingeniería de Telecomunicación Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR Autor: Mario Martín Casanova Tutor: Jorge Calvillo Arbizu Profesor Ayudante Doctor Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2022 Proyecto Fin de Carrera: Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR Autor: Mario Martín Casanova Tutor: Jorge Calvillo Arbizu El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2022 El Secretario del Tribunal v A mi familia A mis maestros Agradecimientos Quisiera agradecer todo este esfuerzo que he tenido que hacer para llegar hasta este punto a varias personas. En primer lugar, agradecer a mi familia por el apoyo incondicional que me han dado a lo largo no solo de la realización de este trabajo, sino también de la carrera. En segundo lugar, agradecer a mi tutor Jorge por hacer que todo sea más sencillo. Desde el inicio de la carrera le dije que sería mi tutor de TFG y así fue. En tercer lugar, agradecer a todos mis amigos tanto de Huelva como los que he hecho a lo largo de la carrera. Fran, Estrella, Miguel, Alejandro. Han sido mi soporte y no estaría donde estoy si no fuera gracias a ellos. Por último, dejar cuatro menciones especiales que son las personas, junto con mi familia, que más me han aportado y les tengo un amor inmenso. Francisco, Cinta, Víctor y Julia. Aportáis mucho más de lo que realmente pensáis. Mario Martín Casanova Sevilla, 2022 vii Resumen La Regulación General de Protección de Datos (GDPR) establece que el tratamiento de datos personales por parte de las organizaciones debe estar previamente autorizado por los propios ciudadanos a los que se refieren dichos datos. En el dominio sanitario es aún más importante puesto que los datos personales incluyen información sensible como es la relacionada con la salud de la persona. Por ello, el uso que una organización sanitaria hace de los datos sanitarios de sus pacientes (por ejemplo, para análisis, investigación, docencia, etc.) debe estar autorizada por los propios pacientes. Tradicionalmente el paciente firmaba un consentimiento en papel antes de recibir un servicio por parte de la organización. No obstante, con la revolución digital de todos los sectores de la sociedad podemos encontrarnos que los ciudadanos creen consentimientos independientemente de las organizaciones sanitarias y sean gestionados por terceros (por ejemplo, agencias gubernamentales). Este trabajo parte de dicho escenario y se basa en la adquisición y filtrado de consentimientos por parte de una organización sanitaria desde una entidad de gestión de consentimientos. La organización sanitaria deberá así recoger solo aquellos consentimientos de sus pacientes y que sean relevantes con la información almacenada en sus sistemas de información sanitarios. De esta forma, cada corporación observará los pacientes que tiene y reunirá los consentimientos públicos para filtrarlos, recogiendo la información que se tiene sobre cada una de las personas en su base de datos privada. En el caso de que exista un consentimiento que restringe o acepta cierta acción, pero el paciente no contiene dichos de datos, se desechará ya que no se le dará un uso al consentimiento. La idea principal es almacenar consentimientos de los pacientes que estén relacionados con la información que se tiene sobre ellos, así si la organización quiere realizar un estudio pues revisará los consentimientos de la persona específica para mirar si se ha aceptado o se ha denegado el uso. El formato de los consentimientos adopta el estándar FHIR de Health Level 7 International (HL7 ®) diseñado para permitir un intercambio rápido de registros sanitarios electrónicos. FHIR trata de combinar lo mejor de cada uno de los modelos que están actualmente en uso con estándares web modernos de forma que se mejore en la medida de lo posible la implementación de los estándares de interoperabilidad. Finalmente, se llega a la conclusión de que es necesario comprobar los consentimientos de los pacientes en el caso de que la organización sanitaria quiera realizar un estudio. Para ello, se va a usar el estándar FHIR con la definición de 4 recursos (pueden ser más). Además, se hace uso de la API que proporciona el estándar llamado HAPI-FHIR para almacenar primeramente los datos de los pacientes y su información correspondiente. Para almacenar los consentimientos se ha decidido usar una base de datos no relacional (por ejemplo, MongoDB). Se ha de remarcar que el uso de esta aplicación es muy sencillo para la organización y que en un futuro que exista una interfaz gráfica hará que sea más intuitivo, facilitando el trabajo. Finalmente, el uso de FHIR no es sencillo y sumándole la poca documentación que existe hace que el realizar un proyecto sobre dicho estándar sea un trabajo tedioso. ix Abstract The General Data Protection Regulation (GDPR) states that the processing of personal data by organisations must be previously authorised by the citizens to whom the data relates. In the field of health, it is even more important since personal data include sensitive information such as that related to the health of the person. Therefore, a healthcare organisation’s use of its patients' health data (e. g. for analysis, research, teaching, etc. ) must be authorised by the patients themselves. Traditionally, the patient signed a written consent before receiving a service from the organization. However, with the digital revolution in all sectors of society, we may find that citizens create consents independently of health organisations and are managed by third parties (e. g. government agencies). This work starts from this scenario and is based on the acquisition and filtering of consents by a health organization from a consent management entity. The healthcare organisation should therefore collect only those consents of its patients that are relevant to the information stored in its healthcare information systems. In this way, each corporation will observe the patients it has and gather public consents to filter them, collecting the information it has about each individual in its private database. In the event that there is a consent that restricts or accepts a certain action, but the patient does not contain such data, it will be discarded as the consent will not be used. The main idea is to store patient consents that are related to the information that is held about them, so if the organization wants to conduct a study it will review the consents of the specific person to see if the use has been accepted or denied. The form of consent adopts the FHIR standard of Health Level 7 International (HL7 ®) designed to enable rapid exchange of electronic health records. FHIR strives to combine the best of each of the models currently in use with modern web standards so that the implementation of interoperability standards is improved as much as possible. Finally, it is concluded that it is necessary to check patients' consent if the health organisation wants to carry out a study. For this, we will use the FHIR standard with the definition of 4 resources (may be more). In addition, the API provided by the standard called HAPI-FHIR is used to first store patient data and related information. To store consents it has been decided to use a non-relational database (e. g. MongoDB). It should be noted that the use of this application is very simple for the organization and that in the future the existence of a graphical interface will make it more intuitive, facilitating the work. Finally, the use of FHIR is not easy and adding the little documentation that exists makes it tedious to carry out a project on this standard. Ilustración 2.33 Representación de diagrams.net 28 Ilustración 2.34 Maven 29 Ilustración 3.1 POST de un consentimiento 33 Ilustración 3.2 GET al consentimiento 33 Ilustración 3.3 Swagger UI 34 Ilustración 3.4 Consent URL JSON 34 Ilustración 3.5 Estructura del proyecto 36 Ilustración 3.6 Estructura Database 37 Ilustración 3.7 Estructura Filtrado 37 Ilustración 3.8 Estructura Importacion 38 Ilustración 3.9 Diagrama de Actividad de App v1 38 Ilustración 3.10 Diagrama de Actividad del método pocosPacientes 39 Ilustración 3.11 Diagrama de Actividad del método pocosConsentimientos 40 Ilustración 3.12 Diagrama de clase Database 45 Ilustración 3.13 “exeTFG.sh” 46 Ilustración 3.14 POST patient 47 Ilustración 3.15 Body Json 47 Ilustración 3.16 POSTMAN Patient 47 Ilustración 3.17 POSTMAN 201 Created 48 Ilustración 3.18 POSTMAN 400 Bad Request 48 Ilustración 3.19 POST consent 48 Ilustración 3.20 Cuerpo del recurso consent 49 Ilustración 3.21 POST observation 50 Ilustración 3.22 Cuerpo del recurso Observation 50 Ilustración 3.23 Filtro por código 51 Ilustración 3.24 Filtro Codigo MongoDB 51 Ilustración 3.25 Filtro por capa de seguridad 52 Ilustración 3.26 Filtro capa de seguridad MongoDB 52 Ilustración 3.27 Filtro por fecha 53 Ilustración 3.28 Filtro fecha MongoDB 54 Ilustración 3.29 Filtro por referencia 55 Ilustración 3.30 Filtro Referencia MongoDB 55 Ilustración 0.1 Docker Desktop 62 Ilustración 0.2 Servidor FHIR local 63 Ilustración 0.3 Servidor FHIR-REST 63 Ilustración 0.4 CapabilityStatement Postman 64 Ilustración 0.5 Docker mongo 65 Ilustración 0.6 Comando mongo 66 Ilustración 0.7 Extensión mongoDB VScode 66 xvii Ilustración 0.8 Conexión a mongoDB 67 Ilustración 0.9 Menu de MongoDB en VSCode 67 Notación FHIR Fast Health Interoperability Resources HL7 Health Level Seven GDPR General Data Protection Regulation (Reglamento General de Protección de Datos) JSON JavaScript Object Notation POM Project Object Model API Application Programming Interface 1 1 INTRODUCCIÓN n este capítulo se abordarán los temas como la motivación que ha llevado a realizar este trabajo, los objetivos que se desean conseguir, la metodología seguida en el transcurso de la operación y por último un esquema que mostrará el tiempo invertido en este proyecto. 1.1 Motivación y objetivos Uno de los pilares fundamentales en el nuevo Reglamento Europeo de Protección de Datos (GDPR) es el consentimiento de los interesados como forma de legitimar el tratamiento de sus datos personales. Un campo en el que el consentimiento informado toma especial importancia es el sanitario puesto que trabajan no solo con datos personales habituales, sino también con lo que se conoce como información sensible. [1] El GDPR afecta a todos los profesionales que operan en el sector sanitario y su correcta aplicación es incluso mayor que en otros ámbitos, ya que el tipo de datos que tratan son especialmente sensibles: los datos de salud. El matiz novedoso es que también se incluye como datos de salud la información o datos relativos a la prestación de servicios de atención sanitaria que revelen información sobre el estado de salud de una persona. Por lo trascendental que puede tener este tipo de datos para la privacidad del interesado, el GDPR otorga a este tipo de datos mayor protección, lo cual hace que se deban cumplir una serie de condiciones adicionales para su tratamiento [3]. De esta forma, existen algunos derechos listados a continuación: - Derecho a estar informado o Un sujeto tiene el derecho a conocer cómo serán sus datos recolectados, procesados, almacenados y con qué finalidad. - Derecho al acceso o Un sujeto tiene el derecho a conocer cómo los datos existentes han sido recolectados, procesados y almacenados, y con qué propósitos. - Derecho a la corrección o Un sujeto tiene el derecho a obtener la corrección de datos que estén incompletos o incorrectos. - Derecho a la eliminación (Derecho a ser olvidado) o Un sujeto tiene el derecho de tener sus datos personales eliminados de forma permanente. - Derecho a restringir el procesamiento o Un sujeto tiene el derecho de bloquear o suprimir sus datos personales en el momento en que están siendo procesados o en uso. - Derecho a la portabilidad de datos o Un sujeto tiene el derecho de mover, copiar, o transferir datos personales de un controlador a otro, de una forma segura, en un formato legible y comúnmente usado. - Derecho a objetar el procesamiento o Un sujeto tiene el derecho a objetar el hecho de ser sujeto para autoridades públicas o empresas E Introducción 2 que procesen sus datos sin un consentimiento explícito. - Derecho a no ser sujeto de toma de decisiones automatizadas o Un sujeto tiene el derecho de solicitar intervención humana en la toma de decisiones, en lugar de ser objetivo de decisiones tomadas solamente por algoritmos. Sin embargo, lo que se ha explicado previamente no se refleja con la realidad ya que la mayoría de las organizaciones gestionan los consentimientos de manera limitada sin observar la amplitud de derechos considerados en la GDPR.[4] Tras lo explicado previamente, se ha decidido desarrollar un proyecto en el que se lleve a cabo la importación y filtrado de los consentimientos de los pacientes por parte de una organización sanitaria desde otras organizaciones de gestión de consentimientos. La organización sanitaria deberá así recoger solo aquellos consentimientos de sus pacientes y que sean relevantes con la información almacenada en sus sistemas de información sanitarios. Para ello, hay que apoyarse en el estándar más conocido en el ámbito de la sanidad FHIR. En él, se define el formato y cómo se representan los datos con los que se trabajará. Ciertamente, en este proyecto se busca realizar un análisis detallado sobre el funcionamiento y el formato de la representación de la información sobre dicho estándar. De hecho, otro objetivo es aplicar los derechos del Reglamento Europeo de Protección de Datos sobre FHIR, para poder generar un programa que permita importar los consentimientos de los pacientes de una organización sanitaria. Ilustración 1.1 Estructura del proyecto Como se puede observar en la Figura 1.1 la estructura del proyecto se basa en la división de la organización sanitaria y otras organizaciones que gestionan consentimientos de ciudadanos. Las organizaciones sanitarias contienen una base de datos donde almacenan o reside la información de sus pacientes. Por ende, el servicio de importación se va a encargar de recoger todos los informes de dicha base de datos (contiene todos los pacientes) para posteriormente, solicitar a las entidades de gestión de consentimientos los asociados a cada uno de ellos. Cabe destacar que se ha optimizado de tal forma que, si el consentimiento ya se ha guardado previamente y no se ha modificado, no se realizará todo el proceso y se desechará inmediatamente. Dado que 3 3 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL se recogen datos que pertenecen a otras entidades, se necesita un filtrado para poder eliminar aquella información que no se corresponda con los datos que se tiene guardado de los pacientes. Una vez que han pasado la depuración, se almacenará en una base de datos específica de consentimientos. 1.2 Metodología Empleada La metodología empleada para el desarrollo del trabajo está basada en el modelo incremental. Este método combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos y tiene como objetivo un crecimiento progresivo de la funcionalidad. Por tanto, el producto se irá desarrollando con cada una de las entregas previstas.[5] Ilustración 1.1.2 Metodología incremental Como se puede observar en la Figura 1.2 el proyecto se desarrolla mediante iteraciones de incrementos los cuales se dividen en cinco fases. No todos los modelos incrementales siguen estas fases, son flexibles en su representación y depende de la empresa. Cuando acaba el último periodo se produce una retroalimentación y se vuelve a empezar con el primer ciclo. Este método es muy usando en metodologías como SCRUM y AGILE. El primer incremento representa el desarrollo del núcleo del proyecto. Cuando acaba, se produce una retroalimentación, que permite aprovechar los conocimientos y experiencia aprendidos de dicha fase para poder progresar de forma más sencilla en la siguiente iteración. El último incremento acaba cuando el cliente ya está satisfecho con su solución. 1.3 Plan de trabajo En la Tabla adjunta se puede observar todas las tareas que se han realizado para llegar al final del proyecto. Introducción 4 Tabla 1 Plan de trabajo Tareas Horas estimadas Horas reales Estudio del estándar FHIR y su API 10 20 Estudio de los recursos FHIR que se van a implementar 7 15 Estudio de la base de datos HAPI-FHIR 10 20 Estudio de la librería HAPI-FHIR 30 40 Diseño e implementación de la estructura del proyecto 10 15 Implementación del código de los puntos anteriores 60 80 Pruebas y evaluación de los resultados obtenidos 40 50 Corrección de errores 80 90 Total de horas 247 330 5 2 MATERIALES continuación se va a describir la parte teórica del proyecto. En este capítulo se involucra la definición del estándar FHIR junto con su implementación y los recursos que han sido necesarios para el desarrollo del proyecto. Por último, se explica qué materiales se han usado a lo largo del proyecto, por qué y qué han aportado. 2.1 FHIR La medicina es una ciencia de la salud dedicada a la prevención, diagnóstico, pronóstico y tratamiento de las enfermedades, lesiones y problemas de salud del ser humano que se lleva practicando desde la época de la prehistoria. Asimismo, el tiempo transcurre y se ha convertido en una de las ciencias más básicas e importantes. Con ello, otra ciencia muy importante que se ha desarrollado de forma paralela y ha llegado a cruzarse sus caminos es la tecnología. HL7 es el ejemplo perfecto de la fusión de la tecnología y la sanidad. Este es un promotor que hace más sencillo la interoperabilidad entre todas las partes del mundo. Las siglas vienen dadas por Health Level Seven y es una organización de Desarrollo de Estándares para el ámbito de la salud. Fue fundada sin ánimo de lucro en 1987, opera a nivel internacional y su misión es proveer estándares globales para los dominios clínicos, asistencial, administrativo y logístico para conseguir una interoperabilidad entre los diferentes sistemas de información en el área de la salud. HL7 fue quien dio forma y definió FHIR, el significado de las siglas viene dadas por Fast Healthcare Interoperability Resources y es una especificación de plataforma que describe formatos y elementos de datos, también conocidos como recursos. Estos (los recursos) son la unidad básica de interoperabilidad y la más pequeña que se puede intercambiar de manera significativa. Se pueden usar en la forma más simple o como un mensaje (los recursos se adaptan a los segmentos del mensaje), los documentos (como colecciones de recursos agrupados) o los servicios (usando uno o más recursos) también se pueden agrupar. Todos los recursos, salvo excepciones, contienen un identificador a través de la cual puede ser registrado, localizado y recuperado. También tienen extensiones que permite a los implementadores agregar fácilmente nuevas propiedades. Todo esto hace que los documentos físicos no sean archivados y se pierdan en el transcurso del tiempo. Ahora los datos están directamente disponibles como servicios. Por ejemplo, se puede acceder y editar datos médicos como pacientes, admisiones hospitalarias, informes de diagnóstico y medicamentos mediante URL de recursos únicos. En la página oficial de FHIR [6] se divide en módulos la documentación para ayudar a responder ciertas preguntas a los usuarios. Cada uno de ellos representa un área funcional diferente de la especificación. Como se puede observar en la Figura 2.1, existen cinco niveles distintos: • Primer nivel: Representa el marco básico desde donde se construye las especificaciones. • Segundo nivel: Muestra información sobre la implementación y la vinculación a especificaciones externas. A MATERIALES 6 • Tercer nivel: Relaciona los conceptos de la vida real con los de los sistemas de salud. • Cuarto nivel: Objetos de información para el registro e intercambio de datos en el proceso sanitario. • Quinto nivel: Recursos relacionados con la capacidad de razonar sobre el proceso de atención de la salud. Ilustración 2.1 Módulos FHIR 2.1.1 Tipos de datos FHIR tiene establecido y definido ciertos tipos de datos. Estos se dividen en cuatro categorías que pueden ser [9]: • Tipos simples / primitivos: Son elementos individuales con un valor primitivo, es decir, tienen un único valor y no tienen elementos adicionales como hijos, aunque, como todos los tipos, tiene extensiones. 7 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Ilustración 2.2 Datos primitivos Se muestra a continuación un ejemplo de cómo se realiza la representación completa en el formato JSON. Se puede ver que el valor muestra la propiedad en sí misma. Ilustración 2.3 JSON primitivo • Tipos complejos: Se realiza un uso general y son grupos de elementos reutilizables. MATERIALES 14 - Consentimiento para recopilar, acceder, usar o divulgar (compartir) información. - Política de Consentimiento Médico: Consentimiento (o registro de negativa de consentimiento) para recibir ciertos tratamientos médicos. - Política de consentimiento de investigación: se requiere consentimiento para participar en protocolos de investigación y compartir información. - Testamentos en vida: estar de acuerdo con cualquier orden de tratamiento necesaria (como DNR). Este recurso está diseñado para cubrir los cuatro casos de uso, pero actualmente solo se modela el caso de uso de protección de datos. El alcance de los recursos está sujeto a cambios a medida que se exploran, prueban o perfilan otras áreas potenciales. [10] Ilustración 2.14 FHIR consentimiento parte 1 Ilustración 2.15 FHIR consentimiento parte 2 15 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Ilustración 2.16 Consentimiento JSON Para este proyecto, este recurso es el más importante de todos porque indicará a las organizaciones sanitarias si los pacientes permiten o no el tratamiento de sus datos de salud para propósitos diferentes al de la asistencia sanitaria. La organización si quiere usar la información con un fin no puede tramitarlo como quiera, necesita el permiso del sujeto asociado a dicho consentimiento y por tanto será necesario acudir a este recurso para conocer si se permite o no. MATERIALES 16 2.1.2.3 Bundle Bundle es un recurso FHIR que se encuentra dentro del grupo de “Otros” en la zona de “Fundación”. Su grado de madurez es el máximo, “Normative”. Este es un contenedor de colección de recursos. Dado que un paquete en sí mismo es un recurso, tiene los mismos metadatos comunes que todos los recursos, incluyendo afirmaciones de perfiles, etiquetas y etiquetas de seguridad. Aunque el propio recurso Bundle no contiente extensiones, a pesar de ello “link”, “entry”, “search/request/response” pueden sí contenerlo. Un bundle suele contener una colección de recursos en una sola instancia con un contexto contenedor. En FHIR, esto se denomina "agrupación" de recursos. Estos paquetes son útiles por unas grandes variedades de razones. Por ejemplo, si se devuelve un conjunto de recursos que cumplen los criterios especificados como parte de una operación del servidor y también retorna un grupo de versiones de recursos como parte de una operación de historial en el servidor. Además, agrupa un conjunto autónomo de recursos para servir como una colección permanente e intercambiable con integridad clínica. Por último, crea/actualiza/elimina registros de recursos en el servidor como una sola operación, incluida su realización como una sola transacción atómica y almacena colecciones de recursos. Se muestra en la siguiente Figura los campos que contiene dicho recurso y los tipos de datos.[13] 17 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Ilustración 2.17 Recurso Bundle MATERIALES 18 Ilustración 2.18 Instancia de recurso Bundle en formato JSON Este recurso se ha usado en el proyecto para almacenar, en formato de lista, información de todos los otros recursos. 2.1.2.4 Observation Este recurso se encarga de las mediciones y las simples afirmaciones hechas sobre un paciente, dispositivo u otro sujeto. Además, es un recurso de eventos desde una perspectiva de flujo de trabajo FHIR. Observation es un elemento central de la asistencia sanitaria, usado para apoyar el diagnóstico, monitorizar el progreso y determinar líneas de base y patrones. También para captar características demográficas. La mayoría de estos recursos son simples aserciones de pares de nombre/valor con algunos metadatos, pero algunas observaciones agrupan otras observaciones lógicamente, o incluso son de varios componentes. Se observa que el recurso DiagnosticReport proporciona un contexto clínico o de flujo de trabajo para un conjunto de observaciones y DiagnosticReport hace referencia al recurso Observation para representar datos de laboratorio, imágenes y otros datos clínicos y diagnósticos para formar un informe completo. Este tipo de recuso se usa para: - Signos vitales como el peso corporal, la presión sanguínea y la temperatura - Datos de laboratorio como sangre, glucosa y tasa de filtración glomerular estimada - Datos de densidad de los huesos y medidas fetales - Medidas de dispositivos como los datos EKG o los datos de pulso de oximetría 19 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL - Características personales como el color de los ojos… - Características principales como el estado de embarazo, o una afirmación de una muerte - Antecedentes sociales como el consumo del tabaco, el apoyo familiar o el estado cognitivo Ilustración 2.19 Recurso Observation parte 1 MATERIALES 20 Ilustración 2.20 Recurso Observation parte 2 21 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Ilustración 2.21 Instancia de recurso Observation en formato JSON MATERIALES 22 Este recurso se ha usado en el proyecto para marcar la información de los pacientes. Ya que cuando un paciente visita una organización sanitaria se genera información sobre la acción que ha realizado. Todos estos datos se guardan en este tipo de recurso para luego compararlo con los consentimientos y saber si la entidad puede realizar estudios.[12] 2.2 Herramientas Software Para poder realizar este proyecto se ha hecho uso de programas que han ayudado al desarrollo del trabajo y son los siguientes. 2.2.1 Visual Studio Code Microsoft ha desarrollado un editor de código fuente llamado Visual Studio Code (VS Code) basado en Electron. Es compatible con la mayoría de los lenguajes de programación, contiene multitud de extensiones para lenguajes de programación como PHP, Python, Java … y muchos más. Además, incluye soporte para JavaScript, Node.js Está disponible en los tres sistemas operativos más usados, Linux/GNU, Windows y macOS y es software libre. La integración con Git es extraordinaria, contando con soporte para la depuración de código, multitud de extensiones que se pueden descargar en el propio programa, posibilidad de personalizar el diseño de las letras.[25] Gracias a este programa, se ha desarrollado la mayoría del proyecto, además se han incluido varias extensiones como pueden ser: - Docker, es una aplicación de contenedores que ha permitido que se pueda realizar el despliegue de dos aplicaciones que son mongoDB (base de datos no relacional) y HapiFHIR (base de datos FHIR implementada en una página web) - MongoDB: Es una base de datos no relacional que desde VS Code ha permitido observar de forma gráfica toda la información que existe y se ha ido guardando. También se puede ver desde el terminal. - Maven: Es una herramienta de software para la gestión y construcción de proyectos en Java. Se ha usado en este proyecto para importar librerías como “hapi fhir”, “mongo-db”, “slf4j-api” y otras. Ilustración 2.22 IDE VS CODE 23 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Ilustración 2.23 Visual Studio code Logo 2.2.2 Postman Postman es una herramienta que sirve para realizar peticiones RESTful y está disponible como una aplicación de escritorio para cualquier sistema operativo, GNU/Linux, Windows, macOS. [23]Tiene la estructura de cliente-servidor, siendo el cliente HTTP que realiza las peticiones al servidor. Para poder generar una solicitud hay que especificar la URL destino y seleccionar el tipo de mensaje que se desea. Los tipos de peticiones RESTful que existen en POSTMAN son: - GET, se solicitan datos de lectura, se puede obtener un mensaje 200 (todo ha ido bien y se ha encontrado el recurso) o bien 404 (algo ha ido mal). - POST, es solicitado para realizar la creación de un nuevo registro. - PUT, su uso está basado en la actualización de recursos existentes. - DELETE, este tipo de mensaje se usa para mandar una petición de borrado. - PATCH, este método es similar a PUT porque permite actualizar registros existentes. Sin embargo, solo se desea actualizar un fragmento del registro. - HEAD, este método se usa para obtener información sobre un determinado recurso. - OPTIONS, este tipo de petición RESTful se usa para determinar las opciones de comunicación para el recurso de destino. Esta aplicación se ha usado en el proyecto para realizar peticiones GET depurando y comprobando el perfecto funcionamiento. Además, se han insertado los recursos FHIR a la base de datos. Se detallará en los próximos capítulos cómo se ha realizado.[24] MATERIALES 30 cambió el nombre de Swagger a Especificación OpenAPI, pero todavía se lo conoce informalmente como Swagger. 31 3 RESULTADOS e va a detallar el desarrollo y los resultados del trabajo en el presente capítulo. Con ello primero se comentará como se ha realizado la puesta en marcha del servidor FHIR, junto con las otras posibles soluciones. Además, se mostrará un trabajo previo que ha sido necesario realizar para poder poner en marcha el proyecto. De forma análoga, se detallarán todas las partes del trabajo con su funcionalidad correspondiente. Para finalizar, se mostrará el modelado de la base de datos de los consentimientos junto con las pruebas que demuestran el buen funcionamiento de las partes que se han implementado. 3.1 Análisis del proyecto En este apartado se va a explicar detalladamente la funcionalidad que tiene el trabajo y los distintos problemas que se han encontrado en el transcurso del proyecto. Ilustración 1.1 Estructura del proyecto 3.1.1 Base de datos EHR FHIR Para poder realizar este proyecto es necesario montar una base de datos local HAPI-FHIR donde se tiene almacenados todos los pacientes de la organización sanitaria. Para ello, se ha decidido realizar un trabajo previo donde se almacene la información necesaria para este proyecto. Se muestra cierta información sobre ellos: - Patient El recurso Patient está en el último grado de madurez, esto quiere decir que no sufrirá modificaciones. La estructura de datos se almacenará en formato JSON. Es importante subir primero el recurso Patient porque más en adelante se verá que el recurso Consent y Observation dependen de este. S Resultados 32 Entonces, generará una errata porque se subirá un consentimiento asociado con un paciente y este no existe en la base de datos. Por tanto, a pesar de que sintácticamente es correcto generará un error de que no existe dicha persona en la base de datos. El cómo subir la información a la base de datos se explicará detenidamente más adelante. Cabe destacar que se puede crear el recurso con los campos que el usuario desee o bien puede acceder a la base de datos pública copiando uno de los que ha proporcionado la comunidad. - Consent Este recurso es el más importante del proyecto. Como se ha comentado en el punto anterior, para poder subir cualquier información de tipo Consent tiene que existir un paciente que este asociado a dicho consentimiento. Los campos a destacar de dicho recurso son: • Provision o code: este campo indica el código que regirá el consentimiento. Puede ser de distintos tipos como LOINC o SNOMED CT. o data.reference: Indica la referencia actual de datos del consentimiento por el que se rige. o securityLabel: este campo indica las etiquetas de seguridad que definen los recursos afectados. o dataPeriod: este campo indica el periodo/intervalo de validación de un consentimiento. o type: este campo indica si el consentimiento restringe los datos o los permite. - Observation Este recurso también depende de Patient. Por tanto, es necesario primero que exista en el base de datos el paciente asociado al recurso Observation. Los campos a destacar son: • Subject: campo usado para guardar la referencia de quién o de qué trata la observación. • EffectiveDateTime: marca el tiempo relevante de la observación • Code: se guarda la representación de un valor que es una referencia a las terminologías u ontologías como LOINC, SNOMED CT… 3.1.1.1 Postman Se realiza una petición REST llamada “POST” en la que se insertará información, según como indica Postman en formato “raw”. Después, se debe introducir la URL necesaria, en este caso http://localhost:8080/fhir/Consent. Es importante indicar que el tipo de dato que se va a introducir es de tipo JSON. 33 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Ilustración 3.1 POST de un consentimiento Como se puede observar en la Figura anterior, el estado de la operación es 201 por tanto se ha creado el objeto correctamente. Si se desea comprobar, se puede acceder al navegador (se detallará más en adelante) o bien se puede realizar una petición GET en POSTMAN a la URL http://localhost:8080/consent/{id} siendo el id 1852. Recordar que el id se ha establecido de forma aleatoria, como ya existe un consentimiento con el id que se ha establecido en el cuerpo, se ha puesto uno al azar. En la siguiente Figura se puede observar como el estado de la operación es un 200 OK recibiéndose el consentimiento que se había escrito anteriormente en el cuerpo de la petición. Por tanto, todo ha transcurrido de forma correcta. Ilustración 3.2 GET al consentimiento Resultados 34 3.1.1.2 Swagger UI Por ello, cuando se accede a la URL http://localhost:8080/fhir, se selecciona la opción de Consent y tras ello se obtendrá una gran serie de peticiones REST que se puede aplicar de forma directa. Para poder subir un nuevo consentimiento en la base de datos se tiene que escoger la opción de POST /Consent. En ella, se mostrará una interfaz sencilla donde se deberá insertar el cuerpo de la información en formato JSON. Tras realizarlo, se subirá a la base de datos y en la siguiente Figura se puede observar cómo se puede recoger la información de un consentimiento a través de su id. Se puede ver que es correcto porque la respuesta que se recibe es un 200 OK Ilustración 3.3 Swagger UI También se proporciona la URL de la petición que si se copia y se pega en el navegador se obtiene el objeto en formato JSON. Ilustración 3.4 Consent URL JSON Para este proyecto se ha decidido usar Swagger UI para subir la información de los recursos FHIR. 35 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL 3.1.2 Servicio de Importación El servicio de importación se va a encargar primero de recoger todos los pacientes de la base de datos en un recurso llamado ‘Bundle’ (agrupa o contiene hasta 20 pacientes distintos en una página). Una vez recogido los recursos de todos los pacientes, la organización sanitaria pedirá a todas las entidades existentes de gestión de consentimientos información sobre los consentimientos asociados a cada uno de los pacientes. Cabe destacar que puede existir más de un consentimiento asociado a un paciente. Una vez que se ha realizado la importación de los consentimientos de los pacientes, se pasan al servicio de filtrado para que produzca la depuración de los consentimientos. 3.1.3 Servicio de Filtrado Cuando se ha realizado la importación, todos los consentimientos de cada paciente deben de ser filtrados. Esto se debe a que se quieren almacenar solo aquellos consentimientos relacionados con la información que la organización sanitaria tenga de cada paciente. Por tanto, si se obtuviese un consentimiento que no estuviese relacionado con los datos que tiene la organización sobre dicho sujeto, entonces se desechará y no se guardará en la base de datos. Este pequeño resumen se muestra en la Ilustración 1.1, se puede ver cómo el servicio de filtrado, que recibe tan solo consentimientos, solicita información a la base de datos para comparar los documentos que se tienen del paciente y lo que este permite tramitar. Es importante destacar que las organizaciones sanitarias quieren los consentimientos de todos los pacientes (que se encuentren en su base de datos) para poder controlar cómo se usa la información dentro de la organización. Es decir, si el paciente permite o no el uso de los documentos que se le imputan de forma directa. En este proyecto se han puesto cuatro ejemplos de filtros, se nombran a continuación, pero más tarde se explicarán detalladamente. • Filtrado por nivel de seguridad de la información. • Filtrado por código LOINC o SNOMED de enfermedad. • Filtrado por fecha de creación de datos. • Filtrado por un tipo de dato concreto que en el consentimiento se señale directamente. 3.1.4 Base de datos Consent En esta base de datos se guardará toda la información de los consentimientos que se han imputado a los pacientes con sus correspondientes referencias. Cabe destacar que en el proyecto no se ha realizado tan solo una depuración de la información y la inserción a la base de datos a posteriori. Primero, se comprueba que el consentimiento no existe en la base de datos, en el caso de que exista este se desecha. Segundo, se comprueba si se halla un consentimiento con el mismo id, de esta forma si fuese correcto se extrae un campo que detalla la última actualización que ha tenido el consentimiento, en el caso de que sea mayor se actualiza y si es menor se desecha. Por último, si no existiese se inserta. Resultados 36 3.2 Servidor FHIR El estándar FHIR no proporciona un servidor, por ende, la comunidad se ha encargado de desarrollar un servidor público que todo el mundo pueda acceder (https://hapi.fhir.org/). En él, todas las personas pueden subir los recursos (siempre y cuando sintácticamente sean correctos) de cualquier tipo del estándar. Sin embargo, la desventaja que ofrece para el uso de este proyecto es que es muy recurrente que dejase de funcionar durante un cierto tiempo, lo que impedía y retrasaba el desarrollo del proyecto. Así pues, se decidió implementar un servidor local FHIR. 3.2.1 Instalación Para poder realizar la instalación del servidor se ha usado una página web donde se sube contenido de directorios, archivos, proyectos comúnmente denominados repositorios. El propio estándar FHIR ha subido un repositorio [15] En él se encuentra un archivo que se llama “README.md” en el que se explica detalladamente como se debe realizar la instalación de forma local. A pesar de ello en el Anexo A se explica cómo se realiza el proceso, en el apartado A.1. 3.2.2 Puesta en marcha La puesta en marcha del servicio no ha requerido ninguna modificación. Por tanto, los pasos se marcan en el Anexo, en el apartado A.2. 3.3 Implementación FHIR En esta sección se verá cómo se ha conseguido implementar el proyecto. Se comenzará viendo la estructura del servicio junto con el único paquete que se ha desarrollado para después entrar en el código usado para lograr el correcto funcionamiento. 3.3.1 Estructura El servicio está dividido en varios paquetes. Por tanto, cada paquete genera una funcionalidad distinta y funcionan en conjunto a través de llamadas para darle forma al proyecto. Ilustración 3.5 Estructura del proyecto 37 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Como se puede observar en la Figura, existe un paquete que se llama tfg que sirve para arrancar el servicio. A continuación, se explicará detalladamente la funcionalidad del resto de paquetes. 3.3.1.1 Paquete Database En el paquete Database se tiene las clases correspondientes a la funcionalidad de la base de datos de MongoDB donde se almacenará los consentimientos. A través de la librería de mongo se conectará a la base de datos que se ha desplegado con Docker Desktop para poder realizar la inserción de los archivos o la actualización de estos. Esta clase será llamada por la aplicación general una vez se cumplan con las restricciones previas para poder subir el consentimiento a la base de datos. Cabe destacar que en el caso de que el consentimiento ya esté almacenado en la base de datos este no se guardará. Además, si ha sido actualizado se observará la fecha de modificación para comprobar si se debe de subir a la base de datos o no. Ilustración 3.6 Estructura Database 3.3.1.2 Paquete Filtrado En el paquete de Filtrado se tiene la clase correspondiente con el filtrado de los consentimientos que se han recibido del paquete de importación. Esta clase contiene métodos que depuran la información, próximamente se explicará detalladamente sus funcionalidades. Sin embargo, para poder realizarlo es necesario llamar al paquete de importación para obtener información sobre los pacientes asociados a los consentimientos. De esta forma, se llamará a los distintos métodos de filtrado según las restricciones que exige el consentimiento con las observaciones que se tiene. Este paquete es llamado por la app general tantas veces como consentimientos se hayan recogido de los pacientes. Devolverá una lista con todos los consentimientos que hayan coincidido con la información que se almacena. Ilustración 3.7 Estructura Filtrado Resultados 38 3.3.1.3 Paquete Importación El paquete de importación se encarga de llamar a la base de datos local FHIR, con el código correspondiente de la librería de HAPI-FHIR para poder obtener un Bundle de los datos necesarios (no tiene por qué ser un recurso de tipo Bundle). Esto es posible porque en el constructor de la clase, la aplicación general le pasa por parámetro el contexto de la base de datos además del cliente. Por tanto, se puede acceder a la librería de HAPI FHIR para recoger información, modificarla etc. Ilustración 3.8 Estructura Importacion 3.3.2 Implementación código FHIR 3.3.2.1 App.java A continuación, se muestran los diagramas de clase relacionados. Ilustración 3.9 Diagrama de Actividad de App v1 39 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Como se puede observar en la Ilustración 3.9, se busca primeramente recoger los pacientes que tiene la organización sanitaria. Esto se recoge en formato de recurso Bundle de la base de datos local HAPI-FHIR que se ha desplegado. Una vez obtenido en un Bundle todos los pacientes de la organización sanitaria se comprueban si son más de viente pacientes o menos. Según una opción u otra pues se invocará a un método u a otro. Cabe destacar que se comprueba si son más de veinte pacinetes porque la base de datos HAPIFHIR almacena la información de los pacientes en un recurso Bundle, en el momento que supera dicha cantidad se instancia un nuevo Bundle con veinte pacientes más. Ilustración 3.10 Diagrama de Actividad del método pocosPacientes Como se puede observar en la Ilustración 3.10, se ha invocado un método de la clase App llamado pocosPacientes. Este se encarga de forma iterativa de recoger los recursos Patient obteniéndolo del Bundle. Después, se obtiene su id correspondiente para recoger los consentimientos asociados (también están almacenados en un recurso Bundle) de dichos pacientes. Los consentimientos se recogerán en el formato de recurso Bundle, como se ha explciado anteriormente solo se pueden almacenar hasta veinte consentimientos en dicho recurso. Por ende, en el caso de que existan más se llamará a un método calculando previamente el número de páginas. Resultados 46 Parámetros de entrada Respuesta Devuelve un objeto de tipo MongoClient con la conexión a la base de datos. Tabla 19 Método insertarDatos Método insertarDatos Descripción Método que se encarga de insertar los datos a la base de datos. Parámetros de entrada Json(String): Consentimiento en formato cadena de texto Respuesta No devuelve nada. Tabla 20 Método comprobarDatos Método comprobarDatos Descripción Método que invoca a todos los paquetes, además de crear el contexto con la base de datos local HAPI FHIR. Ejecuta la aplicación Parámetros de entrada Json(String): Consentimiento en formato cadena de texto Respuesta Devuelve ‘true’ si existe el consentimiento o ‘false’ si no existe Tabla 21 Método actualizarDatos Método actualizarDatos Descripción Método que se encarga de actualizar los datos de la base de datos Parámetros de entrada Json(String): Consentimiento en formato cadena de texto id(String): Id del consentimiento en formato cadena de texto Respuesta No devuelve nada. Tabla 22 Método recogerConsent Método recogerConsent Descripción Método que se encarga de recoger un consentimiento. Parámetros de entrada id(String): Id del consentimiento en formato cadena de texto Respuesta Devuelve el consentimiento si lo encuentra, sino null. 3.5 Pruebas 3.5.1 Ejecución de la aplicación Para poder realizar la ejecución de la aplicación se necesitan los siguientes archivos que se han hecho para facilitar el proceso. Ilustración 3.13 “exeTFG.sh” 47 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Se ha tenido en cuenta que se ha realizado el proceso del Anexo A, ya que se necesita tener en marcha los dos contenedores. 3.5.2 Creación de instancias Patient Se envía un POST a la base de datos con las características de la Figura siguiente. Se usa esta URL, ejecutándose en el servidor local en el puerto 8080. Como se va a insertar un paciente, se tiene que especificar en la URL /Patient. Ilustración 3.14 POST patient Es importante escoger en el cuerpo de la petición el formato raw con la especificación de tipo JSON. Ilustración 3.15 Body Json Una vez realizado estas partes, se inserta el cuerpo del recurso Patient. Ilustración 3.16 POSTMAN Patient Si todo va bien, el servidor local responderá con una respuesta HTTP con código 201 Created. Resultados 48 Ilustración 3.17 POSTMAN 201 Created En el caso de que se haya producido un error sintáctico, el servidor mostrará una respuesta HTTP con código 400 Bad Request. Ilustración 3.18 POSTMAN 400 Bad Request 3.5.3 Creación de instancias Consent Para la creación de un recurso Consent es importante haber realizado un estudio de los campos que se van a necesitar de estándar. Posteriormente, una vez escrito el cuerpo del mensaje (en formato JSON) se tiene que enviar la petición a la siguiente URL. Esta petición viajará hacia el servidor local por el puerto 8080. En la Ilustración 3.20 se muestra el cuerpo del mensaje del recurso Consent. Ilustración 3.19 POST consent 49 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Ilustración 3.20 Cuerpo del recurso consent El proceso de realizar una petición POST es el mismo que se ha aplicado en el recurso Patient. Donde se recibe una respuesta HTTP desde el servidor 201 Created si se ha creado correctamente el servidor y un 400 Bad Request en el caso de que exista un error en el cuerpo de la petición. 3.5.4 Creación de instancias Observation Como en los casos anteriores, para poder insertar un recurso se necesita la siguiente URL http://localhost:8080/fhir/<recurso>/ En este caso, como se desea insertar el recurso Observation pues se cumple con lo establecido anteriormente. En la Ilustración 3.22 se puede observar los campos que se han rellenado de recurso Observation. No son estándares, es decir, no es necesarios que todos los pacientes de la organización sanitaria deban de tener los mismos campos. Esto mismo se aplica a los demás recursos Resultados 50 Ilustración 3.21 POST observation Ilustración 3.22 Cuerpo del recurso Observation Ya se ha comentado en los puntos anteriores las respuestas que se obtiene por parte del servidor en el caso de que el recurso no esté bien escrito sintácticamente y cuando no hay ningún error. 3.5.5 Filtrar por código En los apartados anteriores se ha explicado que se hace un proceso de filtrado. Sin embargo, no se ha especificado exactamente cómo se realiza, pues se pueden implementar numerosos filtros. En este apartado y los sucesivos, describimos algunos tipos de filtros de consentimientos. En este primer caso, la filtración se realizará comparando el campo del consentimiento “code” con el campo “code” de todos los recursos Observation asociados al mismo paciente. En la siguiente figura se puede observar cómo ciertos consentimientos pasan el filtro. Cabe destacar que, para este caso, se ha modificado el código para que se muestra visualmente los consentimientos que pasan el filtro. Lo ideal es que no se muestre nada porque ciertas organizaciones sanitarias pueden contener grandes cantidades de pacientes y esto lo haría incomprensible. 51 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Ilustración 3.23 Filtro por código Para comprobar que se ha subido a la base de datos, se muestra en la siguiente Figura donde uno de los consentimientos ha pasado el filtro. Es decir, la organización sanitaria tiene al menos una instancia de recurso Observation para el paciente del consentimiento, y esa instancia posee el código que indica el consentimiento. Ilustración 3.24 Filtro Codigo MongoDB Resultados 52 3.5.6 Filtrar por capa de seguridad Este tipo de filtrado es muy importante. La idea principal es recoger el campo “provision.securityLabel” del recurso Consent para compararlo con la información que tiene el paciente. En este caso, se debería buscar en el campo “category” del recurso Observation. Por tanto, en el caso de que la organización sanitaria necesite cierta información del paciente para realizar un estudio, se necesitará que exista un consentimiento en el que coincida la capa de seguridad frente a la categoría del paciente. Cabe destacar que el consentimiento puede no permitir el uso de dicha información. En la Ilustración 3.25 se muestra como un consentimiento ha pasado el filtrado y posteriormente como se ha subido a la base de datos. Se puede ver claramente por el ID que se muestra en la Ilustración 3.25 y 3.26. Ilustración 3.25 Filtro por capa de seguridad Ilustración 3.26 Filtro capa de seguridad MongoDB 53 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL 3.5.7 Filtrar por fecha Si una organización sanitaria desea recoger cierta información de un paciente, necesita acudir a los consentimientos que se tiene sobre él para poder observar si el usuario permite o restringe su uso. Un ejemplo para este filtrado puede ser cuando se tiene información en la base de datos de un usuario de una fecha específica. El consentimiento establece que permite que se pueda hacer uso de dichos datos en un intervalo de tiempo, por tanto, en el caso de que la fecha que se tiene está dentro del rango se guarda el consentimiento. Posteriormente, se hace uso de la información del paciente porque el usuario a través del consentimiento lo ha permitido. Para este caso, la filtración se realizará comparando el campo del consentimiento “dataPeriod” con el campo “effectiveDateTime” de todos los recursos Observation asociados al mismo paciente. Ilustración 3.27 Filtro por fecha Resultados 54 Ilustración 3.28 Filtro fecha MongoDB 3.5.8 Filtrar por referencia Por último, existe otro tipo de filtrado que se va a realizar y es el de referencia. Como se ha comentado antes, se recogerán los consentimientos de un paciente para después mandar una petición a la base de datos local HAPI-FHIR sobre la información, en este caso la referencia, de dicho paciente. Se comparará pues el campo del consentimiento “provision.data.reference” con el campo “performer” del recuros observación para saber si la información que tiene la organización sanitaria se cumple con el consentimiento asocaido al paciente. En el caso de que coincida, se almacenará para el posterior uso de la organización. 55 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL En la Figura 3.29 se puede ver como un consentimiento con el ID 5058 ha pasado la depuración. Más tarde, en la Ilustración 3.30 se puede ver en la base de datos MongoDB como sí se ha almacenado correctamente con el id 5058. Ilustración 3.29 Filtro por referencia Ilustración 3.30 Filtro Referencia MongoDB Anexo a: Manual de instalación y despliegue de la aplicación 62 62 ANEXO A: MANUAL DE INSTALACIÓN Y DESPLIEGUE DE LA APLICACIÓN A.1 Instalación del servidor HAPI FHIR Para realizar la instalación del servidor se pueden seguir dos caminos.[26] - Vía Docker: Primero se procede a visitar la página oficial de Docker y descargar la interfaz disponible en los S.O de Apple y de Windows. Una vez descargada, siguiendo los pasos de instalación se obtendrá algo como la Figura, pero sin los contenedores (la foto se realizó después de añadir los contenedores). Ilustración 0.1 Docker Desktop Una vez descargado Docker Desktop, se procede a abrir el terminal e insertar el siguiente comando: docker pull hapiproject/hapi:latest docker run -p 8080:8080 hapiproject/hapi:latest Esto ejecutará la imagen de Docker con la configuración predeterminada, asignando el puerto 8080 en el contenedor al puerto 8080 en el host. A.2 Puesta en marcha del servidor HAPI-FHIR La puesta en marcha del servidor FHIR se rige habiendo realizado el paso anterior. Una vez se hayan ejecutado los comandos, se puede acceder a la interfaz de usuario del servidor HAPI FHIR visitando la URL http://localhost:8080 en cualquier navegador, o puede usar http://localhost:8080/fhir para realizar las solicitudes REST. Otra opción para poder iniciar el servicio es mediante Docker Desktop pulsando el botón de iniciar y tras ello, aparecerá nuevos iconos en el que se deberá pulsar sobre “Abrir en el navegador”. 63 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Existe la opción de cambiar el puerto asignado desde la configuración de HAPI. Ilustración 0.2 Servidor FHIR local Ilustración 0.3 Servidor FHIR-REST Además, se puede observar que el servidor funciona correctamente si en la aplicación POSTMAN se realiza una petición GET sobre la URL localhost:8080/fhir/metadata. Devolverá un recurso de tipo” CapabilityStatement” con información. Anexo a: Manual de instalación y despliegue de la aplicación 64 64 Ilustración 0.4 CapabilityStatement Postman A.3 Instalación MongoDB Como se ha comentado con anterioridad, los consentimientos se guardarán en una base de datos MongoDB. Por tanto, para poder realizar la instalación de dicho programa se seguirán los pasos que se detallan a continuación, aclarar que existen dos formas de realizar la instalación[28]: Þ Vía Docker Los prerrequisitos que se necesitan para instalar mongodb es tener la aplicación de Docker Desktop. Una vez instalada, cualquier usuario puede comenzar con un contenedor MongoDB usando Docker con el siguiente comando en su terminal: docker run –name mongodb -d mongo Este comando empezará a ejecutar un servidor de mongoDB con la última versión disponible. Se recomienda que se use una etiqueta para especificar la versión para asegurar la consistencia. Si necesita acceder al servidor desde otra aplicación que está en local, tendrá que especificar el puerto con el comando -p docker run –name mongodb -d -p 27017:27017 mongo Una vez haya terminado la ejecución ya se dispondrá en la interfaz gráfica de Docker desktop el contenedor de mongo. En él se puede iniciar y se estará haciendo uso de la aplicación en el puerto 27017. Þ Vía manual Para poder realizar la instalación y ejecución de MongoDB de forma manual se debe ir a la sección de descargas de la página web https://www.mongodb.com/try/download/community y descargar la versión correcta que se adapte a las condiciones de su sistema operativo. 65 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Tras descargar mongo, debe mover el archivo comprimido .tar (el archivo con la extensión .tgz que has descargado) al directorio donde desee instalar su base de datos no relacional. Para este caso, se dice que mongo resida en la carpeta de inicio, por lo que se abre el terminal y se expresan los siguientes comandos: • cd Downloads • tar -zxvf mongodb-osx-x86_64-6.0.1.tgz • sudo mv mongodb-macos-x86_64-6.0.1 /usr/local/mongodb • cd /usr/local/mongodb/ • sudo mkdir -p /data/db • cd /data/db • sudo chown mariomartin /data/db • cd • open .bash_profile Entonces el usuario debe de copiar y pegar las dos siguientes líneas en el fichero: export MONGO_PATH=/url/local/mongodb export PATH=$PATH:$MONGO_PATH/bin Esto se hace para poder guardar las variables en el PATH y ejecutar la aplicación con un alias en vez de tener que poner toda la ruta donde se encuentra el archivo. Una vez copiada las dos líneas, se procede a ejecutar el comando “source .bash_profile” para actualizarlo. [27] Por último, se debe de abrir un nuevo terminal para poder ejecutar el servidor con el comando mongod, comúnmente llamado demonio, mientras que en otro terminal se ejecutará el comando mongo (correspondiente al cliente). A.4 Puesta en marcha de MongoDB Una vez se hará ejecutado la instalación del servicio, la puesta en marcha se puede realizar de dos formas: - Vía terminal Para poder acceder desde el terminal se debe pulsar la opción que proporciona Docker “Abrir en un terminal” como en la Figura (en el caso de que se haya instalado la aplicación por Docker Desktop). En él iniciará una nueva ventana en la que se tendrá que escribir el comando “mongo” para poder interactuar con la base de datos. Si se ha instalado manualmente la aplicación solo bastaría con abrir un nuevo terminal y ejecutar el comando anterior, siempre y cuando el demonio, es decir mongod, también esté ejecutándose. Ilustración 0.5 Docker mongo Anexo a: Manual de instalación y despliegue de la aplicación 66 66 Ilustración 0.6 Comando mongo - Vía Visual Studio Code Para poder interactuar con la base de datos desde Visual Studio Code hay que dirigirse al apartado de extensiones y buscar “MongoDB for VS Code”. Una vez se ha instalado, aparecerá un nuevo incono en la esquina izquierda, al pulsar sobre él se mostrará la información que aparecer en la Figura. Cuando el usuario se haya conectado a la base de datos tendrá la opción de observar de forma gráfica toda la información, tal y como se muestra en la Figura x.x Ilustración 0.7 Extensión mongoDB VScode 67 Servicio de adquisición y filtrado de consentimientos de pacientes en formato HL7 FHIR INTERNAL Ilustración 0.8 Conexión a mongoDB Ilustración 0.9 Menu de MongoDB en VSCode