Posted on

Technical Standards of the Personal Health Records (PHR) component of the National Health Stack

We have an exciting announcement for you all today!

We are publishing a draft of the technical standards of the Personal Health Records (PHR) component of the National Health Stack (NHS)!

As a refresher, these standards govern the consented sharing of health information between Health Information Providers (HIPs) – like hospitals, pathology labs, and clinics –  and Health Information Users (HIUs) like pharmacies, medical consultants, doctors, and so on. The user’s consent to share their health data is issued via a new entity called a Health Data Consent Manager (HDCM). 

This is a big deal. The problem today is that the electronic health records listed in one app or ecosystem are not easily portable to other systems. There is no common standard that can be used to discover, share, and authenticate data between different networks or ecosystems. This means that the electronic medical records generated by users end up being confined to many different isolated silos, which can result in frustrating and complex experiences for patients wishing to manage data lying across different providers. 

With the PHR system, a user is able to generate a longitudinal view of their health data across providers. The interoperability and security of the PHR architecture allows users to securely discover, share, and manage their health data in a safe, convenient, and universally acceptable manner. For instance, a user could use a HDCM to discover their account at one hospital or diagnostic lab, and then select certain electronic reports to share with a doctor from another hospital or clinic. The flow of data would be safe, and the user would have granular control over who can access their data and for how long. Here is a small demo of the PHR system in action. 

The standards document released today offers a high level description of the architecture and flows that make this possible. You can find version 0.5 of the document embedded below.

Health Information Flows Technical Standards – V 0.5 from ProductNation/iSPIRT.

All the exciting progress we are making on this new digital public infrastructure for healthcare is all thanks to you, the community. We are grateful for your support and look forward to engaging with you further!

The blogpost is co-authored by our volunteers Aaryaman Vir, Saurabh Panjwani and Graphics by Dharmesh BA.

Posted on

NHS Open House Discussion #4: Doctor Registry, Enrollment APIs And PHR

On 13th June, iSPIRT hosted the fourth open house discussion on the National Health Stack (NHS). For anybody unfamiliar with the NHS, here are some introductory blog posts and videos.

In the session, our volunteer Vikram Srinivasan deep dived into the Enrollment APIs of the electronic doctor registry. These APIs are called when a new doctor is being added to the registry, or when a doctor’s information is being uploaded. 

Vikram also spoke about the attestation APIs, which come into play when an attesting institution (such as a state medical council, medical college, or hospital) confirms some data about a doctor. This is crucially important for building trust in the registry and preventing the proliferation of false profiles. With the release of these enrolment and attestation APIs, all the APIs pertaining to the electronic doctor registry are now available here.

After Vikram’s presentation, he and our other volunteer Siddharth Shetty answered some technical questions submitted by the community. Here are some of the questions they fielded:

  • Doctors have multiple identities (from different medical councils), how are these unique IDs handled by the electronic registry?
  • Can anybody access the doctor information in the registry, including phone numbers and photographs of doctors?
  • Who can healthcare companies partner with in the Health Stack Ecosystem?
  • How does the federated network architecture of the PHR system deal with downtimes, incorrect data, and other failure? Is this architecture scalable for a system with 1000s of participants?

As always, these were great questions. You can watch Sid and Vikram answer these questions and walk through their presentations below. Please keep the questions coming by sending them in through this form: https://bit.ly/NHS-QAForm.

If you would like to get involved with Health Stack, we encourage you to watch the recordings of the previous Health Stack open house discussions before reaching out.

Furthermore, if you are interested in the Health Stack and wish to build on top of it or contribute to the working groups being formed, you should reach out to [email protected]

Please note: The fifth open house on PHR Implementation was previously planned for 27th June. This has been postponed to 11:30 am on 4th July due to unavoidable circumstances.

To confirm your participation, continue to register on this form.

Posted on

iSPIRT NHS Open House Session #2: PHR and Doctor Registry

iSPIRT hosted the second open house session on the National Health Stack (NHS). 

In this session, our health stack volunteers dived deeper into the Personal Health Record (PHR) system and also covered the concept of the Electronic Doctor Registry.

In the first part of the session, our volunteer Siddharth Shetty answered technical questions pertaining to the PHR system. These questions, which were all submitted by the community, covered topics ranging from blockchains and zero-knowledge proofs to assisted consent flow for low tech-savvy users. A link to a recording of the session can be found at the end of this post.

In the second half of the session, our volunteer Kiran Anandampillai explained the concept of the doctor registry. The electronic registry system is a mechanism for managing master data about different entities in the healthcare ecosystem. Although some of these entities do appear in existing databases, these legacy systems are often incomplete, outdated, and seldom accessible via APIs. In contrast, the registries in the NHS are intended to capture trusted, non-repudiable data and enable self-maintainability. These registries will also have open APIs and will allow for secure authentication and data sharing. 

In the context of doctors, the electronic doctor registry can be used to:

  • Prove their identity and credentials as doctors
  • Electronically sign documents such as prescriptions, insurance claims, operating theatre notes, and more
  • Streamline workflows such as joining or telehealth application or registering for CME points (Continuing Medical Education points necessary for renewing a doctor’s license)

A recording of the entire session, including a breakdown of the design principles, APIs, and timelines behind the doctor registry, can be found below.

Inquisitive readers are also encouraged to submit their technical questions around the NHS to [email protected].

