Posted on

Bending India’s COVID-19 Curve Through Science & Data-Led Models

Powered by data-led scientific rigor, the India COVID-19 SEIR Model delivers early infection trends for every district in India. The model is geared to help Indians from all walks of life plan life and work decisions around their region’s projected trends over the next 15-30 days. Hospitals can use the model to plan for a surge in demand for resources (beds, ICUs, ventilators); local and national level leaders across private and public sectors can use the model to decide how best to contain the spread of the disease and re-open safely. Epidemiologists can use the model to define how different behavioural and environmental factors affect disease transmission. We introduce 3 use cases in this blog post—the first in a series aimed at promoting scientific and modelling capability. 

Wherever the Coronavirus curve has bent to our will, it has happened on the back of behaviour changes based on data-led insights. Everywhere, simple shifts in behavior—staying at home, wearing masks, sanitizing hands—have been informed by predictive models that showed us the mirror to a dystopian future if we didn’t edit our lifestyles. As a digital public good for a billion Indians, the value of the India COVID-19 SEIR Model lies in its reach and widespread use. 

Until a vaccine is developed, we have to make sense of today’s numbers in the context of all our tomorrows. Individuals, policymakers—and everyone in between—can make smarter decisions if they know the evolving shape of the outbreak, and the India COVID-19 SEIR Model aims to do just that by enabling identification of potential trends and patterns in the next 15-30 days. 

The approach taken by the model provides flexibility and utilisation from both a view of trends as core model adoption/enhancement.

We can all use it to bend India’s curve. That’s the ultimate use case, really — where the model tells us where it’s going and we, in turn, steer it in an entirely other direction. Models will change and that’s a good thing. It means we are responding. The power of models and data science in this particular moment is the ability to assist a very scientific approach to scenario planning during an ongoing pandemic.

We can turn the course of this pandemic and transform what this model tells us, every 24 hours. We are already watching the shape-shifting in real-time. It’s in your hands. Go on, try it. 

Use Cases

User — Individuals & Businesses (PDF format)

User — Scientists (PDF format)

User — Policy-Makers (PDF format)

About the contributors: The blog post is co-authored by our volunteers Yashvi Jaju, Nikhila Natarajan and Srikar V Cintalagiri

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

#4 Reimagining Cancer Care

In the last few months, I have had the opportunity to work closely with the National Cancer Grid – a network of 150+ cancer centres in India – and in the process, better understand the workflows involved in different medical processes and the requirements of medical professionals. I have closely observed care delivery, interviewed cancer patients and oncologists, learnt about current challenges and about initiatives being undertaken by NCG and other organisations to tackle them.

This blog post is an evolved version of an earlier post, where I had talked about the use cases of health data and the implementation of a PHR (Personal Health Record). Of these, I believe that the biggest use of health data will be in improving the quality of care in complex medical cases (either acute like surgical procedures, or chronic like cancer). In this post, I will use cancer care to exemplify this.

Core idea
Let us visualise a specific application for cancer care, with oncologists as its primary users. There are only around 1000 trained oncologists in India, so let’s assume that all of them are users of this application. Let us also assume that clinical data of all patients treated by these oncologists is conveniently accessible through this application (with due privacy and security measures). What will these users do now?

Expert consultation
I attended a Virtual Tumour Board run by the National Cancer Grid – a weekly remote consultation program run on Saturday mornings where teams of doctors voluntarily join to discuss well-documented cases and their potential treatment plans. VTBs are run separately for each speciality (like head & neck tumour, gynaecology, neurology, etc.), which means that it takes up to 4-6 weeks for one’s turn. Doctors usually do not have the luxury of such long waiting periods, and therefore turn to individual consultations which are often not documented, depend on informal connects and are sometimes made with incomplete data. Formalising this process and making it asynchronous can be of huge benefit to all medical professionals.

Care team collaboration

Complex medical procedures often involve a team of doctors and other medical professionals, working responsibly for a given patient. A significant percentage of all deaths due to medical negligence is caused by lack of communication between the care team members. The communication process today is paper-based and unstructured, leading to accidents that can, in fact, be prevented – especially with the growing use of IoT devices and voice-based inputs. (I saw one such application at Narayana Health being used by their ICU teams).

Performance evaluation

Lack of organised data, changing patient care-providers and long feedback loops make it difficult for medical professionals to monitor their performance. Can we empower them with tools to do so? Doctors today lack visibility on the outcome of the treatment given and rely on intuition, experience or techniques tested in developed countries for care delivery. Such a tool would not only help doctors improve their performance, but also improve the trust equation with their patients.

User Experience
There are three crucial elements for enabling a good user experience:

Data input – Most EHR systems require text input to be typed in by doctors. This makes it difficult to use. Other input techniques for automated data transcription like touch, voice, or other innovative methods for data capture will need to be explored. Additionally, interoperability across all systems and devices will be key in enabling access to all data.

Data interpretation – Sorting through a patient’s health records takes up a substantial amount of time of a physician, especially when the data is unstructured. Developing intelligence to sort the relevant records as per the case in question will significantly enhance the user experience of the product.

Safety and Privacy– All solutions should ensure complete privacy of patients. This could mean access controls, electronic consent, digital signatures, digital logs, tools for data anonymisation, etc. it might also be important to perform basic verification of users of the platform.

Value Discovery
The value of the platform will increase as more and more physicians become a part of it. For example, an endocrinologist might need to consult a cardiologist in a case of disease progression, or an ENT specialist might need to consult an oncologist to confirm a diagnosis. More importantly, the platform will also drive innovation, i.e., other use cases can be developed on top of it. For example, the expert opinions mentioned above can also be used for consulting patient remotely, pre-authorising claims, forming medical peer review groups, etc. Similarly, working care groups can also simultaneously enrol staff for upskilling (as practised today in an offline setting), and information about treatment outcomes can help guide better research.

Next steps
We remain on a quest to find use-cases for PHR since we believe technology pilots alone would not be enough to drive its adoption. In that context, we are looking for partners to experiment with this in different healthcare domains. If you are interested, please reach out to me at [email protected]!