PHR – Personal Health Record – is a mechanism to access a longitudinal view of a patient’s health history and be able to use it for different purposes. It is a component of the health stack:
It relies on two building blocks – (a) registries, to know the source of the data; and (b) health identifier, to know whom the data belongs to. Separating out the building blocks with each serving singular functions helps design a more scalable and sustainable system. We follow certain principles for both of these building blocks:
1. Registries are master databases with information about different entities in the healthcare ecosystem, for example, of hospitals, doctors, care beneficiaries, etc. There should be checks and balances built to ensure correctness of data (such as digital signatures, audit trails, etc.), and this information should be made accessible for different use cases (through open APIs, and consent). Opening access to this information will have a positive effect of increased demand, thus improving quality and leading to convergence towards singular sources.
2. Health identifier is a mechanism to integrate a patient’s health records. This identifier should incorporate the following features:
- The identifier need not be unique. This means that a patient should have the ability to create multiple health identifiers for different health records – think of different digital folders for mental health cases and cancer cases (a common practice in the physical world).
- The power to unify health records should lie with the patient. In the physical world, this would translate to the patient having the right to either keep two folders or merge them into one. The same should be allowed digitally.
- Patients should be allowed to use any identifier to verify themselves. However, since we are creating an electronic system of health records, it is important that these be digitally verifiable – such as mobile number, email ID or Aadhaar.
3. Electronic consent, as specified by MeitY, is a mechanism to give consent electronically in a manner that follows the ORGANS Principles – Open, Revocable, Granular, Auditable, Notifiable, Secure.
_____________________________________________________________________
With these building blocks in place, we come to features of the PHR architecture:
1. Federated – instead of having a centralised repository of all health records, we propose a federated framework where data resides at the source of generation. This has many benefits – (i) ease of operations, as data is not stored with a single entity (ii) lower costs, as no additional repository is being built (iii) better security, as data is stored at different nodes; and (iv) patient empowerment, as data is being shared directly with the patient.
2. Schema level standardisation – we believe that only standardising the schema without enforcing codification standards (which require a significant behavioural shift) should be sufficient for a number of use cases. Since this standardisation is at an IT systems level, it only requires a one-time mapping and does not require any change in clinical workflows.
3. Health data access fiduciaries – these would be entities that would route the consent and data requests between information users and information providers. In doing so, they would play the role of privacy protection, consent management and user education.
4. Health data vault – this is an option for the patient to store his/ her records in a personal storage space. While most hospitals that capture data continue to store it for a long period of time, an individual might still choose to store this information separately (for long-term access, trust-deficit between patient and provider, etc.). In such a case, the patient can request a copy of the record to be pushed to his/her health data vault.
_____________________________________________________________________
Proposed architecture:
Workflow:
Patient goes to a healthcare provider. At the time of issuance:
Option 1: patient shares mobile number/ email id/ aadhaar no.
1. Provider authenticates user using one of the digital identifiers
2. (a) Provider sends a link to patient for downloading the report. Patient can later link these records with his/ her HDAF; or
2. (b) Patient can sign up with HDAF and search for provider to link records
Option 2: patient shares HDAF ID
1. Provider links patient records to the HDAF
Post linkage, patient can approve requests from data consumers through the HDAF for different use cases.
_____________________________________________________________________
We believe that building PHR as a public good will enable interesting use cases to come to life, that would together improve the healthcare ecosystem. While we will continue our quest for these, we would love to receive feedback on our thinking! If you work in this space and have comments, or would like to understand how this could help your product, please drop me a line at [email protected].