ES2949554T3

ES2949554T3 - Sistema y método para proporcionar control de acceso multicapa

Info

Publication number: ES2949554T3
Application number: ES16184681T
Authority: ES
Inventors: Benjamin Alexander Hughes; Michael Carl Friedrich Opel; Braley B Crandall
Original assignee: Iqvia Inc
Current assignee: Iqvia Inc
Priority date: 2015-08-19
Filing date: 2016-08-18
Publication date: 2023-09-29
Anticipated expiration: 2036-08-18
Also published as: EP3133521A1; US10726148B2; US20170053130A1; EP3133521B1; EP4220457A1

Abstract

Se divulga un método y un sistema para proporcionar control de acceso de múltiples capas para conjuntos de datos de atención médica. El método comprende definir una política de información para cada uno de los conjuntos de datos de atención médica, en donde la política de información comprende permisos de acceso a la información. Además, se define una política de organización para cada uno de los conjuntos de datos de atención médica, en donde la política de organización comprende permisos de licencia para organizaciones que acceden a los conjuntos de datos de atención médica. A partir de entonces, se define una política maestra de cuenta de usuario para cada uno de los conjuntos de datos de atención médica, en donde la política maestra de cuenta de usuario comprende permisos de cuenta asignados a los usuarios de las organizaciones. Posteriormente se genera una política maestra de usuario para cada uno de los usuarios en base a la política de información, la política de la organización, la política maestra de cuentas de usuario o una combinación de las mismas. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Sistema y método para proporcionar control de acceso multicapa

Antecedentes de la invención

Campo de la invención

Las realizaciones de la presente invención generalmente se refieren a técnicas de acceso y seguridad de datos y, en particular, a un sistema y método para proporcionar acceso a conjuntos de datos.

Descripción de la técnica relacionada

Las aplicaciones y los servicios de software generalmente usan varios mecanismos para la autenticación y/o autorización de un usuario para acceder a datos, como datos sanitarios, de los conjuntos de datos. Las preocupaciones sobre la privacidad son especialmente importantes para los datos sanitarios. Estas preocupaciones sobre la privacidad pueden variar según el país, el propietario de los datos, el propietario comercial o la organización que utiliza los datos. Por lo general, los propietarios de datos limitan las actividades de un usuario de datos contractualmente. Por ejemplo, el propietario de un conjunto de datos puede limitar el acceso de un usuario al historial médico de un paciente almacenado en un conjunto de datos. Sin embargo, estas limitaciones no garantizan al propietario de los datos que sus conjuntos de datos se utilicen completamente dentro de las restricciones establecidas contractualmente. Además, las técnicas convencionales que no permiten configuraciones específicas de privacidad no se pueden usar para controlar el acceso a los datos sanitarios. Sin embargo, la configuración específica de privacidad carece de la funcionalidad de protección de privacidad requerida para uso comercial y/o científico de los conjuntos de datos. Además, las técnicas convencionales utilizadas para permitir que los usuarios accedan a los conjuntos de datos requieren tiempo, esfuerzo y competencia y, por lo tanto, los propietarios de los datos implementan modelos de permisos incompletos, que a su vez limitan las búsquedas de los usuarios. Además, las técnicas convencionales limitan el acceso de los usuarios a los datos sanitarios dentro de un solo país y, por lo tanto, no permiten que los usuarios accedan a datos en conjuntos de datos distribuidos o dispersos geográficamente. Los usuarios pueden acceder a los conjuntos de datos dentro del país en base a la configuración específica de privacidad predefinida. Además, la autenticación y/o autorización se logra mediante el uso de una contraseña, una respuesta a preguntas de seguridad u otras credenciales que pueden validarse contra una Lista de Control de Acceso (ACL) almacenada. Por ejemplo, se le puede solicitar al usuario que proporcione credenciales de inicio de sesión, como nombre de usuario y/o contraseña, para acceder a los datos almacenados en los conjuntos de datos. Sin embargo, las técnicas convencionales para proporcionar configuraciones específicas de privacidad para acceder a datos de conjuntos de datos carecen de especificidad, facilidad de uso, requieren mucho tiempo y no brindan suficiente control de acceso a datos protegidos distribuidos o dispersos geográficamente.

El documento US 2005/0236474 se relaciona con un sistema para procesar información de salud del paciente (PHI) que protege la confidencialidad de la PHI para lograr el cumplimiento normativo. La PHI contiene datos médicos del paciente y datos de identificación del paciente asociados. Un agente de desidentificación extrae los datos médicos del paciente y los separa de todos los datos de identificación para crear datos de pacientes no identificados. Se genera una clave que permite volver a asociar posteriormente los datos médicos del paciente y los datos de identificación del paciente. La base de datos de pacientes no identificados se puede consultar con fines de selección de pacientes. Las consultas de los pacientes se procesan solo si el estudio o la evaluación del paciente han sido autorizados por las autoridades correspondientes, como una junta de revisión interna. Los pacientes cuyas características médicas se ajustan a la consulta del paciente se seleccionan para su posible uso en un estudio. Si es necesaria y autorizada la reidentificación de los pacientes seleccionados, la clave puede utilizarse para proporcionar la reasociación necesaria. Un registro de datos registra todos los accesos a los datos del paciente.

El documento US 2013/0346104 se refiere a un sistema y un método incluye recibir, de un proveedor, datos no identificados que describen a los pacientes. El método incluye además habilitar el acceso selectivo a los datos no identificados en el almacén de datos por parte de buscadores autorizados por el proveedor.

El documento US 2013/0304512 se relaciona con el método para compartir datos en un entorno de red clínica e incluye asociar a un participante con una comunidad en un entorno de red clínica que comprende pacientes, proveedores médicos y pagadores, determinar los privilegios de acceso de los participantes a los datos en una base de datos y proporcionar acceso a los datos de acuerdo con un modo predeterminado de compartir asociado con los datos. Los datos incluyen datos médicos, datos financieros y datos de operaciones asociados con pacientes, proveedores médicos y pagadores. El modo predeterminado de compartir puede incluir el modo pesimista, el modo optimista o el modo oportunista. Según el modo optimista, todos los participantes de la comunidad pueden acceder a todos los datos de la base de datos. De acuerdo con el modo pesimista, los datos seleccionados en la base de datos son accesibles para todos los participantes de la comunidad. De acuerdo con el modo oportunista, los datos personalizados seleccionados en la base de datos son accesibles para participantes específicos de la comunidad. Por lo tanto, se requieren técnicas mejoradas para proporcionar seguridad de datos y control de acceso a datos.

Resumen

La presente invención se define en las reivindicaciones independientes adjuntas a las que se debe hacer referencia. Las características ventajosas se exponen en las reivindicaciones dependientes adjuntas.

Las realizaciones de acuerdo con la presente divulgación proporcionan un método implementado por ordenador para proporcionar control de acceso multicapa para conjuntos de datos sanitarios distribuidos. El método que comprende: definir una política de información para cada uno o más conjuntos de datos sanitarios distribuidos, en donde la política de información comprende uno o más permisos de acceso a la información; definir una política de organización para cada uno o más conjuntos de datos sanitarios distribuidos, en donde la política de organización comprende uno o más permisos de licencia para una o más organizaciones que acceden a uno o más conjuntos de datos sanitarios distribuidos; definir una política maestra de cuenta de usuario para cada uno o más conjuntos de datos sanitarios distribuidos, en donde la política maestra de cuenta de usuario comprende uno o más permisos de cuenta asignados a uno o más usuarios de una o más organizaciones; y generar una política de usuario maestra para cada uno de los uno o más usuarios en base a al menos una de las políticas de información, la política de organización, la política maestra de cuenta de usuario o una combinación de las mismas, en donde la política de usuario maestra comprende uno o más permisos de control de acceso para proporcionar acceso a cada uno de los uno o más usuarios al uno o más conjuntos de datos sanitarios distribuidos.

