WO2024171219A1

WO2024171219A1 - Secure and interoperable federated blockchain health record ecosystem

Info

Publication number: WO2024171219A1
Application number: PCT/IN2024/050147
Authority: WO
Inventors: Prabhu Rajagopal; Vinesh RAJA VIJAYARAJ; Anirudh Varna; Vijayaraja Rathinasamy
Original assignee: Indian Institute of Technology Madras
Current assignee: Indian Institute of Technology Madras
Priority date: 2023-02-14
Filing date: 2024-02-14
Publication date: 2024-08-22
Anticipated expiration: 2025-08-14

Abstract

The present invention discloses a patient-centric federated blockchain system for managing health records which also achieves interoperability between multiple health institutions and provides data privacy and security to the patients. The system helps to build a Personal Health Trajectory of a patient, which contains all the health records on a blockchain. Every patient registered on the system will be storing data on a personal blockchain, referred to as 'subchains', and these subchains are indexed on a router blockchain, referred to as the 'mainchain' layer, which is maintained by all the institutions on the system. Any institution can add diagnosis data to a patient's blockchain on approval from the patient. Data from various institutions will be added to the patient's subchain. The system also caters to verification authorities (like insurance agencies) by providing them with a verification mechanism for a patient's medical data, without loss in security and transparency.

Description

Secure and interoperable federated blockchain health record ecosystem

The field of invention generally relates to the field of global health record management systems. More specifically, it relates to a system and method for using federated blockchain systems because of their security and interoperability, the way of storing information in Electronic Health Record and their ability to maintain data in a patient-centric manner.

An Electronic Health Record (EHR) is a record of all the medical data of a person stored in one place. The current systems result in numerous issues even when they are built in a patient-centric manner. Currently, existing systems do not succeed in achieving the following features:

Interoperability: EHR systems in different institutions often have difficulty communicating with each other, which can make it difficult for multiple healthcare institutions to access and share patient data.

Data security: EHR systems are vulnerable to cyber-attacks and data breaches since existing systems are either outdated or contain single points of failure (SPOF), which can compromise patient privacy and put sensitive medical information at risk.

Lack of standardization: There is a lack of standardization in the way that EHR systems are designed, implemented and maintained, which can make it difficult for healthcare providers to share and access data across different systems.

Overall, while EHRs have the potential to improve the quality and efficiency of healthcare, there are a number of challenges that need to be addressed.

EHR systems mentioned in the prior art use institute-centric systems, and do not provide direct access to the patients to their health records. Also, other proposals which involve blockchain databases involve regular blockchain systems maintained by the institutes, which is computationally infeasible for large populations.

Thus, in light of the above discussion, it is implied that there is a need for a system and method, which is reliable and does not suffer from the problems discussed above.

Object of Invention

The principal object of this invention is to provide a secured interoperable electronic health record management system using federated blockchain.

A further object of the invention is to provide a system and method for a health record management system which allows all organizations relating to healthcare data to operate without loss in data privacy and security by permissioned blockchain.

Another object of the invention is to make use of ‘blockchain of blockchains’ architecture to provide a Federated Health Architecture system, which caters to various organizations.

Yet another objective is to provide an interoperability of organization with a patient-centric approach.

Yet another objective is to provide an attribute-based access control to enable data sharing and interoperability of organizations.

Yet another objective is to provide the Patients the control of access to their records, where such control is capable of being withdrawn at the Patient’s choice.

This invention is illustrated in the accompanying drawings, throughout which, like reference letters indicate corresponding parts in the various figures.

The embodiments herein will be better understood from the following description with reference to the drawings, in which:

Fig. 1A

depicts/illustrates a network architecture comprising a blockchain of blockchains in a federated service depicting the working of a blockchain of blockchains architecture in a two-layer consortium blockchain system, in accordance with an embodiment;

Fig. 1B

depicts/ illustrates a Smart Contract and a Chaincode representing on the network, in accordance with an embodiment;

Fig. 2

depicts/ illustrates a transaction flow demonstrating multiple function calls to book an appointment with a health institution, in accordance with an embodiment;

Fig. 3

depicts/ illustrates a method for a flow chart depicting identity creation to consultation, explaining overall flow of all functions and conditions involved from Identity Creation to a stage of booking an appointment, in accordance with an embodiment;

Fig. 4

depicts/ illustrates a method for a flow chart depicting contract execution, from admin creation to Consultation, explaining contracts used to create an admin until initiation of generating a Consultation Log (diagnosis inference / prescription), in accordance with an embodiment;

Fig. 5

depicts/ illustrates a method for a flow chart depicting Deletion Flow of Entities and actions for deleting a particular entity from the system and removing all their data from the blockchain., in accordance with an embodiment; and

Fig. 6

depicts/ illustrates the network architecture for a Federated Health Record Ecosystem describing involved parties and their functionality within the system, in accordance with an embodiment.

Statement of Invention

