ES2936078T3 - Sistema de control y método de la asistencia sanitaria para comunicar datos de pacientes de forma segura - Google Patents

Sistema de control y método de la asistencia sanitaria para comunicar datos de pacientes de forma segura Download PDF

Info

Publication number
ES2936078T3
ES2936078T3 ES17765395T ES17765395T ES2936078T3 ES 2936078 T3 ES2936078 T3 ES 2936078T3 ES 17765395 T ES17765395 T ES 17765395T ES 17765395 T ES17765395 T ES 17765395T ES 2936078 T3 ES2936078 T3 ES 2936078T3
Authority
ES
Spain
Prior art keywords
patient
application
access key
host application
host
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES17765395T
Other languages
English (en)
Inventor
Nina Sellberg
Casper Winsnes
Fredrik Henriques
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Addi Medical AB
Original Assignee
Addi Medical AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Addi Medical AB filed Critical Addi Medical AB
Application granted granted Critical
Publication of ES2936078T3 publication Critical patent/ES2936078T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/88—Medical equipments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Bioethics (AREA)
  • Medical Informatics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Epidemiology (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Computing Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

Se proporciona un método en un sistema de monitoreo de atención médica para la comunicación anónima de datos de pacientes asociados con un paciente desde un dispositivo de usuario electrónico, usando una aplicación de paciente implementada en el dispositivo de usuario electrónico, a un servidor anfitrión, usando una aplicación de anfitrión implementada en el dispositivo anfitrión. servidor, a través de una red inalámbrica, y la identificación del paciente asociado con los datos del paciente después de recibir los datos del paciente en el servidor host. Además, se proporciona un sistema correspondiente, un programa informático y un soporte de datos no volátil que contiene el programa informático. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Sistema de control y método de la asistencia sanitaria para comunicar datos de pacientes de forma segura
CAMPO TÉCNICO
La presente invención se refiere en general a soluciones que permiten la comunicación segura de datos de pacientes.
En particular, la invención se refiere a un método para permitir la comunicación segura de datos de pacientes y su correspondiente sistema. La invención se expone en el conjunto de reivindicaciones adjuntas.
ANTECEDENTES
En el texto que se encuentra a continuación, se utiliza a la asistencia sanitaria como ejemplo de un propietario que tiene una aplicación host. El propietario de la aplicación host podría ser cualquier grupo u organización que pudiera tener interés en los datos de asistencia sanitaria registrados que pertenecen a un individuo / paciente. Los datos de salud se representan como datos cuantitativos, como el número de pasos, el peso, las medidas de electrocardiografía, las medidas del espirómetro, la presión arterial, el grado de percepción del dolor del paciente, etc., o datos cualitativos, que son la percepción del individuo escrita en formato de texto libre.
El grupo y/u organización que tenga interés en los datos cuantitativos o cualitativos registrados de la persona descrita podría ser la asistencia sanitaria pública o privada, proyectos de investigación académica, proyectos de investigación de la industria, registros públicos/privados, registros cualitativos, biobancos, autoridades sanitarias, etc. Los datos también podrían recuperarse con consentimiento para el seguimiento de la venta de bienes de consumo con fines de control de funcionalidad o calidad y de satisfacción del cliente o de comercialización directa. Otra parte interesada en los datos cuantitativos o cualitativos registrados del individuo podría ser la industria farmacéutica.
Cuando nos referimos a la "aplicación del paciente", esto incluye el Conector del Paciente (PC) y también la unidad/dispositivo/cliente del paciente en el que está implementada la aplicación. Cuando nos referimos a la "aplicación host" del personal sanitario, esto incluye el Conector del Paciente ("PC") y también el servidor/unidad/sistema del cuidador.
Transferencia de datos significa que la información se envía a través de un mensaje entre la aplicación en el dispositivo del paciente y la aplicación host en el servidor de asistencia sanitaria.
Un equipo de desarrollo de software ("SDK") es un componente/conjunto de herramientas de desarrollo de software que permite crear aplicaciones para un determinado paquete de software, marco de software, la aplicación del paciente, una historia clínica electrónica, un sistema de investigación u otras aplicaciones y sistemas.
Un ejemplo de la técnica en cuestión se encuentra en el documento de patente US 2008/304663 A1, que describe un sistema para gestionar datos sensibles de pacientes.
RESUMEN
Comunicación segura mediante la conexión de una aplicación host con una aplicación en un dispositivo del paciente (también denominada aplicación del paciente), que contiene información registrada o generada por el paciente. La aplicación host y la aplicación en el dispositivo del paciente se han emparejado a través de un proceso de autorización realizado mediante autenticación segura, ya sea durante una reunión en persona o utilizando la aplicación host y/o la aplicación en la aplicación del paciente. El PC se distribuye como un equipo de desarrollo de software (SDK) que se importa en cualquier aplicación host y cualquier aplicación del paciente. El PC empareja la aplicación host con la aplicación del paciente de forma segura y precisa. El PC proporciona la transferencia de información anónima del paciente entre la aplicación del dispositivo del paciente y la aplicación host.
Según un aspecto, se proporciona un método en un sistema de control de asistencia sanitaria para la comunicación anónima de datos del paciente, asociados con un paciente desde un dispositivo electrónico del usuario, utilizando una aplicación del paciente implementada en el dispositivo electrónico del usuario, a un servidor host, utilizando una aplicación host implementada en el servidor host, a través de una red inalámbrica, y la identificación del paciente asociado con los datos del paciente después de que los datos del paciente se reciban en el servidor host, donde el método comprende:
- emparejar la aplicación del paciente 110 y la aplicación host 130, donde el emparejamiento comprende generar una clave de acceso única K para el paciente P, utilizando la aplicación host 130, donde la clave de acceso única K comprende una primera parte K_1 y una segunda parte K_2, donde la primera parte K_1 de la clave de acceso única K es la clave original y la segunda parte K_2 de la clave de acceso única K es un código con función hash o una huella digital de la clave original, y en la que la clave de acceso K o cualquiera de sus partes K_1 y K_2 no pueden vincularse por sí mismas al paciente P; almacenar la segunda parte K_2 de la clave de acceso única K en una memoria 160 accesible por la aplicación host 130, en la que la segunda parte K_2 se almacena asociada a información que identifica al paciente P; enviar la primera parte K_1 de la clave de acceso única K desde la aplicación host 130 a la aplicación del paciente 110; almacenar la primera parte K_1 de la clave de acceso única K en una memoria 150 accesible por la aplicación del paciente 110;
- recibir en la aplicación del paciente 110 datos del paciente D, de al menos un dispositivo de registro de datos del paciente 170;
- en respuesta a la recepción de los datos del paciente D en la aplicación del paciente 110, enviar los datos del paciente D recibidos y la primera parte de la clave de acceso K_1 a la aplicación host 130, en la que los datos del paciente D no comprenden ninguna información que identifique al paciente P;
- recibir en la aplicación host 130 los datos del paciente D y la primera parte de la clave de acceso K_1; e
- identificar al paciente P asociado con los datos del paciente D recibidos, basándose en la segunda parte K_2 de la clave de acceso K.
Identificar al paciente P asociado con los datos recibidos del paciente D, basándose en la segunda parte K_2 de la clave de acceso K, comprende: generar una segunda parte K_2 de la clave de acceso K basándose en la primera parte recibida K_1 de la clave de acceso K; comparar la segunda parte generada K_2 de la clave de acceso K con una o más segundas partes de claves de acceso almacenadas en la memoria 160 accesible para la aplicación host 130 a fin de encontrar una segunda parte coincidente, en donde la una o más segundas partes de claves de acceso almacenadas se han generado durante el emparejamiento de la aplicación host 150 con una o más aplicaciones del paciente 110; y, si se encuentra una segunda parte coincidente de una clave de acceso, identificar al paciente P como el paciente asociado con la segunda parte coincidente almacenada en la memoria 160.
En algunas realizaciones, el método comprende además, antes de emparejar la aplicación del paciente 110 y la aplicación host 130: autenticar a un personal sanitario como usuario autorizado de la aplicación host 130, utilizando autenticación segura; y autenticar a un paciente como usuario autorizado de la aplicación del paciente 130 utilizando autenticación segura. La autenticación del personal sanitario puede realizarse utilizando la aplicación host 130. La autenticación del paciente P puede realizarse utilizando la aplicación del paciente 110.
En una o más realizaciones, el método puede comprender además el almacenamiento de los datos recibidos del paciente D en la memoria 150 con acceso a la aplicación 110 del paciente;
En una o más realizaciones, la generación de una clave de acceso única K para el paciente P comprende: generar un código numérico aleatorio C que no está relacionado con ninguna información que identifique al paciente P mediante la aplicación host 130; recibir el código numérico aleatorio C en la aplicación del paciente 110; enviar un mensaje en forma de señal de control S1 desde la aplicación del paciente 110 a la aplicación host 130 en respuesta a la recepción de la clave de acceso única K; recibir la señal de control S1 en la aplicación host 130; y generar la clave de acceso única K en la aplicación host 130 en respuesta a la recepción de la señal de control S1.
Según otro aspecto, se proporciona un sistema de control de asistencia sanitaria 100 para la comunicación anónima de datos del paciente D asociados con un paciente P desde un dispositivo de usuario electrónico 120 a un servidor host140 a través de una red inalámbrica 180, y la identificación del paciente P asociada con los datos del paciente D después de que los datos del paciente D se reciban en el servidor host 140, en donde el dispositivo de usuario electrónico 120 comprende una aplicación del paciente 110; y el servidor host 140 comprende una aplicación host 130; y en donde la aplicación del paciente 110 está configurada para comunicarse con la aplicación host 130 a través de la red inalámbrica 180. El sistema 100 comprende además una memoria 150 con acceso por la aplicación del paciente 110 y una memoria 160 con acceso por la aplicación host 130. El sistema 100 está configurado para emparejar la aplicación del paciente 110 y la aplicación host 130 mediante:
- la aplicación host está configurada para: generar una clave de acceso única K para el paciente P, en la que la clave de acceso única K comprende una primera parte K_1 y una segunda parte K_2, en la que la primera parte (K_1) de la clave de acceso única (K) es la clave original y la segunda parte (K_2) de la clave de acceso única (K) es un código con función hash o huella digital de la clave original, y en la que la clave de acceso (K) o cualquiera de sus partes (K_1) y (K_2) no pueden vincularse por sí mismas al paciente (P); almacenar la segunda parte K_2 de la clave de acceso única K en la memoria 160 a la cual puede acceder la aplicación host 130, en la que la segunda parte K_2 se almacena asociada a información que identifica al paciente P; y enviar la primera parte K_1 de la clave de acceso única K a la aplicación de paciente 110;
- la aplicación del paciente 110 está configurada para recibir la primera parte K_1 de la clave de acceso única K de la aplicación host 130; almacenar la primera parte K_1 recibida de la clave de acceso única K en la memoria 150 a la que puede acceder la aplicación del paciente 110; recibir datos del paciente D, de al menos un dispositivo de registro de datos del paciente 170; y en respuesta a la recepción de datos del paciente D en la aplicación del paciente 110, enviar los datos del paciente D recibidos y la primera parte de la clave de acceso K_1 a la aplicación host 130, en la que los datos del paciente (D) no comprenden ninguna información que identifique al paciente (P); y
- la aplicación host 130 está configurada además para: recibir los datos del paciente D y la primera parte de la clave de acceso K_1 de la aplicación del paciente 100; e identificar al paciente P asociado con los datos del paciente D recibidos, basándose en la segunda parte K_2 de la clave de acceso K recibida.
La aplicación host 130 está configurada además para identificar al paciente P asociado con los datos del paciente D recibidos, basándose en la segunda parte K_2 de la clave de acceso K, mediante: generar una segunda parte K_2 de la clave de acceso K basándose en la primera parte recibida K_1 de la clave de acceso K; comparar la segunda parte generada K_2 de la clave de acceso K con una o más segundas partes de claves de acceso almacenadas en la memoria 160 accesible para la aplicación host 130 para encontrar una segunda parte coincidente, en donde la una o más segundas partes de claves de acceso almacenadas se han generado durante el emparejamiento de la aplicación host 150 con una o más aplicaciones del paciente 110; y, si se encuentra una segunda parte coincidente de una clave de acceso, identificar al paciente P como el paciente asociado con la segunda parte coincidente almacenada en la memoria 160.
En algunas realizaciones, la aplicación host 130 está configurada para autenticar a un personal sanitario como usuario autorizado de la aplicación host 130, utilizando autenticación segura, antes del emparejamiento de la aplicación del paciente 110 y la aplicación host 130.
En algunas realizaciones, la aplicación del paciente 110 está configurada para autenticar a un paciente P como usuario autorizado de la aplicación del paciente 110 utilizando autenticación segura, antes del emparejamiento de la aplicación del paciente 110 y la aplicación host 130.
En algunas realizaciones, para generar una clave de acceso única K para el paciente P, la aplicación host 130 está configurada para generar un código numérico aleatorio C que no está relacionado con ninguna información que identifique al paciente P; la aplicación del paciente 110 está configurada para recibir el código numérico aleatorio C de la aplicación host 130; y enviar un mensaje en forma de señal de control S1 a la aplicación host 130 en respuesta a la recepción de la clave de acceso única K; y la aplicación host 130 está configurada para recibir la señal de control S1 de la aplicación del paciente 110; y generar la clave de acceso única K en respuesta a la recepción de la señal de control S1.
DESCRIPCIÓN DE LAS FIGURAS
La invención se explicará ahora más detalladamente por medio de realizaciones preferidas, que se exponen como ejemplos, y en relación con los dibujos adjuntos.
La figura 1 muestra una visión general de un sistema según una o más realizaciones de la invención;
La figura 2 muestra un diagrama de flujo que ilustra un proceso para la comunicación segura de información digital, que comprende pasos según una o más realizaciones del método propuesto;
La figura 3 muestra un diagrama de flujo que ilustra el paso de emparejar la aplicación del paciente y la aplicación host;
La figura 4 muestra un diagrama de flujo que ilustra un proceso para la comunicación segura de información digital, que comprende pasos según una o más realizaciones del método propuesto.
DESCRIPCIÓN DE LA INVENCIÓN
La invención en cuestión proporciona una comunicación segura mediante la transferencia de información que no incluye información de identificación personal o individual para mantener la identidad del proveedor o proveedores de información confidencial durante la transferencia de información. La aplicación del paciente y la aplicación host se emparejarán a través del PC utilizando un código generado aleatoriamente que es único para el paciente en cuestión. El código aleatorio se transfiere a una clave de identificación/acceso en la aplicación del paciente que es conocida por la aplicación host. La identificación o clave de acceso se compara con un código con función hash almacenado en la aplicación host para identificar al proveedor de la información.
En otras palabras, las realizaciones que aquí se presentan permiten la comunicación segura de datos confidenciales y sensibles del paciente, incluso a través de redes abiertas e inalámbricas como Internet, ya que los datos del paciente son completamente anónimos durante la transferencia desde la aplicación del paciente a la aplicación host. Esto es esencial porque existen normativas estrictas que controlan el manejo de datos sensibles de pacientes, las cuales deben cumplirse. Por ejemplo, las realizaciones que aquí se presentan tienen por objeto cumplir el Reglamento General de Protección de Datos (RGPD) de la UE.
Además, las realizaciones que se dan a conocer en el presente documento permiten a la aplicación host, como por ejemplo un proveedor de asistencia sanitaria/personal sanitario, asociar con precisión los datos del paciente con la identidad correcta del paciente una vez que los datos del paciente han sido recibidos desde la aplicación del paciente. Esto también es esencial, ya que los datos médicos enviados por el paciente son inútiles para el proveedor de asistencia sanitaria/personal sanitario, si no se puede establecer sin lugar a dudas con qué paciente están asociados los datos recibidos. Por no mencionar que si no puede establecerse sin lugar a dudas a qué paciente están asociados los datos del paciente recibidos, la seguridad del paciente se vería comprometida debido al riesgo de proporcionar un tratamiento equivocado al paciente equivocado o de no proporcionar tratamiento a un paciente que lo necesita, por ejemplo.
La invención proporciona una solución al problema técnico que supone transferir de forma segura información sensible a través de Internet o de otras redes de información. La invención en cuestión ofrece la solución proporcionando medios y métodos para enviar dicha información sin identificar y sin información de identificación personal, y emparejando la información no identificada en la recepción por parte del usuario host con la información de identidad en la clave de identificación/acceso. Antes de la invención no existía ninguna solución al reto de enviar datos del pacientes no identificados a través de Internet y seguir siendo capaz de conectar de forma segura los datos registrados del paciente en una aplicación del paciente a una aplicación host, por ejemplo, un sistema de apoyo a la toma de decisiones de asistencia sanitaria, un registro electrónico de asistencia sanitaria o un sistema de información de una institución de investigación o cualquier otro registro relacionado con la salud o la biotecnología. En el contexto de la presente divulgación, los datos registrados por el paciente pueden sustituirse o complementarse con datos generados por el paciente, sin que sea necesario modificar el método ni el sistema. Los sistemas host actuales son incapaces de decir con certeza aceptable qué información pertenece a qué paciente sin acomodar la información de identidad del paciente durante la transferencia de información. Para las aplicaciones en las que los pacientes transfieren datos registrados a un proveedor de asistencia sanitaria para el diagnóstico o el seguimiento de la asistencia sanitaria, existe la necesidad de mecanismos de desidentificación, seguridad y precisión al transferir los datos. La invención propuesta resuelve este problema emparejando la aplicación del paciente y la aplicación host durante una reunión presencial entre el paciente y, por ejemplo, un profesional médico de la salud. Alternativamente, la reunión podría ser con una persona que lleve a cabo un proyecto de investigación farmacéutica. En relación con este encuentro, el paciente se ha identificado de forma segura en el mostrador de registro de un departamento en un hospital y el profesional médico se ha identificado, con la denominada autenticación segura, al iniciar sesión en la aplicación host. Los procedimientos de identificación/autenticación cumplen los grados de seguridad y precisión requeridos.
Como alternativa, también el paciente se identifica, utilizando la denominada autenticación segura, al iniciar sesión en la aplicación del paciente o utilizando otro sistema proporcionado por el profesional médico de la salud. También en este caso, los procedimientos de identificación/autenticación cumplen los grados de seguridad y precisión requeridos.
Además, en relación con la realización del emparejamiento de aplicaciones, el paciente acepta conscientemente que la aplicación host y, a su vez, el usuario host (personal médico, personal sanitario u otro agente descrito en el presente documento) tengan acceso a los datos del paciente que se comunican de forma anónima desde la aplicación del paciente con la aplicación host y, además, tengan acceso a la información que identifica de forma exclusiva al paciente, la cual está asociada con los datos del paciente. De acuerdo con las realizaciones que se describen aquí en relación con las figuras, cada vez que se van a enviar datos del paciente desde la aplicación del paciente y también cada vez que se va a realizar una identificación en la aplicación host, se realiza una verificación para determinar si existe un emparejamiento entre la aplicación host y la aplicación del paciente. En otras palabras, el consentimiento del paciente se verifica en todo momento. Si por alguna razón el paciente ya no consiente en compartir sus datos de paciente y sus datos de identificación, puede eliminar la aplicación para pacientes de su teléfono inteligente o de otro dispositivo de usuario en el que se haya instalado la aplicación para pacientes. De este modo, cuando se realiza la siguiente verificación, en el paso 240 o 280 en relación con la figura 2, no se encuentra ningún emparejamiento y el método finaliza. De este modo, se obtiene el grado de seguridad necesario para, por ejemplo, cumplir la GDPR y otras normativas legales pertinentes.
En la figura 1, se muestran realizaciones de un sistema de control de asistencia sanitaria 100 para la comunicación anónima de datos del paciente D, asociados a un paciente P, desde un dispositivo electrónico de usuario a un servidor host, a través de una red inalámbrica, y la identificación del paciente P asociado a los datos del paciente D después de que los datos del paciente D se reciban en el servidor host.
El sistema de control de asistencia sanitaria 100 comprende un dispositivo electrónico de usuario 120, que comprende una aplicación para el paciente 110; y un servidor host 140, que comprende una aplicación host 130. La aplicación para el paciente 110 está configurada para comunicarse con la aplicación host 130 a través de una red inalámbrica 180. El sistema 100 comprende además una memoria 150 con acceso por la aplicación del paciente 110 y una memoria 160 con acceso por la aplicación host 130. El sistema 100 está configurado para emparejar la aplicación del paciente 110 y la aplicación host130. Esto se consigue configurando la aplicación host para i) generar una clave de acceso única K para el paciente P, en la que la clave de acceso única K no está relacionada con ninguna información que identifique al paciente P, en la que la clave de acceso única K comprende una primera parte K_1 y una segunda parte K_2; ii) almacenar la segunda parte K_2 de la clave de acceso única K en la memoria 160 accesible por la aplicación host 130, en la que la segunda parte K_2 se almacena asociada a información que identifica al paciente P; y iii) enviar la primera parte K_1 de la clave de acceso única K a la aplicación del paciente 110; donde la aplicación del paciente 110 está configurada para i) recibir la primera parte K_1 de la clave de acceso única K de la aplicación host 130; ii) almacenar la primera parte K_1 recibida de la clave de acceso única K en la memoria 150 accesible por la aplicación del paciente 110; iii) recibir los datos del paciente D, de al menos un dispositivo de registro de datos del paciente 170; y iv) en respuesta a la recepción de los datos del paciente D en la aplicación del paciente 110, enviar los datos del paciente D recibidos y la primera parte de la clave de acceso K_1 a la aplicación host 130. La aplicación host 130 está configurada además para: i) recibir los datos del paciente D y la primera parte de la clave de acceso K_1 de la aplicación del paciente 100; e ii) identificar al paciente P asociado con los datos del paciente D recibidos, basándose en la segunda parte recibida K_2 de la clave de acceso K. De este modo, los datos del paciente D son anónimos y seguros cuando se envían a través de la red inalámbrica pero se identifican de forma única como asociados con el paciente P después de ser recibidos en la aplicación host.
La aplicación host 130 puede estar configurada para autenticar a un personal sanitario como usuario autorizado de la aplicación host 130, utilizando autenticación segura, antes del emparejamiento de la aplicación para el paciente 110 y la aplicación host 130.
En algunas realizaciones, la aplicación del paciente 110 está configurada para autenticar a un paciente P como usuario autorizado de la aplicación del paciente 110 utilizando autenticación segura, antes del emparejamiento de la aplicación del paciente 110 y la aplicación host 130.
La aplicación host 130 está configurada para identificar al paciente P asociado con los datos recibidos del paciente D, basándose en la segunda parte K_2 de la clave de acceso K, mediante: generar una segunda parte K_2 de la clave de acceso K basándose en la primera parte recibida K_1 de la clave de acceso K; comparar la segunda parte generada K_2 de la clave de acceso K con una o más segundas partes de claves de acceso almacenadas en la memoria 160 accesible para la aplicación host 130 para encontrar una segunda parte coincidente, en donde la una o más segundas partes de claves de acceso almacenadas se han generado durante el emparejamiento de la aplicación host 150 con una o más aplicaciones del paciente 110; y, si se encuentra una segunda parte coincidente de una clave de acceso, identificar al paciente P como el paciente asociado con la segunda parte coincidente almacenada en la memoria 160.
En una o más realizaciones, la generación de una clave de acceso única K para el paciente P se habilita configurando la aplicación host 130 para generar un código numérico aleatorio C que no está relacionado con ninguna información que identifique al paciente P; configurando la aplicación del paciente 110 para recibir el código numérico aleatorio C de la aplicación host 130 y enviar un mensaje en forma de señal de control S1 a la aplicación host 130 en respuesta a la recepción de la clave de acceso única K; y configurando la aplicación host 130 para recibir la señal de control S1 de la aplicación del paciente 110 y generar la clave de acceso única K en respuesta a la recepción de la señal de control S1.
El sistema de control de asistencia sanitaria 100 comprende o está conectado a una memoria 150 accesible para la aplicación del paciente 110. El sistema de control sanitario 100 comprende además o está conectado a una memoria 160 accesible para la aplicación host 130. En la figura 1, la memoria 150 se ilustra como parte de la aplicación del paciente 110 y la memoria 160 se ilustra como parte de la aplicación host 130. Sin embargo, la memoria 150 puede estar integrada, conectada o acoplada comunicativamente a la aplicación del paciente 110 y la memoria 160 puede estar integrada, conectada o acoplada comunicativamente a la aplicación host 130.
La figura 2 muestra un diagrama de flujo que ilustra una o más realizaciones de un método/proceso en un sistema de control de asistencia sanitaria 100 para la comunicación anónima de datos del paciente D, asociados con un paciente P, desde un dispositivo electrónico de usuario 120, utilizando una aplicación para el paciente 110 implementada en el dispositivo electrónico de usuario 120, a un servidor host 140, utilizando una aplicación host 130 implementada en el servidor host 140, a través de una red inalámbrica 180, y además para la identificación del paciente P, asociado con los datos del paciente D, después de que los datos del paciente D se reciban en el servidor host 140.
Según una o más realizaciones ilustradas en la figura 2, el método comprende:
En el paso 200: Emparejar la aplicación para el paciente 110 y la aplicación host 130.
Por supuesto, una aplicación host 130 puede emparejarse con una o más aplicaciones para el paciente 110, para recibir datos del paciente de uno o más pacientes correspondientes.
En un paso opcional 210: Verificar si el emparejamiento del paso 200 se ha realizado correctamente.
Según realizaciones en las que el paso 210 del método consiste en verificar si el emparejamiento del paso 200 se ha realizado correctamente:
- si el emparejamiento no tuvo éxito, el método vuelve al paso 200 para permitir otro intento de emparejamiento opcional; o
- si el emparejamiento fue exitoso, el método continúa según el paso 220 y el paso 260, respectivamente.
Los pasos 220-250 describen los pasos del método ejecutados por la aplicación del paciente 110, y los pasos 260­ 290 describen los pasos del método ejecutados por la aplicación host 130.
En una o más realizaciones, la aplicación del paciente 110 está configurada para ejecutar cualquiera o todas los pasos 220-250 del método.
En una o más realizaciones, la aplicación host 130 está configurada para ejecutar cualquiera o todas los pasos 220­ 250 del método.
En un paso opcional 220: Verificar si se han registrado los datos del paciente D.
Los datos del paciente D pueden haber sido registrados por al menos un dispositivo de registro de datos del paciente 170, en el que al menos un dispositivo de registro de datos del paciente 170 puede comprender una selección de los siguientes: uno o más sensores para la frecuencia de la presión arterial, la frecuencia cardíaca, la frecuencia respiratoria, ECG/EKG (electrocardiograma), la respiración, los niveles de oxígeno en sangre, la temperatura de la sangre, el espirómetro o los equipos Medtech (ultrasonido, control de anestesia para el paciente, equipos de rayos X móviles, concentrador de oxígeno, coagulómetro, báscula para adultos, tomografía computarizada, uno o más formularios digitales, o aplicaciones tales como, por ejemplo, Health Kit o Google Fit.)
Según realizaciones en las que el paso 220 del método consiste en comprobar si se han registrado los datos D del paciente:
- si no se han registrado los datos del paciente D, el método vuelve al paso 220; o
- si se han registrado los datos del paciente D, el método continúa en el paso 230.
En el paso 230: Recibir, en la aplicación del paciente 110, datos del paciente D de al menos un dispositivo de registro de datos del paciente 170.
La recepción de datos del paciente D también puede referirse a la generación de nuevos datos relevantes en la aplicación del paciente 110.
En un paso opcional 240: Verificar si existe un emparejamiento entre la aplicación del paciente 110 y la aplicación host 130.
Las razones por las que un emparejamiento puede dejar de existir son, por ejemplo, que: el emparejamiento entre la aplicación host 130 y la aplicación del paciente 110 haya finalizado, bien porque el paciente P haya borrado la aplicación del paciente 110 de su teléfono inteligente o de otro dispositivo de usuario en el que se haya instalado la aplicación del paciente 110; el proveedor de asistencia sanitaria haya borrado al paciente en la aplicación host 130 borrando la segunda parte K_2 (por ejemplo, el código con función hash) de la clave de acceso única K que está relacionada o asociada con la información de identificación del paciente; o debido a un error.
De acuerdo con realizaciones en las que el paso 210 del método consiste en verificar si existe un emparejamiento entre la aplicación de paciente 110 y la aplicación host 130.
- si no existe emparejamiento alguno, el método finaliza y no se comunican más datos del paciente D desde la aplicación para el paciente 110 a la aplicación host 130; o bien
- si existe un emparejamiento, el método continúa en el paso 250.
En el paso 250: Enviar los datos recibidos del paciente D y de la primera parte K_1 de la clave de acceso K a la aplicación host 130.
El envío de los datos recibidos del paciente D y de la primera parte K_1 de la clave de acceso K a la aplicación host 130 se realiza en respuesta a la recepción de los datos del paciente D en la aplicación del paciente 110.
Como se ha mencionado en relación con la figura 4, de aquí en adelante la información se transfiere de forma segura y automática, de acuerdo con la configuración de la aplicación del paciente 110, entre la aplicación para el paciente 110 y la aplicación host 130. Según diferentes ajustes o configuraciones de la aplicación del paciente 110, los datos del paciente D pueden enviarse/transferirse a la aplicación host 130 de forma continua, con determinados intervalos de tiempo, solo en determinados momentos, por ejemplo, solo por la noche o según cualquier otra regla/configuración adecuada en función de las circunstancias.
En un paso opcional 260: Verificar si se han enviado los datos D del paciente.
Según realizaciones en las que el paso 260 del método consiste en verificar si se han enviado los datos D del paciente:
- si los datos del paciente D no se han enviado, el método repite el paso 260; o
- si se han enviado los datos del paciente D, el método continúa según el paso 270.
En el paso 270: Recibir en la aplicación host 130 los datos del paciente D y la primera parte K_1 de la clave de acceso K.
En un paso opcional 280: Verificar si existe un emparejamiento entre la aplicación del paciente 110 y la aplicación host 130.
De acuerdo con realizaciones en las que el paso 280 del método consiste en verificar si existe un emparejamiento entre la aplicación de paciente 110 y la aplicación host 130.
- si no existe emparejamiento, el método finaliza; o
- si existe un emparejamiento, el método continúa en el paso 290.
En el paso 290: Identificar al paciente P asociado según los datos de paciente D recibidos, basándose en la segunda parte de la clave de acceso K.
El emparejamiento del paso 200 comprende los subpasos 310-340, en los que:
En el subpaso 310: Generar una clave de acceso única K para el paciente P, utilizando la aplicación host 130, en donde la clave de acceso única K no está relacionada en sí misma con ninguna información que identifique al paciente P, en donde la clave de acceso única K comprende una primera parte K_1 y una segunda parte K_2.
El subpaso 310 en el que se genera una clave de acceso única K para el paciente P puede comprender a su vez:
- generar un código numérico aleatorio C, utilizando la aplicación host 130, que no está relacionado con ninguna información que identifique al paciente P;
- recibir el código numérico aleatorio C en la aplicación del paciente 110;
- enviar un mensaje en forma de señal de control S1 desde la aplicación del paciente 110 a la aplicación host 130 en respuesta a la recepción de la clave de acceso única K;
- recibir la señal de control S1 en la aplicación host 130; y
- generar la clave de acceso única K en respuesta a la recepción de la señal de control S1 en la aplicación host 130.
El código numérico aleatorio C puede recibirse en la aplicación del paciente 110 en respuesta a un usuario, es decir, el paciente P, que registra/introduce el código utilizando uno o más dispositivos de entrada (que no se muestran en la figura), los cuales están integrados, conectados o acoplados de forma comunicativa al dispositivo electrónico del usuario 120. Uno o más dispositivos de entrada pueden ser, por ejemplo, en forma de teclado, funcionalidad táctil, funcionalidad de voz a texto o cualquier otro dispositivo de entrada adecuado y conocido en la técnica. Según diferentes realizaciones, se puede comunicar el código numérico aleatorio C al paciente P oralmente por el personal médico/personal sanitario/usuario host o puede enviarse como una señal digital desde la aplicación host 130 a la aplicación del paciente 110 antes de ser introducido en la aplicación del paciente 110 utilizando cualquier protocolo de comunicación adecuado y método de comunicación conocido en la técnica. Como ejemplos no limitativos, el código numérico aleatorio C podría enviarse en forma de un servicio de mensajes cortos (SMS), correo electrónico o un mensaje en la interfaz de la aplicación del paciente.
El paso 310 del método puede comprender además, y la aplicación host 130 puede estar configurada además para, establecer/configurar el número de dígitos en el código numérico aleatorio C y/o la duración de la validación del código numérico aleatorio C.
En el subpaso 320: Almacenar la segunda parte K_2 de la clave de acceso única K en una memoria 160 accesible para la aplicación host 130, en la que la segunda parte K_2 se almacena en relación con la información que identifica al paciente P.
En el subpaso 330: Envío de la primera parte K_1 de la clave de acceso única K desde la aplicación host 130 a la aplicación del paciente 110.
En el subpaso 340: Almacenar la primera parte K_1 de la clave de acceso única K en una memoria 150 accesible para la aplicación del paciente 110.
- Identificar al paciente P asociado con los datos recibidos del paciente D basándose en la segunda parte K_2 de la clave de acceso K, que comprende:
- generar una segunda parte K_2 de la clave de acceso K basándose en la primera parte recibida K_1 de la clave de acceso K;
- comparar la segunda parte generada K_2 de la clave de acceso K con una o más segundas partes de claves de acceso almacenadas en la memoria 160 accesible para la aplicación host 130 para encontrar una segunda parte coincidente, en la que la una o más segundas partes de claves de acceso almacenadas se han generado durante el emparejamiento de la aplicación host 130 con una o más aplicaciones del paciente 110; y
- si se encuentra una segunda parte de una clave de acceso coincidente, se identifica al paciente P como el paciente asociado con la segunda parte coincidente almacenada en la memoria (160).
Una ventaja sustancial de utilizar una clave de acceso única K que no esté relacionada con ninguna información que identifique al paciente P es que la clave de acceso K o cualquiera de sus partes K_1 y K_2 no pueden vincularse por sí mismas al paciente P. En caso de que los datos del paciente D caigan en manos de alguien que no sea el usuario previsto de la aplicación host o del servidor host, la identidad del paciente queda protegida de esta manera.
La primera parte K_1 de la clave de acceso única K es la clave original y la segunda parte K_2 de la clave de acceso única K es un código con función hash o huella digital de la clave original.
El método puede comprender, para generar la segunda parte K_2 de la clave de acceso K basándose en la primera parte K_1 de la clave de acceso K recibida, la ejecución de una función matemática en la primera parte K_1.
La aplicación host 130 puede estar configurada para ejecutar una función matemática en una primera parte K_1 de una clave de acceso única K para generar una segunda parte K_2 de la clave de acceso única K.
El método según cualquiera de las realizaciones que aquí se presentan puede comprender además, antes de emparejar la aplicación de paciente 110 y la aplicación host 130:
- autenticar a un personal sanitario como usuario autorizado de la aplicación host 130 utilizando autenticación segura; y
- autenticar a un paciente como usuario autorizado de la aplicación del paciente 130 utilizando autenticación segura. La autenticación del personal sanitario puede realizarse mediante la aplicación host 130, por ejemplo, durante el inicio de sesión.
La autenticación del paciente P puede realizarse utilizando una aplicación del paciente 110, por ejemplo, durante el inicio de sesión. De forma alternativa, la autenticación del paciente P puede realizarse identificando al paciente P en el mostrador de facturación de un hospital o en un lugar similar utilizando un permiso de conducir, pasaporte o alguna identificación similar.
El método según cualquiera de las realizaciones que aquí se presentan puede comprender además el almacenamiento de los datos recibidos del paciente D en la memoria 150 accesible para la aplicación 110 del paciente.
La figura 4 muestra un diagrama de flujo que ilustra un proceso para la comunicación segura de información digital, que comprende pasos según una o más realizaciones del método propuesto. El paciente de la descripción de la figura 4 corresponde al paciente P.
El proceso para aplicar una comunicación segura mediante la transferencia de información que no incluya datos personales o de identidad individual consta de varios pasos.
A continuación, se describe con más detalle el proceso de comunicación segura ilustrado en la figura 4:
1. El PC se importa tanto en la aplicación host del personal sanitario como en la aplicación del paciente. En cuanto a los números de referencia de la figura 4, este es el paso 1.
2. El PC se personaliza en la aplicación host
a. Configurar el número de dígitos del código aleatorio
b. Duración de la validación del código aleatorio
En cuanto a los números de referencia de la figura 4, este es el paso 2.
3. En la aplicación del paciente, se configura cuándo debe transferirse la información entre la aplicación del paciente y la aplicación host. En cuanto a los números de referencia de la figura 4, este es el paso 3.
4. Identificación
a. El paciente se identifica de forma segura en el mostrador de facturación de un hospital utilizando un permiso de conducir o una identificación similar.
b. El personal médico se identifica de forma segura mediante un inicio de sesión con autenticación segura en la aplicación host.
En cuanto a los números de referencia de la figura 4, este es el paso 4. Como puede verse en el paso 4 de la figura 4. la identificación del paciente puede realizarse, por ejemplo, en la recepción del hospital. Otras opciones aplicables se presentan en relación con la figura 2.
5. El personal médico le pide al paciente que se descargue la aplicación para pacientes en su teléfono inteligente durante la reunión presencial.
6. El personal médico le pide al paciente que abra la aplicación para pacientes en su teléfono inteligente durante la reunión presencial. En cuanto a los números de referencia de la figura 4, esto forma parte del paso 5. 7. El personal médico genera un conjunto aleatorio de números (es decir, un código aleatorio) en la aplicación host para el paciente específico que asiste a la reunión presencial. La aplicación host genera el conjunto aleatorio de números a través del PC importado. En cuanto a los números de referencia de la figura 4, esto forma parte del paso 6. Esto corresponde a la generación del código numérico aleatorio C según las realizaciones que aquí se presentan.
8. El personal médico transmite oralmente al paciente el conjunto aleatorio de números dado durante la reunión presencial. En cuanto a los números de referencia de la figura 4, esto forma parte del paso 6.
9. El paciente registra el conjunto aleatorio de números en la aplicación del paciente a la que accede a través de/la que está instalada en su teléfono inteligente durante la reunión presencial. En cuanto a los números de referencia de la figura 4, este es el paso 7.
El código numérico aleatorio C puede, alternativamente, comunicarse directamente desde la aplicación host 130 y recibirse en la aplicación del paciente, de acuerdo con las realizaciones que aquí se presentan.
10. Se realiza un emparejamiento técnico entre la aplicación host del personal sanitario y la aplicación del paciente. En cuanto a los números de referencia de la figura 4, esto forma parte del paso 8. Esto corresponde al emparejamiento descrito en relación con la figura 2.
11. En adelante, la información se transfiere de forma segura y automática según la configuración del PC entre la aplicación del paciente y la aplicación host del personal sanitario cada vez que se generan y almacenan nuevos datos relevantes en la aplicación del paciente. El mensaje no incluye ninguna información personal o de identidad individual durante la transferencia de información a través de Internet o de cualquier otra red. En cuanto a los números de referencia de la figura 4, esto forma parte de los pasos 8 y 9.
12. El emparejamiento entre la aplicación host y la aplicación del paciente finaliza cuando:
a. El paciente elimina la aplicación del paciente de su teléfono inteligente.
b. El proveedor de asistencia sanitaria elimina al paciente de la aplicación host borrando el código con función hash relacionado con el paciente. En cuanto a los números de referencia de la figura 4, este es el paso 10.
El inicio de sesión por parte del paciente en la aplicación puede incluir la introducción de una contraseña u otros datos no relacionados con su identidad. Esto es preferible a utilizar, por ejemplo, la identificación bancaria u otros métodos vinculados a la identidad del paciente y que, por lo tanto, podrían utilizarse para identificar al paciente que utiliza la aplicación y envía sus datos confidenciales.
A continuación se describe con más detalle cómo se lleva a cabo el emparejamiento técnico entre la aplicación host del personal sanitario y la aplicación del paciente:
i. El personal médico solicita un conjunto aleatorio de números para el paciente identificado delante de él en la aplicación host.
ii. Se crea una identificación en la aplicación host para este paciente específico. Esta identificación no se basa en una identificación personal y no puede vincularse a la identidad de un individuo.
iii. Cuando el conjunto aleatorio de números que se le ha dado oralmente al paciente se registra en la aplicación del paciente, el PC de la aplicación del paciente envía un mensaje al PC de la aplicación host.
iv. Cuando la aplicación host recibe el mensaje, el PC de la aplicación host genera una clave de acceso que se envía a la aplicación del paciente;
a. La clave de acceso se compone de dos partes: a) una clave original que posee la aplicación del paciente y b) un código con función hash de la clave original que posee la aplicación host.
b. El PC de la aplicación host ejecuta una función matemática en la clave de acceso cuando la recibe de la aplicación del paciente. La función matemática genera el código con función hash de la clave original.
Esta clave de acceso corresponde a la clave de acceso única K, que tiene las dos partes K_1 y K_2, según las realizaciones que aquí se presentan.
v. Un código con función hash/huella digital de la clave de acceso que se ha almacenado en la aplicación host; (es un código con función hash/huella digital de la clave de acceso enviada a la aplicación del paciente)
vi. Cada vez que la aplicación del paciente transfiere datos a la aplicación host, la clave de acceso se acompaña/envía junto con esta transferencia.
vii. Cuando la aplicación host recibe el mensaje de la aplicación del paciente, la clave de acceso acompañante recibida se ejecuta a través de una función matemática. El resultado de pasar la clave de acceso por una función matemática es el código con función hash del paciente.
viii. Este código con función hash/huella digital se compara con los códigos con función hash almacenados en la aplicación host para buscar una coincidencia y la identificación del paciente que ha enviado los datos. Esta es una realización de cómo identificar al paciente P asociado con los datos del paciente D recibidos basándose en la segunda parte K_2 de la clave de acceso K, tal como se describe en el presente documento.
El conector del paciente está configurado con un número de dígitos comprendido entre 1 y un número infinito. Se recomienda proporcionar un código aleatorio de al menos 8 dígitos. Para realizar el emparejamiento, el código se transmite de forma oral, por ejemplo, de un profesional médico que trabaje en la aplicación host a un paciente.
El paciente debe realizar el emparejamiento introduciendo el código numérico en la aplicación del cliente que tiene en su teléfono inteligente. Alternativamente, el código numérico se comunica directamente desde la aplicación host 130 a la aplicación del paciente según cualquiera de las realizaciones que aquí se presentan. El cliente de la aplicación debe llamar al código del servidor host dentro de un tiempo determinado, de lo contrario, el código no será válido. La duración se establece en 30 minutos o cualquier otra duración adecuada dependiendo de las circunstancias.
El código se verifica y, si es válido, se empareja con la identidad de un paciente en la aplicación y se genera una clave de acceso. Esta clave de acceso se devuelve a la aplicación del paciente. En la aplicación host se almacena un código con función hash de la clave de acceso que se utiliza para averiguar qué paciente ha comunicado los datos de una aplicación del paciente a la aplicación host. La solución ha logrado así una conexión entre la aplicación del paciente y la aplicación host del personal sanitario. La clave de acceso en sí no contiene ninguna información sobre a quién pertenece la información enviada. Las futuras conexiones entre la aplicación del paciente y la aplicación host del personal sanitario utilizarán la misma clave de acceso cada vez que se realice una transferencia, lo que permitirá a la aplicación host saber siempre de qué paciente proceden los datos enviados.
La comunicación segura se ejercerá ventajosamente en un sistema de ordenador y/o a través de Internet o de cualquier otra red.
El PC se utilizará ventajosamente dentro de cualquier trabajo en una sociedad que pueda beneficiarse del acceso continuo a datos registrados de forma individual, los cuales son seguros y precisos.
En una o más realizaciones, la aplicación del paciente 110 y/o la aplicación host 130 pueden configurarse para realizar cualquiera o todos los pasos y funciones relevantes del método que aquí se presentan.
Todos los pasos del proceso, así como cualquier subsecuencia de pasos, descritos con referencia a las figuras 2, 3 o 4 pueden controlarse utilizando un procesador programado. Las realizaciones de la invención descritas anteriormente en los dibujos comprenden procesadores y procesos realizados en al menos un procesador.
Una realización que no se contempla en la invención reivindicada se refiere a programas informáticos, en particular a programas informáticos sobre o en un soporte, adaptados para poner en práctica la invención. El programa puede estar en forma de código fuente, código objeto, un código fuente intermedio y un código objeto como de forma parcialmente compilada o cualquier otra forma adecuada para su uso en la implementación del proceso según la invención. El programa puede formar parte de un sistema operativo o ser una aplicación independiente. El portador puede ser cualquier entidad o dispositivo capaz de portar el programa. Por ejemplo, el soporte puede ser un medio de almacenamiento, como una memoria Flash, una memoria ROM (memoria de solo lectura), un DVD (disco versátil digital), un CD (disco compacto) o una ROM semiconductora, una memoria EPROM (ROM reprogramable borrable), una memoria EEPROM (ROM reprogramable y borrable eléctricamente), o un medio de almacenamiento magnético, como un disquete o un disco duro. Además, el portador puede ser un portador transmisible, como una señal eléctrica u óptica que puede transportarse por cable eléctrico u óptico, por radio o por otros medios. Cuando el programa está incorporado en una señal que puede transportarse directamente por un cable u otro dispositivo o medio, el soporte puede estar constituido por dicho cable, dispositivo o medio. Alternativamente, el portador puede ser un circuito integrado en el que está incorporado el programa, donde el circuito integrado está adaptado para realizar los procesos pertinentes o para su uso en la realización de los procesos pertinentes. Dicho programa informático puede cargarse en un soporte de datos no volátil, no cubierto por la invención reivindicada, que está conectado comunicativamente a una unidad de procesamiento, el programa de ordenador que comprende un software para ejecutar el método de acuerdo con cualquiera de las realizaciones del método presentadas en el presente documento cuando el programa se ejecuta en la unidad de procesamiento.
El término "comprende" se utiliza en esta especificación para especificar la presencia de características, números enteros, pasos o componentes declarados. Sin embargo, el término no excluye la presencia o adición de una o más características, números enteros, pasos, componentes adicionales o grupos de alguno de ellos.

