Mecanismo de registro de transacciones de información sanitaria basado en blockchain

Equation Chapter 1 Section 1 Trabajo de Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Mecanismo de registro de transacciones de información sanitaria basado en blockchain Autora: Marta García Benzal Tutor: Jorge Calvillo Arbizu Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2023 iii Trabajo de Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Mecanismo de registro de transacciones de información sanitaria basado en blockchain Autora: Marta García Benzal Tutor: Jorge Calvillo Arbizu Profesor Ayudante Doctor Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2023 v Trabajo de Fin de Grado: Mecanismo de registro de transacciones de información sanitaria basado en blockchain Autora: Marta García Benzal 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, 2023 El Secretario del Tribunal vii Agradecimientos Con este proyecto pongo fin a mis estudios en Ingeniería de las Tecnologías de Telecomunicación. La consecución de este título no habría sido posible sin las personas que me han acompañado en esta etapa. Por ello, quiero aprovechar estas líneas para agradecer su apoyo. En primer lugar, quiero agradecer a Jorge Calvillo, tutor de este trabajo, por la asignación del tema y por la atención rápida, eficaz y cercana durante estos meses de trabajo. Gracias también al resto de docentes del grado por todos los conocimientos transmitidos. A día de hoy ya estoy comprobando que todo lo aprendido en estos años va a serme de gran utilidad y me va a abrir muchas puertas en el futuro. En segundo lugar, quiero agradecer a Pablo, Rocío, María, Isa, Itxaso, Gabriel, Ana, Paula, Marta y Miguel por apoyarme, animarme y escucharme cada vez que lo he necesitado. En Huelva, Sevilla, Francia o cualquier lugar: estar con vosotros es sentirse en casa. Gracias también a Fernando, Celia, Ángel, Rubio, Juanjo, Manolo, Jacinto, Julio, Carlos y Alejandra. Gracias, Pablo, por descubrirme nuevas amistades cuando más lo necesitaba. Lo mejor que me llevo del grado sois vosotros y todos los momentos vividos que llevaré conmigo para siempre. Gracias, Vicente, por cuidarme y creer en mí. Por hacer siempre todo lo posible por verme bien en los malos momentos y por hacer aún mejores los buenos. Eres un verdadero tesoro y yo tengo la suerte de haberte encontrado en este camino. Por último, gracias, papá, por ayudarme y apoyarme, por ser un gran ejemplo para mí, por enseñarme lo que es ser ingeniero y por tener siempre algo nuevo que enseñarme. Gracias, David, por aconsejarme y escucharme siempre. Ojalá logres todas las metas que te propongas, que yo estaré siempre cerca tuya para celebrarlo. Gracias, mamá, por ser mi mayor apoyo en estos años. Por celebrar conmigo cada triunfo y llorar cada mal momento, por escuchar día tras día mi rutina sin importar la monotonía de algunas etapas. Gracias también a mis tíos, abuelos y primos, por seguir de cerca mi evolución en el grado y alegraros de cada pasito que he dado. No sabéis lo afortunada que me siento de tener una familia como vosotros. Lo mejor de cumplir este gran objetivo es poder compartirlo con vosotros. Os quiero con todo mi corazón. Marta García Benzal Sevilla, 2023 ix Resumen En el sector sanitario, los datos son especialmente valiosos. El volumen de datos generados en este sector ha crecido exponencialmente en los últimos años, impulsado por la adopción de tecnologías digitales, la creciente demanda de atención médica y la necesidad de analizar grandes cantidades de información para mejorar la calidad de la atención. Compartir datos sanitarios es una tarea compleja debido a la naturaleza altamente sensible de la información que se maneja. Además, la complejidad del sector de la salud hace que sea difícil intercambiar datos entre diferentes organizaciones, ya que estos datos se almacenan en diferentes formatos y sistemas de información, lo que dificulta el intercambio entre diferentes organizaciones y proveedores de atención médica. A pesar de estas dificultades, este intercambio es fundamental para la investigación y la mejora de la calidad de la atención médica. Por ello, en este proyecto se buscará desarrollar una solución que acompañe a esta distribución de datos. Este mecanismo deberá responder a los principios de seguridad, trazabilidad, descentralización e interoperabilidad para solventar las dificultades expuestas. Con este fin, habrá dos pilares fundamentales en el proyecto: blockchain y FHIR. La primera es una tecnología que permitirá desarrollar y desplegar una red para registrar intercambios de información entre entidades sanitarias, y cubrirá los principios de seguridad, trazabilidad y descentralización. La segunda se trata de un estándar diseñado para facilitar la interoperabilidad entre diferentes sistemas de información sanitaria, por lo que dará cobertura al cuarto principio planteado. En resumen, en el presente trabajo se abordarán los siguientes aspectos: • Desarrollo de una red blockchain para implementar el mecanismo de registro de transacciones. • Uso del estándar FHIR para definir el formato y estructura de las transacciones. • Desarrollo de una aplicación formada por una API REST y una interfaz gráfica de usuario para facilitar la interacción con la red. Figura 3-13. Fragmento de configtx.yaml para el MSP y políticas de firma de la organización HLA. 32 Figura 3-14. Fragmento de configtx.yaml para políticas implícitas. 32 Figura 3-15. Fragmento de configtx.yaml para el bloque génesis y el algoritmo de consenso. 33 Figura 3-16. Ubicación del smartcontract. 33 Figura 3-17. Importación de paquetes en el chaincode. 33 Figura 3-18. Definición de los assets en el chaincode. 34 Figura 3-19. Función Invoke del chaincode. 34 Figura 3-20. Función GetAssetsBySourceOrg del chaincode. 36 Figura 3-21. Perfil de conexión de la organización Viamed. 37 Figura 3-22. Directorios tras la fase 1 del despliegue (I) 38 Figura 3-23. Directorios tras la fase 1 del despliegue (II). 38 Figura 3-24. Creación del canal y unión de los orderers. 39 Figura 3-25. Votación y elección de leader y followers en RAFT. 39 Figura 3-26. Creación de asset a través del CLI. 39 Figura 3-27. Lectura de assets a través del CLI. 40 Figura 3-28. Contenido de la ledger desde couchDB. 40 Figura 3-29. Acciones del SDK 41 Figura 3-30. Estructura de directorios de la aplicación. 41 Figura 3-31. Secuencia de alta de un usuario en la red. 42 Figura 3-32. Wallets tras la creación de identidades. 43 Figura 3-33. Endpoint /login. 43 Figura 3-34. Endpoint /ledger/invoke. 44 Figura 3-35. Función query de ledgerActions.js 46 Figura 3-36. Creación del servidor HTTPS. 47 Figura 3-37. Ejemplo de login con Postman. 47 Figura 3-38. Ejemplo de invoke con Postman. 48 Figura 3-39. Ejemplo de query y cabecera authorization con Postman. 48 Figura 3-40. Página de inicio de sesión de la interfaz. 49 Figura 3-41. Ejemplo de petición con Axios para readByDate. 50 Figura 3-42. Nombres, direcciones IP y contenedores de los equipos del escenario. 51 Figura 3-43. Cambios en la configuración de CAs para swarm. 51 Figura 3-44. Sección extra_hosts en la configuración del swarm para el peer0 de la organización SAS. 52 Figura 3-45. Comprobación de despliegue en los equipos correspondientes. 52 Figura 3-46. Error en login. 53 Figura 3-47. Vista principal de la interfaz. 53 Figura 3-48. NewTransaction en interfaz. 54 Figura 3-49. Resultado de ReadAll en la interfaz. 54 Figura 3-50. Resultado de ReadBySource en la interfaz. 54 Figura 3-51. Fragmento del resultado de una búsqueda en formato JSON. 55 xvii Notación ACK Acknowledgement API Application Programming Interface CLI Command Line Interface CSR Solicitud de Firma de Certificado EHR Electrinic Health Record FHIR Fast Healthcare Interoperability Resource JSON JavaScript Object Notation JWT JSON Web Token MSP Membership Service Provider PoS Proof of Stake PoW Proof of Work RGPD Reglamento General de Protección de Datos SDK Software Development Kit SGBD Sistema Gestor de Bases de Datos SNS UE Sistema Nacional de Salud Unión Europea 1 1 INTRODUCCIÓN n este capítulo se presentarán los motivos que han llevado a la realización de este proyecto, cuyo resultado será el desarrollo de una red blockchain para dar soporte al registro de transacciones de información sanitaria entre organizaciones. Además, se expondrán los objetivos que se pretenden lograr con la solución adoptada, así como la metodología y el plan de trabajo seguidos en el desarrollo del proyecto. 1.1. Motivación y objetivos El desarrollo incesante de la tecnología en todos los ámbitos de nuestras vidas, incluido el de la salud, ha permitido que las organizaciones sanitarias abandonen el almacenamiento de datos sobre historiales médicos, diagnósticos, resultados de pruebas, imágenes médicas y tratamientos de forma impresa, a favor de un registro digital, en lo que se conoce como EHR (registro electrónico de salud). Esta digitalización, que surgió hace ya décadas, supone cada vez más una ventaja, debido a la creciente cantidad de datos de pacientes que necesitan ser almacenados [1]. A menudo, parte de estos datos son compartidos con aseguradoras médicas, laboratorios y otras entidades cuando participan en la asistencia de un determinado paciente. Según recoge el Reglamento General de Protección de Datos (RGPD), en uno de los 7 derechos de los que disponen los ciudadanos de la UE, el derecho a la portabilidad de los datos consiste en otorgar a cualquier ciudadano europeo el derecho a consentir que cualquier empresa que trate sus datos personales de forma autorizada se los ceda o los transfiera a cualquier otra empresa que este les indique en un formato estructurado, inteligible, e interoperable [2]. La portabilidad de los datos permite que los usuarios autoricen el intercambio, de manera limitada y controlada, de sus datos personales entre empresas u organizaciones. De esta forma, se enriquecen las experiencias y los servicios de los consumidores. Sin embargo, en el ámbito sanitario, esta portabilidad o cesión no está soportada entre organizaciones en la mayoría de las situaciones, sobre todo cuando conviven organizaciones públicas y privadas [3]. Uno de los principales motivos de esta causa es que los datos relacionados con la salud e historias clínicas son considerados altamente sensibles, por lo que su protección es de obligado cumplimiento para cualquier entidad y su compartición debe realizarse de forma segura. Este proyecto plantea una solución a la problemática expuesta, poniendo el foco en el paciente para mejorar la continuidad asistencial de este, a la vez que garantiza la privacidad de sus datos sanitarios. La motivación del proyecto gira en torno al desarrollo de un mecanismo que registre flujos de información sanitaria entre distintas organizaciones. Además de dar soporte al derecho de portabilidad, esta solución permitiría mejorar y agilizar los diagnósticos y tratamientos, reducir costes innecesarios por pruebas duplicadas e impulsar la investigación médica al poder compartir los datos con fines de estudio y educación, siempre bajo el consentimiento del paciente. El mecanismo desarrollado debe cumplir diversos requisitos: • Ha de ser seguro, trazable y garantizar el no repudio. • Debe acogerse a las regulaciones de protección de datos en el ámbito sanitario. • Debe ser interoperable y distribuido, dado que la información será compartida entre organizaciones independientes. Por todo ello, se ha escogido desarrollar esta solución basándose en las redes blockchain. A modo de resumen, se trata de una tecnología que está cobrando gran importancia en la actualidad por sus características de seguridad, transparencia, descentralización y consenso entre los participantes [4]. El objetivo principal del proyecto es desarrollar el mecanismo planteado anteriormente, de forma que se registre qué organización es la emisora de los datos, qué organización los recibe, con qué fin se comparten, durante E Introducción 2 cuánto tiempo pueden compartirse y a qué paciente afectan. Todo ello utilizando la tecnología blockchain. Además, se proponen otros objetivos secundarios, tales como: • Montaje de un escenario de prueba en el que la red se despliegue en varios equipos. • Desarrollo de una API REST para acceder a la red. • Desarrollo de una interfaz gráfica de usuario para interactuar con la red. Para cumplir estos objetivos, deben satisfacerse los siguientes: • Estudio de la tecnología Hyperledger Fabric y despliegue de las soluciones de prueba. • Análisis del estándar FHIR para definir la estructura de las transacciones. • Análisis y elección de los lenguajes de programación y entornos de ejecución disponibles y estudio de su uso y funcionamiento. • Pruebas de validación de las distintas partes y de la solución al completo. La estructura del mecanismo que será desarrollado se ilustra de forma básica en la Figura 1-1. Diagrama de estructura básica de la solución. Se desarrollará una red blockchain en la que participarán varias organizaciones. Cada organización dispone de los datos de sus pacientes almacenados en registros EHR y de una copia de la cadena de bloques. El funcionamiento básico es el siguiente: 1) Un paciente firma un consentimiento en el que autoriza a la organización 1, la cual posee sus datos sanitarios, a ceder parte de (o todos) ellos a la organización 2. 2) La organización 1 solicita compartir dichos datos con la organización 2. 3) Todas las organizaciones que participan de la red consensúan la validez o no de la solicitud. 4) En caso de ser validada, estas organizaciones registran una transacción en la que se incluyen, entre otros, los datos mostrados en la figura. 5) Cada organización añade a su cadena de bloques la transacción realizada. Figura 1-1. Diagrama de estructura básica de la solución 3 Mecanismo de registro de transacciones de información sanitaria basado en blockchain 1.2. Metodología El desarrollo ágil de software es una metodología para la construcción de software basada en ciclos de desarrollo iterativos e incrementales, donde los requisitos y las soluciones van evolucionando según las necesidades del proyecto. La metodología Scrum sigue el modelo de desarrollo ágil de software que ayuda a los equipos a desarrollar productos en periodos cortos, permitiendo obtener de forma rápida una realimentación por parte del cliente, permitiendo adaptaciones y una mejora continuada [5]. Para el desarrollo de este proyecto, se ha seguido una metodología basada en Scrum, con ciertas variaciones, al tratarse de un proyecto personal en el que no hay un cliente real. Se ha tomado la unidad de trabajo fundamental en Scrum, las iteraciones. Además, cada iteración se ha basado en las distintas fases establecidas por la metodología, que son: • Plan • Análisis • Diseño • Construcción • Prueba • Despliegue Un esquema con el funcionamiento de la metodología se muestra en la Figura 1-2. Funcionamiento metodología de desarrollo ágil. Figura 1-2. Funcionamiento metodología de desarrollo ágil En este proyecto, se ha diseñado una solución básica para cumplir los objetivos marcados anteriormente. A medida que se ha evolucionado en la primera iteración, han surgido otras funcionalidades o características que se han considerado fundamentales o útiles para lograr un resultado lo suficientemente completo. Estas nuevas necesidades se han añadido en un “backlog” o lista de tareas y se han desarrollado en iteraciones posteriores, dando lugar al proyecto completo al finalizar la última iteración. Las distintas iteraciones y etapas de trabajo que se han desarrollado se exponen en el apartado siguiente. Introducción 4 1.3. Plan de trabajo A continuación, se listan las distintas tareas que se han realizado a lo largo del proyecto, agrupadas en las iteraciones en las que se han llevado a cabo. Cabe destacar que, al tratarse de un proyecto en el que ha sido mi primer contacto con la mayoría de las tecnologías y herramientas empleadas, se ha requerido una documentación sobre estas en la fase de planteamiento y análisis, al principio de cada iteración. Primera iteración – red básica y chaincode • Documentación sobre redes blockchain en general y sobre la herramienta Hyperledger Fabric en particular. • Documentación sobre Docker y Docker compose. • Diseño de la red blockchain básica. • Configuración de la red basada en la red de prueba proporcionada por Hyperledger Fabric. • Pruebas del chaincode de prueba proporcionado por Hyperledger Fabric, usando la interfaz de línea de comandos propia de la herramienta. • Diseño del chaincode propio. • Desarrollo y pruebas del chaincode propio. Segunda iteración – API REST • Documentación sobre el funcionamiento básico de Node.js para construir una API REST ofrecida a través de un servidor HTTPS. • Diseño y desarrollo de la API REST. • Generación de certificado autofirmado con openSSL. • Implementación del certificado en la API. • Pruebas de la API en Postman. Tercera iteración – interfaz de usuario web • Documentación sobre el funcionamiento de Reactjs para desarrollo de interfaz web sencilla. • Diseño y desarrollo de la interfaz básica. • Pruebas de la interfaz básica. Cuarta iteración – mejoras en la configuración de red y en el chaincode • Adición de funcionalidad de búsqueda en el chaincode inicial (se pasó de 4 a 5 opciones de búsqueda). • Adaptación en la interfaz web para soportar la nueva funcionalidad. • Mejoras en la API y en la interfaz. • Adición de 2 nodos en el servicio de ordenamiento para comprobar el funcionamiento del algoritmo de consenso. Quinta iteración – despliegue distribuido usando Docker Swarm • Documentación sobre configuración y funcionamiento de Docker Swarm. • Diseño de la red distribuida y preparación del entorno (2 máquinas virtuales adicionales). • Adaptación de la configuración de la red para el despliegue en varios equipos. • Despliegue final y realización de pruebas en los distintos equipos, a través de la interfaz web. 5 Mecanismo de registro de transacciones de información sanitaria basado en blockchain A continuación, se añade una tabla con la estimación horaria para cada grupo de tareas descrito, acompañada de la duración real del desempeño de estas tareas. TAREA DURACIÓN ESTIMADA (horas) DURACIÓN REAL (horas) Primera iteración Documentación y diseño de la red 40 h 45 h Duración de la iteración: 124 h Configuración de la red y despliegue 40 h 60 h Pruebas del chaincode de prueba 5 h 5 h Diseño y desarrollo del chaincode propio 15 h 12 h Pruebas y correcciones del chaincode 3 h 2 h Segunda iteración Documentación 20 h 20 h Duración de la iteración: 72 h Diseño y desarrollo de la API 35 h 38 h Generación e implementación del certificado 2 h 2 h Pruebas y correcciones de la API 10 h 12 h Tercera iteración Documentación 15 h 15 h Duración de la iteración: 62 h Diseño de la interfaz 12 h 10 h Desarrollo de la interfaz 20 h 22 h Pruebas y correcciones de la interfaz 10 h 15 h Tabla 1-1. Plan de trabajo I Introducción 6 TAREA DURACIÓN ESTIMADA (horas) DURACIÓN REAL (horas) Cuarta iteración Adición de nuevo filtro de búsqueda en chaincode 2 h 2 h Duración de la iteración: 30 h Adaptación de la interfaz para la nueva funcionalidad 2 h 3 h Mejoras en la API y en la interfaz 10 h 15 h Adición de dos nodos en el servicio de ordenamiento 10 h 10 h Quinta iteración Documentación 20 h 18 h Duración de la iteración: 92 h Diseño de la red distribuida 5 h 7 h Preparación del entorno 4 h 4 h Adaptación de la configuración de la red 15 h 20 h Despliegue final 15 h 18 h Pruebas finales 20 h 25 h DURACIÓN TOTAL 330 h 380 h Tabla 1-2. Plan de trabajo II 7 2 ESTADO DEL ARTE n este capítulo se definirá, desde un punto de vista teórico, el punto de partida del proyecto. Se abordarán las cuestiones más relevantes sobre las redes blockchain, el estándar FHIR y el RGPD, que constituyen la base del trabajo. Además, se explicarán las distintas plataformas y herramientas utilizadas para el diseño y desarrollo de la solución. 2.1. Marco teórico 2.1.1. Redes blockchain 2.1.1.1. ¿Qué es la tecnología blockchain? Blockchain es una tecnología que permite crear aplicaciones en las que varias partes pueden registrar transacciones directamente, sin la necesidad de una autoridad central de confianza para garantizar que se verifiquen las transacciones. Esto se consigue usando una red peer-to-peer donde cada participante en la red tiene acceso a un libro mayor compartido en el que se registran las transacciones. Estas transacciones son, por diseño, inmutables y verificables criptográficamente. A alto nivel, la tecnología blockchain consta de tres componentes: un libro mayor distribuido (en adelante, ledger, por el frecuente uso del término en inglés), un algoritmo de consenso y contratos inteligentes (en adelante, smartcontract, por el frecuente uso del término en inglés) [6]. • Una ledger es un registro transaccional que mantiene todo el historial de cambios de datos. Las ledgers son inmutables y de solo escritura (no borrado) por diseño, y las transacciones son verificables de forma independiente por cada miembro de una red. Cada uno de estos miembros mantiene una copia de la ledger. • Un algoritmo de consenso es un mecanismo para garantizar que todos los miembros de la red puedan ponerse de acuerdo respecto a una fuente única de verdad. En blockchain, se aplican algoritmos de consenso para la ejecución de código y registro de transacciones [7]. • Los smartcontracts definen reglas entre los participantes de la red en forma de código ejecutable. Es el mecanismo que permite generar transacciones y registrarlas en la ledger. 2.1.1.2. Características y ventajas Algunas de las características de blockchain son las siguientes [4]: • Inmutabilidad: Una vez añadida una transacción, nadie puede eliminarla o modificarla. Además, todos los bloques en el registro tienen un hash único y contienen el hash del bloque anterior. Modificar todos los bloques en todos los nodos de la red es prácticamente imposible. • Descentralización: No existe una sola autoridad que gobierne la red o que ejerza un control total sobre esta. • Altamente segura: Los registros cuentan con un cifrado extremo a extremo, lo que ayuda a prevenir el fraude y la actividad no autorizada. Además, el almacenamiento de la información de forma descentralizada también dificulta que la información sea visible por personas no deseadas. • Registros distribuidos: los datos se registran de manera idéntica en múltiples ubicaciones. Todos los participantes de la red ven la misma información al mismo tiempo, lo que brinda total transparencia. E Estado del Arte 14 El derecho de portabilidad habilita al interesado para solicitar al responsable del tratamiento sus datos personales en un formato estructurado, de uso común, de lectura mecánica e interoperable, para poder trasladarlos a otro responsable, cuando medie el consentimiento del interesado o sea necesario para la ejecución de un contrato. o Derecho de acceso Todo interesado tiene derecho a conocer si sus datos personales están siendo tratados, para lo que puede ejercer el derecho de acceso, dirigiéndose al responsable del tratamiento para ello. Si sus datos están siendo tratados, podrá solicitar la siguiente información sobre ellos: ▪ Copia de los datos objeto del tratamiento. ▪ Con qué finalidad se están tratando. ▪ Qué categorías de datos se están tratando. ▪ Si los datos se han cedido a terceros. ▪ El plazo previsto de conservación. ▪ El origen de los datos (cuando no se hayan obtenido directamente del interesado). ▪ Si se están usando en decisiones automatizadas o elaboración de perfiles. ▪ Si se han transferido fuera de la UE. Tal y como se ha mencionado en el capítulo 1, este proyecto pretende desarrollar un mecanismo que acompañe a la transmisión de datos sanitarios entre distintas organizaciones, registrando información relevante relativa a estos flujos de información. Este mecanismo permitiría dar soporte al derecho de portabilidad. La información que se va a registrar pretende acogerse al derecho de acceso, de forma que en cada transacción se almacenará: • El paciente al que pertenecen los datos transmitidos. • La organización origen y la organización destino. • Propósito del tratamiento de los datos. • Periodo de validez durante el cual la organización destino está autorizada a almacenar y tratar los datos. 2.2. Herramientas software, tecnologías y lenguajes 2.2.1. Hyperledger Fabric 2.2.1.1. ¿Qué es Hyperledger Fabric? Hyperledger Fabric es una plataforma de tecnología de libro mayor distribuido (DLT) de código abierto, diseñada para contextos empresariales, que ofrece algunas capacidades de diferenciación clave sobre otras plataformas populares de blockchain [25]. Estas características son las siguientes: • Código abierto: al ser una plataforma de código abierto, todos pueden usarla libremente. Además, Hyperledger Fabric pertenece al proyecto Hyperledger, establecido bajo la Fundación Linux, que tiene una larga historia de nutrir proyectos de código abierto bajo gobierno abierto. 15 Mecanismo de registro de transacciones de información sanitaria basado en blockchain • Lenguajes de programación: Fabric es la primera plataforma de blockchain que admite contratos inteligentes creados en lenguajes de programación de uso general como Java, Go y Node.js, en lugar de lenguajes específicos de dominio restringidos. • Permisionada: a diferencia de una red pública sin permiso, los participantes se conocen entre sí. Esto significa que, si bien los participantes pueden no confiar completamente entre sí, una red puede operarse bajo un modelo de gobernanza que se basa en que la confianza existe entre los participantes. • Protocolos de consenso: Uno de los diferenciadores más importantes de la plataforma es su compatibilidad con protocolos de consenso conectables que permiten que la plataforma se personalice de manera más eficaz para adaptarse a casos de uso particulares y modelos de confianza. • No requiere una criptomoneda: Evitar una criptomoneda reduce algunos vectores de riesgo o de ataque significativos. Además, la ausencia de operaciones de minería criptográfica reduce los costes de implementación. • Modularidad: Fabric tiene una arquitectura altamente modular y configurable, que permite la innovación, la versatilidad y la optimización para una amplia gama de casos de uso de la industria. La combinación de estas características convierte a Fabric en una de las plataformas de mejor rendimiento disponibles en la actualidad tanto en términos de procesamiento de transacciones como de latencia de confirmación de transacciones. Hyperledger Fabric constituirá la base fundamental del proyecto. Será la plataforma usada para construir la red blockchain sobre la que se desarrollará la solución anteriormente presentada. Figura 2-6. Logo Hyperledger Fabric 2.2.1.2. Conceptos clave y elementos de la arquitectura Peers Los nodos pares, o peers, son el elemento fundamental de la red. Cada peer soporta una instancia de uno o varios smartcontracts y de una o varias ledgers. Además, pueden ser peers básicos o clasificarse en la categoría de endorsing peers (aquellos que se encargan de validar transacciones) o anchor peers (aquellos con los que los peers de otras organizaciones pueden comunicarse para descubrir la red). Estado del Arte 16 Figura 2-7. Esquema de peers, smartcontracts y ledgers Servicio de ordenamiento Está formado por otro tipo de nodos, los orderers. En las redes blockchain públicas, los peers realizan tanto la ejecución de smartcontracts como la ordenación de las transacciones en bloques. En hyperledger fabric, estas funciones se separan, de forma que existen nodos dedicados únicamente a ordenar las transacciones en bloques. Esto asegura que todos los peers de la red tengan una copia idéntica de la ledger. Además, esta separación mejora el rendimiento y la escalabilidad. Assets Los assets son las identidades que existen en la ledger. Son pares clave-valor. Smartcontract o Chaincode Chaincode es el nombre que reciben los smartcontracts en fabric. El chaincode es el mecanismo para interactuar con la ledger. Se trata de reglas escritas en código ejecutable que indican qué operaciones se pueden hacer en la ledger (añadir, leer, actualizar o borrar assets) y cómo deben hacerse. Canal Un canal es una subred privada de comunicación entre dos o más organizaciones dentro de una red. En cada red debe existir, como mínimo, un canal. El canal está formado por varias organizaciones (cada una con sus propios peers regulares y con, al menos, un anchor peer), una ledger, un chaincode y un servicio de ordenamiento. Membership Service Provider (MSP) Al ser una red permisionada, los participantes de la red necesitan una forma de probar su identidad frente al resto de participantes para poder operar en la red. De esta gestión de identidades se encargan los Proveedores de Servicios de Membresía (Membership Service Provider, MSP). Los MSP pueden registrar participantes almacenando información sobre ellos (qué rol tienen, qué privilegios…). Con esta información, se generan certificados, que actúan como la identidad de los participantes en la red. Para crear estas identidades digitales, se usa Fabric CA. Fabric CA es un mecanismo de generación de Autoridades de Certificación (CA), usadas para crear el material criptográfico de los participantes de la red en todos sus roles: peer, orderer, admin (nodo encargado de tareas administrativas) o clientes (usuarios que pretenden interactuar con la red). 17 Mecanismo de registro de transacciones de información sanitaria basado en blockchain Organizaciones En fabric, una organización está formada por el conjunto de nodos gestionados por un mismo MSP. Un esquema de la arquitectura básica de una red de Hyperledger Fabric puede verse en la Figura 2-8. Esquema de arquitectura básica de Hyperledger Fabric. En este caso, la red está formada por dos organizaciones y una “organización” orderer, que sirve para agrupar y gestionar los nodos orderer, que proveerán el servicio de ordenamiento. Figura 2-8. Esquema de arquitectura básica de Hyperledger Fabric Nodo peer Organización Smartcontract Canal Ledger Conexión con canal Autoridad de Certificación Nodo orderer Membership Services Provider Tabla 2-1. Leyenda de la Figura 2-8 Estado del Arte 18 Ledger En Hyperledger Fabric, la ledger está formada por dos componentes. El primer componente es el “estado mundial” o world state. Es una base de datos que almacena, en pares clavevalor, el estado actual de los bienes sobre los que se quiere registrar información (los llamados assets). El segundo componente es la blockchain en sí. Se trata de un registro de transacciones que recoge todos los cambios que han resultado en el world state. Este componente es inmutable una vez escrito. De forma resumida, la blockchain está formada por bloques, que contienen: • Una cabecera, que almacena el hash de las transacciones del bloque, así como el hash de la cabecera del bloque anterior. • Una zona de datos, que contiene las transacciones del bloque. • Una zona de metadatos. Figura 2-9. Estructura de la ledger En el caso que nos ocupa, los assets no podrán sufrir modificaciones (no se podrá, por ejemplo, establecer un fin de tratamiento distinto para los datos de un paciente, dado que esto se registraría en otra transacción), por lo que el world state solo servirá para realizar consultas del estado de la blockchain. Gateway Hyperledger Fabric Gateway es un componente que proporciona la conexión entre aplicaciones cliente y la red blockchain. Funciona como un puente entre ambas, de forma que las aplicaciones pueden interactuar con la red sin tener acceso directo a los nodos y la ledger. SDK El SDK de Hyperledger proporciona APIs y herramientas para desarrollar aplicaciones con las que realizar acciones como conectar con la red, registrar transacciones y consultar la ledger. Raft A partir de la versión 2.x, el algoritmo de consenso recomendado en Fabric es Raft. Raft sigue un modelo de «líder y seguidor». El nodo líder es el encargado de recibir peticiones, ordenar las transacciones y replicar la ledger a los seguidores. Si el orderer peer líder falla, se inicia una votación en la que los seguidores eligen al 19 Mecanismo de registro de transacciones de información sanitaria basado en blockchain nodo que pasará a ser el líder [26]. Mientras que, en otros algoritmos, como Kafka, los nodos pertenecen a un mismo clúster que debe ser gestionado por una única organización, en Raft, cada organización puede tener sus propios nodos orderers participando en el servicio de ordenamiento. Esto aumenta la descentralización del sistema [27]. Un esquema del proceso de cambio de estado usando el algoritmo Raft se muestra en la Figura 2-10. Funcionamiento de RAFT para cambio de estado. El funcionamiento es el siguiente: 1. El cliente realiza una solicitud de cambio (lectura o escritura). 2. El nodo leader recibe la solicitud y la registra. 3. El leader manda el cambio a los nodos followers. 4. Los followers registran el cambio. 5. Los followers confirman al leader la recepción (envían un ACK). 6. Si el líder recibe confirmación de la mayoría de los followers, confirma el cambio. 7. El líder confirma el cambio a los followers, de forma que el sistema queda actualizado de manera consensuada. Figura 2-10. Funcionamiento de RAFT para cambio de estado Flujo de transacciones El flujo de transacciones de Hyperledger Fabric puede resumirse en los siguientes pasos [28]: 1. Desde una aplicación cliente se hace una propuesta de transacción (crear, leer, actualizar o borrar assets) y se manda firmada a los endorser peers de las organizaciones, a través de la gateway. Estado del Arte 20 Figura 2-11. Fase 1 del flujo de transacciones 2. Los endorser peers verifican: - Que la propuesta está bien formada. - Que la transacción no se ha registrado anteriormente. - Que la firma del cliente es válida. - Que el cliente está autorizado para hacer la operación solicitada. Después, ejecutan la transacción invocando al chaincode, generan y firman la respuesta y la mandan a la aplicación. Figura 2-12. Fase 2 del flujo de transacciones 3. La aplicación comprueba las firmas de las respuestas y compara estas respuestas entre sí, para ver que son iguales. Además, si la operación que se desea realizar implica actualizar la ledger, se comprueba el cumplimiento de las políticas de los endorsers (que han respondido todos los endorser peers requeridos, etcétera). Figura 2-13. Fase 3 del flujo de transacciones 4. La aplicación genera un mensaje que contiene la propuesta de transacción y la respuesta y la envía al servicio de ordenamiento. Después, los orderers ordenan la transacción y la añaden a un bloque. 21 Mecanismo de registro de transacciones de información sanitaria basado en blockchain Figura 2-14. Fase 4 del flujo de transacciones 5. Cuando los peers de la red reciben un bloque, comprueban que se han cumplido las políticas y que no se han producido cambios en la ledger desde que se ejecutó la transacción en el paso 2. Se marca la transacción como válida o inválida. Figura 2-15. Fase 5 del flujo de transacciones 6. Los peers marcan la transacción como válida o inválida y actualizan la ledger con el bloque de transacciones válidas. Después, notifican al cliente de que la transacción ha sido añadida a la cadena. Figura 2-16. Fase 6 del flujo de transacciones 2.2.2. JWT JSON Web Token (JWT) es un estándar abierto definido en la RFC 7519. Determina un mecanismo compacto para transmitir información segura entre dos partes con un objeto JSON. Esta información se puede verificar porque está firmada digitalmente [29]. En este proyecto, se van a usar para uno de los fines más comunes de estos tokens, la autenticación en APIs y mantenimiento de sesión. Así, al iniciar sesión, el usuario recibirá un token que incluirá en las solicitudes posteriores. Estado del Arte 22 2.2.3. Docker Docker es una herramienta usada para crear, desplegar y ejecutar aplicaciones en un entorno de contenedores. Un contenedor es un paquete ligero, ejecutable y autónomo que incluye todo lo que una aplicación necesita para ser ejecutada, incluyendo código, librerías, dependencias y runtime [30]. Con los contenedores, las aplicaciones son portables y autocontenidas, lo que facilita el despliegue de estas en diferentes plataformas y entornos. En este proyecto, todos los peers, oderers, Cas y otros elementos de la red serán serán componentes desplegados en contenedores Docker. Figura 2-17. Algunos contenedores del proyecto. 2.2.4. Docker compose Docker compose es una herramienta para definir y ejecutar aplicaciones multi-contenedor. Con Docker compose, pueden usarse ficheros YAML para definir los distintos componentes de la aplicación, tales como servicios, dependencias y configuración [31]. Docker compose se utilizará, en el caso que ocupa, para un primer despliegue en un solo equipo. 2.2.5. Docker swarm Docker swarm permite ejecutar aplicaciones multi-contenedor en modo clúster. Es decir, mientras que con Docker compose el despliegue se realiza en un solo equipo, con Docker Swarm se puede desplegar en múltiples nodos. En Docker Swarm, los nodos se clasifican en administradores (o managers) y trabajadores (o workers). Los managers realizan la orquestación de los contenedores y la administración del clúster, mientras que los workers reciben y ejecutan tareas desde los managers [32]. Docker swarm será utilizado en este proyecto para el despliegue de la red en un escenario con 3 equipos, donde el primero actuará como manager y los dos restantes lo harán como workers. 23 Mecanismo de registro de transacciones de información sanitaria basado en blockchain Figura 2-18. Logo Docker swarm 2.2.6. NodeJS NodeJS es un entorno de ejecución para JavaScript que se utiliza para desarrolla aplicaciones web del lado del servidor [33]. En concreto, cabe destacar Express.js, un framework de Node ampliamente utilizado para el desarrollo de APIs. Proporciona herramientas para el manejo de rutas e implementación de funcionalidades como el manejo de sesiones y la autenticación de usuarios [34]. NodeJS es una de las opciones en las que Hyperledger Fabric ofrece su SDK y será la utilizada en esta solución. Figura 2-19. Logo NodeJS 2.2.7. Go Go, también conocido como Golang, es un lenguaje de programación de código abierto creado por Google en 2009. Go se caracteriza por su sintaxis clara y concisa, su tipado estricto y su enfoque en la concurrencia y la eficiencia [35]. Este lenguaje ha sido escogido entre las distintas alternativas que Hyperledger Fabric propone para el desarrollo del chaincode. Figura 2-20. Logo Golang Resultados 30 Una vez configurados los peers, se pasa a configurar la base de datos que dará soporte al world state. Hyperledger Fabric ofrece la posibilidad de usar para ello CouchDB. CouchDB es un SGBD de Apache, de código abierto y NoSQL. Recoge la información en documentos con formato JSON [39]. Se deberá configurar una instancia de CouchDB para cada peer. Figura 3-10. Ficheros de configuración de couchDB. Figura 3-11. Fragmento de compose-couch.yaml para la CouchDB de la organización Quirón. 31 Mecanismo de registro de transacciones de información sanitaria basado en blockchain Orderers En el mismo fichero en el que se han configurado los peers (compose-test-net.yaml) se configurarán los orderers. En este caso habrá tres contenedores, uno para cada nodo orderer. Figura 3-12. Fragmento de compose-test-net.yaml para el orderer2 Algoritmo de consenso, directorio MSP y políticas Además de los servicios a desplegar, deben configurarse otros aspectos en el fichero configtx.yaml (Figura 3-3. Estructura de directorios del proyecto.). Esta configuración comprende: • Directorio MSP y políticas de firma para cada organización: se establecerá el directorio base que actuará como MSP (aquí se almacenarán todos los certificados necesarios para los integrantes de la organización). Con las políticas de firma, cada organización puede especificar qué miembros o roles pueden realizar distintas operaciones en el canal y la ledger. Las palabras reservadas que pueden usarse son AND, OR y NoutOf (y, o, número sobre, por ejemplo, 11 de 20). En este caso, podrán hacer lecturas los roles de administrador, peer y cliente; podrán escribir los roles de administrador y cliente; podrá hacer funciones de administración el rol de administrador y podrá validar transacciones el rol de peer. Resultados 32 Figura 3-13. Fragmento de configtx.yaml para el MSP y políticas de firma de la organización HLA. • Políticas implícitas: son políticas que sirven para validar las políticas de firma (están a un nivel menos profundo que estas últimas). Esto puede ser útil para evitar conflictos en caso de cambios en las políticas de firma. Por ejemplo, en este caso, la política de firma de “Endorsement” (roles que pueden validar transacciones) debe ser validada por la mayoría de los que pertenecen a esta política de firma. Las palabras reservadas que pueden usarse son ANY, ALL y MAJORITY (cualquiera, todos, la mayoría). Figura 3-14. Fragmento de configtx.yaml para políticas implícitas. • Algoritmo de consenso: por último, cabe destacar la configuración de los perfiles. En esta sección, se establecerá la configuración a tener en cuenta para crear el primer bloque de la red, el llamado bloque génesis. Como puede observarse en la Figura 3-15. Fragmento de configtx.yaml para el bloque génesis y el algoritmo de consenso., se establecen las organizaciones que forman parte de la aplicación, así como el tipo de algoritmo de consenso y los participantes en este. Para este proyecto, se usará el algoritmo RAFT, detallado en capítulos anteriores, y estará formado por tres orderers. Para cada uno de ellos se define el nombre, el puerto y la ubicación de los certificados correspondientes. 33 Mecanismo de registro de transacciones de información sanitaria basado en blockchain Figura 3-15. Fragmento de configtx.yaml para el bloque génesis y el algoritmo de consenso. Chaincode Por último, se procede a configurar el chaincode. Para este proyecto, se ha desarrollado en lenguaje Golang. Figura 3-16. Ubicación del smartcontract. En el fichero del chaincode pueden diferenciarse las siguientes partes: • Importación de paquetes. Cabe destacar el paquete “shim”, que implementa la interfaz “ChaincodeStubInterface” y ofrece métodos para acceder y modificar la ledger, y el paquete “peer”, que implementa el mecanismo “Protocol Buffer”, utilizado para serializar datos estructurados. Figura 3-17. Importación de paquetes en el chaincode. Resultados 34 • Definición de los assets. Para definir los assets, se crean tipos de tipo estructura, dentro de las cuales se especifican los campos del asset. Además, se añade la etiqueta del JSON para su posterior conversión a este formato. Esta estructura se ha formado a partir de los campos de los recursos FHIR mencionados en las figuras Figura 2-3. Formato JSON recurso AuditEvent, Figura 2-4. Formato JSON recurso Organization y Figura 2-5. Formato JSON recurso Patient. Figura 3-18. Definición de los assets en el chaincode. • Definición de funciones. Se dispondrá de una función principal, “Invoke”, que será a la que se llame desde la línea de comandos o desde la API de Node. Dentro de esta función, se invocará a la función encargada de realizar la operación que se ha solicitado, pasada como parámetro a Invoke. Figura 3-19. Función Invoke del chaincode. Las distintas funciones implementadas se resumen en la Tabla 3-1. Funciones del chaincode.. 35 Mecanismo de registro de transacciones de información sanitaria basado en blockchain Nombre de la función Recibe Devuelve Funcionalidad CreateAsset ChaincodeStubInterface, puntero al SmartContract, datos para el nuevo asset pb.Response con mensaje de éxito o error Completa los campos del asset con los argumentos recibidos. Convierte a formato JSON y añade el asset a la ledger. Crea claves compuestas con el id del asset y la org. Origen, org. Destino, fecha de fin de periodo de validez y DNI del paciente para posteriores búsquedas. GetAllAssets ChaincodeStubInterface, puntero al SmartContract pb.Response con mensaje de éxito y la lista de assets o error Recorre la ledger y añade cada asset a una lista para devolerla con todos los assets. GetAssetsBySourceOr g ChaincodeStubInterface, puntero al SmartContract, nombre de la org. Origen pb.Response con mensaje de éxito y la lista de assets o error Recorre la ledger usando la clave compuesta correspondiente para añadir a una lista los assets que tengan como org. Origen la que se ha pasado como parámetro. GetAssetsByDestinati onOrg ChaincodeStubInterface, puntero al SmartContract, nombre de la org. Destino pb.Response con mensaje de éxito y la lista de assets o error Recorre la ledger usando la clave compuesta correspondiente para añadir a una lista los assets que tengan como org. Destino la que se ha pasado como parámetro. GetAssetsByEndDate ChaincodeStubInterface, puntero al SmartContract, fecha fin de periodo de validez pb.Response con mensaje de éxito y la lista de assets o error Recorre la ledger usando la clave compuesta correspondiente para añadir a una lista los assets que tengan como fecha de fin de periodo de validez la que se ha pasado como parámetro. GetAssetsByPatient ChaincodeStubInterface, puntero al SmartContract, DNI del paciente pb.Response con mensaje de éxito y la lista de assets o error Recorre la ledger usando la clave compuesta correspondiente para añadir a una lista los assets que tengan como DNI del paciente el que se ha pasado como parámetro. Tabla 3-1. Funciones del chaincode. Resultados 36 3.2.2. Despliegue con Docker Compose Tras finalizar la configuración, el siguiente paso es desplegar y poner en marcha la red. Con este fin, Hyperledger Fabric facilita un conjunto de scripts para hacer el despliegue de forma ordenada, cómoda y rápida. A continuación, se enumeran y explican las fases o pasos que se deben seguir para desplegar la red. 1. Levantar la red a) Levantar los contenedores de las CA. b) Crear MSP para cada organización, registrar e inscribir a los usuarios. El MSP en Hyperledger Fabric no es más que una estructura de directorios que contienen los certificados TLS y de la organización. En este paso, se crearán los directorios necesarios y se hará el registro e inscripción de un rol peer, un rol usuario y un rol administrador. En el proceso de registro se creará una identidad para el usuario en el sistema, asignándole un Figura 3-20. Función GetAssetsBySourceOrg del chaincode. 37 Mecanismo de registro de transacciones de información sanitaria basado en blockchain certificado y una clave privada. En este punto, el usuario aún no tiene acceso de la red. En el proceso de inscripción, el usuario utilizará su certificado y clave para obtener acceso a la red y así activar su identidad. c) Generar los CCPs Los perfiles de conexión son ficheros en formato JSON o YAML que describen la topología de la red a nivel de peers, orderers y CAs. Estos ficheros configuran la conexión de una aplicación o cliente (en este caso, el SDK) con una red de Hyperledger. Se generará un CCP para cada organización. Figura 3-21. Perfil de conexión de la organización Viamed. Resultados 38 Figura 3-22. Directorios tras la fase 1 del despliegue (I) Figura 3-23. Directorios tras la fase 1 del despliegue (II). d) Levantar los contenedores de los peers y couchDB 2. Crear los “Channel Artifacts” (elementos del canal) a) Crear el bloque génesis El bloque génesis es el primer bloque de la blockchain y contiene la información sobre la red indicada en configtx.yaml. b) Crear el canal En este paso, se creará el canal y se unirán a este los tres nodos orderers. En este punto, los orderers habrán interactuado entre ellos para definir quién será el leader y quiénes los followers (sección 2.2.1.2 – Raft). c) Unir los peers al canal d) Establecer anchor peers Tal y como se ha descrito en la sección 2.2.1.2 – Peers, los anchor peers permiten que otros peers se comuniquen con ellos para describir la red. En este paso, se añadirá un anchor peer por cada organización. 39 Mecanismo de registro de transacciones de información sanitaria basado en blockchain Figura 3-25. Votación y elección de leader y followers en RAFT. 3. Desplegar el chaincode a) Empaquetar el chaincode en un archivo .tar.gz e instalar en los peers. b) Comprobaciones de la instalación. Para finalizar con el despliegue, se debe comprobar la correcta instalación del chaincode, aprobar la definición de este y confirmarla. Una vez realizados estos pasos, la red estará desplegada y lista para ser usada. 3.2.3. Pruebas en CLI Una vez desplegada la red, se puede hacer uso del CLI y los comandos que ofrece para comprobar el correcto funcionamiento del chaincode. A continuación, se presenta un ejemplo de creación de un asset y de lectura de todos los assets. Figura 3-26. Creación de asset a través del CLI. Figura 3-24. Creación del canal y unión de los orderers. Resultados 46 Figura 3-35. Función query de ledgerActions.js 47 Mecanismo de registro de transacciones de información sanitaria basado en blockchain 3.2.4.3. Configuración y despliegue del servidor Una vez desarrollados los endpoints, es necesario configurar la aplicación como servidor para que pueda atender las solicitudes de los clientes. Para este proyecto, se ha optado por un servidor HTTPS, usando un certificado autofirmado. Figura 3-36. Creación del servidor HTTPS. En este punto, se podrá desplegar el servidor en un contenedor con la ayuda del fichero docker-compose.yml. Además, se dispone del fichero Dockerfile, que se encargará de iniciar la aplicación al levantar el contenedor. De esta forma, se podrá acceder al servidor con la URL https://localhost:4000. 3.2.4.4. Pruebas con Postman Una vez el servidor esté en marcha, se pueden realizar pruebas para interactuar con la red. En este caso, se ha usado el cliente HTTP proporcionado por Postman. Figura 3-37. Ejemplo de login con Postman. Resultados 48 Figura 3-38. Ejemplo de invoke con Postman. Figura 3-39. Ejemplo de query y cabecera authorization con Postman. 49 Mecanismo de registro de transacciones de información sanitaria basado en blockchain 3.2.5. Interfaz gráfica de usuario Para facilitar el uso de la aplicación se ha desarrollado una sencilla interfaz de usuario web, usando la librería de JavaScript React. Para el desarrollo, se han usado como base los repositorios compartidos en GitHub por el usuario Chhaileng Peng para la parte del consumo de una aplicación REST [41] y por el usuario Techomoro para desarrollar una web multi-página [42]. Esta solución estará estructurada en los siguientes componentes: • Componente de navegación para desplazarse a la página principal desde las distintas secciones. • Componente Login para introducir el nombre de la organización e identidad del usuario. Desde este componente, se llamará al endpoint /login para obtener en JW Token. • Componente Home (página principal) en el que aparecerá un listado de las funcionalidades que se podrán realizar. • Componentes ReadAll, ReadByDate, ReadByDestination, ReadByPatient y ReadBySource, que permitirán elegir el argumento según la funcionalidad escogida y realizar una búsqueda filtrada en la ledger llamando al endpoint /ledger/query. • Componente NewTransaction, desde el que se podrá añadir una transacción a la ledger rellenando un formulario. Desde este componente, se llamará al endpoint /ledger/invoke. Las distintas acciones sobre la ledger que se pueden realizar desde la interfaz serán detalladas en la Sección 3.3. Figura 3-40. Página de inicio de sesión de la interfaz. Una vez iniciada, la interfaz será accesible en la dirección http://172.16.17.11:3000. Para las distintas llamadas a la API, se ha utilizado la librería Axios, que actúa como cliente HTTP. Resultados 50 Figura 3-41. Ejemplo de petición con Axios para readByDate. 3.2.6. Configuración y despliegue con Docker Swarm Para plantear un caso de uso más cercano a la realidad, se ha optado por diseñar un pequeño escenario en el que participen varios equipos, que puedan representar varias organizaciones. Para desplegar la solución del proyecto en este escenario, se ha usado la herramienta Docker Swarm. Por simplicidad, se ha optado por incluir tres hosts en el escenario, situados en la misma subred, y agrupar organizaciones en ellos, ya que se ha considerado cantidad suficiente para mostrar el funcionamiento con Swarm. El primero de los equipos actuará como manager del swarm y albergará a las organizaciones Orderer y SAS; el segundo, será de tipo worker y albergará a las organizaciones Quirón y HLA y el tercero, también de tipo worker, albergará a la organización Viamed. 51 Mecanismo de registro de transacciones de información sanitaria basado en blockchain Figura 3-42. Nombres, direcciones IP y contenedores de los equipos del escenario. Cambios en la configuración de Hyperledger Fabric • Autoridades de certificación: en la configuración de las CA, debe añadirse la sección “deploy”, en la que se indicará, entre otros, el equipo en el que se debe desplegar el contenedor correspondiente. También se añadirá el nombre del equipo o hostname. Además, se dividirá el fichero de configuración de las CA en 5 ficheros, uno para cada organización. Por último, se debe añadir el nombre de la autoridad de certificación (ca.<nombreOrg>.org.com) en la sección de equipos de las CSR Figura 3-43. Cambios en la configuración de CAs para swarm. • Peers y CouchDB: para el despliegue con swarm, se han configurado los peers y las CouchDB en el mismo fichero, habiendo un fichero para cada organización. Cabe destacar que, además de añadir la sección “deploy”, se debe añadir la sección “extra_hosts”, en la que se mapean el resto de los nombres del escenario a sus correspondientes direcciones IP. Resultados 52 Figura 3-44. Sección extra_hosts en la configuración del swarm para el peer0 de la organización SAS. Despliegue El despliegue de la red seguirá la misma secuencia que para Docker compose. En este caso, en vez de utilizar un único script, se dispondrá de un script para cada organización. El levantamiento de los contenedores se realizará desde el manager, pero estos se levantarán en el equipo correspondiente debido a la sección deploy. El registro e inscripción de los usuarios, la unión de los peers al canal y el despliegue del chaincode se realizará desde cada equipo. Por último, el contenedor de la aplicación se desplegará en el manager. Uso La interacción con la red no se ve alterada por este despliegue. Desde cada equipo, se puede acceder a la interfaz de usuario para realizar acciones sobre la ledger. Estos cambios se verán reflejados en la copia de la ledger que tiene cada peer, de forma que podrán también observarse desde la interfaz del resto de equipos 3.3. Pruebas finales En esta sección se expondrá el proceso de interacción con la red a través de la interfaz gráfica de usuario. 3.3.1. Inicio de sesión En primer lugar, al acceder a la interfaz se mostrará una ventana, en la que el usuario deberá introducir el nombre de la organización y el identificador de usuario. En caso de que no coincidan o que no exista el usuario introducido, se mostrará un modal con un mensaje de error. Figura 3-45. Comprobación de despliegue en los equipos correspondientes. 53 Mecanismo de registro de transacciones de información sanitaria basado en blockchain Figura 3-46. Error en login. 3.3.2. Pantalla principal Una vez que se ha iniciado sesión con éxito, se mostrará una vista con las distintas interacciones que se pueden realizar. Estas son: • Nueva transacción. • Leer todas las transacciones. • Buscar transacciones por organización de origen. • Buscar transacciones por organización de destino. • Buscar transacciones por fecha de fin del periodo de validez. • Buscar transacciones por identificador de paciente. Figura 3-47. Vista principal de la interfaz. 3.3.3. Casos de uso NewTransaction Esta acción permitirá introducir transacciones en la blockchain. Para ello, se debe rellenar un formulario con la organización de destino, la fecha de fin del periodo de validez, el identificador del paciente y el propósito de uso de los datos. Una vez completados, al pulsar el botón “Submit”, se registrará la transacción, mostrando un modal de éxito al finalizar. Resultados 54 Figura 3-48. NewTransaction en interfaz. ReadAll Desde esta sección se podrá ver un resumen sobre todos los assets registrados en la ledger en forma de lista. Figura 3-49. Resultado de ReadAll en la interfaz. ReadBySource Esta acción permitirá filtrar la búsqueda de assets en función de la organización de origen. Se debe introducir una organización en el campo de búsqueda y clicar en “Search”. Si la búsqueda ha sido exitosa, se mostrarán los resultados de forma similar al caso anterior. Además, se podrán ver los assets completos en formato JSON pulsando el botón “Show in JSON format”. En caso de no haber ningún resultado, aparecerá el mensaje “There is not any asset that matches the search”, permitiendo realizar de nuevo la búsqueda. Figura 3-50. Resultado de ReadBySource en la interfaz. 55 Mecanismo de registro de transacciones de información sanitaria basado en blockchain ReadByDestination, ReadByDate y ReadByPatient Estas acciones tienen un comportamiento análogo al del ReadBySource, permitiendo filtra la búsqueda por organización de destino, fecha hasta la que la organización de destino puede conservar los datos (fin del periodo de validez) e identificador del paciente. Figura 3-51. Fragmento del resultado de una búsqueda en formato JSON. 62 ANEXO A: MANUAL DE INSTALACIÓN Y DESPLIEGUE CON DOCKER COMPOSE En esta sección se explicará qué prerrequisitos de instalación se deben cumplir para desplegar el proyecto en un solo equipo con Docker Compose. Además, se incluirán las instrucciones para desplegar la red usando los scripts incluidos en el código. Cabe destacar que, para este proyecto, se ha utilizado el sistema operativo Ubuntu en su versión 20.0.4 LTS. A.1. Prerrequisitos A continuación, se indican las herramientas necesarias para la ejecución y despliegue del proyecto [45]. A.1.1. Instalar Docker # configurar el repositorio sudo apt install \ apt-transport-https \ ca-certificates \ curl \ gnupg-agent \ software-properties-common # añadir la clave GPG oficial de Docker curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - # configurar el repositorio estable sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" # instalar el motor de Docker apt update apt install docker-ce docker-ce-cli containerd.io # comporbar la version de Docker docker --version En este proyecto se ha instalado la versión 20.10.14. 63 Mecanismo de registro de transacciones de información sanitaria basado en blockchain A.1.2. Instalar Docker Compose # instalar Docker-compose curl -L "https://github.com/docker/compose/releases/download/1.27.4/dockercompose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose # dar permiso de ejecución al binario sudo chmod +x /usr/local/bin/docker-compose # comprobar la version de Docker-compose docker-compose --version En este proyecto se ha instalado la versión 1.27.4. A.1.3. Instalar Golang # descargar y descomprimir go wget -c https://dl.google.com/go/go1.14.9.linux-amd64.tar.gz -O - | tar -xz -C /usr/local # añadir el binario de go a la ruta echo 'export PATH="$PATH:/usr/local/go/bin:/root/fabric/fabric-samples/bin"' >> $HOME/.profile # hacer que la vble de entorno GOPATH apunte al directorio base de fabric echo 'export GOPATH="$HOME/fabric"' >> $HOME/.profile # recargar el perfil source $HOME/.profile # comprobar la version de go go version # comprobar las variables printenv | grep PATH En este proyecto se ha instalado la versión 1.14.9. A.1.4. Instalar Node.js # añadir PPA desde NodeSource curl -sL https://deb.nodesource.com/setup_16.x -o nodesource_setup.sh # ejecutar el script de instalación . nodesource_setup.sh # instalar Node.js apt-get install -y nodejs # comprobar la versión node -v En este proyecto se ha instalado la versión 16.4.2. Anexo A: Manual de Instalación y Despliegue con Docker Compose 64 A.1.5. Instalar Hyperledger Fabric Con estos comandos, se clona el repositorio de Hyperledger Fabric, se instalan los binarios y se descargan las imágenes Docker. curl -sSL https://bit.ly/2ysbOFE | bash -s -- 2.4.3 # comprobar las imágenes descargadas docker images # comprobar el comando peer y la versión de Hyperledger Fabric peer version En este proyecto se ha instalado la versión 2.4.3. A.2. Despliegue # crear la red Docker docker network create mynetwork # crear Cas, peers y canal (desde el directorio donde se ubique network.sh) ./network.sh up createChannel -s couchdb -ca # desplegar el chaincode ./network.sh deployCC -c mychannel -ccn testqueries -ccp ../chaincode-go -ccl go # lanzar el servidor de la API cd ../myapp # Directorio donde se ubique el Dockerfile ./build.sh docker-compose up -d docker exec -it <nombre_contenedor_api> node createWallet.js # crear admins y usuarios y añadir a los wallets docker exec -it <nombre_contenedor_api> node addToWallet.js # arrancar la interfaz web cd ../mynetwork-ui npm start # para detener la red ./network.sh down docker system prune –volumes -f 65 ANEXO B: MANUAL DE DESPLIEGUE CON DOCKER COMPOSE En esta sección se incluirán las instrucciones para desplegar la red con Docker Swarm usando los scripts incluidos en el código. Cabe destacar que se parte un escenario como el de la Figura 3-42. Nombres, direcciones IP y contenedores de los equipos del escenario. Por tanto, para realizar el despliegue en un escenario distinto, se deben adaptar los scripts en función de los elementos que se deseen desplegar en cada equipo. B.1. Despliegue # 1º: CREAR SWARM: crea el swarm y la red mynetwork (Desde equipo manager) ./networkGeneral.sh createSwarm # 2º: UNIR EQUIPOS AL SWARM (Desde equipos worker1 y worker2) docker swarm join --token <token_obtenido_al_crear_el_swarm> 172.16.17.11:2377 # 3º: CREAR CAs: despliega los contenedores de las CAs (Se realiza desde manager, cada # CA será desplegada en el equipo configurado en los ficheros yaml) ./networkGeneral.sh createCAOrderer ./networkGeneral.sh createCASas ./networkGeneral.sh createCAQuiron ./networkGeneral.sh createCAHla ./networkGeneral.sh createCAViamed # 4º REGISTER AND ENROLL: registra e inscribe un usuario y administrador para cada # organización # Desde equipo manager ./networkSas.sh registerEnroll ./networkOrderer.sh registerEnroll # Desde equipo worker1 ./networkQuiron.sh registerEnroll ./networkHla.sh registerEnroll # Desde equipo worker2 ./networkViamed.sh registerEnroll # 5º COPIAR MATERIAL CRIPTOGRÁFICO: Es necesario que el material criptográfico de las # organizaciones esté en el equipo desde el que se vaya a crear el bloque génesis, por # lo que se copia al equipo manager desde los equipos worker1 y worker2. Se ha escogido # el protocolo SFTP para transferir este material (Desde equipo manager) cd organizations/fabric-ca sftp marta@worker1 get -Pr /home/marta/mynetwork/mnw/organizations/fabric-ca/quiron get -Pr /home/marta/mynetwork/mnw/organizations/fabric-ca/hla exit cd ../peerOrganizations sftp marta@worker1 Anexo B: Manual de Despliegue con Docker Swarm 66 get -Pr /home/marta/mynetwork/mnw/organizations/peerOrganizations/quiron.org.com get -Pr /home/marta/mynetwork/mnw/organizations/peerOrganizations/hla.org.com exit cd ../fabric-ca sftp marta@worker2 get -Pr /home/marta/mynetwork/mnw/organizations/fabric-ca/viamed exit cd ../peerOrganizations sftp marta@worker2 get -Pr /home/marta/mynetwork/mnw/organizations/peerOrganizations/viamed.org.com exit cd ../.. # Además, es necesario que los equipos workers tengan el material criptográfico de los # nodos orderers para poder desplegar en ellos los contenedores de estos nodos # Desde equipos worker1 y worker2 cd organizations sftp marta@manager get -Pr /home/marta/mynetwork/mnw/organizations/ordererOrganizations exit cd fabric-ca sftp marta@manager get -Pr /home/marta/mynetwork/mnw/organizations/fabric-ca/ordererOrg exit cd ../.. # 6º GENERAR CCPs: Los perfiles de conexión se generan en el manager y se almacenan en # el directorio de la aplicación, ya que serán necesarios para crear los wallets y las # identidades de los usuarios (Desde equipo manager) ./networkGeneral.sh generateCCP # 7º DESPLEGAR SERVICIOS DE PEERS Y COUCHDBS (Se realiza desde manager, cada contenedor # será desplegado en el equipo configurado en los ficheros yaml) ./networkGeneral.sh deployComponentsOrderer ./networkGeneral.sh deployComponentsSas ./networkGeneral.sh deployComponentsQuiron ./networkGeneral.sh deployComponentsHla ./networkGeneral.sh deployComponentsViamed # 8º CREAR BLOQUE GÉNESIS (Desde equipo manager, ya que es desde donde se creará el # # canal) ./networkGeneral.sh createGenesis # 9º CREAR CANAL (Desde equipo manager) ./networkGeneral.sh createChannel # 10º UNIR PEERS AL CANAL (Desde equipo manager, ya que es donde está desplegado el # contenedor cli) ./networkGeneral.sh joinChannelSas ./networkGeneral.sh joinChannelQuiron ./networkGeneral.sh joinChannelHla ./networkGeneral.sh joinChannelViamed 67 Mecanismo de registro de transacciones de información sanitaria basado en blockchain # Cambiar línea 83 de createChannel.sh en equipo manager ya que el sufijo # del servicio varía en cada ejecución (ejecutar docker ps, coger peer_sas_cli) # 11º ESTABLECER ANCHOR PEERS (Desde equipo manager) ./networkGeneral.sh setAnchorPeerSas ./networkGeneral.sh setAnchorPeerQuiron ./networkGeneral.sh setAnchorPeerHla ./networkGeneral.sh setAnchorPeerViamed # 12º EMPAQUETAR CHAINCODE (Desde equipo manager) ./networkGeneral.sh vendorAndPackageCC # Además, es censario que todas las organizaciones tengan el paquete del chaincode # para poder desplegarlo # Desde equipos workers sftp marta@manager get -P /home/marta/mynetwork/mnw/smartcontract.tar.gz exit # 13º INSTALAR CHAINCODE # Desde equipo Manager ./networkSas.sh installCC # Desde equipo worker1 ./networkQuiron.sh installCC ./networkHla.sh installCC # Desde equipo worker2 ./networkViamed.sh installCC # 14º COMPROBAR Y APROBAR INSTALACIÓN (Desde equipo Manager) ./networkGeneral.sh queryInstalledApproveSas ./networkGeneral.sh queryInstalledApproveQuiron ./networkGeneral.sh queryInstalledApproveHla ./networkGeneral.sh queryInstalledApproveViamed # 15º COMPROBAR QUE EL CHAINCODE ESTÁ LISTO PARA CONFIRMAR checkReadiness (Desde equipo # Manager) ./networkGeneral.sh checkReadinessSas ./networkGeneral.sh checkReadinessQuiron ./networkGeneral.sh checkReadinessHla ./networkGeneral.sh checkReadinessViamed # 16º CONFIRMAR LA DEFINICIÓN DEL CHAINCODE commitDefinition (Desde equipo Manager) ./networkGeneral.sh commitDefinition # 17º COMPROBAR LA CONFIRMACIÓN DEL CHAINCODE querycommited (Desde equipo Manager) ./networkGeneral.sh queryCommitted # 18º DESPLEGAR api (Desde equipo Manager) cd ../myapp # Construir y arrancar el servidor ./build.sh ./run.sh # Crear wallets e identidades de administradores y usuarios (ejecutar dentro del # contenedor) docker exec -it api_sdk_api node createWallet.js docker exec -it api_sdk_api node addToWalletAdmin.js docker exec -it api_sdk_api node addToWalletUser.js Anexo B: Manual de Despliegue con Docker Swarm 68 # 19º Arrancar interfaz cd ../mynetwork-ui npm start # PARA DETENER LA RED # Desde equipo Manager ./networkSas.sh networkDown ./networkOrderer.sh networkDown # Desde equipo worker1 ./networkQuiron.sh networkDown ./networkHla.sh networkDown # Desde equipo worker2 ./networkViamed.sh networkDown