The present invention discloses a system and method for a federated blockchain EHR management system. The invention comprises a decentralized system for storing and managing patient health data. The system is a collection of federated patient blockchains (referred to as ‘subchain’ from hereon) which are collected together for a main blockchain (referred to as ‘mainchain’ from hereon). The patient data comprises at least one of basic personal and medical information, test results, treatment plans, and insurance information, among others.

One key advantage of using blockchains for EHRs is that it would enable healthcare providers to access and share patient data in a secure and decentralized manner, by creating a personal health blockchain for each patient, which is used by multiple healthcare institutions in a federated manner. These personal blockchains will be linked together on a bigger ‘main blockchain’ which would help institutions to access required healthcare data with permission, without loss of privacy and data security. This improves the quality and efficiency of patient care, as it would allow healthcare providers to access a more comprehensive view of a patient's health history.

Additionally, the proposed system enables patients to own and control over their own health data, as they would be able to grant and revoke access to their EHRs, to health institutions, and doctors as they see fit. This helps improve patient privacy and empowers individuals to take a more active role in managing their own health. Since the system is a collection of federated patient blockchains (referred to as ‘subchain’ from hereon) which are collected together for a main blockchain (referred to as ‘mainchain’ from hereon), researchers and analysts can make use of the required data without loss in privacy or confidentiality of the patient data.

The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and/or detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

The invention uses a ‘blockchain of blockchains’ network architecture to create a patient-centric federated health record management system. Each patient will be maintaining a blockchain for storing their patient health data, which is indexed to a particular institution or organization based on their recent diagnosis, called a subchain. A ‘router’ or main blockchain called mainchain will be maintained by the organizations, which helps the organizations keep track of patients and their diagnoses at the organization. Further, any operation to be conducted on the patient health data by organizations/individuals other than the patient must be approved by the patient. The organizations will be running ‘nodes’ for maintaining the router blockchain or mainchain. Patients will be able to access their records through any user device.

depicts/illustrates a network architecture 100 comprising a blockchain of blockchains in a federated health record management system depicting the working of a blockchain of blockchains architecture in a two-layer consortium blockchain system, in accordance with an embodiment.

The electronic health record (EHR) management system is also called as EHR system hereinafter.

The network architecture 100 comprises: a mainchain layer 102 comprising a main blockchain layer, a subchain layer 104 comprising patient blockchains, a storage layer 106 configured to store one or more health data of a patient, and a user interface layer 108 enabling easy access and use of the EHR system.

The mainchain layer 102 is also called as mainchain 102, and the subchain layer 104 is also called as subchain 104 hereinafter.

In an embodiment, any number of end user devices can access the EHR system. Further, any user device will be able to operate with the EHR system, which enables communication through multiple provided API endpoints. Advantageously, patients, hospitals and doctors can access the patient’s health records through any user device which can connect to the EHR system.

The mainchain 102 and the subchain 104 are built using different frameworks. The use of two blockchains by blockchain layering enables easier client performance, lesser load on client devices and better performance on devices with lower processing power. Further, all blockchain functions are handled through two different layers for processing the transactions and execution. This reduces the computational load on the client devices on the application layer. This helps in deploying these systems across different geographies and user-bases.

In an embodiment, the mainchain layer 102 comprises a router blockchain, referred to as the mainchain 102. The mainchain layer 102 is a blockchain which comprises of transactions which store data of the location and route for the patient’s blockchain or subchain layer 104.

In an embodiment, the mainchain layer 102 comprises of a different set of nodes, where each node represents an institution/organization. Further, access control will be based on the institution’s organization of the latest transaction on a subchain 104.

In an embodiment, the mainchain layer 102 is organized as a DAG (Directed Acyclic Graph) which comprises of vertices and edges in a chronological order. Vertices represent different subchain layers’ 102 latest transactions, while edges represent the proofs for the transaction. This network architecture 100 is helpful for creating an interoperable system of health records which is also patient-centric.

In an embodiment, nodes are required to maintain any blockchain to maintain a distributed database. Here, the mainchain layer 102 and subchain layer 104 comprise different network level architectures since the parties involved need to have different abilities.

In an embodiment, the mainchain layer 102 nodes comprise healthcare institutions which work in a federated manner amongst multiple patients. Each hospital represents a node on the mainchain layer 102, with specific hardware requirements, and will trigger smart contracts for various functionalities.

In an embodiment, in the subchain layer 104, the patient is the leader node, and also acts as the validator node, since the subchain layer 104 comprises patient data. The nodes in the subchain layer 104 hence comprise at least one of: nodes of the hospitals involved, and the patient’s device. The patient can be a functional node depending on the patient’s user device specifications and willingness to participate as a node in the blockchain. Various smart contracts to be executed for various operations will be executed by the hospital's nodes, with the approval of the patient.

In an embodiment, Smart contract execution and users are managed different layers, namely the mainchain 102 manages smart contract execution and subchain 104 manages users. Hence, the system achieves better transaction processing speed due to two-layered blockchain architecture.