Claims (10)

REIVINDICACIONES
1. Método en un sistema de control de asistencia sanitaria (100) para la comunicación anónima de datos del paciente (D) asociados a un paciente (P) desde un dispositivo electrónico de usuario (120), utilizando una aplicación para el paciente (110) implementada en el dispositivo electrónico de usuario (120), a un servidor host (140), utilizando una aplicación host (130) implementada en el servidor host, a través de una red inalámbrica (180), e identificación del paciente (P) asociado a los datos del paciente (D) tras la recepción de los datos del paciente (D) en el servidor host (140) que comprende:
- emparejar la aplicación del paciente (110) y la aplicación host (130), donde el emparejamiento comprende:
i) generar una clave de acceso única (K) para el paciente (P), utilizando la aplicación host (130), en la que la clave de acceso única (K) comprende una primera parte (K_1) y una segunda parte (K_2), en la que la primera parte (K_1) de la clave de acceso única (K) es la clave original y la segunda parte (K_2) de la clave de acceso única (K) es un código con función hash o huella digital de la clave original, y en la que la clave de acceso (K), o cualquiera de sus partes (K_1) y (K_2), no pueden vincularse por sí mismas al paciente (P);
ii) almacenar la segunda parte (K_2) de la clave de acceso única (K) en una memoria (160) accesible por la aplicación host (130), en la que la segunda parte (K_2) se almacena en relación con la información que identifica al paciente (P); iii) enviar la primera parte (K_1) de la clave de acceso única (K) desde la aplicación host (130) a la aplicación del paciente (110);
iv) almacenar la primera parte (K_1) de la clave de acceso única (K) en una memoria (150) accesible por la aplicación del paciente (110);
- recibir en la aplicación del paciente (110) datos del paciente (D) procedentes de al menos un dispositivo de registro de datos del paciente (170);
- en respuesta a la recepción de los datos del paciente (D) en la aplicación del paciente (110), enviar los datos del paciente (D) recibidos y la primera parte de la clave de acceso (K_1) a la aplicación host (130), en la que los datos del paciente (D) no comprenden ninguna información que identifique al paciente (P);
- recibir en la aplicación host (130) los datos del paciente (D) y la primera parte de la clave de acceso (K_1); y - identificar al paciente (P) asociado a los datos recibidos del paciente (D), basándose en la segunda parte (K_2) de la clave de acceso (K), mediante:
i) generar una segunda parte (K_2) de la clave de acceso (K), basándose en la primera parte (K_1) recibida de la clave de acceso (K);
ii) comparar la segunda parte generada (K_2) de la clave de acceso (K) con una o más segundas partes de claves de acceso almacenadas en la memoria (160) accesible para la aplicación host (130) para encontrar una segunda parte coincidente, en la que la segunda parte o segundas partes de claves de acceso almacenadas se han generado durante el emparejamiento de la aplicación host (150) con una o más aplicaciones del paciente (110); y
iii) si se encuentra una segunda parte coincidente de una clave de acceso, se identifica al paciente (P) como el paciente asociado a la segunda parte coincidente almacenada en la memoria (160).
2. El método de la reivindicación 1, en el que el método comprende además, antes de emparejar la aplicación del paciente (110) y la aplicación host (130):
- autenticar a un personal sanitario como usuario autorizado de la aplicación host (130) utilizando autenticación segura; y
- autenticar a un paciente como usuario autorizado de la aplicación del paciente (130) utilizando autenticación segura.
3. El método de la reivindicación 2, en el que la autenticación del personal sanitario se realiza mediante la aplicación host (130).
4. El método de la reivindicación 2 o 3, en el que la autenticación del paciente (P) se realiza mediante la aplicación del paciente (110).
5. El método de cualquiera de las reivindicaciones anteriores, que comprende además almacenar los datos recibidos del paciente (D) en la memoria (150) accesible para la aplicación del paciente (110);
6. El método de cualquiera de las reivindicaciones anteriores, en el que generar una clave de acceso única (K) para el paciente (P) comprende:
- generar, mediante la aplicación host (130), un código numérico aleatorio (C) que no está relacionado con ninguna información que identifique al paciente (P);
- recibir, en la aplicación del paciente (110), el código numérico aleatorio (C);
- enviar un mensaje en forma de señal de control (S1) desde la aplicación del paciente (110) a la aplicación host (130) en respuesta a la recepción de la clave de acceso única (K)
- recepción, en la aplicación host (130), de la señal de control (S1); y
- generar, en la aplicación host (130), la clave de acceso única (K) en respuesta a la recepción de la señal de control (S1).
7. Un sistema de control de asistencia sanitaria (100) para la comunicación anónima de datos del paciente (D) asociados a un paciente (P) desde un dispositivo electrónico de usuario (120) a un servidor host (140), a través de una red inalámbrica (180), y la identificación del paciente (P) asociada a los datos del paciente (D) después de que los datos del paciente (D) se reciban en el servidor host (140), en el que:
- el dispositivo electrónico del usuario (120) comprende una aplicación del paciente (110)
- el servidor host (140) comprende una aplicación host (130);
- la aplicación del paciente (110) está configurada para comunicarse con la aplicación host (130) a través de la red inalámbrica (180);
- el sistema (100) comprende además una memoria (150) accesible por la aplicación del paciente (110), y una memoria (160) accesible por la aplicación host (130);
en el que el sistema (100) está configurado para emparejar la aplicación del paciente (110) y la aplicación host (130), mediante:
- la aplicación host está configurada para:
i) generar una clave de acceso única (K) para el paciente (P), donde la clave de acceso única (K) comprende una primera parte (K_1) y una segunda parte (K_2), en la que la primera parte (K_1) de la clave de acceso única (K) es la clave original y la segunda parte (K_2) de la clave de acceso única (K) es un código con función hash o huella digital de la clave original, y en la que la clave de acceso (K) o cualquiera de sus partes (K_1) y (K_2) no pueden vincularse por sí mismas al paciente (P);
ii) almacenar la segunda parte (K_2) de la clave de acceso única (K) en la memoria (160) accesible por la aplicación host (130), en la que la segunda parte (K_2) se almacena en relación con la información que identifica al paciente (P); y
iii) enviar la primera parte (K_1) de la clave de acceso única (K) a la aplicación del paciente (110);
- la aplicación del paciente (110) está configurada para:
i) recibir la primera parte (K_1) de la clave de acceso única (K) de la aplicación host (130);
ii) almacenar la primera parte (K_1) de la clave de acceso única (K) recibida en la memoria (150) accesible por la aplicación del paciente (110);
iii) recibir datos del paciente (D), procedentes de al menos un dispositivo de registro de datos del paciente (170); y iv) en respuesta a la recepción de los datos del paciente (D) en la aplicación del paciente (110), enviar los datos recibidos del paciente (D) y la primera parte de la clave de acceso (K_1) a la aplicación host (130), donde los datos del paciente (D) no comprenden ninguna información que identifique al paciente (P); y
- la aplicación host (130) está configurada además para:
i) recibir los datos del paciente (D) y la primera parte de la clave de acceso (K_1) de la aplicación del paciente (100); e
ii) identificar al paciente (P) asociado a los datos recibidos del paciente (D) basándose en la segunda parte (K_2) de la clave de acceso (K) recibida, mediante:
- generar una segunda parte (K_2) de la clave de acceso (K) basándose en la primera parte (K_1) de la clave de acceso (K) recibida;
- comparar la segunda parte (K_2) de la clave de acceso generada (K) con una o más segundas partes de claves de acceso almacenadas en la memoria (160) accesible para la aplicación host (130), a fin de encontrar una segunda parte coincidente, en la que la una o más segundas partes de claves de acceso almacenadas se han generado durante el emparejamiento de la aplicación host (150) con una o más aplicaciones del paciente (110); y
- si se encuentra una segunda parte coincidente de una clave de acceso, identificar al paciente (P) como el paciente asociado con la segunda parte coincidente almacenada en la memoria (160).
8. Sistema de control de asistencia sanitaria (100) de la reivindicación 7, en el que la aplicación host (130) está configurada para autenticar a un personal sanitario como usuario autorizado de la aplicación host (130) utilizando autenticación segura, antes del emparejamiento de la aplicación del paciente (110) y la aplicación host (130).
9. Sistema de control de asistencia sanitaria (100) de la reivindicación 7 u 8, en el que la aplicación del paciente (110) está configurada para autenticar a un paciente (P) como usuario autorizado de la aplicación del paciente (110) utilizando autenticación segura, antes del emparejamiento de la aplicación del paciente (110) y la aplicación host (130).
10. Sistema de control de asistencia sanitaria (100) de cualquiera de las reivindicaciones 7 a 9, en el que, para generar una clave de acceso única (K) para el paciente (P):
- la aplicación host (130) está configurada para generar un código numérico aleatorio (C) que no está relacionado con ningún tipo de información que identifique al paciente (P);
- la aplicación del paciente (110) está configurada para recibir el código numérico aleatorio (C) de la aplicación host (130) y enviar un mensaje en forma de señal de control (S1) a la aplicación host (130) en respuesta a la recepción de la clave de acceso única (K); y
- la aplicación host (130) está configurada para recibir la señal de control (S1) de la aplicación del paciente (110); y generar la clave de acceso única (K) en respuesta a la recepción de la señal de control (S1).
ES17765395T 2016-09-06 2017-09-05 Sistema de control y método de la asistencia sanitaria para comunicar datos de pacientes de forma segura Active ES2936078T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662383716P 2016-09-06 2016-09-06
PCT/EP2017/072237 WO2018046495A1 (en) 2016-09-06 2017-09-05 Healthcare monitoring method and system for secure communication of patient data