Las realizaciones de acuerdo con la presente divulgación proporcionan un sistema para proporcionar control de acceso multicapa para conjuntos de datos sanitarios distribuidos. El sistema que comprende: un módulo de información configurado para definir una política de información para cada uno o más conjuntos de datos sanitarios distribuidos, en donde la política de información comprende uno o más permisos de acceso a la información; un módulo de organización configurado para definir una política de organización para cada uno o más conjuntos de datos sanitarios distribuidos, en donde la política de organización comprende uno o más permisos de licencia para una o más organizaciones que acceden a uno o más conjuntos de datos sanitarios distribuidos; un módulo maestro de cuenta de usuario configurado para definir una política maestra de cuenta de usuario para cada uno o más conjuntos de datos sanitarios distribuidos, en donde la política maestra de cuenta de usuario comprende uno o más permisos de cuenta asignados a uno o más usuarios de una o más organizaciones; y un módulo de acceso de usuario configurado para generar una política de usuario maestra para cada uno o más usuarios en base a al menos una de la política de información, la política de organización, la política maestra de cuenta de usuario o una combinación de las mismas, en donde la política de usuario maestra comprende uno o más permisos de control de acceso para proporcionar a cada uno de los uno o más usuarios acceso a uno o más conjuntos de datos sanitarios distribuidos.

Las realizaciones de acuerdo con la presente divulgación proporcionan un método implementado por ordenador para proporcionar control de acceso multicapa para conjuntos de datos sanitarios distribuidos. El método que comprende: definir una política de información para cada uno o más conjuntos de datos sanitarios distribuidos, en donde la política de información comprende uno o más permisos de acceso a la información; definir una política de organización para cada uno o más conjuntos de datos sanitarios distribuidos, en donde la política de organización comprende uno o más permisos de licencia para una o más organizaciones que acceden a uno o más conjuntos de datos sanitarios distribuidos; definir una política maestra de cuenta de usuario para cada uno o más conjuntos de datos sanitarios distribuidos, en donde la política maestra de cuenta de usuario comprende uno o más permisos de cuenta asignados a uno o más usuarios de una o más organizaciones; generar una política de usuario maestra para cada uno de los uno o más usuarios en base a al menos una de las políticas de información, la política de organización, la política maestra de cuentas de usuario o una combinación de las mismas, en donde la política de usuario maestra comprende uno o más permisos de control de acceso para proporcionar a cada uno de los uno o más usuarios acceso a uno o más conjuntos de datos sanitarios distribuidos; y definir una política de administrador principal, en donde la política de administrador principal comprende uno o más permisos principales para el control de al menos una de las políticas de información, la política de organización o una combinación de las mismas.

Lo anterior es un resumen simplificado de las realizaciones de la divulgación para proporcionar una comprensión de algunos aspectos de la divulgación. Este resumen no es una descripción general extensa ni exhaustiva de la divulgación y sus diversas realizaciones. Este no pretende identificar elementos clave o críticos de la divulgación ni delinear el alcance de la divulgación, sino presentar conceptos seleccionados de la divulgación en forma simplificada como una introducción a la descripción más detallada que se presenta a continuación. Como se apreciará, son posibles otras realizaciones de la divulgación utilizando, solas o en combinación, una o más de las características expuestas anteriormente o descritas en detalle a continuación.

Breve descripción de los dibujos

Las anteriores y otras características y ventajas de la presente invención se harán evidentes al considerar la siguiente descripción detallada de las realizaciones de la misma, especialmente cuando se toman en conjunto con los dibujos adjuntos en los que se utilizan números de referencia similares en las diversas figuras para designar componentes similares, y en donde:

La Figura 1 representa un sistema para proporcionar control de acceso multicapa para conjuntos de datos sanitarios distribuidos, según una realización de la presente divulgación;

La Figura 2 representa componentes de una plataforma de permisos, según una realización de la presente divulgación;

La Figura 3 ilustra un diagrama de flujo de un método para proporcionar control de acceso multicapa para conjuntos de datos sanitarios distribuidos, de acuerdo con una realización de la presente divulgación;

La Figura 4 ilustra un diagrama de flujo de un método para proporcionar control de acceso multicapa para conjuntos de datos sanitarios distribuidos a un usuario, según otra realización de la presente divulgación;

La Figura 5 ilustra un escenario ilustrativo para proporcionar control de acceso multicapa para conjuntos de datos sanitarios distribuidos, de acuerdo con una realización de la presente divulgación;

La Figura 6 es una tabla ilustrativa que ilustra permisos de políticas multicapa, de acuerdo con una realización de la presente divulgación;

La Figura 7 representa un diagrama de bloques ilustrativo del flujo de información en la plataforma de permisos, de acuerdo con una realización de la presente divulgación; y

La Figura 8 representa un sistema informático que puede usarse para implementar diversas realizaciones ilustrativas de la presente divulgación.

Todos los encabezados utilizados en la presente memoria son solo para fines organizativos y no pretenden usarse para limitar el alcance de la descripción o las reivindicaciones. Como se usa a lo largo de esta solicitud, la palabra “puede” se usa en un sentido permisivo (es decir, que significa tener el potencial para) en lugar del sentido obligatorio (es decir, que significa debe). De manera similar, las palabras "incluye" y "que incluye" significan que incluyen, pero sin limitarse a. Para facilitar la comprensión, se han usado los mismos números de referencia, cuando sea posible, para designar los mismos elementos que son comunes a las figuras. Las porciones opcionales de las figuras se pueden ilustrar usando líneas discontinuas o punteadas, a menos que el contexto de uso indique lo contrario.

Descripción detallada

La divulgación se ilustrará a continuación junto con un sistema de información digital ilustrativo. Aunque es muy adecuado para su uso con, por ejemplo, un sistema que utiliza un servidor y/o bases de datos, la divulgación no se limita al uso con ningún tipo particular de sistema o configuración de elementos del sistema. Los expertos en la materia reconocerán que las técnicas descritas pueden utilizarse en cualquier sistema o proceso en el que sea deseable gestionar datos y proporcionarlos a los clientes en base a sus preferencias.

Los sistemas y métodos ilustrativos de esta divulgación también se describirán en relación con el software, los módulos y el hardware asociado. Sin embargo, para evitar una confusión innecesaria de la presente divulgación, la siguiente descripción omite estructuras, componentes y dispositivos bien conocidos que pueden mostrarse en forma de diagrama de bloques, que son bien conocidos o se resumen de otro modo.

En la siguiente descripción detallada, se exponen numerosos detalles específicos para proporcionar una comprensión exhaustiva de las realizaciones u otros ejemplos descritos en la presente memoria. En algunos casos, los métodos, procedimientos, componentes y circuitos bien conocidos no se han descrito en detalle, para no provocar una confusión de la presente descripción. Además, los ejemplos divulgados son solo para fines ilustrativos y se pueden emplear otros ejemplos en lugar de, o en combinación con los ejemplos divulgados. También debe tenerse en cuenta que los ejemplos presentados en este documento no deben interpretarse como limitantes del alcance de las realizaciones de la presente invención, ya que son posibles y probables otros ejemplos igualmente efectivos.

Como se usa aquí, el término "módulo" se refiere generalmente a una secuencia lógica o asociación de pasos, procesos o componentes. Por ejemplo, un módulo de software puede comprender un conjunto de rutinas o subrutinas asociadas dentro de un programa informático. Alternativamente, un módulo puede comprender un dispositivo de hardware sustancialmente autónomo. Un módulo también puede comprender un conjunto lógico de procesos independientemente de cualquier implementación de software o hardware.

Un módulo que realiza una función también puede denominarse como configurado para realizar la función, por ejemplo, un módulo de datos que recibe datos también puede describirse como configurado para recibir datos. La configuración para realizar una función puede incluir, por ejemplo: proporcionar y ejecutar código informático en un procesador que realiza la función; proporcionar parámetros de configuración provisionales que controlan, limitan, habilitan o deshabilitan las capacidades del módulo (por ejemplo, establecer una bandera, establecer permisos, establecer niveles de umbral utilizados en puntos de decisión, etc.); proporcionar una conexión física, tal como un puente para seleccionar una opción, o para habilitar/deshabilitar una opción; adjuntar un enlace de comunicación físico; habilitar un enlace de comunicación inalámbrica; suministrar circuitos eléctricos diseñados para realizar la función sin el uso de un procesador, como por ejemplo mediante el uso de componentes discretos y/o circuitos integrados sin CPU; energizar un circuito que realiza la función (por ejemplo, proporcionar energía a un circuito transceptor para recibir datos); etcétera.