The transactions are routed from the subchain 104 to the mainchain layer 102 for executing the smart contracts. The second layer is dynamic, and consists of various load-managing functionalities, which help certain services to be increased in user allocation, based on the demand. This provides better transaction finality and processing times.

In an embodiment, the Subchain Layer 104 comprises a Hyperledger Fabric structure. The Hyperledger Fabric is an open-source enterprise-grade, permissioned distributed ledger Technology (DLT) platform, designed for enterprise contexts. The Hyperledger Fabric supports distributed ledger solutions on permissioned networks for a wide range of industries , which provides attribute-based access control (ABAC). This is advantageous in data sharing, and interoperability of organizations. Hyperledger Fabric is an open-source blockchain platform that is designed to support the development of modular and customizable enterprise blockchain applications. It is one of several blockchain platforms that could potentially be used to create electronic health record (EHR) systems.

Its modular architecture maximizes the confidentiality, resilience, and flexibility of blockchain solutions.

Advantageously, using the Hyperledger fabric for the subchain 104 enables the following features or advantages:

a) Participants must be identifiable and should be non-duplicable.

b) Networks need to be permissioned

c) High transaction throughput

d) Low latency of transaction confirmation

e) Privacy and confidentiality of the transactions and data pertaining to business transactions

Hyperledger Fabric fulfills all the above requirements and is used as the framework for building the patient subchains 104 which is a federated blockchain where multiple health institutions propose transactions for variable operations.

The technical advantages of using Hyperledger Fabric in subchains 104 is the enablement of modular architecture, permissioned membership, performance maintains with scale, data on a need-to-know basis (Channels), and rich API model for all operations.

In an embodiment, the storage layer 106 is configured to store all patient health data on off-chain storage systems, since storing heavy data on a blockchain reduces the speed of the blockchain. Further, access to various elements in storage are managed by the blockchain nodes and smart contracts.

In an embodiment, the storage layer 106 comprises at least one of ledgers, state databases, FTP servers, Anonymized databases and identity registries.

Advantageously, since databases in the storage layer 106 are accessed only through the subchain 104, there is improved security due to blockchain-managed data. Additionally, since the storage layer 106 is managed and invoked only through the blockchain layer, thus inhibiting direct access to the database by any external user, the security of medical data is significantly improved.

Further, since medical records recorded through transactions are indexed on the subchain 104, this helps in auditing of the medical records and data created by different nodes.

In an embodiment, the user interface layer 108 is configured to enable users to access the system through one or more external platforms by using user devices.

The user interface layer 108 comprises an application layer communicating directly with the subchain layer 106. The user interface layer 108 comprises at least one software client comprising at least one of web/mobile clients, API servers, and aggregators. The user interface layer 108 also comprises at least one hardware client comprising at least one of medical devices, and imaging services.

Advantageously, since there is direct hardware interfacing at the application layer, faster data collection and indexing is achieved. Further, since medical devices are directly interacting with the blockchain layer, the transaction processing and executing speed are improved and, the data is recorded at the point of data creation, on-stop data collection, and better for collecting medical data directly from medical devices and can be directly indexed with the patient’s credentials.

In an embodiment, the system comprises a federated blockchain system which provides a Unified Personal Health Record for the patients with interoperability. Advantageously, the system when deployed across multiple hospitals and healthcare service providers, creates a federated ecosystem of all healthcare services, which effectively leads to the creation of a single unified data platform for all medical data and services.

This results in the creation of a Unified Personal Health Record (PHR) from all service providers for the patients, which is interoperable across multiple services.

Advantageously, the federated blockchain system enables easy data sharing between entities with proof of sharing, and without loss of privacy.

Medical records are recorded on the ledger, and channels can be created between multiple institutions which help to exchange data between two entities securely and create a record of the data being shared, without loss in privacy.

In an embodiment, the structure of the EHR system is explained as follows. The patient’s EHR will be updated by multiple health institutions to create a Personal Health Trajectory, which is an aggregate of all the health records of a patient from conception. The communication between the mainchain layer 102 and the subchain layer 104 is done by using connector REST APIs to which certain nodes have access. The subchain layer 104 communications are done by using Hyperledger Fabric’s transaction flow, while the mainchain 102 is handled using REST APIs with keys available only to authorized institutions.

In an embodiment, the subchain and mainchain consensus mechanisms is explained as follows.

The patient subchain 104 doesn’t require consensus of multiple nodes since any transaction is to be approved by the patient and the institution proposing the transaction. The transaction between one institution and the patient will be agreed upon by the two dealing parties. Hence, the subchain 104 is a consortium of multiple organizations, which each have a node in the subchain 104. Each organization in the subchain 104 is represented by a node.

The mainchain 102 is a huge set of transactions, with at least one transaction per patient, which is the registration of a patient. The transactions in the mainchain 102 comprise details of the registration and a router for the institutions to query the mainchain 102. The patients do not interact directly with the mainchain 102 since they are concerned with only their subchain 104.