Publications (1)

Publication Number Publication Date
ES2936078T3 true ES2936078T3 (es) 2023-03-14

Family

ID=59858705

Family Applications (1)

Application Number Title Priority Date Filing Date
ES17765395T Active ES2936078T3 (es) 2016-09-06 2017-09-05 Sistema de control y método de la asistencia sanitaria para comunicar datos de pacientes de forma segura

Country Status (11)

Country Link
US (1) US11188676B2 (es)
EP (1) EP3510519B1 (es)
JP (1) JP2019532446A (es)
CN (1) CN110036388B (es)
DE (1) DE112017004464T5 (es)
DK (1) DK3510519T3 (es)
ES (1) ES2936078T3 (es)
FI (1) FI3510519T3 (es)
GB (1) GB2569717A (es)
SE (1) SE543935C2 (es)
WO (1) WO2018046495A1 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6910529B2 (ja) * 2018-02-21 2021-07-28 帝人ファーマ株式会社 酸素濃縮装置を監視するサーバ、監視システム、端末、監視装置及び方法
EP4102796A1 (en) 2021-06-07 2022-12-14 Addi Medical AB Method, computer program product and processing circuitry for making medical data available to third parties

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7519591B2 (en) * 2003-03-12 2009-04-14 Siemens Medical Solutions Usa, Inc. Systems and methods for encryption-based de-identification of protected health information
US8308640B2 (en) * 2004-09-30 2012-11-13 Koninklijke Philips Electronics N.V. System for automatic continuous and reliable patient identification for association of wireless medical devices to patients
FR2881248A1 (fr) * 2005-01-26 2006-07-28 France Telecom Systeme et procede d'anonymisation de donnees personnelles sensibles et procede d'obtention de telles donnees
WO2012015645A2 (en) * 2010-07-27 2012-02-02 Quantia Communications, Inc. Computer method and system binding patient devices and physician devices
CN105339977A (zh) * 2013-01-21 2016-02-17 赫美特里克斯有限公司 安全实时健康记录交换
US10607726B2 (en) * 2013-11-27 2020-03-31 Accenture Global Services Limited System for anonymizing and aggregating protected health information

