WO2022112624A1 - Sistema y método de gestión para una arquitectura de base de datos multimodelo distribuida - Google Patents

Sistema y método de gestión para una arquitectura de base de datos multimodelo distribuida Download PDF

Info

Publication number
WO2022112624A1
WO2022112624A1 PCT/ES2021/070271 ES2021070271W WO2022112624A1 WO 2022112624 A1 WO2022112624 A1 WO 2022112624A1 ES 2021070271 W ES2021070271 W ES 2021070271W WO 2022112624 A1 WO2022112624 A1 WO 2022112624A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
data
microservice
database
profile
Prior art date
Application number
PCT/ES2021/070271
Other languages
English (en)
French (fr)
Inventor
Hugo HERRERO ANTÓN DE VEZ
Ferran GARCÍA CASADO
Original Assignee
Alma It Systems, S.L.
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 Alma It Systems, S.L. filed Critical Alma It Systems, S.L.
Priority to CN202180079847.1A priority Critical patent/CN116917881A/zh
Priority to EP21724345.0A priority patent/EP4254219A1/en
Priority to US18/253,715 priority patent/US20230418839A1/en
Publication of WO2022112624A1 publication Critical patent/WO2022112624A1/es

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273—Asynchronous replication or reconciliation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases

Definitions

  • the present invention relates to a distributed multi-model database architecture, where the database architecture comprises a plurality of user microservices configured to create, store and manage graph databases with sensitive data from conventional databases. existing services, a management system for distributed multi-model database architecture, where the management system comprises a user interface, a plurality of profile microservices, a key-value database and middleware, and a method for manage a distributed multi-model database architecture.
  • the records are usually scattered in different storages belonging to various hospitals, sometimes belonging to different jurisdictions. Even in the same hospital, different types of data are stored on different servers that are designed under different medical standards and thus each of these servers has its own data architecture and communication protocols (DICOM, LOINC, RxNORM, SNOMED CT, etc. ); In addition, each of these systems is developed and maintained by different providers, which gives more variability and complexity to data integration. This fragmentation of data is often a serious obstacle to collecting, updating, or researching these records, whether they are considered as a single patient or as a group. These data integrations, or data joins, typically occur at the application level, making data management complex. inefficient and very expensive, due to the need to configure caches, intermediate data lakes and scale databases and processing servers to perform data aggregations and translations.
  • BDs databases
  • RDBs relational databases
  • These relational databases become especially complex and rigid when it comes to expressing relationships between data elements, especially in the case of complex relationships, for example, when it is necessary to obtain information from two or more related database tables ( multi-level joins); on the other hand, these multilevel joins are difficult to scale horizontally. Joins can efficiently compute statistics from existing database tables, but multilevel joining is also too complex for large data sets.
  • DGPs database graphs
  • BDGs can handle the real complexity of data dependencies.
  • ML machine learning algorithms work much better with vectorized implementations, such as those for graph databases, and that implementation makes it much easier to use libraries to process data in parallel; since BDGs are normally represented using an affinity matrix, they share the same structure with vectorized machine learning applications.
  • functions in a graph can be represented as a vector, which brings another advantage: graph analysis algorithms can be implemented directly in graph databases, allowing ML and graph analysis techniques to be executed in the same environment, making it possible to close cooperation with each other, for example by feeding the ML algorithms with graphical metrics computed as predictor variables; therefore, the same can be used environment to carry out analysis and efficiency of information and even compartmentalized searches, maintaining the privacy of patient information.
  • BDRs are optimized for data aggregation
  • other nonrelational databases focus on the volume and properties of the data; for example, BDGs are optimized for data connections:
  • BDGs are designed to handle a high level of data complexity, in part because the structure of the data is not fixed in advance. But these are not all benefits: BDGs are also more expensive, and there are fewer tools available to perform complex operations in a production or service environment.
  • the invention provides a management system for a distributed multi-model database architecture, the distributed multi-model database architecture comprising a plurality of user microservices, each connected to a database of a plurality of pre-existing relational databases stored on respective servers, where each user microservice is associated with a user, each user microservice is configured to create, store and manage a database of graphs, comprising nodes and edges, with related data with the associated user of the pre-existing database connected to the user microservice, each user microservice comprises an encrypted file that can be decrypted by the user microservice and that contains instructions to create and store the user database with related data with the associated user, each microservice of user is stored in the preexisting database server connected to the user microservice, and the user database is configured to be accessed only through the user microservice; wherein the management system is stored on a cloud server and wherein the management system comprises: a user interface, a plurality of profile microservices, where each profile microservice is associated with a single distinct user, in where each
  • the management system provides centralized access to data stored in a plurality of distributed independent multi-model pre-existing databases, with a high degree of security and without loss of property by the legitimate owner of the data; the database architecture provides, for each legacy database, or node, a plurality of user microservices tasked with creating a user-specific data base (BDG) exclusively with user-related data from of the existing database, and the management of access and communication with the management system.
  • BDG user-specific data base
  • Gratos database data is stored on the legacy database server and encrypted.
  • the management system is only authorized to access user microservices, and receives encrypted data, even without gaining access to the rest of the data in the pre-existing database; therefore a high level of security is achieved.
  • Each profile microservice is associated with a single user, who preferentially maintains ownership of, or is duly authorized to access, certain data in pre-existing databases.
  • the user would access the individual databases and manually extract the relevant information, if the entity hosting the databases allows it.
  • the present invention overcomes such difficulties and provides a centralized database management system with a single authentication process through a user interface, a key-value database with an index with the locations of each of the data user interface, and middleware that manages the communication between the management system and the distributed database architecture.
  • Profile microservices provide end-to-end management of permissions, data requests, and communications with the database architecture.
  • the management system is hosted by a cloud server; per server in the cloud should be understood as a computer or computer system comprising a processor, storage media and Internet access, and configured to host and run the database management system.
  • microservice should be understood as each of the software applications or elements of a microservice structure, as is known in the art.
  • all microservices are related to users; for example, there may be only a single profile microservice for each user, while there may be more than one user microservice per user; in particular, for each user there is one user microservice per node.
  • the names profile and user should be understood as simple denominations of convenience for a first class of microservices and a second class of microservices.
  • the profile microservice will always have a higher hierarchy than the user microservice, and will have the authority to read the encrypted files generated by the user microservices.
  • a graph database should be understood as either a non-relational database or a pure graph database, comprising nodes and vectors, and storing user-related data;
  • the nodes of a BDG must be understood as vertices of the graph, or discrete data elements linked by means of vectors or edges to other vertices, and are different from the nodes that refer to these pre-existing databases.
  • the key-value database should be understood as a hash function table comprising at least one index of the location of each data record stored in the graph databases related to each unique user, as well as other relevant data. .
  • Middleware is an element configured to enable and manage communication and data transfer between the database architecture, in particular the user microservices, and the management system.
  • the present invention is of particular interest for the management of patient records in a health system with a plurality of loosely related or independent databases belonging to autonomous or independent health institutions.
  • a patient, the rightful owner of relevant data such as patient records, medical history, etc.
  • the user interface is a web-based user interface.
  • a web-based interface ensures that any user can access information from anywhere in the world, providing the user has the required permissions.
  • the key-value database is configured as a distributed ledger. More particularly, the Clavel Valor database is configured as a distributed ledger (distributed iedger) of blockchains, so that any attempt to manipulate the information stored by a malicious user can be reported and tracked by a user. authorized.
  • distributed ledger distributed iedger
  • the key-value database comprises key-value pairs encrypted with a public key encryption algorithm.
  • the key-value database is encrypted using an asymmetric cryptography system, which includes at least one public key and one private key.
  • the key-value database comprises a key-value database manager.
  • system further comprises a low-availability backup database controlled by the middleware.
  • the middleware is partially stored on a legacy database server.
  • part of the middleware is distributed across the nodes of the existing database servers, and is stored in the corresponding database servers, with a higher degree of integration.
  • the middleware is configured as a peer-to-peer network.
  • the middleware is configured to perform synchronous masterless replication between nodes of the grate databases.
  • the middleware is configured to perform multicast queries according to a round-robin schedule.
  • at least one profile microservice comprises an intermediate database configured to store data from the grate databases, location data with a hash function of the user microservices, and/or decryption keys.
  • Intermediate databases are small-volume, user-specific databases for storage of various data, such as microservice locations and encryption/decryption keys; these intermediate databases function as local stores of information and allow faster access to a user's query.
  • the invention provides a computer system comprising a cloud server configured to store and execute the management system according to the first inventive aspect.
  • the computer system comprises at least one cloud server with an Internet connection, and optionally additional computers and/or similar devices such as portable devices, tablets, smartphones, and the like.
  • the invention provides a distributed multi-model database architecture, comprising a plurality of user microservices, each connected to a database of a plurality of pre-existing relational databases stored on respective servers, in where each user microservice is associated with a user, each user microservice is configured to create, store and manage a database of graphs, comprising nodes and edges, with data related to the associated user from the connected pre-existing database
  • each user microservice comprises an encrypted file that can be decrypted by the user microservice and that contains instructions to create and store the grates database with data related to the associated user
  • each user microservice is stored in the server of the existing database connected to the m user microservice, the gratos database is configured to be accessed only through the user microservice.
  • the user microservices make use of respective encrypted files to create or build the graph database; such encrypted file comprises the specific instructions for the task and is encrypted to avoid security threats. Therefore, the distributed multi-model database architecture advantageously provides a substitute database with a normalized model, regardless of the type of databases. pre-existing
  • the encrypted file is encrypted with a public key encryption algorithm.
  • Public key encryption algorithms advantageously provide a highly secure asymmetric encryption system that can withstand most attack attempts without requiring high processing load or processing times.
  • the encrypted file comprises one or more of the following: user data, hash functions, metadata, encryption keys.
  • the encrypted file advantageously stores the instructions to create, or build, the gratos database, and other useful data that ensures access to the gratos database and the security of the information; furthermore, the encrypted file can directly store certain data, instead of simply pointing to a different address.
  • the encrypted file is encrypted as a JSON file.
  • the JSON-formatted file preferably comprises the instructions to create, or build, the gratos database, as well as hash locations, metadata, and encryption keys for encrypted data that is not stored directly in the gratos database. ; Examples of such data not stored directly in the gratos database are DICOM files, high-resolution videos, or large files.
  • the data in the grate databases is encrypted with a public key encryption algorithm.
  • the encryption of the BDG data prevents any possible attack from a malicious user accessing the database.
  • the data of the grata databases are coded according to DICOM and/or HL7 FHIFi medical standards. Compliance with medical standards, such as DICOM and/or HL7 FHIR ensures the compatibility of data from different sources, such as data from internal databases of hospitals, clinics, research centers and/or universities. Additionally, in one embodiment, the middleware comprises export interfaces configured to output standard compatible files with data from the databases.
  • the data in the gratos databases is encoded as JSON files.
  • the JSON format is a highly versatile file format that ensures interoperability of microservices and compatibility with pre-existing databases.
  • the invention provides a method for managing a distributed multi-model database architecture according to the third inventive aspect with a management system according to the first inventive aspect, wherein the method comprises the steps of: receive, by a profile microservice, a request for data from a user interface, request, by a profile microservice, the location of data in one or more databases of gratos to the key-value database, transfer, by a profiling microservice, the data request and data location to the middleware, transfer, by the middleware, the data request to one or more of the user microservices of the gratos databases where the data is stored requested data, receiving, by the middleware, encrypted data from the one or more user microservices, transferring, by the middleware, the encrypted information to the microser profile vice.
  • the invention provides a computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the steps of: receiving, by a profile microservice, a request for data from a user interface, request, by a profile microservice, the location of data in one or more databases of gratos to the key-value database, transfer, by a profile microservice, the data request and location to the middleware, transfer, by the middleware, the data request to one or more user microservices in the gratos databases where the requested data is stored, receive, by the middleware, encrypted data from the one or more user microservices, transfer, via the middleware, the encrypted information to the profile microservice.
  • Figure 1 shows a preferred embodiment of the management system.
  • Figure 2 shows a preferred embodiment of the database architecture.
  • Figure 3 shows another aspect of an embodiment of the database architecture.
  • Figure 4 shows a preferred embodiment of the management system and database architecture.
  • Figure 5 shows the physical structure of the management system and the database architecture.
  • the invention is particularly suitable for the management of medical data stored in a plurality of local databases of medical institutions, such as hospitals, clinics and the like; these databases normally contain data from a high number of patients and most of them contain sensitive data; in conventional architectures, access to a single patient's data would entail granting access to the entire data set for all patients, as well as requiring individual access to each database. Consequently, the users are patients, but also doctors and researchers who want to obtain anonymous data from a wide range of sources.
  • Figure 1 shows a preferred embodiment of the management system (1); the management system (1) comprises a plurality of profile microservices (3), of which only three are represented in this figure, connected to each other and to the user interface (2).
  • the user interface (2) is preferably a web application, accessible from any device with an internet connection.
  • the profile microservices (3) are grouped by containers of a suite of platform as a service (PaaS) software products that use OS-level virtualization to deliver the software in packages called containers. These containers are isolated from each other and bundle their own software, libraries, and configuration files; containers can communicate with each other through well-defined channels. All containers are run by a single operating system core and therefore use fewer resources than virtual machines.
  • the profile microservices (3) also comprise an intermediate database in the event that the user wishes to permanently store data on the cloud server (10). In practice, the profile microservices (3) act as a virtual representation of the users and have full authority over the data owned by the user.
  • the key-value database (4) is a blockchain-based hash function table with the location of each user's data in the database architecture (20).
  • Middleware (5) is a distributed database management system NoSQL with peer-to-peer architecture that provides high availability between multiple data nodes, with asynchronous masterless replication between nodes installed within local databases (30) and the management system (1).
  • the middleware 5 can execute multicast queries to a number of user microservices 11 through a round-robin scheduling system; the only user microservices (11) that respond to the query are the user microservices (11) that contain the data and have been authorized by the user to share it.
  • the general scheme of the distributed multi-model database architecture (20) is shown in Figure 3, which represents four databases (30) or nodes.
  • the distributed multi-model database architecture (20) is essentially a federated database with a plurality of pre-existing relational databases (30), data being managed on a per-user basis by a plurality of user microservices (11). , in such a way that only certain data owned by the user is extracted from the database (30), reorganized in a user-specific graph database (12) and encrypted with a public key algorithm, all according to the instructions of an encrypted file (13).
  • Figure 3 shows a simplified view of the database architecture (20) with four databases (30) and a single user microservice (11) per database (30), whereas normally each database ( 30) will be associated with a plurality of microservices (11), normally one per user.
  • Figure 2 shows a view of a possible embodiment of one of the database architecture nodes (20), with a single database (30) and four user microservices (11); Also, each user microservice (11) is connected to its corresponding graph database (12) and encrypted file (13).
  • Figure 4 shows the management system (1) together with the distributed multi-model database architecture (20), represented by only two nodes.
  • Figure 5 shows a preferred implementation of the management system (1) and the distributed database architecture (20); the Figure shows the profile microservice (3), the key-value database (4) and part of the middleware (5) hosted on the cloud server (10); the user interface (2) in this example is a web application.
  • the database servers (31), of which only one unit is represented in Figure 5 host the user microservices (11), of which only one unit is represented in Figure 5, the same pre-existing database (30) and a part of the intermediate software (5).
  • the graph database (12) the data structure is implemented by a graph with a tree-like structure in documents that store references to "parent" nodes in child nodes.
  • the "parent reference pattern" stores each tree node in a document; in addition to the tree node, the document stores the identification, or ID, of the node's parent.
  • the key challenge in data modeling is balancing application needs, database engine performance characteristics, and data retrieval patterns.
  • gratos database collections by default, do not require their documents to have the same schema.
  • Documents in a single collection do not need to have the same set of fields, and the data type for a field may differ across documents within a collection.
  • To change the structure of documents in a collection such as adding new fields, removing existing fields, or changing field values to a new type, the documents are updated to the new structure.
  • the database architecture (20) is not only compatible with medical standards such as DICOM and HL7, the middleware (5) also comprises export interfaces to these formats, so that the database architecture data (20) is fully compatible with the existing hospital system and independent of software service providers.
  • the data is encrypted in such a way that the profile microservices (3) always have higher authority to decrypt the data.
  • the data location is known through the hierarchy established by the tree, and the cost of going from one node to another to build our necessary data structure at each moment. Therefore, the Dijkstra algorithm is the preferred algorithm to build the data network.
  • a minimum path algorithm will be used, that is, an algorithm for determining the shortest path between nodes.
  • the management system (1) executes these steps: receive, by a profile microservice (3), a data request from a user interface
  • Management system (1) according to any of the preceding clauses, wherein the key-value database (4) is configured as a distributed ledger.
  • Management system (1) according to any of the preceding clauses, further comprising a low-availability backup database controlled by middleware (5).
  • Management system (1) according to any of the previous clauses, where the intermediate software (5) is partially stored in a server (31) of the pre-existing database (30).
  • Management system (1) according to any of the preceding clauses, wherein the middleware (5) is configured to perform asynchronous masterless replication between nodes of the graph databases (12).
  • Management system (1) in accordance with any of the previous clauses, where the middleware (5) is configured to perform multicast queries according to a round-robin schedule.
  • At least one profile microservice (3) comprises an intermediate database configured to store data from the graph databases (12), data location with hash function of the user microservices (11), and/or decryption keys.
  • Computer system comprising a cloud server (10) configured to store and run the management system (1) according to clauses 1-11.
  • Distributed multi-model database architecture (20 comprising a plurality of user microservices (11), each connected to a database (30) of a plurality of pre-existing relational databases (30) stored in respective servers (31), where each user microservice (11) is associated with a user, each user microservice (11) is configured to create, store and manage a graph database (12), comprising nodes and edges, with data related to the associated user from the pre-existing database (30) connected to the user microservice (11), each user microservice (11) comprises an encrypted file (13) that can be decrypted by the user microservice (11) and containing instructions to create and store the graph database (12) with data related to the associated user, and each user microservice (11) is stored in the server (31) of the database pr database (30) connected to the user microservice (11), the graph database (12) is configured to be accessed only through the user microservice (11).
  • Computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the steps of: receiving, by a profile microservice (3), a request for data from a user interface

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

La presente invención se refiere a una arquitectura de base de datos multimodelo distribuida, en donde la arquitectura de base de datos comprende una pluralidad de microservicios de usuario configurados para crear, almacenar y gestionar bases de datos de grafos con datos sensibles de bases de datos convencionales prexistentes, un sistema de gestión para arquitectura de base de datos multimodelo distribuida, en donde el sistema de gestión comprende una interfaz de usuario, una pluralidad de microservicios de perfil, una base de datos clave-valor y un software intermedio, y un método para gestionar una arquitectura de base de datos multimodelo distribuida.

Description

DESCRIPCIÓN
Sistema y método de gestión para una arquitectura de base de datos multimodelo distribuida
Objeto de la invención
La presente invención se refiere a una arquitectura de base de datos multimodelo distribuida, en donde la arquitectura de base de datos comprende una pluralidad de microservicios de usuario configurados para crear, almacenar y gestionar bases de datos de grafos con datos sensibles de bases de datos convencionales prexistentes, un sistema de gestión para arquitectura de base de datos multimodelo distribuida, en donde el sistema de gestión comprende una interfaz de usuario, una pluralidad de microservicios de perfil, una base de datos clave-valor y un software intermedio, y un método para gestionar una arquitectura de base de datos multimodelo distribuida.
Antecedentes de la invención
Hoy en día, el análisis, procesamiento y aprovechamiento de los datos es un campo técnico floreciente con perspectivas de crecimiento enormes en los próximos años, como lo sugiere el éxito de las compañías líderes en el campo. Aunque se han dirigido muchos esfuerzos a analizar hábitos de consumo, otras aplicaciones potenciales han atraído menos atención; este es el caso, por ejemplo, de los datos médicos. Cada paciente tiene un registro de por vida de diagnósticos, tratamientos, pruebas clínicas y otros datos valiosos y sensibles que se almacenan por las instituciones médicas o los mismos pacientes durante décadas. Al ser un almacenamiento de información a muy largo plazo, estos registros comprenden diferentes formatos, que varían de copias físicas impresas con notas manuscritas de médicos hasta los últimos formatos digitales.
Adicionalmente, los registros normalmente están dispersos en diferentes almacenamientos que pertenecen a varios hospitales, en ocasiones que pertenecen a diferentes jurisdicciones. Incluso en un mismo hospital se almacenan diferentes tipos de datos en diferentes servidores que están diseñados bajo diferentes estándares médicos y así cada uno de estos servidores tiene su propia arquitectura de datos y protocolos de comunicación (DICOM, LOINC, RxNORM, SNOMED CT, etc.); además, cada uno de esos sistemas es desarrollado y mantenido por diferentes proveedores, lo que le da más variabilidad y complejidad a la integración de datos. Esta fragmentación de los datos a menudo es un obstáculo grave para la recopilación, actualización o investigación de estos registros, ya sea que se consideren como un único paciente o como un colectivo. Esta integración de datos o uniones de datos, generalmente ocurren a nivel de aplicación, lo que hace que la administración de datos sea compleja, ineficiente y muy costosa, debido a la necesidad de configurar cachés, lagos de datos intermedios y escalar bases de datos y servidores de procesamiento para realizar las agregaciones y traducciones de datos.
Debe considerarse que los datos cuantitativos proporcionados por pruebas complementarias (como radiología o análisis de laboratorio) son mucho más valiosos si están relacionados con el resto de los datos de registro clínico del paciente; de hecho, el valor de los datos es proporcional al número de relaciones significativas que puedan establecerse. Por lo tanto, es deseable tener una base de datos que permita una búsqueda y actualización sencilla de las relaciones entre las diferentes variables incluidas en el registro del paciente.
Típicamente, la mayoría de las bases de datos (BD) están estructuradas como bases de datos relaciónales (BDR); estas bases de datos relaciónales se vuelven especialmente complejas y rígidas cuando se trata de expresar relaciones entre elementos de datos, especialmente en el caso de relaciones complejas, por ejemplo, cuando es necesario obtener información de dos o más tablas relacionadas de la base de datos ( uniones de múltiples niveles ); por otro lado, estas uniones de múltiples niveles son difíciles de escalar horizontalmente. Las uniones pueden calcular eficazmente estadísticas de tablas de bases de datos existentes, pero la unión de múltiples niveles también es demasiado compleja para conjuntos de datos grandes. Si es necesario analizar una gran cantidad de datos, sería necesario enumerar todas las tupias de entidades relacionadas: "el coste del enfoque de enumeración está cerca de la materialización del producto cartesiano de los conjuntos de entidades, que crece exponencialmente con el número de conjuntos de entidades implicadas (Oliver y Zhensong, 2015; Das et al., 2015), (Vicknair et al., 2010; Partner et al., 2014)".
Un posible enfoque sería estructurar datos de paciente en bases de datos de grafos (BDG). Tales BDG pueden manejar la complejidad real de las dependencias entre datos. Además, la mayoría de los algoritmos de aprendizaje de máquina (ML) funcionan mucho mejor con implementaciones vectorizadas, tales como aquellas de las bases de datos de grafos, y esa implementación hace mucho más fácil el uso de bibliotecas para procesar datos en paralelo; puesto que las BDG normalmente se representan usando una matriz de afinidad, comparten la misma estructura con aplicaciones vectorizadas de aprendizaje de máquina. Además, las funciones en un grafo pueden representarse como un vector, que conlleva otra ventaja: los algoritmos de análisis de grafos pueden implementarse directamente en bases de datos de grafos, permitiendo ejecutar técnicas de ML y de análisis de grafos en el mismo entorno, posibilitando una cooperación estrecha entre sí, por ejemplo alimentando los algoritmos ML con métricas gráficas calculadas como variables predictivas; por lo tanto, puede usarse el mismo entorno para llevar a cabo análisis y eficiencia de información e incluso búsquedas compartimentadas, manteniendo la privacidad de la información del paciente.
Aunque las BDR están optimizadas para agregación de datos, otras bases de datos no relaciónales se centran en el volumen y las propiedades de los datos; por ejemplo, las BDG están optimizadas para conexiones de datos: en comparación con otros modelos, las BDG están diseñadas para gestionar un alto nivel de complejidad de datos, en parte debido a que la estructura de los datos no está fijada con antelación. Pero no todo ello son ventajas: las BDG también son más costosas, y hay menos herramientas disponibles para realizar operaciones complejas en un entorno de producción o servicios de mantenimiento.
Descripción de la invención
En un primer aspecto inventivo la invención proporciona un sistema de gestión para una arquitectura de base de datos multimodelo distribuida, comprendiendo la arquitectura de base de datos multimodelo distribuida una pluralidad de microservicios de usuario, cada uno conectado con una base de datos de una pluralidad de bases de datos relaciónales prexistentes almacenadas en respectivos servidores, en donde cada microservicio de usuario está asociado con un usuario, cada microservicio de usuario está configurado para crear, almacenar y gestionar una base de datos de gratos, que comprende nodos y aristas, con datos relacionados con el usuario asociado de la base de datos prexistente conectada con el microservicio de usuario, cada microservicio de usuario comprende un fichero encriptado que puede desencriptarse por el microservicio de usuario y que contiene instrucciones para crear y almacenar la base de datos de gratos con datos relacionados con el usuario asociado, cada microservicio de usuario se almacena en el servidor de la base de datos prexistente conectada al microservicio de usuario, y la base de datos de gratos está configurada para ser accedida únicamente a través del microservicio de usuario; en donde el sistema de gestión se almacena en un servidor en la nube y en donde el sistema de gestión comprende: una interfaz de usuario, una pluralidad de microservicios de perfil, en donde cada microservicio de perfil está asociado con un único usuario distinto, en donde cada microservicio de perfil está conectado con al menos otro microservicio de perfil, y en donde cada microservicio de perfil está configurado para desencriptar los ficheros encriptados de los microservicios de usuario asociados con el mismo usuario al que está asociado el microservicio de perfil, una base de datos clave-valor, conectada con los microservicios de perfil, y configurada para almacenar datos de ubicación con función de hash de cada base de datos de gratos, datos de ubicación con función de hash de los microservicios de perfil, y datos de ubicación con función de hash de los microservicios de usuario, y un software intermedio, configurado para conectar los microservicios de usuario y los microservicios de perfil.
El sistema de gestión proporciona un acceso centralizado a datos almacenados en una pluralidad de bases de datos preexistentes multimodelo independientes distribuidas, con un alto grado de seguridad y sin la pérdida de propiedad por el propietario legítimo de los datos; la arquitectura de base de datos proporciona, para cada base de datos prexistente, o nodo, una pluralidad de microservicios de usuario encargados de la creación de una base de datos de gratos (BDG) específica de usuario exclusivamente con datos relacionados con el usuario a partir de la base de datos prexistente, y de la gestión del acceso y comunicación con el sistema de gestión. Los datos de la base de datos de gratos se almacenan en el servidor de base de datos prexistente y se encriptan. El sistema de gestión únicamente está autorizado a acceder a los microservicios de usuario, y recibe datos encriptados, incluso sin obtener acceso al resto de los datos en la base de datos preexistente; por lo tanto se consigue un alto nivel de seguridad.
Cada microservicio de perfil está asociado con un único usuario, que mantiene preferentemente la propiedad de, o está debidamente autorizado a acceder a ciertos datos en las bases de datos preexistentes. En una disposición convencional, el usuario tendría acceso a las bases de datos individuales y extraería manualmente la información relevante, si la entidad que aloja las bases de datos lo permite. Esto crea dos problemas principales: en primer lugar, una vez que se concede acceso a un usuario a la base de datos, él puede acceder a cualquier registro en la base de datos, incluyendo datos sensibles de otros usuarios, poniendo en peligro por lo tanto la privacidad y seguridad de la base de datos; y en segundo lugar, el usuario tendría que solicitar manualmente y extraer datos relevantes de cada base de datos individual; como resultado, la extracción de datos de varias bases de datos sería costosa en tiempo y recursos.
La presente invención supera tales dificultades y proporciona un sistema de gestión de base de datos centralizado con un único proceso de autenticación a través de una interfaz de usuario, una base de datos clave-valor con un índice con las ubicaciones de cada uno de los datos de usuario, y un software intermedio que gestiona la comunicación entre el sistema de gestión y la arquitectura de base de datos distribuida. Los microservicios de perfil proporcionan una gestión integral de los permisos, las solicitudes de datos y las comunicaciones con la arquitectura de base de datos. El sistema de gestión se aloja mediante un servidor en la nube; por servidor en la nube debe entenderse un ordenador o sistema informático que comprende un procesador, medios de almacenamiento y acceso a Internet, y configurado para alojar y ejecutar el sistema de gestión de base de datos.
A lo largo de todo el presente documento, microservicio debe entenderse como cada una de las aplicaciones de software o elementos de una estructura de microservicio, como es conocido en la técnica. En la presente invención, todos los microservicios están relacionados con usuarios; por ejemplo, puede existir únicamente un único microservicio de perfil para cada usuario, mientras que puede haber más de un microservicio de usuario por usuario; en particular, para cada usuario hay un microservicio de usuario por nodo. Los nombres perfil y usuario deben entenderse como simples denominaciones de conveniencia para una primera clase de microservicios y una segunda clase de microservicios. El microservicio de perfil siempre tendrá una jerarquía superior que el microservicio de usuario, y tendrá la autoridad para leer los ficheros encriptados generados por los microservicios de usuario.
Una base de datos de gratos, o BDG, debe entenderse como cualquiera de una base de datos no relacional o una base de datos de grafos pura, que comprende nodos y vectores, y que almacena datos relacionados con el usuario; Los nodos de una BDG deben entenderse como vértices del grafo, o elementos de datos discretos enlazados mediante vectores o aristas a otros vértices, y son diferentes a los nodos que hacen referencia a estas bases de datos preexistentes.
La base de datos clave-valor, debe entenderse como una tabla de función de hash que comprende al menos un índice de la ubicación de cada registro de datos almacenado en las bases de datos de grafos relacionadas con cada usuario único, así como otros datos relevantes.
El software intermedio es un elemento configurado para posibilitar y gestionar la comunicación y la transferencia de datos entre la arquitectura de base de datos, en particular los microservicios de usuario, y el sistema de gestión.
La presente invención es de interés particular para la gestión de registros de paciente en un sistema de salud con una pluralidad de bases de datos poco relacionadas o independientes que pertenecen a instituciones sanitarias autónomas o independientes. Un paciente, propietario legítimo de datos relevantes tales como registros de paciente, historial médico, etc., puede acceder a la información almacenada en bases de datos hospitalarias separadas y mantener la propiedad de esos datos; adicionalmente, un doctor, facultativo médico o similares, puede acceder a los datos de sus pacientes también, con la condición de que el facultativo médico haya concedido permisos al propietario legítimo de los datos.
En una realización particular, la interfaz de usuario es una interfaz de usuario basada en web. Una interfaz basada en web asegura que cualquier usuario pueda acceder a la información desde cualquier parte en el mundo, proporcionando que el usuario posea los permisos requeridos.
En una realización particular, la base de datos clave-valor está configurada como un libro mayor distribuido. Más particularmente la base de datos clavel valor está configurada como un libro mayor distribuido (distributed iedger) de cadenas de bloques ( blockchain ), de manera que puede notificarse cualquier intento de manipulación de la información almacenada por un usuario malicioso puede y rastrearse por un usuario autorizado.
En una realización particular, la base de datos clave-valor comprende pares clave-valor encriptados con un algoritmo de encriptación de clave pública. Como una medida de seguridad adicional, la base de datos clave-valor se encripta usando un sistema de criptografía asimétrica, que incluye al menos una clave pública y una clave privada.
En una realización particular, la base de datos clave-valor comprende un gestor de base de datos clave-valor.
En una realización particular, el sistema comprende adicionalmente una base de datos de respaldo de baja disponibilidad controlada por el software intermedio.
En una realización particular, el software intermedio se almacena parcialmente en un servidor de la base de datos prexistente. Ventajosamente, parte del software intermedio está distribuido a través de los nodos de los servidores de bases de datos prexistentes, y está almacenado en los correspondientes servidores de bases de datos, con un grado de integración superior.
En una realización particular, el software intermedio está configurado como una red entre pares (peer-to-peer network).
En una realización particular, el software intermedio está configurado para realizar replicación sin maestro síncrono entre nodos de las bases de datos de gratos.
En una realización particular, el software intermedio está configurado para realizar consultas de multidifusión de acuerdo con una planificación por orden cíclico. En una realización particular, al menos un microservicio de perfil comprende una base de datos intermedia configurada para almacenar datos de las bases de datos de gratos, datos de ubicación con función de hash de los microservicios de usuario, y/o claves de desencriptación. Las bases de datos intermedias son bases de datos específicas de usuario de pequeño volumen para el almacenamiento de diversos datos, tales como las ubicaciones de los microservicios y las claves de encriptación/desencriptación; estas bases de datos intermedias funcionan como almacenamientos locales de información y posibilitan un acceso más rápido a una consulta de un usuario.
En un segundo aspecto inventivo, la invención proporciona un sistema informático que comprende un servidor en la nube configurado para almacenar y ejecutar el sistema de gestión de acuerdo con el primer aspecto inventivo. El sistema informático comprende al menos un servidor en la nube con conexión a Internet, y opcionalmente ordenadores adicionales y/o dispositivos similares tales como dispositivos portátiles, tabletas, teléfonos inteligentes, y similares.
En un tercer aspecto inventivo, la invención proporciona una arquitectura de base de datos multimodelo distribuida, que comprende una pluralidad de microservicios de usuario, cada uno conectado con una base de datos de una pluralidad de bases de datos relaciónales prexistentes almacenadas en respectivos servidores, en donde cada microservicio de usuario está asociado con un usuario, cada microservicio de usuario está configurado para crear, almacenar y gestionar una base de datos de gratos, que comprende nodos y aristas, con datos relacionados con el usuario asociado de la base de datos prexistente conectada con el microservicio de usuario, cada microservicio de usuario comprende un fichero encriptado que puede desencriptarse por el microservicio de usuario y que contiene instrucciones para crear y almacenar la base de datos de gratos con datos relacionados con el usuario asociado, y cada microservicio de usuario se almacena en el servidor de la base de datos prexistente conectada al microservicio de usuario, la base de datos de gratos está configurada para ser accedida únicamente a través del microservicio de usuario.
Los microservicios de usuario hacen uso de respectivos ficheros encriptados para crear o construir la base de datos de grafos; tal fichero encriptado comprende las instrucciones específicas para la tarea y están encriptadas para evitar amenazas de seguridad. Por lo tanto, la arquitectura de base de datos multimodelo distribuida proporciona ventajosamente una base de datos sustituía con un modelo normalizado, independientemente del tipo de bases de datos preexistentes.
En una realización particular, el fichero enchptado está enchptado con un algoritmo de encriptación de clave pública. Los algoritmos de encriptación de clave pública proporcionan ventajosamente un sistema de encriptación asimétrica altamente seguro que puede resistir la mayoría de los intentos de ataque sin requerir una carga de procesamiento o tiempos de procesamiento altos.
En una realización particular, el fichero enchptado comprende uno o más de lo siguiente: datos de usuario, funciones de hash, metadatos, claves de encriptación. El fichero encriptado almacena ventajosamente las instrucciones para crear, o construir, la base de datos de gratos, y otros datos útiles que aseguran el acceso a la base de datos de gratos y la seguridad de la información; además, el fichero encriptado puede almacenar directamente ciertos datos, en lugar de simplemente apuntar a una dirección diferente.
En una realización particular, el fichero encriptado se codifica como un fichero JSON. El fichero formateado como JSON comprende preferentemente las instrucciones para crear o construir, la base de datos de gratos, así como ubicaciones con función de hash, metadatos, y claves de encriptación para datos encriptados que no se almacenan directamente en la base de datos de gratos; ejemplos de tales datos no almacenados directamente en la base de datos de gratos son ficheros DICOM, vídeos de alta resolución o ficheros grandes.
En una realización particular, los datos de las bases de datos de gratos están encriptados con un algoritmo de encriptación de clave pública. Ventajosamente, la encriptación de los datos de la BDG evita cualquier posible ataque de un usuario malicioso que acceda a la base de datos.
En una realización particular, los datos de las bases de datos de gratos se codifican de acuerdo con estándares médicos DICOM y/o HL7 FHIFi. El cumplimiento con los estándares médicos, tales como DICOM y/o HL7 FHIR asegura la compatibilidad de datos de diferentes fuentes, tales como datos de las bases de datos internas de hospitales, clínicas, centros de investigación y/o universidades. Adicionalmente, en una realización, el software intermedio comprende exportar interfaces configuradas para emitir ficheros compatibles normalizados con datos de las bases de datos.
En una realización particular, los datos de las bases de datos de gratos se codifican como ficheros JSON. El formato JSON es un formato de fichero altamente versátil que asegura la interoperabilidad de los microservicios y la compatibilidad con las bases de datos preexistentes. En un cuarto aspecto inventivo, la invención proporciona un método para gestionar una arquitectura de base de datos multimodelo distribuida de acuerdo con el tercer aspecto inventivo con un sistema de gestión de acuerdo con el primer aspecto inventivo, en donde el método comprende las etapas de: recibir, por un microservicio de perfil, una solicitud de datos desde una interfaz de usuario, solicitar, por un microservicio de perfil, la ubicación de datos en una o más bases de datos de gratos a la base de datos clave-valor, transferir, por un microservicio de perfil, la solicitud de datos y la ubicación de datos al software intermedio, transferir, por el software intermedio, la solicitud de datos a uno o más de los microservicios de usuario de las bases de datos de gratos donde se almacenan los datos solicitados, recibir, por el software intermedio, datos encriptados desde el uno o más microservicios de usuario, transferir, por el software intermedio, la información encriptada al microservicio de perfil.
En un quinto aspecto inventivo, la invención proporciona un medio legible por ordenador que comprende instrucciones que, cuando se ejecutan por un ordenador, hacen que el ordenador lleve a cabo las etapas de: recibir, por un microservicio de perfil, una solicitud de datos desde una interfaz de usuario, solicitar, por un microservicio de perfil, la ubicación de datos en una o más bases de datos de gratos a la base de datos clave-valor, transferir, por un microservicio de perfil, la solicitud de datos y la ubicación de datos al software intermedio, transferir, por el software intermedio, la solicitud de datos a uno o más de los microservicios de usuario de las bases de datos de gratos donde se almacenan los datos solicitados, recibir, por el software intermedio, datos encriptados desde el uno o más microservicios de usuario, transferir, por el software intermedio, la información encriptada al microservicio de perfil.
Descripción de los dibujos
Las ventajas y características anteriores y otras se entenderán más completamente a partir de la siguiente descripción detallada de realizaciones de ejemplo con referencia a los dibujos adjuntos, que deben considerarse por medio de ilustración y no limitación, en los que:
La Figura 1 muestra una realización preferida del sistema de gestión.
La Figura 2 muestra una realización preferida de la arquitectura de base de datos. La Figura 3 muestra otro aspecto de una realización de la arquitectura de base de datos.
La Figura 4 muestra una realización preferida del sistema de gestión y la arquitectura de base de datos.
La Figura 5 muestra la estructura física del sistema de gestión y la arquitectura de base de datos.
Realización preferida de la invención
La invención es particularmente adecuada para la gestión de datos médicos almacenados en una pluralidad de bases de datos locales de instituciones médicas, tales como hospitales, clínicas y similares; estas bases de datos normalmente contienen datos de un número alto de pacientes y en su mayoría contienen datos sensibles; en arquitecturas convencionales, el acceso a los datos de un único paciente conllevaría la concesión de acceso a la totalidad del conjunto de datos de todos los pacientes, así como requeriría la obtención de acceso individual a cada base de datos. Por consiguiente, los usuarios son pacientes, pero también médicos e investigadores que desean obtener datos anónimos de una amplia gama de fuentes.
La Figura 1 muestra una realización preferida del sistema de gestión (1); el sistema de gestión (1) comprende una pluralidad de microservicios de perfil (3), de los cuales únicamente se representan tres en esta figura, conectados entre sí y a la interfaz de usuario (2). La interfaz de usuario (2) es preferentemente una aplicación web, accesible desde cualquier dispositivo con conexión a internet.
En una realización, los microservicios de perfil (3) están agrupados por contenedores de un conjunto de productos de software de plataforma como un servicio ( platform as a Service, PaaS) que usan virtualización de nivel de Sistema Operativo para entregar el software en paquetes denominados contenedores. Estos contenedores están aislados entre sí y agrupan su propio software, bibliotecas y ficheros de configuración; los contenedores pueden comunicarse entre sí a través de canales bien definidos. Todos los contenedores se ejecutan por un único núcleo de sistema operativo y por lo tanto usan menos recursos que las máquinas virtuales. Los microservicios de perfil (3) también comprenden una base de datos intermedia en el caso de que el usuario desee almacenar datos permanentemente en el servidor en la nube (10). En la práctica, los microservicios de perfil (3) actúan como una representación virtual de los usuarios y tienen autoridad total sobre los datos de propiedad del usuario.
En este ejemplo, la base de datos clave-valor (4) es una tabla de funciones de hash basada en cadena de bloques con la ubicación de los datos de cada usuario en la arquitectura de base de datos (20). El software intermedio (5) es un sistema de gestión de base de datos distribuido NoSQL con arquitectura peer-to-peer que proporciona una alta disponibilidad entre múltiples nodos de datos, con replicación sin maestro asincrona entre nodos instalados dentro de bases de datos locales (30) y el sistema de gestión (1). El software intermedio (5) puede ejecutar consultas de multidifusión a un número de microservicios de usuario (11) mediante un sistema de planificación por orden cíclico; los únicos microservicios de usuario (11) que responden a la consulta, son los microservicios de usuario (11) que contienen los datos y han sido autorizados por el usuario para compartirlos.
El esquema general de la arquitectura de base de datos multimodelo distribuida (20) se muestra en la Figura 3, que representa cuatro bases de datos (30) o nodos. La arquitectura de base de datos multimodelo distribuida (20) es esencialmente una base de datos federada con una pluralidad de bases de datos relaciónales prexistentes (30), datos que se gestionan en una base por usuario por una pluralidad de microservicios de usuario (11), en una forma tal que únicamente se extraen ciertos datos de propiedad por el usuario desde la base de datos (30), se reorganizan en una base de datos de grafos específica de usuario (12) y se encriptan con un algoritmo de clave pública, todo de acuerdo con las instrucciones de un fichero encriptado (13).
La Figura 3 muestra una vista simplificada de la arquitectura de base de datos (20) con cuatro bases de datos (30) y un único microservicio de usuario (11) por base de datos (30), mientras que normalmente cada base de datos (30) estará asociada a una pluralidad de microservicios (11), normalmente uno por usuario. La Figura 2 muestra una vista de una posible realización de uno de los nodos de la arquitectura de base de datos (20), con una única base de datos (30) y cuatro microservicios de usuario (11); También, cada microservicio de usuario (11) está conectado a su correspondiente base de datos de grafos (12) y fichero encriptado (13).
La Figura 4 muestra el sistema de gestión (1) junto con la arquitectura de base de datos multimodelo distribuida (20), representado por dos nodos únicamente.
La Figura 5 muestra una implementación preferida del sistema de gestión (1) y la arquitectura de base de datos distribuida (20); la Figura muestra el microservicio de perfil (3), la base de datos clave-valor (4) y parte del software intermedio (5) alojado en el servidor en la nube (10); la interfaz de usuario (2) en este ejemplo es una aplicación web. Por otra parte, los servidores de base de datos (31), de los que únicamente se representa una unidad en la Figura 5, alojan los microservicios de usuario (11), de los que únicamente se representa una unidad en la Figura 5, la misma base de datos prexistente (30) y una parte del software intermedio (5). En la base de datos de gratos (12), la estructura de datos se implementa mediante un grato con estructura similar a árbol en documentos que almacenan referencias a nodos "padres" en nodos hijos. El "patrón de referencias padre" almacena cada nodo de árbol en un documento; además del nodo de árbol, el documento almacena la identificación, o ID, del padre del nodo. El desafío de clave en el modelado de datos es el equilibrio de las necesidades de la aplicación, las características de rendimiento del motor de base de datos, y los patrones de recuperación de datos. A diferencia de SQL, o las bases de datos convencionales, donde debe determinarse un esquema de tabla y declararse antes de insertar datos, las colecciones de bases de datos de gratos, por defecto, no requieren que sus documentos tengan el mismo esquema. Los documentos en una única colección no necesitan tener el mismo conjunto de campos y el tipo de datos para un campo puede diferir a través de documentos dentro de una colección. Para cambiar la estructura de los documentos en una colección, tal como añadir nuevos campos, eliminar campos existentes o cambiar los valores de campo a un nuevo tipo, se actualizan los documentos a la nueva estructura. Esta flexibilidad facilita el mapeo de documentos a una entidad o un objeto. Cada documento puede adaptar los campos de datos de la entidad representada, incluso si el documento tiene variación sustancial de otros documentos en la colección. La decisión clave al diseñar modelos de datos para aplicaciones de base de datos de grafos gira en torno a la estructura de documentos y cómo la aplicación representa relaciones entre datos.
En un ejemplo preferido, la arquitectura de base de datos (20) no es compatible únicamente con estándares médicos tales como DICOM y HL7, el software intermedio (5) también comprende interfaces de exportación a estos formatos, de manera que la arquitectura de base de datos (20) es completamente compatible con el sistema hospitalario existente e independiente de los proveedores de servicio de software.
Adicionalmente, el acceso a los datos es únicamente posible a través de los microservicios de usuario (11), y con la condición de que la solicitud se autorice debidamente con la correspondiente clave. Los datos se encriptan de tal manera que los microservicios de perfil (3) siempre tienen una autoridad superior para desencriptar los datos.
La ubicación de datos es conocida a través de la jerarquía establecida por el árbol, y el coste que tiene pasar de un nodo a otro para construir nuestra estructura de datos necesaria en cada momento. Por consiguiente, el algoritmo Dijkstra es el algoritmo preferido para construir la red de datos. Se usará un algoritmo de ruta mínimo, es decir, un algoritmo para la determinación de la ruta más corta entre nodos. Una vez que es conocida la ubicación de los ficheros en cada uno de los nodos (hospitales), es posible ejecutar el algoritmo para reconstruir el mismo árbol de datos. Si cualquiera de los nodos sufre cambios en las rutas de fichero, tendremos que reconstruir el árbol usando el mismo patrón.
Para solicitar un registro de datos después de la solicitud de un usuario debidamente autorizado, el sistema de gestión (1) ejecuta estas etapas: recibir, por un microservicio de perfil (3), una solicitud de datos desde una interfaz de usuario
(2), solicitar, por un microservicio de perfil (3), la ubicación de datos en una o más bases de datos de gratos (12) a la base de datos clave-valor (4), transferir, por un microservicio de perfil (3), la solicitud de datos y la ubicación de datos al software intermedio (5), transferir, por el software intermedio (5), la solicitud de datos a uno o más microservicios de usuario (11) de las bases de datos de gratos (12) donde se almacenan los datos solicitados, recibir, por el software intermedio (5), datos encriptados desde el uno o más microservicios de usuario (11), transferir, por el software intermedio (5), la información encriptada al microservicio de perfil (3).
Cláusulas de la invención
1. Sistema de gestión (1) para una arquitectura de base de datos multimodelo distribuida (20), arquitectura de base de datos multimodelo distribuida (20) que comprende una pluralidad de microservicios de usuario (11), cada uno conectado con una base de datos (30) de una pluralidad de bases de datos relaciónales prexistentes (30) almacenadas en respectivos servidores (31), en donde cada microservicio de usuario (11) está asociado con un usuario, cada microservicio de usuario (11) está configurado para crear, almacenar y gestionar una base de datos de gratos (12), que comprende nodos y aristas, con datos relacionados con el usuario asociado de la base de datos prexistente (30) conectada con el microservicio de usuario, cada microservicio de usuario comprende un fichero encriptado (13) que puede desencriptarse por el microservicio de usuario (11) y que contiene instrucciones para crear y almacenar la base de datos de gratos (12) con datos relacionados con el usuario asociado, cada microservicio de usuario (11) se almacena en el servidor (31) de la base de datos prexistente (30) conectada al microservicio de usuario (11), y la base de datos de gratos (12) está configurada para ser accedida únicamente a través del microservicio de usuario (11); en donde el sistema de gestión (1) se almacena en un servidor en la nube (10) y en donde el sistema de gestión (1) comprende: una interfaz de usuario (2), una pluralidad de microservicios de perfil (3), en donde cada microservicio de perfil (3) está asociado con un único usuario distinto, en donde cada microservicio de perfil (3) está conectado con al menos otro microservicio de perfil (3), y en donde cada microservicio de perfil (3) está configurado para desencriptar los ficheros encriptados (13) de los microservicios de usuario (11) asociados con el mismo usuario al que está asociado el microservicio de perfil (3), una base de datos clave-valor (4), conectada con los microservicios de perfil (3), y configurada para almacenar datos de ubicación con función de hash de cada base de datos de grafos (12), datos de ubicación con función de hash de los microservicios de perfil (3), y datos de ubicación con función de hash de los microservicios de usuario (11), y un software intermedio (5), configurado para conectar los microservicios de usuario (11) y los microservicios de perfil (3).
2. Sistema de gestión (1) de acuerdo con la cláusula anterior, en donde la interfaz de usuario (2) es una interfaz de usuario basada en web.
3. Sistema de gestión (1) de acuerdo con cualquiera de las cláusulas anteriores, en donde la base de datos clave-valor (4) está configurada como un libro mayor distribuido.
4. Sistema de gestión (1) de acuerdo con cualquiera de las cláusulas anteriores, en donde la base de datos clave-valor (4) comprende pares clave-valor encriptados con un algoritmo de encriptación de clave pública.
5. Sistema de gestión (1) de acuerdo con cualquiera de las cláusulas anteriores, en donde la base de datos clave-valor (4) comprende un gestor de base de datos clave-valor.
6. Sistema de gestión (1) de acuerdo con cualquiera de las cláusulas anteriores, que comprende adicionalmente una base de datos de respaldo de baja disponibilidad controlada por el software intermedio (5).
7. Sistema de gestión (1) de acuerdo con cualquiera de las cláusulas anteriores, en donde el software intermedio (5) está parcialmente almacenado en un servidor (31) de la base de datos prexistente (30).
8. Sistema de gestión (1) de acuerdo con cualquiera de las cláusulas anteriores, en donde el software intermedio (5) está configurado como una red entre pares.
9. Sistema de gestión (1) de acuerdo con cualquiera de las cláusulas anteriores, en donde el software intermedio (5) está configurado para realizar replicación sin maestro asincrona entre nodos de las bases de datos de grafos (12).
10. Sistema de gestión (1) de acuerdo con cualquiera de las cláusulas anteriores, en donde el software intermedio (5) está configurado para realizar consultas de multidifusión de acuerdo con una planificación por orden cíclico.
11. Sistema de gestión (1) de acuerdo con cualquiera de las cláusulas anteriores, en donde al menos un microservicio de perfil (3) comprende una base de datos intermedia configurada para almacenar datos de las bases de datos de grafos (12), datos de ubicación con función de hash de los microservicios de usuario (11), y/o claves de desencriptación.
12. Sistema informático que comprende un servidor en la nube (10) configurado para almacenar y ejecutar el sistema de gestión (1) de acuerdo con las cláusulas 1-11.
13. Arquitectura de base de datos multimodelo distribuida (20), que comprende una pluralidad de microservicios de usuario (11), cada uno conectado con una base de datos (30) de una pluralidad de bases de datos relaciónales prexistentes (30) almacenadas en respectivos servidores (31), en donde cada microservicio de usuario (11) está asociado con un usuario, cada microservicio de usuario (11) está configurado para crear, almacenar y gestionar una base de datos de grafos (12), que comprende nodos y aristas, con datos relacionados con el usuario asociado de la base de datos preexistente (30) conectada con el microservicio de usuario (11), cada microservicio de usuario (11) comprende un fichero encriptado (13) que puede desencriptarse por el microservicio de usuario (11) y que contiene instrucciones para crear y almacenar la base de datos de grafos (12) con datos relacionados con el usuario asociado, y cada microservicio de usuario (11) se almacena en el servidor (31) de la base de datos prexistente (30) conectada al microservicio de usuario (11), la base de datos de grafos (12) está configurada para ser accedida únicamente a través del microservicio de usuario (11).
14. Arquitectura de base de datos multimodelo distribuida (20) de acuerdo con la cláusula anterior, en donde el fichero encriptado (13) se encripta con un algoritmo de encriptación de clave pública.
15. Arquitectura de base de datos multimodelo distribuida (20) de acuerdo con cualquiera de las cláusulas 13-14, en donde el fichero encriptado (13) comprende uno o más de lo siguiente: datos de usuario, funciones de hash, metadatos, claves de encriptación.
16. Arquitectura de base de datos multimodelo distribuida (20) de acuerdo con cualquiera de las cláusulas 13-15, en donde el fichero encriptado (13) se codifica como un fichero JSON.
17. Arquitectura de base de datos multimodelo distribuida (20) de acuerdo con cualquiera de las cláusulas 13-16, en donde los datos de las bases de datos de grafos (12) se encriptan con un algoritmo de encriptación de clave pública.
18. Arquitectura de base de datos multimodelo distribuida (20) de acuerdo con cualquiera de las cláusulas 13-17, en donde los datos de las bases de datos de gratos (12) se codifican de acuerdo con los estándares médicos DICOM y/o HL7 FHIR.
19. Arquitectura de base de datos multimodelo distribuida (20) de acuerdo con cualquiera de las cláusulas 13-18, en donde los datos de las bases de datos de gratos (12) se codifican como ficheros JSON.
20. Método para gestionar una arquitectura de base de datos multimodelo distribuida (20) de acuerdo con cualquiera de las cláusulas 13 a 19 con un sistema de gestión (1) de acuerdo con cualquiera de las cláusulas 1 a 11, en donde el método comprende las etapas de: recibir, por un microservicio de perfil (3), una solicitud de datos desde una interfaz de usuario
(2), solicitar, por un microservicio de perfil (3), la ubicación de datos en una o más bases de datos de gratos (12) a la base de datos clave-valor (4), transferir, por un microservicio de perfil (3), la solicitud de datos y la ubicación de datos al software intermedio (5), transferir, por el software intermedio (5), la solicitud de datos a uno o más microservicios de usuario (11) de las bases de datos de gratos (12) donde se almacenan los datos solicitados, recibir, por el software intermedio (5), datos encriptados desde el uno o más microservicios de usuario (11), transferir, por el software intermedio (5), la información encriptada al microservicio de perfil (3).
21. Medio legible por ordenador que comprende instrucciones que, cuando se ejecutan por un ordenador, hacen que el ordenador lleve a cabo las etapas de: recibir, por un microservicio de perfil (3), una solicitud de datos desde una interfaz de usuario
(2), solicitar, por un microservicio de perfil (3), la ubicación de datos en una o más bases de datos de gratos (12) a la base de datos clave-valor (4), transferir, por un microservicio de perfil (3), la solicitud de datos y la ubicación de datos al software intermedio (5), transferir, por el software intermedio (5), la solicitud de datos a uno o más microservicios de usuario (11) de las bases de datos de gratos (12) donde se almacenan los datos solicitados, recibir, por el software intermedio (5), datos encriptados desde el uno o más microservicios de usuario (11), transferir, por el software intermedio (5), la información encriptada al microservicio de perfil (3).

Claims

REIVINDICACIONES
1. Sistema de gestión (1) para una arquitectura de base de datos multimodelo distribuida (20), arquitectura de base de datos multimodelo distribuida (20) que comprende una pluralidad de microservicios de usuario (11), cada uno conectado con una base de datos (30) de una pluralidad de bases de datos relaciónales prexistentes (30) almacenadas en respectivos servidores (31), en donde cada microservicio de usuario (11) está asociado con un usuario, cada microservicio de usuario (11) está configurado para crear, almacenar y gestionar una base de datos de gratos (12), que comprende nodos y aristas, con datos relacionados con el usuario asociado de la base de datos prexistente (30) conectada con el microservicio de usuario, cada microservicio de usuario comprende un fichero encriptado (13) que puede desencriptarse por el microservicio de usuario (11) y que contiene instrucciones para crear y almacenar la base de datos de gratos (12) con datos relacionados con el usuario asociado, cada microservicio de usuario (11) se almacena en el servidor (31) de la base de datos prexistente (30) conectada al microservicio de usuario (11), y la base de datos de gratos (12) está configurada para ser accedida únicamente a través del microservicio de usuario (11); en donde el sistema de gestión (1) se almacena en un servidor en la nube (10) y en donde el sistema de gestión (1) comprende: una interfaz de usuario (2), una pluralidad de microservicios de perfil (3), en donde cada microservicio de perfil (3) está asociado con un único usuario distinto, en donde cada microservicio de perfil (3) está conectado con al menos otro microservicio de perfil (3), y en donde cada microservicio de perfil (3) está configurado para desencriptar los ficheros encriptados (13) de los microservicios de usuario (11) asociados con el mismo usuario al que está asociado el microservicio de perfil (3), una base de datos clave-valor (4), conectada con los microservicios de perfil (3), y configurada para almacenar datos de ubicación con función de hash de cada base de datos de gratos (12), datos de ubicación con función de hash de los microservicios de perfil (3), y datos de ubicación con función de hash de los microservicios de usuario (11), y un software intermedio (5), configurado para conectar los microservicios de usuario (11) y los microservicios de perfil (3).
2. Sistema de gestión (1) de acuerdo con la reivindicación anterior, en donde la interfaz de usuario (2) es una interfaz de usuario basada en web.
3. Sistema de gestión (1) de acuerdo con cualquiera de las reivindicaciones anteriores, en donde la base de datos clave-valor (4) está configurada como un libro mayor distribuido.
4. Sistema de gestión (1) de acuerdo con cualquiera de las reivindicaciones anteriores, en donde la base de datos clave-valor (4) comprende pares clave-valor encriptados con un algoritmo de encriptación de clave pública.
5. Sistema de gestión (1) de acuerdo con cualquiera de las reivindicaciones anteriores, en donde la base de datos clave-valor (4) comprende un gestor de base de datos clave-valor.
6. Sistema de gestión (1) de acuerdo con cualquiera de las reivindicaciones anteriores, que comprende adicionalmente una base de datos de respaldo de baja disponibilidad controlada por el software intermedio (5).
7. Sistema de gestión (1) de acuerdo con cualquiera de las reivindicaciones anteriores, en donde el software intermedio (5) está almacenado parcialmente en un servidor (31) de la base de datos prexistente (30).
8. Sistema de gestión (1) de acuerdo con cualquiera de las reivindicaciones anteriores, en donde el software intermedio (5) está configurado como una red entre pares.
9. Sistema de gestión (1) de acuerdo con cualquiera de las reivindicaciones anteriores, en donde el software intermedio (5) está configurado para realizar replicación sin maestro asincrona entre nodos de las bases de datos de grafos (12).
10. Sistema de gestión (1) de acuerdo con cualquiera de las reivindicaciones anteriores, en donde el software intermedio (5) está configurado para realizar consultas de multidifusión de acuerdo con una planificación por orden cíclico.
11. Sistema de gestión (1) de acuerdo con cualquiera de las reivindicaciones anteriores, en donde al menos un microservicio de perfil (3) comprende una base de datos intermedia configurada para almacenar datos de las bases de datos de grafos (12), datos de ubicación con función de hash de los microservicios de usuario (11), y/o claves de desencriptación.
12. Sistema informático que comprende un servidor en la nube (10) configurado para almacenar y ejecutar el sistema de gestión (1) de acuerdo con las reivindicaciones 1-11.
13. Arquitectura de base de datos multimodelo distribuida (20), que comprende una pluralidad de microservicios de usuario (11), cada uno conectado con una base de datos (30) de una pluralidad de bases de datos relaciónales prexistentes (30) almacenadas en respectivos servidores (31), en donde cada microservicio de usuario (11) está asociado con un usuario, cada microservicio de usuario (11) está configurado para crear, almacenar y gestionar una base de datos de gratos (12), que comprende nodos y aristas, con datos relacionados con el usuario asociado de la base de datos preexistente (30) conectada con el microservicio de usuario (11), cada microservicio de usuario (11) comprende un fichero encriptado (13) que puede desencriptarse por el microservicio de usuario (11) y que contiene instrucciones para crear y almacenar la base de datos de gratos (12) con datos relacionados con el usuario asociado, y cada microservicio de usuario (11) se almacena en el servidor (31) de la base de datos prexistente (30) conectada al microservicio de usuario (11), la base de datos de gratos (12) está configurada para ser accedida únicamente a través del microservicio de usuario (11).
14. Arquitectura de base de datos multimodelo distribuida (20) de acuerdo con la reivindicación anterior, en donde el fichero encriptado (13) está encriptado con un algoritmo de encriptación de clave pública.
15. Arquitectura de base de datos multimodelo distribuida (20) de acuerdo con cualquiera de las reivindicaciones 13-14, en donde el fichero encriptado (13) comprende uno o más de lo siguiente: datos de usuario, funciones de hash, metadatos, claves de encriptación.
16. Arquitectura de base de datos multimodelo distribuida (20) de acuerdo con cualquiera de las reivindicaciones 13-15, en donde el fichero encriptado (13) se codifica como un fichero JSON.
17. Arquitectura de base de datos multimodelo distribuida (20) de acuerdo con cualquiera de las reivindicaciones 13-16, en donde los datos de las bases de datos de grafos (12) se encriptan con un algoritmo de encriptación de clave pública.
18. Arquitectura de base de datos multimodelo distribuida (20) de acuerdo con cualquiera de las reivindicaciones 13-17, en donde los datos de las bases de datos de grafos (12) se codifican de acuerdo con los estándares médicos DICOM y/o HL7 FHIR.
19. Arquitectura de base de datos multimodelo distribuida (20) de acuerdo con cualquiera de las reivindicaciones 13-18, en donde los datos de las bases de datos de gratos (12) se codifican como ficheros JSON.
20. Método para gestionar una arquitectura de base de datos multimodelo distribuida (20) de acuerdo con cualquiera de las reivindicaciones 13 a 19 con un sistema de gestión (1) de acuerdo con cualquiera de las reivindicaciones 1 a 11, en donde el método comprende las etapas de: recibir, por un microservicio de perfil (3), una solicitud de datos desde una interfaz de usuario
(2), solicitar, por un microservicio de perfil (3), la ubicación de datos en una o más bases de datos de gratos (12) a la base de datos clave-valor (4), transferir, por un microservicio de perfil (3), la solicitud de datos y la ubicación de datos al software intermedio (5), transferir, por el software intermedio (5), la solicitud de datos a uno o más microservicios de usuario (11) de las bases de datos de gratos (12) donde se almacenan los datos solicitados, recibir, por el software intermedio (5), datos encriptados desde el uno o más microservicios de usuario (11), transferir, por el software intermedio (5), la información encriptada al microservicio de perfil (3).
21. Medio legible por ordenador que comprende instrucciones que, cuando se ejecutan por un ordenador, hacen que el ordenador lleve a cabo las etapas de: recibir, por un microservicio de perfil (3), una solicitud de datos desde una interfaz de usuario
(2), solicitar, por un microservicio de perfil (3), la ubicación de datos en una o más bases de datos de gratos (12) a la base de datos clave-valor (4), transferir, por un microservicio de perfil (3), la solicitud de datos y la ubicación de datos al software intermedio (5), transferir, por el software intermedio (5), la solicitud de datos a uno o más microservicios de usuario (11) de las bases de datos de gratos (12) donde se almacenan los datos solicitados, recibir, por el software intermedio (5), datos encriptados desde el uno o más microservicios de usuario (11), transferir, por el software intermedio (5), la información encriptada al microservicio de perfil (3).
PCT/ES2021/070271 2020-11-27 2021-04-23 Sistema y método de gestión para una arquitectura de base de datos multimodelo distribuida WO2022112624A1 (es)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202180079847.1A CN116917881A (zh) 2020-11-27 2021-04-23 一种分布式多模型数据库体系结构的管理系统和方法
EP21724345.0A EP4254219A1 (en) 2020-11-27 2021-04-23 Management system and method for a distributed multi-model database architecture
US18/253,715 US20230418839A1 (en) 2020-11-27 2021-04-23 Management System And Method For A Distributed Multi-Model Database Architecture

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ESU202032593 2020-11-27
ES202032593 2020-11-27

Publications (1)

Publication Number Publication Date
WO2022112624A1 true WO2022112624A1 (es) 2022-06-02

Family

ID=81755361

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2021/070271 WO2022112624A1 (es) 2020-11-27 2021-04-23 Sistema y método de gestión para una arquitectura de base de datos multimodelo distribuida

Country Status (4)

Country Link
US (1) US20230418839A1 (es)
EP (1) EP4254219A1 (es)
CN (1) CN116917881A (es)
WO (1) WO2022112624A1 (es)

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CARPENTER JEFFREY: "Data Model Meets World, Part IV: How Many Databases? | Datastax", 25 October 2020 (2020-10-25), pages 1 - 8, XP055831558, Retrieved from the Internet <URL:https://web.archive.org/web/20201025230246/https://www.datastax.com/blog/data-model-meets-world-part-iv-how-many-databases> [retrieved on 20210811] *
DE SANTIS SANDRO ET AL: "Evolve the Monolith to Microservices with Java and Node", 5 December 2016 (2016-12-05), pages 1 - 132, XP055831625, Retrieved from the Internet <URL:https://www.redbooks.ibm.com/redbooks/pdfs/sg248358.pdf> [retrieved on 20210811] *
KUMAR ROSHAN: "Selecting the Right Database for Your Microservices - The New Stack", 30 January 2019 (2019-01-30), pages 1 - 19, XP055831512, Retrieved from the Internet <URL:https://web.archive.org/web/20190130224759/https://thenewstack.io/selecting-the-right-database-for-your-microservices/> [retrieved on 20210811] *

Also Published As

Publication number Publication date
EP4254219A1 (en) 2023-10-04
US20230418839A1 (en) 2023-12-28
CN116917881A (zh) 2023-10-20

Similar Documents

Publication Publication Date Title
Chen et al. A Blockchain‐Based Medical Data Sharing Mechanism with Attribute‐Based Access Control and Privacy Protection
Alonso et al. Proposing new blockchain challenges in ehealth
US20230009198A1 (en) Query generation for collaborative datasets
AU2017282656B2 (en) Collaborative dataset consolidation via distributed computer networks
EP2241986B1 (en) Privacy and confidentiality preserving schema mapping repository for mapping reuse
US20170041298A1 (en) System for accessing data
Huang et al. FSSR: Fine-grained EHRs sharing via similarity-based recommendation in cloud-assisted eHealthcare system
Kuo et al. Design and construction of a big data analytics framework for health applications
Misbhauddin et al. MedAccess: a scalable architecture for blockchain-based health record management
Chen et al. Secure search for encrypted personal health records from big data NoSQL databases in cloud
Chrimes et al. Towards a real-time big data analytics platform for health applications
Damiani et al. Metadata management in outsourced encrypted databases
Haack et al. Computing the diameter of the space of maximum parsimony reconciliations in the duplication-transfer-loss model
Shin et al. Secured e-health data retrieval in DaaS and Big Data
Hu et al. A semantic privacy-preserving model for data sharing and integration
Agoun et al. Access control based on entity matching for secure data sharing
WO2022112624A1 (es) Sistema y método de gestión para una arquitectura de base de datos multimodelo distribuida
Lebre et al. Decentralizing the storage of a DICOM compliant PACS
Karapiperis et al. FEMRL: A framework for large-scale privacy-preserving linkage of patients’ electronic health records
Kaniovskyi et al. A semantic cloud infrastructure for data-intensive medical research
Sony et al. An intuitionistic fuzzy-based intelligent system for semantic interoperability and privacy preservation in healthcare systems
Sindhu et al. Handling Complex Heterogeneous Healthcare Big Data
Alamri et al. Secure sharing of health data over cloud
Lebre et al. An Efficient and Reliable Architecture for Distributing Medical Imaging Data
Divyashree et al. A scoping review of data storage and interoperability in blockchain based electronic health record’s (EHR)

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21724345

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 18253715

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 202180079847.1

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021724345

Country of ref document: EP

Effective date: 20230627