We will be answering those questions at the start of next week’s open house session, which will begin at 11:30 am on Saturday, 6th June. An invite to that session will be sent out to all participants who sign up at this link: https:// www.bit.ly/NHS-OHD

Although these sessions have so far been focusing on technical features of the NHS, the business and design aspects are also crucially important and will be covered in short order.

The blog post is authored by our volunteer Aaryaman Vir and he can be reached at [email protected].

Posted on

#5 What is the Federated PHR Component of the Health Stack?

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].

Posted on

#2 Federated Personal Health Records – The Quest For Use Cases

Last week we wrote about India’s Health Leapfrog and the role of Health Stack in enabling that (you can read it here). Today, we talk about one component of the National Health Stack – Federated Personal Health Records: its design, the role of policy and potential use cases.

Overview

A federated personal health record refers to an individual’s ability to access and share her longitudinal health history without centralised storage of data. This means that if she has visited different healthcare providers in the past (which is often the case in a real life scenario), she should be able to fetch her records from all these sources, view them and present them when and where needed. Today, this objective is achieved by a paper-based ‘patient file’ which is used when seeking healthcare. However, with increasing adoption of digital infrastructure in the healthcare ecosystem, it should now be possible to do the same electronically. This has many benefits – patients need not remember to carry their files, hospitals can better manage patient data using IT systems, patients can seek remote consultations with complete information, insurance claims can be settled faster, and so on. This post is an attempt to look at the factors that would help make this a reality.

What does it take?

There are fundamentally three steps involved in making a PHR happen:

  1. Capture of information – Even though a large part of health data remains in paper format, records such as diagnostic reports are often generated digitally. Moreover, hospitals have started adopting EMR systems to generate and store clinical records such as discharge summaries electronically. These can act as starting points to build a PHR.
  2. Flow of information- In order to make information flow between different entities, it is important to have the right technical and regulatory framework. On the regulatory front, the Personal Data Protection Bill which was published by MeitY in August last year clearly classifies health records as sensitive personal data, allows individuals to have control over their data, and establishes the right to data portability. On the technical front, the Data Empowerment and Protection Architecture allows individuals to access and share their data using electronic consent and data access fiduciaries. (We are working closely with the National Cancer Grid to pilot this effort in the healthcare domain. A detailed approach along with the technical standards can be found here.)
  3. Use of information – With the technical and regulatory frameworks in place, we are now looking to understand use cases of a PHR. Indeed, a technology becomes meaningless without a true application of it! Especially in the case of PHR, the “build it and they will come” approach has not worked in the past. The world is replete with technology pilots that don’t translate into good health outcomes. We, in iSPIRT,  don’t want to go down this path. Our view is that only pilots that emerge from a clear focus on human-centred design thinking have a chance of success.

Use cases of Personal Health Records

Clinical Decision Making

Description: Patient health records are primarily used by doctors to improve quality of care. Information about past history, prior conditions, diagnoses and medications can significantly alter the treatment prescribed by a medical professional. Today, this information is captured from any paper records that a patient might carry (which are often not complete), with an over-reliance on oral histories – electronic health records can ensure decisions about a patient’s health are made based on complete information. This can prove to be especially beneficial in emergency cases and systemic illnesses.

Problem: The current fee-for-service model of healthcare delivery does not tie patient outcomes to care delivery. Therefore, in the absence of healthcare professionals being penalised for incorrect treatment, it is unclear who would pay for such a service; since patients often do not possess the know-how to realise the importance of health history.

Chronic Disease Management

Description: Chronic conditions such as diabetes, hypertension, cardiovascular diseases, etc. require regular monitoring, strict treatment adherence, lifestyle management and routine follow-ups. Some complex conditions even require second opinions and joint decision-making by a team of doctors. By having access to a patient’s entire health history, services that facilitate remote consultations, follow-ups and improve adherence can be enabled in a more precise manner.

Problem: Services such as treatment adherence or lifestyle management require self-input data by the patient, which might not work with the majority. Other services such as remote consultations can still be achieved through emails or scanned copies of reports. The true value of a PHR is in providing complete information (which might be missed in cases of manual emails/ uploads, especially in chronic cases where the volume and variety of reports are huge) – this too requires the patient to understand its importance.

Insurance

Description: One problem that can be resolved through patient records is incorrect declaration of pre-existing conditions, which causes post-purchase dissonance. Another area of benefit is claims settlement, where instant access to patient records can enable faster and seamless settlement of claims. Both of these can be use cases of a patient’s health records.

Problem: Claim settlement in most cases is based on pre-authorisation and does not depend solely on health records. Information about pre-existing conditions can be obtained from diagnostic tests conducted at the time of purchase. Since alternatives for both exist, it is unclear if these use cases are strong enough to push for a PHR.

Research

Description: Clinical trials often require identifying the right pool of participants for a study and tracking their progress over time. Today, this process is conducted in a closed-door setting, with select healthcare providers taking on the onus of identifying the right set of patients. With electronic health records, identification, as well as monitoring, become frictionless.

Problem: Participants in clinical trials represent a very niche segment of the population. It is unclear how this would expand into a mainstream use of PHR.

Next steps

We are looking for partners to brainstorm for more use cases, build prototypes, test and implement them. If you work or wish to volunteer in the Healthtech domain and are passionate about improving healthcare delivery in India, please reach out to me at [email protected].