In an embodiment, the institutions deal with the mainchain 102 as well as with the patient subchains 104, since they are involved with both the blockchain layers, for example by adding new health records to the subchains, and querying for and adding patients on the mainchain layer.

In an embodiment, the Access control on the mainchain layer is explained as follows.

In an embodiment, health organizations will be allowed to join the mainchain 104 by verification of their certification as a health institution by the government of the country and will be allowed inside the network.

In an embodiment, the four operations: CRUD (Create, Read, Update, Delete) are managed as follows.

In an embodiment, considering two health institutions H1 and H2, H1 can create a new record (transaction), and append it to the subchain 104 of a patient in that institution, and can also create an access URL and key to the same, which will be accessible to the patient as well as to H1. Similarly, H2 can create a record whose access keys will be available only to H2.

In an embodiment, a record created by H1 can be read by H2 only after the patient grants access to H2, and vice versa.

In an embodiment, a record R1 created by H1 can be updated by H1 and H1 only. H2 can only append to H1 if the patient visits H2 after H1.

In an embodiment, a record R1 created by H1 can be deleted by H1 and H1 only. H2 does not have access to this operation.

In addition to the above-mentioned mechanism, the patient also needs to grant access to the institution to perform the operation. These operations happen through REST APIs.

In an embodiment, the storage mechanism is explained as follows.

In an embodiment, the patient’s Electronic Health Record comprises files which are larger than the capacity of a blockchain, since the blockchain would grow up in size very quickly, and transaction throughput and query would become slower. Hence, an off-chain storage model is used to store all medical data.

In an embodiment, each transaction for adding a health record on the patient subchain 104 will contain a link (URI) to files of the diagnosis, and a passkey for the opening same, which will be available to nodes participating in the patient’s subchain 104. The access keys to the URI will only be accessed and manipulated by institutions within the patient’s subchain 104.

depicts/illustrates a smart contract 110 and a chaincode 112 represented on the network, in accordance with an embodiment.

In an embodiment, the smart contract 110 is a digital contract that comprises of business logic written for the corresponding blockchain. It has details and permissions written in code that require an exact sequence of events to occur and trigger the execution of the Smart Contract. This smart contract 110 is then packaged into a chaincode 112 which is then deployed onto the blockchain Network. A chaincode 112 defines the transaction logic that controls the lifecycle of a business object contained in the world state. Smart contracts 110 comprise Business Logic whereas a chaincode 112 is a technical container of a group of related Smart Contracts.

In , ‘Register()’ and ‘BookAppointment()’ are the functions inside a smart contract 110 that handles the business logic of the private blockchain network. This smart contract 110 is then grouped inside a container or chaincode 122 with other related smart contracts that handle the transaction flow to maintain the world state of the Blockchain.

depicts/illustrates a transaction flow 200 demonstrating multiple function calls to book an appointment with a health institution, in accordance with an embodiment.

In an embodiment, an explanation of the Transaction flow 200 is initiated from the Patient node P 204 - for booking an appointment or a consultation.

In an embodiment, a Patient P 204 can be classified as the Client device that belongs to Organization1 202/1. Peer P1 206 can be classified as the peer device that can endorse or commit the transaction for Organization1 202/1. Doctor D 208 can be classified as the client device that belongs to Organization2 202/2. Peer P2 210 can be classified as the peer device that can endorse or commit the transaction for Organization2 202/2.

In an embodiment, the Transaction flow 200 for booking an appointment follows the following four steps.

A transaction to Book an Appointment is proposed by the Patient P 204 of Organization1 202/1 and a few required parameters are passed. This proposed transaction is sent to peer P1 206 and peer P2 210, of organization1 202/1 and organization2 202/2, respectively.

In this step, the transaction is verified by the peer P1 206 and peer P2 210 for transaction proposal format. Further, to avoid replay attacks P1 206 and peer P2 210 check if the transaction is being submitted in the past, and also check if the submitter is authorized to perform the proposed operation.

After all the checks P1 206 and peer P2 210 execute the smart contract against the current state database to produce a transaction proposal. Finally, the ‘Proposal Response’ is sent back to the Submitter.

Again, the Patient P 204 node will inspect the proposal response before submitting or broadcasting the transaction to the Ordering Service.

The Ordering Service doesn’t inspect the entire content of the Appointment Booking transaction, it simply receives transactions, orders them, and creates blocks of transactions per channel. These blocks of transactions are “delivered” to all the peers on the channel. The transactions within the blocks are validated to ensure the endorsement policy is fulfilled. Transactions in the block are tagged as valid or invalid. Each peer appends the block to the channel’s chain, and for each valid transaction, the write sets are committed to a current state database. An event is emitted by each peer to notify the client application that the transaction (invocation) has been immutably appended to the chain, as well as notification of whether the transaction was validated or invalidated.

illustrates a method depicting a flow chart 300 depicting identity creation to consultation, explaining overall flow of all functions and conditions involved from Identity Creation to a stage of booking an appointment, in accordance with an embodiment.

