Gestor de consentimientos para el procesamiento de información sanitaria en el marco de la GDPR y conforme al estándar HL7 FHIR

Abstract

Actualmente podemos encontrar numerosos y variados sistemas que emplean TIC (tecnologías de información y comunicaciones) en cada área de trabajo. Concretamente, en el sector sanitario, podemos ver que los datos sanitarios de un mismo individuo pueden estar almacenados en muchos sistemas (los cuales, en general, no comparten información) y usarse de forma diferente. Es decir, no existe un punto de intercambio entre sistemas que facilite el paso de los datos independientemente de la forma en la que estos datos hayan sido almacenados. Por ello, la comunicación en este ámbito suele ser compleja incluso sin entrar en la burocracia pertinente para el paso de datos entre distintas organizaciones sanitarias, por ejemplo. Además, para realizar cualquier acción sobre los datos sanitarios es necesario el consentimiento previo del paciente para ello de forma que estén restringidos y controlados tal y como indica el Reglamento General de Protección de Datos (GDPR). Existe la posibilidad de que cada sistema gestione los consentimientos aunque esto solo agravaría el problema de la interoperabilidad entre sistemas que usen información sanitaria. De esta forma, llegamos a la conclusión de que sería muy conveniente disponer de un único sistema con el que gestionar todos los consentimientos de los pacientes relacionados con información sanitaria. Así, cualquier acceso a estos datos necesitaría ser solicitado y aprobado por el ciudadano en un único sistema. Para ello, tendríamos que tener en cuenta el Reglamento General de Protección de Datos (Reglamento 2016/679) por el que el Parlamento Europeo, el Consejo de la Unión Europea y la Comisión Europea tienen la intención de reforzar y unificar la protección de datos dentro de la Unión Europea (UE). Por tanto, el objetivo de este trabajo es el diseño y desarrollo de un gestor de consentimientos que funcione bajo el marco del GDPR. Para el almacenamiento de los consentimientos adoptaremos el último estándar desarrollado por Health Level Seven(HL7), empresa responsable de crear algunos de los protocolos de comunicación más utilizados hoy en día en el ámbito sanitario. Se trata del estándar Fast Healthcare Interoperability Resources, FHIR por sus siglas. Dado el gran uso del teléfono móvil que hacemos hoy en día, consideramos que resultaría muy útil disponer de una aplicación móvil con la que el usuario pueda gestionar sus consentimientos médicos y recibir peticiones de tratamiento de sus datos sanitarios. Además, dada la pandemia que estamos viviendo, se hace muy conveniente el uso de una aplicación móvil para cualquier gestión para la que hasta hace nada requeríamos de papel. Todo ello nos da sustento a un trabajo que no podría estar más situado en el contexto actual. Así, tendremos una aplicación móvil de la que un ciudadano o agente solicitante hará uso para gestionar estos consentimientos. A través del estándar FHIR, se hará uso de diferentes recursos recogidos en el estándar y aplicados en el ámbito sanitario para comunicarse con un servicio web el cual se encargará de obtener los datos necesarios de una base de datos y hacérselos llegar al usuario de la aplicación. Finalmente, llegamos a la conclusión de que es necesario capturar qué ciudadano permite realizar una acción sobre determinados datos personales a un agente sanitario el cual solicita el consentimiento. Para ello, se usan un total de 5 recursos comprendidos en la especificación FHIR así como la API que proporciona conocida como HAPI FHIR. Tiene gran importancia el recurso Consent ya que será el que almacene la información presente en el consentimiento. Además de esto, el uso de la aplicación móvil proporciona una forma muy cómoda de gestión para el usuario y posibilita una continuación en el desarrollo del sistema. Por otro lado, el trabajo con los recursos FHIR puede llegar a complicarse ya que es necesario conocer la estructura de los mismos para poder trabajar con ellos correctamente. Además, el estándar usado se encuentra en continuo desarrollo por lo que la implementación conseguida podría verse obsoleta en un futuro.

Nowadays, we can find numerous and varied systems that use ICT (information and communication technologies) in each area of work. Specifically, in the health sector, we can see that health data from the same individual can be stored in many systems (which, in general, do not share information) and used differently. In other words, there is no interchange point between systems to facilitate the passage of data regardless of how this data has been stored. Therefore, communication in this area is often complex even without entering into the relevant bureaucracy for the passage of data between different health organisations, for example. In addition, to carry out any action on health data, the prior consent of the patient is required in order to do so in such a way that they are restricted and controlled as indicated in the General Data Protection Regulation (GDPR). It is possible for each system to manage consents although this would only aggravate the problem of interoperability between systems using health information. In this way, we conclude that it would be highly desirable to have a single system with which to manage all patient consents related to health information. Thus, any access to this data would need to be requested and approved by the citizen in a single system. To do so, we would have to take into account the General Data Protection Regulation (Regulation 2016/679) whereby the European Parliament, the Council of the European Union and the European Commission intend to strengthen and unify data protection within the European Union (EU). Therefore, the objective of this work is the design and development of a consent manager that works under the GDPR framework. For the storage of consents, we will adopt the latest standard developed by Health Level Seven (HL7), a company responsible for creating some of the most widely used communication protocols today in the healthcare field. This is the Fast Healthcare Interoperability Resources standard, FHIR. Given the large use of the mobile phone that we make today, we consider that it would be very useful to have a mobile application with which the user can manage their medical consents and receive requests for treatment of their health data. In addition, given the pandemic we are experiencing, it is very convenient to use a mobile application for any management for which until now we did not require paper. All this gives us sustenance to a job that could no longer be situated in the current context. Thus, we will have a mobile application that an applicant citizen or agent will use to manage these consents. Through the FHIR standard, different resources collected in the standard and applied in the healthcare field will be used to communicate with a web service which will be responsible for obtaining the necessary data from a database and making them available to the user of the application. Finally, we conclude that it is necessary to capture which citizen allows an action on certain personal data to a health agent who requests the consent. For this, a total of 5 resources covered by the FHIR specification are used as well as the API it provides known as HAPI FHIR. The Consent resource is of great importance as it will be the one that stores the information present in the consent. In addition to this, the use of the mobile app provides a very comfortable form of management for the user and enables a continuation in the development of the system. On the other hand, the work with FHIR resources can become complicated as it is necessary to know the structure of the resources in order to work with them correctly. In addition, the standard used is in continuous development so that the implementation achieved could become obsolete in the future.