El término "medio legible por ordenador" como se usa en la presente memoria se refiere a cualquier medio tangible de almacenamiento y/o transmisión que participe en el almacenamiento y/o proporcione instrucciones a un procesador para su ejecución. Tal medio puede tomar muchas formas, que incluyen, pero no se limitan a, medios no volátiles, medios volátiles, y medios de transmisión. Los medios no volátiles incluyen, por ejemplo, NVRAM, o discos ópticos o magnéticos. Los medios volátiles incluyen una memoria dinámica, tal como la memoria principal. Las formas comunes de medios legibles por ordenador incluyen, por ejemplo, un disquete, un disco flexible, un disco duro, una cinta magnética, cualquier otro medio magnético, un CD-ROM,, cualquier otro medio óptico, tarjetas perforadas, cinta de papel, cualquier otro medio físico con patrones de orificios, una RAM, una PROM, una EPROM, una FLASH-EEPROM, un medio en estado sólido como una tarjeta de memoria, cualquier otro chip de memoria o cartucho, un onda portadora como se describe a continuación, o cualquier otro medio que pueda leer un ordenador. Un archivo digital adjunto a un correo electrónico u otro archivo o conjunto de archivos de información independiente se considera un medio de distribución equivalente a un medio de almacenamiento tangible. Cuando los medios legibles por ordenador se configuran como una base de datos, se debe entender que la base de datos puede ser cualquier tipo de base de datos, como relacional, jerárquica, orientada a objetos y/o similar. En consecuencia, se considera que la divulgación incluye un medio de almacenamiento tangible o medio de distribución y equivalentes reconocidos en la técnica anterior y medios sucesores, en los que se almacenan las implementaciones de software de la presente divulgación.

La Figura 1 representa un sistema 100 para proporcionar control de acceso multicapa sobre conjuntos de datos sanitarios distribuidos, según una realización de la presente divulgación. Como se discutió anteriormente, la privacidad y la seguridad son importantes al proporcionar acceso a datos y control. El control de acceso es extremadamente crítico para los datos sanitarios. En una realización, los conjuntos de datos sanitarios 104a-p pueden incluir información sobre un paciente o un especialista en atención médica, por ejemplo, nombre, edad, fecha de nacimiento, ocupación, domicilio, dirección de la oficina, historial médico, informes médicos, detalles del médico en cuestión, experiencia laboral de los médicos, tipo de lesión o enfermedad, y similares. Al menos algunos de estos datos confidenciales de información de salud del paciente están protegidos por la ley (por ejemplo, Ley de Portabilidad y Responsabilidad de la Información de Atención Médica ("HIPAA", codificada en 42 USC § 300gg y 29 U.S.C § 1181 et seq. y 42 USC 1320d et seq.) en Estados Unidos) y debe tratarse de manera que se mantenga la privacidad del paciente. Tal información se denomina información de salud protegida (PHI). El acceso al conjunto de datos sanitarios 104 por parte de una entidad no autorizada puede dar lugar a la violación de la privacidad o seguridad de los pacientes y especialistas registrados en los conjuntos de datos. En una realización, la información en el conjunto de datos sanitarios 104 puede ser pseudoanonimizada. Por ejemplo, la información como el nombre, la dirección particular o el número de seguro social puede eliminarse o anonimizarse. El sistema 100 proporciona control de acceso sobre los conjuntos de datos sanitarios 104. En una realización, el sistema 100 permite hacer cumplir las regulaciones gubernamentales o de salud. Además, el sistema 100 permite la provisión de opciones de permiso para el conjunto de datos sanitarios 104 que reflejan la privacidad existente y las posibles prácticas de protección futuras.

Como se muestra, cada propietario de conjunto de datos 102a-n puede mantener y proporcionar uno o más conjuntos de datos sanitarios 104. Los ejemplos del propietario del conjunto de datos 102 incluyen, entre otros, una organización de investigación sanitaria, una empresa farmacéutica, un agregador de datos y similares. En una realización, los propietarios de conjunto de datos 102 y los conjuntos de datos sanitarios 104 pueden estar distribuidos geográficamente y pueden estar conectados a través de una red 114. Por ejemplo, el propietario del conjunto de datos 102a puede mantener el conjunto de datos sanitarios 104a en Estados Unidos, mientras que el propietario del conjunto de datos 102b puede mantener el conjunto de datos sanitarios 104b en Canadá. Un experto en la técnica apreciará que se pueden realizar varias disposiciones distribuidas geográficamente de los conjuntos de datos sanitarios 104 y los propietarios 102 de conjuntos de datos. Los propietarios de conjunto de datos 102 pueden desear controlar apropiadamente el acceso a los conjuntos de datos proporcionados por ellos. Por ejemplo, el acceso a una parte del conjunto de datos sanitarios 104 mantenido en Canadá puede estar restringido al uso dentro de Canadá. Las ubicaciones geográficas para las restricciones de límites geográficos pueden determinarse, por ejemplo, mediante direcciones IP. Una plataforma de permisos 110 del sistema 100 permite el control de acceso sobre los conjuntos de datos sanitarios 104. En una realización, la plataforma de permisos 110 puede ser mantenida por una organización que permita el acceso consolidado a conjuntos de datos sanitarios distribuidos geográficamente. Además, el acceso a la información en los conjuntos de datos sanitarios 104 puede controlarse en base a las suscripciones o licencias. Por ejemplo, una organización de investigación puede licenciar uno o más conjuntos de datos sanitarios 104, como una base de datos de enfermedades, para realizar investigaciones sobre medicamentos o protocolos potenciales.

En una realización, uno o más usuarios 108a-m acceden a los conjuntos de datos sanitarios 104 a través de la plataforma de permisos 110. Los ejemplos de los usuarios 108 incluyen, pero no se limitan a, una organización, uno o más usuarios de la organización, investigadores independientes y similares. En un escenario ilustrativo, la plataforma de permisos 110 permite que uno o más usuarios de una organización de investigación accedan a los conjuntos de datos sanitarios 104. Como se muestra, los usuarios 108 pueden comunicarse con la plataforma de permisos 110 a través de la red 114. Por ejemplo, la red 114 puede ser una red de telefonía, una red inalámbrica, una red de datos, una red de datos de un proveedor de servicios, Internet y similares. Con fines ilustrativos, la red 114 puede ser cualquier red alámbrica, inalámbrica o una combinación de las mismas, que son gestionadas por uno o más proveedores de servicios. Por ejemplo, la red de telefonía puede incluir, entre otras, una red de conmutación de circuitos, como la Red Telefónica Pública Conmutada (PSTN), una Red Digital de Servicios Integrados (ISDN), una Centralita Privada (PBX), una red basada en el Protocolo de Iniciación de Sesión (SIP) u otras redes similares.

En una realización, la plataforma de permisos 110 define políticas de control de acceso multicapa para controlar el acceso a los conjuntos de datos sanitarios distribuidos 104. Además, cada política puede incluir uno o más permisos definidos para controlar el acceso a los conjuntos de datos sanitarios 104. En una realización, la plataforma de permisos 110 puede definir una política de información para cada uno de los conjuntos de datos sanitarios distribuidos 104. La política de información puede incluir permisos de acceso a la información para los conjuntos de datos sanitarios 104, según lo deseen los propietarios de conjunto de datos 102. En un escenario ilustrativo, si el propietario 102 del conjunto de datos decide denegar el permiso de acceso a una organización a un conjunto de datos, entonces la plataforma 110 de permisos puede definir una política de información apropiada basada en los permisos de acceso a la información. En otro escenario ilustrativo, la política de información definida por la plataforma de permisos 110 puede permitir el acceso a solo un subconjunto del conjunto de datos sanitarios 104. Por lo tanto, la plataforma de permisos 110 permite a los propietarios de conjunto de datos 102 controlar el acceso a los datos que poseen o mantienen.

En una realización, la plataforma de permisos 110 puede definir una política de organización que puede incluir uno o más permisos de licencia para una organización que toma una licencia o se suscribe a conjuntos de datos sanitarios 104. En un escenario ilustrativo, la plataforma de permisos 110 puede permitir que los controladores de licencia o suscripción 106a-n definan los permisos de licencia para que una organización acceda al conjunto de datos sanitarios 104a y al conjunto de datos sanitarios 104b, pero no al conjunto de datos sanitarios 104c en base a una licencia tomada por la organización. Por lo tanto, el acceso de la organización está restringido a los conjuntos de datos permitidos en la política de organización. En una realización, el controlador de licencias 106 puede ser un proveedor de servicios que proporciona suscripciones o licencias a los usuarios 108 para acceder a los conjuntos de datos sanitarios 104 a través de la red 114. En una realización, la política de organización puede heredar los permisos de la política de información. En consecuencia, el permiso de acceso de la organización puede definirse en función tanto de los permisos de acceso a la información como de los permisos de licencia. Por ejemplo, a la organización se le puede permitir el acceso a solo una parte del conjunto de datos sanitarios 104a y al conjunto de datos sanitarios 104b en base a los permisos definidos en la política de información.