The method begins with registering an admin user for each organization, as depicted at step 302. Subsequently, the method 300 discloses creating at least one patient identity and doctor identity by respective admin identity, as depicted at step 304. Thereafter, the method 300 discloses booking an appointment for a patient through their patient identity, as depicted at step 306. Subsequently, the method 300 discloses requesting access to patient health data, by the doctor identity, as depicted at step 308. Thereafter, the method 300 discloses allowing access to the patient health data in case of receiving patient approval, as depicted at step 310.

illustrates a method for a flow chart 400 depicting contract execution, from admin creation to Consultation, explaining contracts used to create an admin until initiation of generating a Consultation Log (diagnosis inference / prescription), in accordance with an embodiment.

The method begins with loading a network configuration file, as depicted at step 402. Subsequently, the method 400 discloses building a certificating Authority (CA) client and a file system wallet to register a first admin, as depicted at step 404. Thereafter, the method 400 discloses building a certificating Authority (CA) client and a file system wallet to register a second admin, as depicted at step 406. Subsequently, the method 400 discloses enabling the first and second admin to register a patient and doctor respectively, as depicted at step 408. Thereafter, the method 400 discloses creating and recording consultation logs after booking and completing an appointment, as depicted at step 410.

In an embodiment, the Hyperledger Fabric Admin is explained as follows.

In an embodiment, in the Hyperledger Fabric Architecture, the Certificate Authority (CA) is used to register Admin, Peer, Orderer, and Client for an Organization. The Certificate Authority registers identities, issues Enrollment Certificates (E-Certs) to the users, and also renews or revokes the certificate in a few cases. Since the hyperledger fabric architecture uses a TLS certificate, a TLS CA is used to issue TLS certificates. Before using the CA Client, it is important to acquire the signing certificate for the CA’s TLS certificate. This certificate will be used to verify all the TLS certificates. The TLS CA server starts with a bootstrap identity (ADMIN) with all the admin privileges. Further, one of the key abilities of the admin is to create new identities.

In an embodiment, the user registration is explained as follows.

The hyperledger fabric admin is registered for each organization. Once admin registration is completed, the admin identity can issue more identities for the respective organization. Further, an Admin for organizations 202/1 and 202/2 is created. This same identity will be used to issue identities. For Organization1 202/1, Patient Identity is being created, and similarly, in organization2 202/2 Doctor identity is created using the admin of respective organizations.

In an embodiment, the User Registration with details is explained as follows. A register() function will register ‘patient’ and ‘doctor’ to the blockchain network. Here, the writeData() function is used by the patient to upload basic health data to the subchain ledger. This function can be accessed only by the registered members.

In an embodiment, the creation flow begins with registering an Admin User for each organization. As an example, users patient1843 and doctor64 were registered for each organization using the Admin Identity of the respective organization. Thereafter, a function for Book Appointment for Users with an appointmentID is executed. Further, a function for Send Request to Access Data and If ‘Approved’ update the Doctor Identity (E-Cert) with PatientID is completed.

Once approved, the Doctor can read the patient’s previous health data and consult accordingly.

The Creation flow can be summarized as Create Admin → Register Client (Users) → Book Appointment → Request Access to Data → ReadData → Consultancy.

In an embodiment, the Access Control List (ACL) is explained as follows. The network architecture 100 uses Access Control Lists (ACLs) to manage access to resources by associating a policy with a resource. A user interacts with fabric by targeting a user chaincode or system chaincode that is called in the background. These endpoints are called “Resources”, on which access control should be exercised. The network architecture 100 contains a number of default ACLs like configtx.yaml. The ACL works on access control at the administration Level.

Further, the ACLs are formatted as a key-value pair comprising of a resource function name followed by a string. Further ACLs define that access to peer/Propose and event/Block resources is restricted to identities satisfying the policy defined at the canonical path of /Channel/Application/Writers and /Channel/Application/Readers, respectively.

Similarly, the network architecture fabric provides Access Control on the Chaincode level through Attribute-based access control (ABAC).

In an embodiment, the Attribute-Based Access Control is explained as follows.

Access control decisions can be made by Chaincode (and by the Hyperledger Fabric Runtime) based on an entity's attributes. This is called Attribute-based Access Control (ABAC). To make this possible, an identity’s enrollment Certificate (E-cert) may contain one or more attribute names and values. The chaincode then extracts an attribute’s value to make an access control decision. For Example: In the smart contract instance we have 2 organizations. Org1 belongs to a patient and Org2 belongs to a doctor from a clinic.

There may be particularly two cases in this scenario.

Case 1: The Doctor requests Access to the Patient’s data and the patient approves the request.

Case 2: The Doctor requests access to the patient’s data and the patient declines the request.

In the first case, the doctor identity from Org2 that got access to read the data will be updated with the ID of the Patient that gave the access. Further, the doctor identity has a new attribute where the patient identity ‘patient1843’ gets mapped.i.e { name: 'doctor64', value: 'patient1843' }. Here, ‘doctor64’ is a client from org2, and 'patient1843' is the patient identity. This chaincode then extracts the value of the attribute and makes the access control decision.