Also Published As

Publication number Publication date
GB2569717A (en) 2019-06-26
US20190188415A1 (en) 2019-06-20
JP2019532446A (ja) 2019-11-07
FI3510519T3 (fi) 2023-01-31
DE112017004464T5 (de) 2019-07-04
SE543935C2 (en) 2021-09-28
SE1950412A1 (en) 2019-04-03
CN110036388A (zh) 2019-07-19
EP3510519B1 (en) 2022-10-26
CN110036388B (zh) 2023-05-26
US11188676B2 (en) 2021-11-30
DK3510519T3 (da) 2023-01-23
GB201904855D0 (en) 2019-05-22
WO2018046495A1 (en) 2018-03-15
EP3510519A1 (en) 2019-07-17

Similar Documents

Publication Publication Date Title
US11335441B2 (en) Health safety system, service, and method
US11335440B1 (en) Health status system, platform, and method
US10019552B2 (en) Systems and methods for remote patient monitoring and storage and forwarding of patient information
CN103733201B (zh) 用于手持医疗设备的密码数据分布和撤销
US20080097793A1 (en) Systems and methods for remote patient monitoring and user interface
US20110288874A1 (en) System and Method for Providing Authentication of Medical Data Through Biometric Identifier
US20080097550A1 (en) Systems and methods for remote patient monitoring and command execution
US20090112769A1 (en) Systems and methods for remote patient monitoring
US8943556B2 (en) Secure information release
US20120041788A1 (en) System and Method for Facilitating Outcome-Based Health Care
US20210118579A1 (en) System and method for secure, private, and trusted medical information monitoring and semi-autonomous prescription management
JP5863993B2 (ja) ソーシャル・ネットワーキング・ウェブ・サービスを介した機密情報アクセスのための方法、システム、コンピュータ・プログラム
ES2672150T3 (es) Métodos para acceder de forma remota a registros médicos electrónicos sin autorización previa
JP2020091850A (ja) 健康データを交換する方法および装置
ES2936078T3 (es) Sistema de control y método de la asistencia sanitaria para comunicar datos de pacientes de forma segura
US20180263495A1 (en) Secure pulse oximeter, monitor and cloud connection
US20160180048A1 (en) Cloud-based medical information retrieval method and system thereof
ES2690354T3 (es) Sistema de seguridad con gestor de cuentas para un dispositivo médico portátil
US20140359715A1 (en) Medical system and method for authorizing a user to use a medical device of a medical system
JP2015201190A (ja) 情報処理装置及び方法、並びにプログラム
JP4986382B2 (ja) 固有情報記録装置を用いたデータ検出システム
CN106415557B (zh) 在基于云的临床决策支持系统(cdss)的去识别的患者数据上执行的控制动作
JP2014160342A (ja) 患者案内システム
Teng et al. Authentication and usability in mHealth apps
US20220117692A1 (en) Healthcare monitoring method and system for secure communication of patient data