En una realización, la plataforma de permisos 110 puede definir una política maestra de cuenta de usuario, que incluye uno o más permisos de cuenta para que uno o más usuarios de una organización accedan a los conjuntos de datos sanitarios 104. Los permisos de cuenta pueden ser requeridos por una organización que tenga licencia de los conjuntos de datos sanitarios 104 para controlar el acceso de los usuarios de la organización. En un escenario ilustrativo, la organización que tiene licencia para el conjunto de datos sanitarios 104a puede desear permitir a sus usuarios solo una parte de los datos del conjunto de datos sanitarios 104a o una parte de la funcionalidad de la plataforma de permisos 110. Por ejemplo, los permisos de la cuenta pueden restringir el acceso de una o más herramientas de análisis proporcionadas por la plataforma de permisos 110 a los usuarios 108.

En una realización, la plataforma de permisos 110 puede generar una política de usuario principal para cada uno de los usuarios 108 en base a la política de información, la política de organización, la política principal de cuenta de usuario o una combinación de las mismas. En una realización, la política de información, la política de organización y la política maestra de cuentas de usuario tienen una arquitectura jerárquica. Por lo tanto, los permisos definidos en cada una de estas políticas se conectan en cascada para generar una política de usuario principal que tenga uno o más permisos de control de acceso. En consecuencia, los permisos de acceso a la información definidos en la política de información pueden estar más restringidos por los permisos de licencia definidos en la política de organización, y los permisos de licencia pueden estar más restringidos por los permisos de cuenta de la política maestra de cuenta de usuario. Por lo tanto, la plataforma de permisos 110 proporciona una arquitectura de política jerárquica multicapa. Las políticas y los permisos se explican con más detalle junto con la Figura 2.

En una realización, la plataforma de permisos 110 puede definir una política de administrador principal. La política de administrador maestra puede incluir permisos maestros para controlar la política de información, la política de organización, la política maestra de cuentas de usuario o una combinación de las mismas. En una realización, los permisos maestros pueden definir las funciones y el acceso de uno más administradores de la plataforma de permisos 110. El administrador puede ser, por ejemplo, un individuo o una entidad habilitada para definir uno o más permisos para una política. Por ejemplo, la política de administrador principal puede permitir que uno o más administradores decidan los permisos sobre los conjuntos de datos sanitarios 104.

En una realización, la plataforma de permisos 110 almacena la política de información, la política de organización, la política principal de la cuenta de usuario, la política principal del usuario, la política principal del administrador y los permisos asociados en una base de datos de permisos 112. La base de datos de permisos 112 puede acoplarse comunicativamente a la plataforma de permisos 110 localmente, en una realización. En otra realización, se puede acceder a la base de datos de permisos 112 a través de la red 114. Por ejemplo, la base de datos de permisos 112 se puede distribuir a través de la red 114. En una realización, la base de datos de permisos 112 puede incluir además información como credenciales de usuario, credenciales de propietario del conjunto de datos, credenciales de organización de licenciatarios o cualquier otra información requerida por la plataforma de permisos 110 para funcionar.

Como se señaló anteriormente, la plataforma de permisos 110 permite a los usuarios 108 acceder a los conjuntos de datos sanitarios 104. A modo de ejemplo, la plataforma de permisos 110 recibe una o más consultas del usuario 108 para acceder al conjunto de datos sanitarios 104. Posteriormente, la plataforma de permisos 110 determina uno o más permisos de control de acceso para el usuario 108 en base a la política de usuario principal definida. Posteriormente, la plataforma de permisos 110 proporciona al usuario 108 acceso a los datos en base a uno o más permisos de control de acceso. En una realización, al menos una parte de los datos se hace accesible al usuario 108 en base a la política de usuario maestra. En otra realización, se impide que el usuario 108 consulte el conjunto de datos en base a los permisos de control de acceso definidos en la política de usuario principal.

En una realización, la plataforma de permisos 110 puede proporcionar una interfaz de usuario basada en web. Por ejemplo, se puede proporcionar una interfaz de usuario basada en Lenguaje de Marcado de Hipertexto (HTML) a la que se puede acceder a través de protocolos de comunicación como, entre otros, el Protocolo de Transferencia de Hipertexto (HTTP). Por lo tanto, los usuarios 108 pueden comunicarse con la plataforma de permisos 110 a través de una red informática o Internet.

La Figura 2 es un diagrama de componentes de la plataforma de permisos 110, según una realización de la presente divulgación. La plataforma de permisos 110 puede incluir varios módulos ejecutables para realizar una o más instrucciones informáticas, de procesamiento de datos o basadas en la red que, en combinación, proporcionan control de acceso multicapa para conjuntos de datos sanitarios distribuidos 104. Dichos módulos pueden implementarse en hardware, firmware, software o una combinación de los mismos. Como se muestra, la plataforma de permisos 110 puede incluir un módulo de información 202, un módulo de organización 204, un módulo maestro de cuenta de usuario 206, un módulo de acceso de usuario 208, un módulo de administrador maestro 210a y un módulo de interfaz de usuario 212 según una realización de la presente invención.

En una realización, el módulo de información 202 puede definir la política de información que incluye los permisos de acceso a la información para los conjuntos de datos sanitarios 104. En una realización, el módulo de información 202 puede recibir los permisos de acceso a la información de los propietarios de conjunto de datos 102. En otra realización, los permisos de acceso a la información pueden ser definidos por un administrador de la política de acceso a la información utilizando el módulo de información 202. Los permisos de acceso a la información pueden incluir uno o más permisos de consulta y uno o más permisos de extracción de datos. Los permisos de consulta pueden referirse a permisos para consultar los conjuntos de datos sanitarios 104. En una realización, los permisos de consulta pueden incluir, además, entre otros, un permiso para explorar metadatos del conjunto de datos sanitarios 104, un permiso para consultar datos para resultados agregados, un permiso para consultar atributos confidenciales, un permiso para establecer límites de granularidad, un permiso para establecer permisos basados en protocolos. El permiso para explorar los metadatos permite o impide que un usuario o una organización acceda a la información sobre el conjunto de datos general. Por ejemplo, los metadatos pueden hacer referencia al tipo de información contenida en el conjunto de datos sanitarios 104, como información de alto nivel sobre la población de pacientes por distribución de género, distribución de edad y similares. En una realización, los metadatos de un conjunto de datos sanitarios 104 pueden incluir solo información agregada de alto nivel, por lo tanto, se puede otorgar permiso para explorar los metadatos para todos los conjuntos de datos sanitarios 104.

El permiso para consultar datos para resultados agregados define si un usuario o una organización puede acceder a subconjuntos o cortes de conjuntos de datos sanitarios 104. Además, el permiso de consulta puede restringir al usuario a que consulte solo una proporción de los conjuntos de datos sanitarios 104. Además, la proporción de conjuntos de datos sanitarios 104 seleccionados para la consulta puede aleatorizarse para controlar aún más el acceso. En una realización, los resultados agregados pueden incluir solo información de alto nivel o subconjunto, por lo tanto, se puede otorgar permiso para consultar datos de resultados agregados para todos los conjuntos de datos sanitarios 104.

Los conjuntos de datos sanitarios 104 pueden incluir uno o más atributos y valores sensibles que pueden afectar a la privacidad de los datos. La información de los atributos sensibles puede permitir la identificación de un paciente. Por ejemplo, los atributos pueden incluir, entre otros, una identificación de paciente (ID), historial médico, atributos genéticos, una identificación de enlace, una identificación de médico, una identificación de plan, una identificación de sitio, un número de sala en un hospital, códigos geográficos, un nivel específico de acceso al código geográfico (por ejemplo, acceso a ZIP y nivel de dígitos accesibles en ZIP), y similares. Los ejemplos de valores asociados con los atributos pueden incluir, entre otros, el virus de la inmunodeficiencia humana (VIH), las enfermedades de transmisión sexual (ETS), las condiciones psicológicas, la edad menor de 18 años y similares. El acceso a atributos y valores confidenciales puede definirse mediante el permiso para consultar atributos confidenciales. Por lo tanto, un usuario puede consultar el conjunto de datos sanitarios 104 en base a los atributos y valores permitidos por los permisos. En consecuencia, se reduce el riesgo de violación de la privacidad o identificación de pacientes de los conjuntos de datos.