In the second case, the doctor's identity didn’t get access to the patient’s data hence, when the doctor tries to access the data it throws an Error: “You have No Access to the Data”. Hence, Attribute-based access control is achieved.

illustrates a method for a flow chart depicting Deletion Flow of Entities and actions for deleting a particular entity from the system and removing all their data from the blockchain, in accordance with an embodiment. method begins with X, as depicted at step 502. Subsequently, the method 500 discloses Deleting at least one consultation log, a;;;s depicted at step 504. Thereafter, the method 500 discloses Deleting at least one request to access data, as depicted at step 506. Subsequently, the method 500 discloses Deleting at least one patient identity, as depicted at step 508. Thereafter, the method 500 discloses Deleting at least one doctor identity, as depicted at step 510.

In an embodiment, the deletion flow is explained as follows. The flow comprises the creation of all the entities of each organization and a few functions performed by each of these entities. The deletion flow tries to achieve the initial state of the ledger, which means deleting the actions performed by the entities and also the identities from the World State and reaching the initial stage of the world state before the ‘creation’ flow was started. The deleteState() method of the Fabric SDK is used to delete the entities and the actions performed by them.

The Consultation log, Request, and Appointment performed by the User of Org2 and Org1 are deleted. Finally, the Identities of the Users from Org2 and Org1 are deleted. The Initial State is achieved once all the actions and identities are deleted. The Deletion Flow can be summarized as: Delete Consultation Log → Delete the Request to access Data → Delete Appointment → Delete Patient identity → Delete Doctor Identity

In an embodiment, the entities that are deleting the actions are mentioned as follows: the Consultation log is being deleted by the ‘Doctor’ Entity. This deletion can only be performed by the ‘Doctor’ and ‘Admin’ if the admin has the access to perform the deletion action. The ‘Patient’ entity is deleting the request that is being sent by the ‘Doctor’. This action can only be performed by the Patient. The ‘Doctor’ and ‘Patient’ can delete the appointment for cancellation/rescheduling purposes.

The Patient's Identity can be deleted by the ‘Patient’ themselves. This deletion action can be performed by the ‘Admin’ or ‘Doctor’ given that they have the required permission from the ‘Patient’. The Doctor’s identity can be deleted by the ‘Doctor’ themselves. The ‘Admin’ can also delete the ‘Doctor’ identity if it has the required permission.

illustrates the network architecture for a Federated Health Record Ecosystem describing involved parties and their functionality within the system, in accordance with an embodiment. The role and responsibility of each component is detailed, in accordance with an embodiment.

In an embodiment, the federated health record network architecture comprises a pattern in enterprise architecture that allows interoperability and information sharing between semi-autonomous de-centrally organized lines of business (LOBs), information technology syste`ms and applications. The proposed system of using a blockchain of blockchains is helpful in creating a federated health records architecture as shown in the diagram below.

In an embodiment, the health data ecosystem comprises of multiple entities with exclusive abilities and functions, for which the proposed system caters to. Using blockchains involves smart contracts, which perform access management and user-client request handling without having a regulatory organization. Also, the federation of organizations on the subchain, allows for sharing of information between organizations without any organization having to take control over the transmission.

illustrates the network architecture for a Federated Health Record Ecosystem describing involved parties and their functionality within the system, in accordance with an embodiment.

In an embodiment, the electronic health record management system comprises multiple parties which can exchange resources and transact various resources, without loss of privacy and security has been laid out in the above diagram which details the parties involved in the system.

In an embodiment, the EHR system comprises at least one gateway 602/1, at least one health locker 604/1, 604/2, at least one repository 606/1-4, at least one Health Data Consent Managers (HDCM) 608/1-2, and users 610.

In an embodiment, the system also comprises one or more Health Information Providers (HIP) and Health Information Users (HIU).

In an embodiment, the gateway 602/1 or Health Information Gateway is the hub that mediates and connects Consent Manager(s) 608, Health Repository Providers and HIUs in the network. Its primary job is to allow for discovery and routing in the network.

In an embodiment, the at least one health locker 604/1, comprise applications and storage services which allow users to create an account, upload documents and view on demand, create transfer mechanisms to send health information to HIUs on request, and others.

In an embodiment, the at least one repository 606/1-4 is the connector or bridge through which any HIU or HIP can connect to the network.

In an embodiment, the at least one Health Data Consent Managers (HDCM) 608/1-2 are configured to create or discover existing ABDM ABHA Number, manage patient linkages to providers, manage consent for access to health information, discover patient information, and monitor information exchange between HIP and HIU.

In an embodiment, the system comprises various registries such as databases containing certifying information, standard rules, and other regulations, which are required for the functioning of the network. The registries may comprise at least one of Health Facility registry (HFR), Doctor or practitioner registry, and HDCM and Health Repository Provider (HPR) Registry.

In an embodiment, the Health Information Providers (HIP) provides the following services. Healthcare institutions produce data in the form of health records of the patients, which is of great interest to many organizations (insurance providers, researchers, etc.). To share this data without loss of privacy and security, the proposed system is used, and hence the institutions act as healthcare data providers.

In an embodiment, the Health Information User (HIU) provides various services. Institutions which make use of the health data for various operations are termed as users here. The data created by the HIPs will be shared with these organizations for multiple purposes. Multiple services (searching for a patient within the repository, requesting permission to view data from institutions) are to be built for the same.

Further, the system comprises multiple user applications with user interfaces for various organizations to interact with the ecosystem. One or more web and mobile based applications can be built on the system and may communicate with the network with the help of APIs.

The proposed system builds the following ecosystem in the following way:

HDCM 608: Blockchain networks manage consent by signing view authorizing transactions, which has to be signed by a patient in this case. The signing of the authority provision is also recorded as a transaction in the patient’s blockchain, hence it also helps the patient to recognize the flow and exposure of their data.

Health Information Gateway 602: Various APIs called by subchains and mainchain will be handling triggering of various scripts and smart contracts, which in turn handle connection between repositories 606 and HIUs, and also access management.

Registries: the respective government’s registries are used for identity management within the system (SSN in the US, ABHA in India, and so on). The registries will be appended within the mainchain as detailed:

Patient registries: Addition of new patients is a transaction (as has been detailed before) and also one category of transactions, which will be easily queryable. A patient registry is hence formed on the mainchain, along with the government’s own registry being a verification database for the mainchain registry.

HIU and HIP registries: These organizations are added to the network on request, which are verified by the legal regulations of the country. Addition of these HIUs will be categorized and managed by smart contracts on the chain, and the government databases will be used for verification.

Health repository 606: The proposed system is built for interoperability and transparency, and hence connection between the HIUs and HIPs is sufficed.

HIP services: Tokenized data can be shared by the HIP to HIUs based on a request for access by the HIU. This mechanism is handled according to the data regulations and standards mentioned before (HIPAA, GDPR, FHIR, and others).

HIU services: HIUs added on the mainchain can raise requests for viewing data from the databases through various API calls which will trigger smart contracts in return.

Health Locker Services: This service can be handled through a mobile or desktop application which allows users to view, add and update their records on their device.

Each process will be recorded on the patient’s subchain 104, and the first transaction of any patient will be recorded on the router mainchain 102 under the particular institution. The health data verification authority is an institution which requires access to a patient’s data for a business decision (ex: an insurance agency needs access to the patient’s data for granting the insurance to the patient). This is possible through the access request feature as has been detailed before.

The advantages of the current invention with respect to data privacy include providing Transparency, Right to access, Right to rectification, Right to be forgotten, Right to data portability, Right to object: Right to restrict processing, Data security, Data breach notification, and Responsibilities of data processors and controllers

The federated blockchain system solves the issues outlined in general data privacy guidelines, and also abides by health data exchange standards FHIR (Fast Healthcare Interoperability Resources). This is a standard for information modeling, storage, representation and exchange of medical data.

The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the embodiments as described here.

Claims

A system for electronic health record management using blockchains, comprising a network architecture comprising:
a mainchain blockchain layer configured to route mainchain transactions by using at least one mainchain node and invoking at least one smart contract;
a subchain blockchain layer in communication with the mainchain blockchain layer, wherein the at least one subchain layer is configured to route subchain transactions of a patient by using subchain nodes; and
at least one storage layer in communication with at least one of the subchain blockchain layer and mainchain blockchain layer, wherein the at least one storage layer is configured for storing one or more health data related to the patients in one or more storage modules, and wherein a Personal Health Trajectory is created for the patient, based on at least one of the mainchain transactions and the subchain transactions.
The system as claimed in claim 1, wherein the system comprises a user interface layer configured to enable users to access the system through one or more external platforms by using user devices.
The system as claimed in claim 2, wherein the user interface layer comprises an application layer communicating directly with the subchain layer, wherein the user interface layer comprises at least one software client comprising at least one of web/mobile clients, API servers, and aggregators, and wherein the user interface layer comprises at least one hardware client comprising at least one of medical devices, and imaging services.
The system as claimed in claim 1, wherein the mainchain layer is organized as a Directed Acyclic Graph (DAG) comprising vertices and edges in a chronological order, wherein vertices represent different patients’ subchains layers’ latest transactions, and edges represent proofs for each transaction.
The system as claimed in claim 1, wherein the subchain layer is organized in Hyperledger Fabric platform comprising a modular architecture, permissioned membership, and data channels.
The system as claimed in claim 1, wherein the mainchain transactions are configured to store data of at least one of location and route of patients’ subchain, wherein the at least one subchain is indexed to at least one mainchain node, and wherein the subchain transactions are configured to store at least one patient data.
The system as claimed in claim 1, wherein the mainchain node comprises at least one of fabric nodes, local validator nodes and cloud nodes,
wherein the mainchain node is configured to invoke and execute at least one smart contract configured to perform at least one of: access management and user-client request handling, and
wherein the at least one smart contract is executed based on at least one approval from the patient.
The system as claimed in claim 1, wherein the subchain layer comprises at least one of: client nodes, local endorser nodes, cloud nodes, hospital nodes, and patient device nodes, wherein the at least one patient device node is a leader node.
The system as claimed in claim 1, wherein transactions in the subchain layer for adding a health record on at least one of the patients’ blockchains comprise at least one of: a Uniform Resource Identifier (URI) link to health data files, and a passkey for opening the URI link, wherein the URI link and the passkey are accessible by hospital nodes in the patients’ blockchains.
The system as claimed in claim 1, wherein communication between the mainchain layer and the subchain layer is conducted by using a Representational State Transfer (REST) Architecture, by using a Representational State Transfer (REST) Application Programming Interface (API).
The system as claimed in claim 1, wherein the system comprises:
at least one Consent Manager configured for at least one of: recording transactions in the subchain based on patient consent, creating or discovering existing government identity Numbers, managing patient linkages to providers, managing consent for access to health information, discovering patient information, and monitoring information exchange between Health Information Providers (HIP) and Health Information Users (HIU);
at least one Health Information Gateway configured to manage access and triggering of scripts and smart contracts by at least one of: subchain, mainchain, Consent Manager(s) 608, Health Repository Providers and HIUs; and
at least one registry in the storage layer, wherein the mainchain is upended with at least one registry comprising: patient registry, Health Information User (HIU) registry, and Health Information Provider (HIP) registry.
The system as claimed in claim 11, wherein the Health Information Users comprise institutions using the health data, and
wherein the Health Information Providers comprise institutions producing and sharing the health data records of the patient.
The system as claimed in claim 1, wherein the system comprises Health Locker services enabling users to create an account, upload and view data on demand, and provide consent to health data requests, wherein the Health Locker services are managed through a Health Locker application accessible by users.
A method for managing electronic health records using blockchains a network architecture comprising:
routing mainchain transactions on a mainchain blockchain layer by using at least one mainchain node and invoking at least one smart contract;
route subchain transactions of a patient on a subchain blockchain layer in communication with the router blockchain, by using subchain nodes;
storing one or more health data related to the patients in at least one storage layer comprising one or more storage modules; and
creating a Personal Health Trajectory for the patient, based on at least one of the mainchain transactions and the subchain transactions.
The method as claimed in claim 14, comprising:
enabling users to access the system via a user interface layer through one or more external platforms by using user devices; and
configuring the user interface layer with an application layer to communicate directly with the subchain layer.
The method as claimed in claim 14, comprising organizing the mainchain layer as a Directed Acyclic Graph (DAG) comprising vertices and edges in a chronological order, wherein vertices represent different patients’ subchain layers’ latest transactions, and edges represent proofs for each transaction.
The method as claimed in claim 14, comprising organizing the subchain layer in Hyperledger Fabric platform comprising a modular architecture, permissioned membership, and data channels.
The method as claimed in claim 14, comprising:
storing data of at least one of location and route of patients’ subchain in the mainchain transactions;
indexing the at least one subchain to at least one mainchain node; and
storing at least one patient data in the subchain transactions.
The method as claimed in claim 14, comprising:
providing at least one of fabric nodes, local validator nodes and cloud nodes for the mainchain node;
using the mainchain node to invoke and execute at least one smart contract configured to perform at least one of: access management and user-client request handling; and
executing the at least one smart contract based on at least one approval from the patient.
The method as claimed in claim 14, comprising:
providing transactions in the subchain layer for adding a health record on at least one of the patients’ blockchains comprising at least one of: a Uniform Resource Identifier (URI) link to health data files, and a passkey for opening the URI link, wherein the URI link and the passkey are accessible by hospital nodes in the patients’ blockchains.
The method as claimed in claim 14, comprising conducting communication between the mainchain layer and the subchain layer by using a Representational State Transfer (REST) Architecture, by using a Representational State Transfer (REST) Application Programming Interface (API).
The method as claimed in claim 14, comprising:
recording transactions in the subchain based on patient consent, creating or discovering existing government identity Numbers, managing patient linkages to providers, managing consent for access to health information, discovering patient information, and monitoring information exchange between Health Information Providers (HIP) and Health Information Users (HIU), by using at least one Consent Manager;
manage access and triggering of scripts and smart contracts by at least one of: subchain, mainchain, Consent Manager(s) 608, Health Repository Providers and HIUs, by using at least one Health Information Gateway; and
upending the mainchain with at least one registry in the storage layer comprising: patient registry, Health Information User (HIU) registry, and Health Information Provider (HIP) registry.
The method as claimed in claim 14, comprising:
enabling users to create an account, upload and view data on demand, and provide consent to health data requests, by using Health Locker services; and
managing the Health Locker services are through a Health Locker application accessible by users.