Por lo general, se genera un conjunto agregado de resultados en base a las consultas a los conjuntos de datos. Los resultados agregados pueden ser una amenaza para la privacidad cuando el número de resultados es muy bajo. Por ejemplo, la identificación del paciente de un total de siete resultados es más fácil que un total de 100 resultados. El permiso para establecer límites de granularidad define el límite en el número de resultados por debajo del cual los resultados de la consulta no se pueden presentar a un usuario. A modo de ejemplo, los resultados de la consulta pueden no mostrarse cuando el número de resultados está por debajo de un rango de 6 a 10 pacientes. El permiso puede denominarse “la regla de los números pequeños”.

El permiso para establecer permisos basados en protocolos permite un acceso restringido a las consultas y a los usuarios que realizan investigaciones basadas en protocolos. En general, la investigación basada en protocolos es una infraestructura común altamente restrictiva para acceder a conjuntos de datos sanitarios 104. Además, los permisos basados en protocolos pueden permitir el acceso a herramientas analíticas o informes a los usuarios que realizan la investigación basada en protocolos. En un escenario ilustrativo, el acceso a conjuntos de datos e informes puede definirse para un investigador principal de una investigación basada en protocolos mediante el establecimiento de permisos basados en protocolos. Por lo tanto, los propietarios de conjunto de datos 102 pueden tener control directo de los usuarios de los conjuntos de datos sanitarios 104.

Los permisos de extracción de datos de la política de información incluyen permisos para que los usuarios 108 extraigan datos de los conjuntos de datos sanitarios 104. En una realización, los permisos de extracción de datos pueden incluir, además, entre otros, permiso para extraer datos a nivel de paciente, permiso para extraer atributos confidenciales y un permiso para establecer permisos basados en protocolos. El permiso para extraer datos a nivel de paciente controla la cantidad y el nivel de datos de pacientes que pueden extraerse o exportarse del conjunto de datos sanitarios 104. Por ejemplo, la extracción de datos puede estar restringida por un límite general a la cantidad de extracciones realizadas, un porcentaje del conjunto de datos extraído o una cantidad de registros extraídos. En una realización, los límites de uso de claves pueden mostrarse antes de la extracción de los datos. El permiso para extraer atributos confidenciales permite o impide que un usuario o una organización extraiga los atributos confidenciales. Los permisos basados en protocolos definen el acceso a la extracción de datos de un usuario para una investigación basada en protocolos. En una realización, se pueden definir diferentes políticas de información para diferentes usuarios u organizaciones. Por lo tanto, el módulo de información 202 permite a los propietarios de conjunto de datos 102 proporcionar permisos de control de acceso detallados y granulares para el conjunto de datos sanitarios 104.

En una realización, el módulo de organización 204 puede definir la política de organización, incluidos los permisos de licencia para los conjuntos de datos sanitarios 104. En una realización, el módulo de organización 204 puede recibir los permisos de licencia del controlador de licencias 106. Como se discutió anteriormente, el controlador de licencias 106 puede ser un proveedor de servicios que proporciona suscripciones o licencias a los usuarios para acceder a los conjuntos de datos sanitarios 104. En una realización, la política de organización mantiene o restringe los permisos definidos en la política de información. La política de organización puede incluir permisos de delegación, uno o más permisos de consulta, uno o más permisos de extracción y uno o más permisos de herramientas.

En una realización, los permisos de delegación permiten la nominación de un maestro de cuenta de usuario, como un maestro de cuenta de usuario en una organización para controlar el acceso al conjunto de datos sanitarios 104. El maestro de cuentas de usuario puede ser un individuo que puede definir las cuentas de usuario para acceder a los conjuntos de datos. Los permisos de consulta de la política de organización pueden restringir aún más los permisos definidos en la política de información para consultar el conjunto de datos sanitarios 104. Por ejemplo, es posible que no se permita consultar un conjunto de datos que no tiene licencia del usuario, incluso cuando no hay restricciones definidas para el usuario en la política de información. Los permisos de consulta de la política de organización pueden habilitar además la configuración del período de acceso para el conjunto de datos sanitarios 104 en base a la suscripción o licencia. Por ejemplo, la licencia se puede configurar para que termine automáticamente según la política de organización. Además, los permisos de consulta de la política de organización pueden definir períodos de actualización del conjunto de datos sanitarios 104 con licencia de la organización. Por ejemplo, el período de actualización puede configurarse semanal o mensualmente según los términos y condiciones de la licencia o la suscripción.

Los permisos de extracción de la política de organización pueden restringir aún más los permisos definidos en la política de información para extraer información del conjunto de datos sanitarios 104. En una realización, los permisos de extracción de la política de organización pueden definir los límites de extracción de una serie de resultados para una organización. A modo de ejemplo, la política de información puede definir un conjunto de datos al que puede acceder la organización, y luego la política de organización restringe aún más la extracción de solo los primeros mil resultados. Por lo tanto, la capacidad de la red y el ancho de banda dentro de la organización pueden estar controlados por los permisos. El controlador de licencias 106 puede proporcionar a la organización acceso a herramientas asociadas con el análisis del conjunto de datos sanitarios 104. Los permisos de herramientas de la política de organización definen el acceso a una o más herramientas y la cantidad de usuarios para las herramientas. Además, los permisos de las herramientas pueden definir los límites de uso de las herramientas en la organización.

En una realización, el módulo maestro de cuenta de usuario 206 puede definir la política maestra de cuenta de usuario que incluye los permisos de cuenta para los conjuntos de datos sanitarios 104. En una realización, el módulo maestro de cuenta de usuario 206 puede recibir los permisos de cuenta de un maestro de cuenta de usuario de la organización. Como se discutió anteriormente, el maestro de cuentas de usuario puede ser un administrador de cuentas de usuario en la organización. En una realización, la política maestra de cuentas de usuario mantiene o restringe los permisos definidos en la política de organización. En una realización, la política maestra de cuentas de usuario distribuye los permisos definidos en la política de organización a los usuarios de la organización. En un escenario ilustrativo, la política maestra de cuenta de usuario puede habilitar permisos de cuenta para un máximo de cinco usuarios en una organización si la licencia o suscripción se toma para cinco licencias. En una realización, el módulo maestro de cuenta de usuario 206 puede generar y mostrar un error si otros usuarios además del número con licencia intentan acceder al conjunto de datos sanitarios 104. En una realización, los permisos de la cuenta pueden definir diferentes niveles de acceso para diferentes usuarios en la organización.

En una realización, el módulo de acceso de usuario 208 puede generar una política de usuario maestra para cada uno de los usuarios 108 en base a la política de información, la política de organización, la política maestra de cuenta de usuario o una combinación de las mismas. La política de usuario maestra puede incluir permisos de control de acceso para proporcionar a cada uno de los usuarios 108 acceso a los conjuntos de datos sanitarios 104 distribuidos. En una realización, los permisos de control de acceso de la política de usuario maestra pueden heredar los permisos definidos en la política de información, la política de organización y la política maestra de cuenta de usuario. Como se indicó anteriormente, la política maestra de cuentas de usuario hereda los permisos de la política de organización, que a su vez hereda los permisos definidos en la política de información. Por lo tanto, los permisos de control de acceso brindan seguridad mejorada y control de privacidad total del conjunto de datos sanitarios 104. En una realización, el módulo de administrador principal 210 puede definir una política de administrador principal. La política de administrador maestra puede incluir los permisos maestros para controlar la política de información, la política de organización, la política maestra de cuentas de usuario o una combinación de las mismas. En una realización, los permisos maestros pueden incluir permisos para delegar funciones de administrador a una o más personas. Por ejemplo, un administrador delegado para la política de organización puede establecer o administrar los permisos definidos en la política de organización. En una realización, la política del administrador principal puede ser la misma para todos los conjuntos de datos sanitarios 104 distribuidos geográficamente. Como se indicó anteriormente, la política de información, la política de organización, la política principal de la cuenta de usuario, la política principal del usuario o la política principal del administrador, o una combinación de las mismas, se almacenan en la base de datos de permisos 112.

En una realización, el módulo de interfaz de usuario 212 puede recibir una o más consultas del usuario 108 y proporcionar datos del conjunto de datos sanitarios 104, según una realización. El módulo de interfaz de usuario 212 puede verificar la política de usuario principal asociada con el usuario 108 desde el módulo de acceso de usuario 208. Posteriormente, los resultados de las consultas se presentan a los usuarios 108. En una realización, el módulo de interfaz de usuario 212 puede proporcionar una interfaz gráfica de usuario (GUI) basada en web. Por ejemplo, se puede proporcionar una interfaz de usuario basada en Lenguaje de Marcado de Hipertexto (HTML) a la que se puede acceder a través de protocolos de comunicación como, entre otros, el Protocolo de Transferencia de Hipertexto (HTTP). En una realización, la interfaz de usuario proporcionada por el módulo de interfaz de usuario 212 puede ser utilizada para establecer los permisos y las políticas por parte de los propietarios de conjunto de datos 102, los controladores de licencias, los maestros de cuentas de usuario u otros administradores de la plataforma de permisos 110.

La Figura 3 ilustra un diagrama de flujo de un proceso 300 para proporcionar control de acceso multicapa para conjuntos de datos sanitarios distribuidos, según una realización de la presente divulgación. El proceso 300 comienza en el paso 302, en el que se define una política de información para el conjunto de datos sanitarios 104. Además, la política de información puede incluir uno o más permisos de acceso a la información. En una realización, los permisos de acceso a la información para la política de información pueden ser recibidos por el propietario del conjunto de datos 102 asociado con los conjuntos de datos sanitarios 104 distribuidos. Como se señaló anteriormente, el propietario del conjunto de datos 102 puede proporcionar los permisos de acceso a la información mediante el uso de la plataforma de permisos 110.

A continuación, el control del proceso 300 continúa con el paso 304, en el que se define una política de organización para cada uno de los conjuntos de datos sanitarios 104 distribuidos. Además, la política de organización puede incluir uno o más permisos de licencia. En una realización, la política de organización se puede recibir del controlador de licencias 106 o de un proveedor de servicios de terceros que administra suscripciones o licencias para conjuntos de datos sanitarios 104. El proveedor de servicios de terceros puede definir políticas de organización para que las organizaciones restrinjan a los usuarios el acceso a datos sanitarios confidenciales almacenados en el conjunto de datos sanitarios 104 distribuidos. Como se señaló anteriormente, la política de organización restringe aún más los permisos definidos en la política de información.

Posteriormente, el control del proceso 300 continúa con el paso 306, en el que se define una política maestra de cuenta de usuario para cada uno de los conjuntos de datos sanitarios 104 distribuidos. La política maestra de cuenta de usuario puede incluir uno o más permisos de cuenta que se asignan a uno o más usuarios de una o más organizaciones. Como se indicó anteriormente, los permisos de la política maestra de cuenta de usuario pueden ser proporcionados por un maestro de cuenta de usuario de la organización. Además, la política maestra de cuentas de usuario restringe aún más los permisos definidos en la política de organización.

A continuación, el control del proceso 300 pasa al paso 308, en el que se genera una política de usuario maestra para cada usuario en base a la política de información definida, la política de organización, la política maestra de cuenta de usuario o una combinación de las mismas. La política de usuario principal incluye uno o más permisos de control de acceso para proporcionar a cada uno de los uno o más usuarios acceso a uno o más conjuntos de datos sanitarios 104 distribuidos. En una realización, se define una política de administrador principal que incluye uno o más permisos maestros para el control de al menos una de las políticas de información, la política de organización o una combinación de las mismas.

La Figura 4 ilustra un diagrama de flujo de un proceso 400 para proporcionar control de acceso multicapa para conjuntos de datos sanitarios distribuidos, según otra realización de la presente descripción. El control del proceso 400 avanza al paso 402, en el que se recibe una consulta del usuario. En una realización, la consulta puede recibirse en la plataforma de permisos 110 a través de la red 114 para acceder a los conjuntos de datos sanitarios 104 distribuidos. La consulta puede ser una consulta basada en web o una consulta local en formatos de consulta como, entre otros, un Lenguaje de Consulta Estructurado (SQL).

El control del proceso 400 pasa al paso 404, en el que se comprueban los permisos de control de acceso para el usuario. En una realización, los permisos de control de acceso pueden verificarse en base a la política de usuario maestra. Como se discutió anteriormente, la política de usuario maestra puede generarse en base a la política de información, la política de organización, la política maestra de cuenta de usuario o una combinación de las mismas. Si al usuario se le permite hacer una consulta, el proceso 400 continúa con el paso 406, en el que se determina si el usuario puede consultar el conjunto de datos sanitarios 104 distribuidos y, si se permite, la consulta se ejecutará en el conjunto de datos sanitarios 104 distribuidos. De lo contrario, el usuario no puede consultar el conjunto de datos sanitarios 104 distribuidos, y el proceso 400 avanza al paso 408. En una realización, la consulta puede ejecutarse solo en una parte del conjunto de datos sanitarios 104, en base a la política de usuario principal.

En el paso 408, se bloquea al usuario para que no consulte el conjunto de datos sanitarios 104 distribuidos en base a uno o más permisos de control de acceso, y finaliza el proceso 400.

En el paso 410, se determinan uno o más permisos de control de acceso para el usuario en base a la política de usuario maestra. Como se señaló anteriormente, los permisos de control de acceso pueden incluir permisos para el nivel de acceso a los datos, uno o más países desde los cuales se puede acceder a los datos, un período de tiempo en el que se puede acceder a los datos, la cantidad de datos (por ejemplo, por "regla de números pequeños”), y similares. A continuación, el control del proceso 400 pasa al paso 412, en el que se proporciona al usuario acceso al conjunto de datos sanitarios 104. En una realización, los datos resultantes de la consulta no se proporcionan al usuario en base a los permisos de control de acceso. En un escenario ilustrativo, si la "regla de los números pequeños" para los resultados se establece en tres y el número de resultados obtenidos de la consulta es tres o menos, es posible que los resultados o los datos no se muestren al usuario.

La Figura 5 representa un escenario ilustrativo para proporcionar control de acceso multicapa para conjuntos de datos sanitarios distribuidos, de acuerdo con una realización de la presente divulgación. Como se muestra, los propietarios de conjunto de datos 102a-c pueden estar ubicados en tres países diferentes (por ejemplo, Canadá, Gran Bretaña y Suecia). Además, los datos asociados con los propietarios de conjunto de datos 102a-c se almacenan en conjuntos de datos distribuidos, como un conjunto de datos sanitarios 104a-c.

El conjunto de datos sanitarios 104a-c puede ser, por ejemplo, registros médicos electrónicos, una base de datos de reclamos médicos, una base de datos de farmacología o similar. Los propietarios de conjunto de datos 102a-c otorgan permisos a la plataforma de permisos 110 que definen además las políticas de información para los usuarios 108a-c ubicados en diferentes ubicaciones geográficas. De forma similar, los controladores de licencias 106a-c proporcionan permisos a la plataforma de permisos 110 para definir políticas de organización, y los maestros de cuentas de usuario 502a-c proporcionan permisos a la plataforma de permisos 110 para definir políticas maestras de cuentas de usuario que permiten a los usuarios 108a-c acceder a datos desde los conjuntos de datos sanitarios 104a-c distribuidos. Además, la plataforma de permisos 110 genera una política de usuario maestra utilizando las políticas de información, las políticas de organización, las políticas maestras de cuenta de usuario o una combinación de las mismas. Como se muestra, los conjuntos de datos sanitarios 104a-c están distribuidos geográficamente y se pueden conectar a nodos de red separados Nodo 1, Nodo 2 y Nodo 3. Cada uno de los nodos Nodo 1, Nodo 2 y Nodo 3 puede entonces conectarse a un concentrador 504. En una realización, los Nodos 1-3 pueden ser servidores de datos que conectan el conjunto de datos sanitarios 104a-c al concentrador 504. Además, el concentrador 504 puede ser un centro de datos que comprenda la información del conjunto de datos sanitarios 104a-c. En una realización, el concentrador 504 puede proporcionar una interfaz de usuario basada en web para definir los permisos y acceder a los datos de los conjuntos de datos sanitarios 104.

Los usuarios 108a-c transmiten consultas a la plataforma de permisos 110 para acceder a los datos de los conjuntos de datos sanitarios 104a-c. Posteriormente, la plataforma de permisos 110 determina las políticas maestras de usuario para los usuarios 108a-c a partir de la base de datos de permisos 112. La política de usuario principal determinada se proporciona al concentrador 504 desde donde los usuarios 108a-c pueden acceder a los datos de los conjuntos de datos sanitarios 104a.

La Figura 6 es una tabla ilustrativa 600 que ilustra la cascada de permisos de políticas multicapa, de acuerdo con una realización de la presente divulgación. Como se indicó anteriormente, la política de información, la política de organización, la política maestra de cuentas de usuario y la política maestra de administrador tienen una arquitectura jerárquica. En una realización, la política de administrador principal definida por el módulo de administrador principal 210 está en el nivel más alto de jerarquía, seguida por la política de información definida por el módulo de información 202, la política de organización definida por el módulo de organización 204 y la política maestra de cuenta de usuario definida por el módulo maestro de cuentas de usuario 206 en ese orden. Por lo tanto, los permisos de la política de información están más restringidos por los permisos de la política de organización, que a su vez están más restringidos por los permisos de la política maestra de cuentas de usuario.

Como se muestra y también como se discutió anteriormente, los permisos de delegación para la política de administrador maestra, la política de organización y la política de información están definidas y controladas por el módulo de administrador maestro 210. Los permisos de delegación para la política maestra de cuenta de usuario pueden ser definidos por el módulo de organización 204. Además, cada uno de los módulos de información 202, el módulo de organización 204 y el módulo maestro de cuentas de usuario 206 pueden definir los permisos de consulta para explorar metadatos, consultar datos para resultados agregados, consultar atributos y/o valores confidenciales y establecer límites de granularidad. El módulo de información 202 puede definir además permisos para establecer permisos basados en protocolos. Además, cada uno del módulo de información 202, el módulo de organización 204 y el módulo maestro de cuentas de usuario 206 puede definir los permisos de extracción para extraer datos a nivel de paciente y extraer atributos y/o valores sensibles. El módulo de información 202 puede definir además permisos de extracción para establecer permisos basados en protocolos.

El módulo de organización 204 y el módulo maestro de cuentas de usuario 206 pueden definir además los permisos para establecer el acceso a las herramientas analíticas y establecer los niveles de acceso permitidos en las herramientas. Por ejemplo, se pueden definir permisos tanto para acceder a las herramientas como el nivel de acceso permitido.

La Figura 7 representa un diagrama de bloques ilustrativo del flujo de información en la plataforma de permisos 110, según una realización de la presente divulgación. El usuario 108 puede usar un navegador web para solicitar permiso para ver la cohorte 702 desde un sitio web alojado en Internet o en una red local/en el sitio, como la red de comunicación 114. La palabra “cohorte” se usa en epidemiología para definir un conjunto de personas que son objeto de seguimiento durante un período de tiempo. En particular, “cohorte” se refiere a un grupo de personas con características definidas que son objeto de seguimiento para determinar la incidencia o la mortalidad por alguna enfermedad específica, todas las causas de muerte o algún otro resultado. En un escenario ilustrativo, el usuario puede proporcionar los permisos para acceder a los conjuntos de datos sanitarios 104. En este caso, el usuario puede ser el propietario de un conjunto de datos, un controlador de licencias, un maestro de cuenta de usuario o cualquier otro administrador autorizado para establecer los permisos para el acceso y control de datos.

En una realización, la vista de la cohorte 702 puede ser mediante el uso de una interfaz de usuario de lenguaje de marcado de hipertexto (HTML) que se comunica con una interfaz de programa de aplicación web (API) 704. Posteriormente, se puede ejecutar una función o servicio de cohorte de la API web 704. La función o servicio de cohorte puede ejecutar además servicios, como un servicio de usuario para obtener y/o establecer los permisos de cuenta definidos por las políticas maestras de cuenta de usuario 706a, un servicio de organización para obtener y/o establecer los permisos de licencia para las políticas de organización 706b y servicio de conjunto de datos para obtener y/o establecer los permisos de información para las políticas de información 706c. Posteriormente, las políticas 706a-c pueden recibirse o enviarse a la base de datos de permisos 112.

La base de datos de permisos 112 puede usar una base de datos de aplicaciones para generar una política de usuario principal que se proporciona al servicio de cohorte 710 a través de un procesador de permisos 708. En una realización, el procesador de permisos 708 proporciona una única política de usuario maestra completa en un formato de notación de objetos de JavaScript (JSON). El servicio de cohorte 710 puede entonces usar la política de usuario principal para brindar acceso al conjunto de datos sanitarios 104. Por ejemplo, cuando se ejecuta una consulta de conteo de deserción de cohorte, la política de usuario principal se aplica antes de proporcionar los resultados. Como se muestra, los atributos del paciente y los eventos del paciente se consultan desde el conjunto de datos sanitarios 104 para presentar datos de transacciones sanitarias. Por lo tanto, al usuario que consulta el conjunto de datos sanitarios 104 se le pueden presentar los resultados en forma de datos de transacciones sanitarias después de aplicar los permisos definidos en la política de usuario principal.

La Figura 8 ilustra un sistema informático (por ejemplo, un cliente) 800 en el que se pueden implementar realizaciones ilustrativas para proporcionar control de acceso multicapa para conjuntos de datos sanitarios distribuidos. En una realización, el sistema informático 800 puede ser la plataforma de permisos 110 que realiza varias funciones para definir y/o generar políticas, como una política de información, una política de organización, una política maestra de cuenta de usuario y similares. El sistema informático 800 incluye un bus 802 para comunicar información y un procesador 804 acoplado al bus 802 para procesar información. El sistema informático 800 también incluye una memoria 806 conectada al bus 802 para almacenar la información y las instrucciones que ejecutará el procesador 804. Los ejemplos de la memoria 806 pueden incluir una memoria de acceso aleatorio (RAM), una memoria de solo lectura (ROM) u otro almacenamiento estático o dinámico para almacenar información e instrucciones para el procesador 804. Además, el sistema informático 800 puede incluir un dispositivo de almacenamiento 808, como un disco magnético, un disco de estado sólido o un disco óptico, acoplado al bus 802 para almacenar información.

El sistema informático 800 puede acoplarse a través del bus 802 a una pantalla 810, como un tubo de rayos catódicos (CRT), una pantalla de cristal líquido, una pantalla plana de diodo emisor de luz (LED), etc. En una realización, el sistema informático 800 incluye un dispositivo de entrada/salida 812, como un teclado, un ratón u otro dispositivo señalador para proporcionar entradas o instrucciones.

El sistema informático 800 también puede incluir una interfaz de comunicación 814 acoplada al bus 802. La interfaz de comunicación 814 proporciona la conexión de un ordenador remoto 818 a través de una red 816, como la red de comunicación 114. Los ejemplos de la interfaz de comunicación 814 pueden incluir un adaptador Ethernet, un transceptor Wi-Fi que utiliza un protocolo IEEE 802.11, etc. Los ejemplos de la red 816 pueden incluir, Red de Área Local (LAN), Red de Área Amplia (WAN), u otras redes por cable o inalámbricas. En una realización, la red 816 puede ser una red en la nube que es una colección de hardware y software que forman un conjunto compartido de recursos informáticos (por ejemplo, redes, servidores, almacenamiento, aplicaciones, servicios, etc.) que se pueden aprovisionar adecuadamente para proporcionar autoservicio bajo demanda, acceso a la red, agrupación de recursos y similares.

Los métodos divulgados pueden implementarse fácilmente en software, como mediante el uso de entornos de desarrollo de software orientados a objetos o de objetos que proporcionan un código fuente portátil que puede usarse en una variedad de plataformas de ordenadores o estaciones de trabajo. Alternativamente, el sistema divulgado puede implementarse parcial o totalmente en hardware, como mediante el uso de circuitos lógicos estándar o diseño VLSI. El hecho de que se pueda usar software o hardware para implementar los sistemas de acuerdo con varias realizaciones de la presente invención puede depender de varias consideraciones, como los requisitos de velocidad o eficiencia del sistema, la función particular y los sistemas de software o hardware particulares que se están utilizando.

Aunque lo anterior se dirige a las realizaciones de la presente invención, otras realizaciones adicionales de la presente invención se pueden concebir sin apartarse del alcance básico de estas. Se entiende que varias realizaciones descritas en la presente memoria se pueden utilizar en combinación con cualquier otra realización descrita, sin apartarse del alcance contenido en la presente memoria. Además, la descripción anterior no pretende ser exhaustiva o limitar las realizaciones de la invención a la forma precisa divulgada. Son posibles modificaciones y variaciones a la luz de las enseñanzas anteriores o pueden adquirirse de la práctica de las realizaciones de la invención. Ciertas realizaciones ilustrativas pueden identificarse mediante el uso de una lista abierta que incluye expresiones para indicar que los elementos de la lista son representativos de las realizaciones y que la lista no pretende representar una lista cerrada exclusiva de realizaciones adicionales. Dichas expresiones pueden incluir "por ejemplo", "etc.", "tal como", "por ejemplo", "y así sucesivamente", "y similares", etc., y otras expresiones que se desprenderán del contexto circundante.

Ningún elemento, acto o instrucción utilizado en la descripción de la presente solicitud debe interpretarse como crítico o esencial para las realizaciones de la invención a menos que se describa explícitamente como tal. Además, como se usa en la presente memoria, el artículo "un/una" pretende incluir uno o más elementos. Cuando solo se pretende un elemento, se utiliza el término "un/una" o un lenguaje similar. Además, los términos "cualquiera de" seguidos de una lista de una pluralidad de artículos y/o una pluralidad de categorías de artículos, tal como se utilizan en este documento, pretenden incluir "cualquiera de", "cualquier combinación de", "cualquier múltiplo de," y/o "cualquier combinación de múltiplos de" los artículos y/o las categorías de artículos, individualmente o en conjunto con otros artículos y/u otras categorías de artículos.

Claims

REIVINDICACIONES

1. Un método implementado por ordenador para otorgar permisos a usuarios de diferentes organizaciones para acceder a la información de salud depositada en una pluralidad de conjuntos de datos sanitarios (104a-104p) que tienen diferentes propietarios que controlan el acceso a los conjuntos de datos que poseen, el método comprende los pasos de:

definir (302) una política de información para cada uno de los conjuntos de datos sanitarios, en donde la política de información comprende permisos de acceso a la información establecidos por los propietarios de cada uno de los conjuntos de datos;

definir (304) una política de organización para cada uno de los conjuntos de datos sanitarios, en donde la política de organización comprende permisos de licencia para las diferentes organizaciones que acceden a los conjuntos de datos sanitarios;

definir (306) una política maestra de cuenta de usuario para cada uno de los conjuntos de datos sanitarios, en donde la política maestra de cuenta de usuario comprende permisos de cuenta asignados selectivamente a usuarios de las diferentes organizaciones; y

generar (308) una política de usuario maestra para cada uno de los usuarios basada en la política de información, la política de organización y la política maestra de la cuenta de usuario, en donde la política de usuario maestra comprende permisos de control de acceso para proporcionar acceso a cada uno de los usuarios de las diferentes organizaciones a los conjuntos de datos sanitarios.

2. El método de la reivindicación 1, que comprende, además:

definir una política de administrador principal, en donde la política de administrador principal comprende uno o más permisos principales para controlar al menos una de las políticas de información, la política de organización o una combinación de las mismas.

3. El método de la reivindicación 1 o 2, que comprende, además:

Recibir (402), de un usuario, una consulta para acceder a datos en al menos un conjunto de datos de los conjuntos de datos sanitarios;

Determinar (404) permisos de control de acceso para el usuario en base a la política de usuario maestra; y

Proporcionar (412), al usuario, acceso a los datos en base a los permisos de control de acceso, en donde al menos una parte de los datos es accesible para el usuario.

4. El método de la reivindicación 3, que comprende, además:

Bloquear (408) que el usuario consulte al menos un conjunto de datos en base a los permisos de control de acceso determinados.

5. El método de cualquier reivindicación anterior, en donde los permisos de acceso a la información comprenden al menos uno de un permiso para explorar metadatos, un permiso para consultar datos para resultados agregados, un permiso para consultar atributos sensibles, un permiso para establecer límites de granularidad, un permiso para establecer permisos basados en protocolos, un permiso para extraer datos a nivel de paciente, un permiso para extraer atributos confidenciales o una combinación de los mismos.

6. El método de cualquier reivindicación anterior, en donde los permisos de licencia comprenden al menos uno de un permiso para establecer una cuenta maestra de usuario, un permiso para establecer restricciones de acceso, un permiso para establecer un período de acceso, un permiso para definir períodos de actualización, un permiso para definir límites de usuario, un permiso para definir herramientas de acceso, o una combinación de los mismos.

7. El método de cualquier reivindicación anterior, en donde los permisos de licencia de la política de organización están restringidos por los permisos de información de la política de información, y los permisos de cuenta de la política maestra de cuentas de usuario están restringidos por los permisos de información y los permisos de licencia.

8. Un sistema (110) implementado por ordenador para otorgar permisos a usuarios de diferentes organizaciones para acceder a información de salud depositada en una pluralidad de conjuntos de datos sanitarios que tienen diferentes propietarios que controlan el acceso a los conjuntos de datos que poseen, que comprende:

un módulo de información configurado para definir (302) una política de información para cada uno de los conjuntos de datos sanitarios, en donde la política de información comprende permisos de acceso a la información establecidos por los propietarios de cada uno de los conjuntos de datos;

un módulo de organización configurado para definir (304) una política de organización para cada uno de los conjuntos de datos sanitarios, en donde la política de organización comprende permisos de licencia para las diferentes organizaciones que acceden a los conjuntos de datos sanitarios;

un módulo maestro de cuenta de usuario configurado para definir (306) una política maestra de cuenta de usuario para cada uno de los conjuntos de datos sanitarios, en donde la política maestra de cuenta de usuario comprende permisos de cuenta asignados a usuarios de las diferentes organizaciones; y

un módulo de acceso de usuario configurado para generar (308) una política de usuario maestra para cada uno de los usuarios en base a la política de información, la política de organización y la política maestra de cuenta de usuario, en donde la política de usuario maestra comprende permisos de control de acceso para proporcionar acceso a cada uno de los usuarios de las diferentes organizaciones a los conjuntos de datos sanitarios.

9. El sistema de la reivindicación 8, en donde el módulo de acceso de usuario está configurado además para definir una política de administrador principal, en donde la política de administrador principal comprende uno o más permisos principales para controlar al menos una de las políticas de información, la política de organización o una combinación de las mismas.

10. El sistema de la reivindicación 8 o 9, que comprende además un módulo de control de acceso configurado para:

recibir, de un usuario, una consulta para acceder a datos en al menos un conjunto de datos de los conjuntos de datos sanitarios;

determinar los permisos de control de acceso para el usuario en base a la política de usuario maestra; y

proporcionar, al usuario, acceso a los datos en base a los permisos de control de acceso, en donde al menos una parte de los datos se proporciona al usuario.

11. El sistema de la reivindicación 10, en donde el módulo de control de acceso está configurado además para impedir que el usuario consulte al menos un conjunto de datos en base a los permisos de control de acceso determinados.

12. El sistema de cualquiera de las reivindicaciones 8 a 11, en donde los permisos de acceso a la información comprenden al menos uno de un permiso para explorar metadatos, un permiso para consultar datos para resultados agregados, un permiso para consultar atributos sensibles, un permiso para establecer límites de granularidad, un permiso para establecer permisos basados en protocolos, un permiso para extraer datos a nivel de paciente, un permiso para extraer atributos confidenciales o una combinación de los mismos.

13. El sistema de cualquiera de las reivindicaciones 8 a 12, en donde los permisos de licencia comprenden al menos uno de un permiso para establecer una cuenta maestra de usuario, un permiso para establecer restricciones de acceso, un permiso para establecer un período de acceso, un permiso para definir períodos de actualización, un permiso para definir límites de usuarios, un permiso para definir herramientas de acceso o una combinación de los mismos.

14. El sistema de cualquiera de las reivindicaciones 8 a 13, en donde la política de administrador principal, la política de información, la política de organización y la política principal de cuenta de usuario tienen una arquitectura jerárquica.

15. El sistema de cualquiera de las reivindicaciones 8 a 14, en donde los permisos de licencia de la política de organización están restringidos por los permisos de información de la política de información, y los permisos de cuenta de la política maestra de cuenta de usuario están restringidos por uno o más permisos de información y el permisos de licencia.