NHS Open House on Open Health Services Network

It has been a while since our last blog on this topic. After a break of two weeks, we recently completed the fifth Open House Discussion on the National Health Stack (NHS).

In this session, held from 11:30 am-12 pm on 31st July 2020, our volunteers Sharad Sharma, Siddharth Shetty, and Dr Pramod Varma talked about the Open Health Services Network (OHSN – pronounced ‘ocean’).

As a refresher, the OHSN is the interface which governs the relationship between various market players in the healthcare ecosystem such as tele consult providers, pharmacies, or diagnostic centres on one side, and government or private apps and platforms on the other side. 

It is important for these relationships to be properly streamlined and mapped out for two reasons:

  • To establish baseline standards of care
  • And to provide auditable and transparent processes governing the transfer of data and payments

If these two objectives are met, the healthcare ecosystem as a whole can be made more accessible, secure, and efficient for both users and service providers.

This session focused upon the specific relationship between teleconsultation service providers and end-user apps (EUAs) offering teleconsultation services. 

From the perspective of OSHN, tele consultations involve three players:

  • the EUA (an end-user app selected by the user)
  • an OHSN gateway (a matching agent of sorts)
  • a telehealth service provider (‘provider’)

The process follows these steps:

  1. The user signs up on an EUA
  2. The user searches for doctors/consultations
  3. The OHSN gateway forwards this customer intent to the network of providers
  4. Providers reply with tele consultation offerings
  5. The user selects the preferred offering on the EUA interface
  6. The user then confirms the session with the provider 
  7. The user conducts a pre-consult with the provider through their EUA
  8. The consultation takes place over a medium offered by the EUA (could be SMS, chat, video, audio, VoIP)
  9. The consultation then gets completed and the doctor sends over their consultation notes and prescription from the provider app to the EUA.

All these steps are standardized so that any EUA can talk to any provider app to facilitate this flow. The API specifications for this are laid out at https://bit.ly/2X6skVV (Version 0.5). These APIs were developed in association with beckn.org, an open protocol for distributed commerce. 

To learn more about this flow and to hear Sharad, Sid, and Pramod talk about the OHSN principles and APIs, you can visit this link: https://youtu.be/kI7aQw3BUTc

In order to ask some questions which can be answered during the next Open House Session, you can visit https://bit.ly/NHS-QAForm

The next seventh Open House Discussion about the National Health Stack takes place tomorrow, Saturday, August 1st, at 11:30 am. The topic for discussion is the PHR (Personal Health Records) economic model. Interested parties can watched the recording here: https://youtu.be/Y5MIEB1TPw4

The following Open House Discussion will focus upon the OHSN technology architecture, and will take place on Saturday, 15th August at 11:30 am. The link for this session is the same as above – https://bit.ly/NHS-OHD

We hope this summary was useful and we look forward to engaging with you during the next Open House Discussion!

PS. Any parties interested in implementing or contributing to these APIs can reach out to [email protected] with the subject line “Interested in technical contributions for NHS”

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.

NHS Open House on PHR & Doctor Registry #3: Summary And Next Steps

On 6th June, we marked the third open house discussion of the National Health Stack (NHS). At the beginning of the session, iSPIRT volunteer Sharad Sharma offered a brief recap of the NHS and painted a roadmap for future developments in this initiative (including timelines, agendas, and future open house sessions). Sharad also discussed the content of the most recent open house session, in which Kiran Anandampillai explained the concept of the electronic registry system. After reiterating the vision for the NHS and the registry system, Sharad passed the floor to iSPIRT volunteer Vikram Srinivasan to dive into the registry APIs.

As a refresher, the electronic registry system is a mechanism for managing master data about different entities in the healthcare ecosystem. In today’ session, Vikram focused on the doctor registry. As the name suggests, the doctor registry will contain information about the doctors licensed to practice in India.

The doctor registry has the following design principles:

  1. Self maintainability: Doctors should be able to enrol themselves and update their own data
  1. Non-repudiable: The data in the registry should be digitally signed by a relevant attester (such as a State Medical Council) so that it can independently be verified by anybody
  1. Layered access: There should be a clear demarcation between public and private data in the registry, with only consent-based access to private data (eg. a doctor’s name and registration status should be public, but mobile number and photo should be private)
  1. Extensible schema: The data in the public registries should be as minimal as possible, allowing private players to build their own extensions around the core schema
  1. Open APIs: The data in the registries should be available via open APIs 
  1. Incentive aligned: The registry must enable convenient use cases so that doctors have an incentive to keep it up to date (eg. doctors can use their registry profile to electronically sign prescriptions, insurance claims etc. or doctors can use their registry profile to streamline and digitize the process of renewing their medical licenses)

After discussing the design principles behind the registry, Vikram dived straight into the details of the doctor registry APIs, which can be broken into the following categories:

  1. Enrollment APIs: These APIs allow doctors to enrol in the registry and update their data
  1. Consented APIs: These APIs allow a doctor to authenticate themselves, share their data/profile, and electronically sign documents
  1. Search APIs: These APIs are used to access the registry to query a doctor’s public data or search for any other publicly available information 

After covering these topics at a high level, Vikram released the API specifications for the Consented APIs and the Search APIs. The Swagger documentation for the same can be found here. The enrollment APIs will be released during next week’s open house session.

Upon completing his walkthrough of the doctor registry APIs, Vikram handed the floor over to our volunteer Siddharth Shetty. In the beginning of his segment, Siddharth answered the community’s technical questions around the NHS. Here are the questions he answered:

  • Is it mandatory to use the Open Source Project Eka codebase that has been published for the Consent Manager, API Bridge, and Gateway? 
  • In case of the Schema Standardization, during the 1st schema-less phase, are HIPs allowed to share data formats like JPEG, PDFs etc? 
  • Can the consent manager give the health locker (as an HIU) a standing consent to keep pulling the user’s information from various HIPs on an ongoing basis i.e. bypass the consent manager for future requests
  • Can the API bridges be configured such that instead of just sending the links to the information based on a request from an HIU (health locker in this case), the information can be sent such that it can be copied into the health locker?
  • Will the consent artifacts be encrypted between parties using any asymmetric key mechanism which will be valid between the services?
  • Is there any defined/recommended timeout for the data transmission from HIU – Bridge – CM- HIP and then HIU – HIP?

These were all great questions, and hopefully Siddharth’s answers helped clarify any doubts. If anybody wishes to ask any other questions around the NHS, please send them in to [email protected] with the subject line “NHS Questions”. Siddharth will continue answering the community’s technical questions during next week’s session (business-related questions will be answered in subsequent sessions).

To close off the open house discussion, Siddharth laid out the different working groups in the NHS ecosystem. Since the NHS is an open, public ecosystem, it is crucial for industry players and interested citizens to contribute to its development and pitch in with their feedback, knowledge, and engagement. Here are the working groups that are currently being formed:

  1. Technical Architecture Group: Responsible for working on open technical problems such as circuit breaker flows and time-out mechanisms. Also responsible for extensions and changes to the tech architecture
  1. Data Dictionary Group: This working group deals with moving away from the current schema-less architecture towards a standardized data vocabulary (leveraging existing medical schema projects and also coming up with new ideas relevant to the Indian context)
  1. Pilot Group: This group is comprised of people who have already started building on the NHS components (or would like to start building on the components). 
  1. Ecosystem Incentives Group: This group is looking at the incentive structures that power the NHS ecosystem (monetary and otherwise)

Any readers who are interested in learning more or joining these working groups are invited to reach out to [email protected]. A complete recording of the 6th June’s open house discussion can be found below

During next week’s session, we will be covering the Personal Health Records system (PHR), particularly as it relates to hospitals, and we will also be diving deeper into the Doctor Registry Enrollment APIs.

Readers are advised that next week’s NHS open house discussion will take place from 11:30 am – 12:30 pm on Saturday, June 13th.

The registration form for next week’s session can be found here

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

Open House Session on NHS’s Electronic Registry System [Technical]

On 23rd May, we hosted our first Open House Session in partnership with Swasth Alliance on the National Health Stack (NHS). For those unfamiliar with this infrastructure, it is helpful to picture the NHS as a multi-layer cake designed to elevate the capacity of the Indian healthcare ecosystem.

At the base layer is a set of generic building blocks. These building blocks, which include bank accounts, digital identities, and mobile numbers, form the basic rails needed to identify, transact with, and communicate with individuals and businesses. Many components of IndiaStack – such as eSign and DigiLocker – leverage and augment these building blocks.

The next layer of the NHS is the ‘plumbing layer’. This layer contains fundamental pillars needed to enable simple, intelligent, and secure healthcare solutions. The three main pillars of the NHS plumbing layer are electronic registries, a personal health record framework, and a claims engine. A brief summary of these pillars is provided below:

  1. Electronic Registries: these registries  allow for efficient discovery and authentication of doctors, hospitals, and other healthcare providers
  2. Personal Health Records System (PHR): a system that allows individuals to enjoy a longitudinal view of all their healthcare data and exercise granular control over how this data is stored and accessed
  3. Claims Engine: a software engine that reduces the cost of processing insurance claims, enabling insurers to cover more kinds of healthcare procedures, such as preventive checkups, walk-in consultations, and other low-cost but high-value procedures that are currently excluded from Indian insurance policies

The third layer of the NHS is an augmentation layer which is intended to utilize the three pillars of the NHS to bring greater efficiency to the Indian healthcare ecosystem. The doctor: patient ratio in this country is relatively low, and cannot be changed overnight.

Having said that, increasing the efficiency of each doctor would have a similar effect to increasing this doctor: patient ratio. The augmentation layer of the NHS is designed to drive up doctor efficiency through the use of technology. Examples of this kind of technology could include a matching engine to pair patients with the most relevant doctor, or a system to help doctors securely and remotely monitor the bio-markers of their patients. Unlike the plumbing layer, the augmentation layer of the NHS is not close to completion, but we do envisage the augmentation layer playing an important role in the ascent of Indian healthcare quality. Both the plumbing layer and the augmentation layer are designed as open, standardized interfaces. These layers serve as digital public infrastructure accessible to public and private entities wishing to build atop them.

That brings us to the fourth and final layer of the NHS: the application layer. This layer comprises all the government and private sector applications that aim to serve the diverse needs of Indian patients. The first three layers of the NHS exist so that the innovators and change-makers of the fourth layer are optimally empowered to organize, access, and process the data that they need to deliver the best service to their users.

National Health Stack Overview

The first session on the NHS followed this schedule and published the entire webinar on our official Youtube channel:

  •  An introduction to iSPIRT and our values
  • An overview of the NHS
  • A deep-dive into and demonstration of the PHR pillar of the plumbing layer
  • A question-answer session with the audience

The objective of the session was to drive awareness of the NHS components, objectives, timelines, and design philosophies. We want participants from all walks of healthcare to be engaged with the NHS and take part in building it.

In keeping with this objective, we will be hosting weekly open house sessions to keep diving deeper into the National Health Stack. The next such event will take place on Saturday (30th May) at 11:30 am. The focus of this second session will be on another pillar of the plumbing layer – the electronic registry system. More specifically, the session will focus upon the doctor registry.

Readers who wish to learn more about the NHS are encouraged to share this post and sign up now for the session below or click here.

Readers may also submit questions about the NHS to [email protected] We shall do our best to answer these questions during next Saturday’s open house discussion.

About the Author: The post is co-authored by our volunteers Aaryaman Vir and Karthik K S.

Further Reading

iSPIRT Open House Sessions on NHS: Summary & Next Steps

Yesterday afternoon, we hosted our first Open House Session in partnership with Swasth Alliance on the National Health Stack (NHS). For those unfamiliar with this infrastructure, it is helpful to picture the NHS as a multi-layer cake designed to elevate the capacity of the Indian healthcare ecosystem.

At the base layer is a set of generic building blocks. These building blocks, which include bank accounts, digital identities, and mobile numbers, form the basic rails needed to identify, transact with, and communicate with individuals and businesses. Many components of IndiaStack – such as eSign and DigiLocker – leverage and augment these building blocks. 

The next layer of the NHS is the ‘plumbing layer’. This layer contains fundamental pillars needed to enable simple, intelligent, and secure healthcare solutions. The three main pillars of the NHS plumbing layer are electronic registries, a personal health record framework, and a claims engine. A brief summary of these pillars is provided below:

  1. Electronic Registries: these registries  allow for efficient discovery and authentication of doctors, hospitals, and other healthcare providers
  2. Personal Health Records System (PHR): a system that allows individuals to enjoy a longitudinal view of all their healthcare data and exercise granular control over how this data is stored and accessed
  3. Claims Engine: a software engine that reduces the cost of processing insurance claims, enabling insurers to cover more kinds of healthcare procedures, such as preventive checkups, walk-in consultations, and other low-cost but high-value procedures that are currently excluded from Indian insurance policies

The third layer of the NHS is an augmentation layer which is intended to utilize the three pillars of the NHS to bring greater efficiency to the Indian healthcare ecosystem. The doctor: patient ratio in this country is relatively low, and cannot be changed overnight.

Having said that, increasing the efficiency of each doctor would have a similar effect to increasing this doctor: patient ratio. The augmentation layer of the NHS is designed to drive up doctor efficiency through the use of technology. Examples of this kind of technology could include a matching engine to pair patients with the most relevant doctor, or a system to help doctors securely and remotely monitor the bio-markers of their patients. Unlike the plumbing layer, the augmentation layer of the NHS is not close to completion, but we do envisage the augmentation layer playing an important role in the ascent of Indian healthcare quality. Both the plumbing layer and the augmentation layer are designed as open, standardized interfaces. These layers serve as digital public infrastructure accessible to public and private entities wishing to build atop them.

That brings us to the fourth and final layer of the NHS: the application layer. This layer comprises all the government and private sector applications that aim to serve the diverse needs of Indian patients. The first three layers of the NHS exist so that the innovators and change-makers of the fourth layer are optimally empowered to organize, access, and process the data that they need to deliver the best service to their users.

National Health Stack Overview

The first session on the NHS followed this schedule and published the entire webinar on our official Youtube channel:

  •  An introduction to iSPIRT and our values
  • An overview of the NHS
  • A deep-dive into and demonstration of the PHR pillar of the plumbing layer
  • A question-answer session with the audience

The objective of the session was to drive awareness of the NHS components, objectives, timelines, and design philosophies. We want participants from all walks of healthcare to be engaged with the NHS and take part in building it.

In keeping with this objective, we will be hosting weekly open house sessions to keep diving deeper into the National Health Stack. The next such event will take place on Saturday (30th May) at 11:30 am. The focus of this second session will be on another pillar of the plumbing layer – the electronic registry system. More specifically, the session will focus upon the doctor registry. 

Readers who wish to learn more about the NHS are encouraged to share this post and sign up now for the session below or click here.

Readers may also submit questions about the NHS to [email protected] We shall do our best to answer these questions during next Saturday’s open house discussion. 

About the Author: The post is co-authored by our volunteers Aaryaman Vir, Siddharth Shetty and Karthik K S.

Further Reading

The future of ‘civic’ technologies after COVID-19

In 1973, the British economist Ernst Schumacher wrote his manifesto “Small is Beautiful”, and changed the world. Schumacher’s prescription — to use technologies that were less resource-intensive, capable of generating employment, and “appropriate” to local circumstances — appealed to a Western audience that worried about feverish consumption by the ‘boomer’ generation. Silicon Valley soon seized the moment, presenting modern-day, personal computing as an alternative to the tyranny of IBM’s Big Machine. Meanwhile, in India too, the government asked citizens to embrace technologies suited to the country’s socio-economic life. Both had ulterior motives: the miniaturisation of computing was inevitable given revolutions in semiconductor technology during the sixties and seventies, and entrepreneurs in Silicon Valley expertly harvested the anti-IBM mood to offer themselves as messiahs. The government in New Delhi too was struggling to mass-produce machines, and starved of funds, so asking Indians to “make do” with appropriate technology was as much a political message as it was a nod to environmentalism.

And thus, India turned its attention to mechanising bullock carts, producing fuel from bio-waste, trapping solar energy for micro-applications, and encouraging the use of hand pumps. These were, in many respects, India’s first “civic”, or socially relevant technologies.

The “appropriate technology” movement in India had two unfortunate consequences. The first has been a celebration of jugaad, or frugal innovation. Over decades, Indian universities, businesses and inventors have pursued low-cost technologies that are clearly not scaleable but valued culturally by peers and social networks. (Sample the press coverage every year of IIT students who build ‘sustainable’ but limited-use technologies, that generate fuel from plastic or trap solar energy for irrigation pumps.) Second, the “small is beautiful” philosophy also coloured our view of “civic technologies” as those that only mobilise the citizenry, out into farms or factory floors. Whether they took the form of a hand pump, solar stove or bullock cart, these technologies did little to augment the productivity of an individual. However, they preserved the larger status quo and did not disrupt social or industrial relations as technological revolutions have historically done. 

Nevertheless, there has always been a latent demand in India for technologies that don’t just mobilise individuals but also act as “playgrounds”, creating and connecting livelihoods. When management guru Peter Drucker visited post-Emergency India in 1979, Prime Minister Morarji Desai sold him hard on “appropriate technology”. India, Drucker wrote, had switched overnight from championing big steel plants to small bullock carts. Steel created no new jobs outside the factory, and small technologies did not improve livelihoods. Instead, he argued, India ought to look at the automotive industry as an “efficient multiplier” of livelihoods: beyond the manufacturing plant, automobiles would create new sectors altogether in road building and maintenance, traffic control, dealerships, service stations and repair. Drucker also pointed to the transistor as another such technology. Above all, transistors and automobiles connected Indians to one another through information and travel. Drucker noted during his visit that the motor scooter and radio transistor were in great demand in even far-flung corners, a claim that is borne by statistics. These, then were the civic technologies that mattered, ones that created playgrounds in which many could forge their livelihoods. 

The lionisation of jugaad is an attitudinal problem, and may not change immediately. But the task of creating a new generation of civic technologies that act as playgrounds can be addressed more readily.  In fact, it is precisely during crises such as the ongoing COVID-19 pandemic that India acutely requires such platforms.


Consider the post-lockdown task of economic reconstruction in India, which requires targeted policy interventions. Currently, the Indian government is blinkered to address only two categories of actors who need economic assistance: large corporations with their bottom lines at risk, and at the micro-level, individuals whose stand to lose livelihoods. India’s banks will bail out Big Business, while government agencies will train their digital public goods — Aadhaar, UPI, eKYC etc — to offer financial assistance to individuals. This formulaic approach misses out the vast category of SMEs who employ millions, account for nearly 40% of India’s exports, pull in informal businesses into the supply chain and provide critical products to the big industries.

To be sure, the data to identify SMEs (Income Tax Returns/ GSTN/ PAN) exists, as do the digital infrastructure to effect payments and micro-loans. The funds would come not only from government coffers but also through philanthropic efforts that have gained steam in the wake of the pandemic. However, the “playground” needs to be created — a single digital platform that can provide loans, grants or subsidies to SMEs based on specific needs, whether for salaries, utilities or other loan payments. A front-end application would provide any government official information about schemes applied for, and funds disbursed to a given SME.

Civic technologies in India have long been understood to mean small-scale technologies. This is a legacy of history and politics, which policymakers have to reckon with. The civic value of technology does not lie in the extent to which it is localised, but its ability to reach the most vulnerable sections of a stratified society like India’s. The Indian government, no matter how expansive its administrative machinery is, cannot do this on its own. It has to create “playgrounds” — involving banks, cooperative societies, regulators, software developers, startups, data fiduciaries and underwriting modellers — if it intends to make digital technologies meaningful and socially relevant.  

Please Note: A version of this was first published on Business Standard on 17 April 2020

About the author: Arun Mohan Sukumar is a PhD candidate at the Fletcher School, Tufts University, and a volunteer with the non-profit think-tank, iSPIRT. He is currently based in San Francisco. His book, Midnight’s Machines: A Political History of Technology in India, was published by Penguin Random House in 2019

#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 PrivacyAll 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]!

#1 India’s Health Leapfrog – Towards A Holistic Healthcare Ecosystem

In July 2018, NITI Aayog published a Strategy and Approach document on the National Health Stack. The document underscored the need for Universal Health Coverage (UHC) and laid down the technology framework for implementing the Ayushman Bharat programme which is meant to provide UHC to the bottom 500 million of the country. While the Health Stack provides a technological backbone for delivering affordable healthcare to all Indians, we, at iSPIRT, believe that it has the potential to go beyond that and to completely transform the healthcare ecosystem in the country. We are indeed headed for a health leapfrog in India! Over the last few months, we have worked extensively to understand the current challenges in the industry as well as the role and design of individual components of the Health Stack. In this post, we elaborate on the leapfrog that will be enabled by blending this technology with care delivery.

What is the health leapfrog?

Healthcare delivery in India faces multiple challenges today. The doctor-patient ratio in the country is extremely poor, a problem that is further exacerbated by their skewed distribution. Insurance penetration remains low leading to out-of-pocket expenses of over 80% (something that is being addressed by the Ayushman Bharat program). Additionally, the current view on healthcare amongst citizens as well as policymakers is largely around curative care. Preventive care, which is equally important for the health of individuals, is generally overlooked.  

The leapfrog we envision is that of public, precision healthcare. This means that not only would every citizen have access to affordable healthcare, but the care delivered would be holistic (as opposed to symptomatic) and preventive (and not just curative) in nature. This will require a complete redesign of operations, regulations and incentives – a transformation that, we believe, can be enabled by the Health Stack.

How will this leapfrog be enabled by the Health Stack?

At the first level, the Health Stack will enable a seamless flow of information across all stakeholders in the ecosystem, which will help in enhancing trust and decision-making. For example, access to an individual’s claims history helps in better claims management, a patient’s longitudinal health record aids clinical decision-making while information about disease incidence enables better policymaking. This is the role of some of the fundamental Health Stack components, namely, the health registries, personal health records (PHR) and the analytics framework. Of course, it is essential to maintain strict data security and privacy boundaries, which is already considered in the design of the stack, through features like non-repudiable audit logs and electronic consent.

At the second level, the Health Stack will improve cost efficiency of healthcare. For out-of-pocket expenditures to come down, we have to enable healthcare financing (via insurance or assurance schemes) to become more efficient and in particular, the costs of health claims management to reduce. The main costs around claims management relate to eligibility determination, claims processing and fraud detection. An open source coverage and claims platform, a key component of the Health Stack, is meant to deal with these inefficiencies. This component will not only bring down the cost of processing a claim but along with increased access to information about an individual’s health and claims history (level 1), will also enable the creation of personalised, sachet-sized insurance policies.

At the final level, the Health Stack will leverage information and cost efficiencies to make care delivery more holistic in nature. For this, we need a policy engine that creates care policies that are not only personalized in nature but that also incentivize good healthcare practices amongst consumers and providers. We have coined a new term for such policies – “gamifier” policies – since they will be used to gamify health decision-making amongst different stakeholders.

Gamifier policies, if implemented well, can have a transformative impact on the healthcare landscape of the country. We present our first proposal on the design of gamifier policies, We suggest the use of techniques from microeconomics to manage incentives for care providers, and those from behavioural economics to incentivise consumers. We also give examples of policies created by combining different techniques.

What’s next?

The success of the policy engine rests on real-world experiments around policies and in the document we lay down the contours of an experimentation framework for driving these experiments. The role of the regulator will be key in implementing this experimentation framework: in standardizing the policy language, in auditing policies and in ensuring the privacy-preserving exchange of data derived from different policy experiments. Creating the framework is an extensive exercise and requires engagement with economists as well as computer scientists. We invite people with expertise in either of these areas to join us on this journey and help us sharpen our thinking around it.

Do you wish to volunteer?

Please read our volunteer handbook and fill out this Google form if you’re interested in joining us in our effort to develop the design of Health Stack further and to take us closer to the goal of achieving universal and holistic healthcare in India!

Update: Our volunteer, Saurabh Panjawani, author of gamifier policies, recently gave a talk at ACM (Association for Computing Machinery)/MSR (Microsoft Research) India’s AI Summit in IIT Madras! Please view the talk here: https://www.microsoft.com/en-us/research/video/gamifier-policies-a-tool-for-creating-a-holistic-healthcare-ecosystem/

Building for Bharat – A Bharat Inclusion Initiative

Bharat Inclusion Initiative seeks to equip entrepreneurs with the right knowledge, skills and tools they need to solve some of the toughest problems of India in a scalable manner using technology. While Bharat Inclusion Research Fellows are working on some of the most interesting studies, another important source of knowledge is thought leaders and domain experts who have been there and done that. In this three-part video series, we have Dr Pramod Varma, the Chief Architect of Aadhaar, providing his perspective on how entrepreneurs can go about building solutions for Bharat.

Part 1: The Key Construct

What are Bharat’s unique attributes? Its needs and aspirations? With data becoming one of Bharat’s key assets, how can entrepreneurs leverage it to provide solutions that matter? Watch the video to know some answers to these questions and much more.

Part 2: The Journey So Far

How to leverage the opportunity made available through Data empowerment? Know how Aadhaar, India’s biometric ID, has fundamentally changed the economics of reaching the poor. Understand how the Aadhaar platform has aided in building further platforms of IndiaStack such as eSign and Digilocker which have further reduced cost and increased trust at scale. The video rounds off with another uniquely Indian platform — Unified Payment Interface (UPI).

Part 3: Exciting Times Ahead

Reimagine solutions. With the newer domain, specific stacks being built, learn how even seemingly unrelated domains can use these platforms to offer innovative solutions. With GST and BBPS already in place, and more being built around transport (ETC), National Health Stack, Diksha and Drone Stack it has been never this good for entrepreneurs crafting solutions for Bharat. Watch the video to understand how.

____________________

What is Bharat Inclusion Initiative?

Bharat Inclusion Initiative (BII) is an incubator platform at CIIE that provides entrepreneurs with the domain knowledge, training, financial support, mentorship, and market access they need to bring inclusive, for-profit-business to life. BII’s core design is to promote technology-driven entrepreneurship towards the delivery of affordable services to the Bharat Segment- the poorest 200 million households in India who survive on less than $5 per person a day through programs, fellowships, and funding where possible.

The program focuses on solutions leveraging technology, especially the India Stack. It integrates financial inclusion research with entrepreneurship and training to transform these solutions into scalable, viable and high impact businesses.  Keen on partnering with entrepreneurs who are driven by building next-generation digital services for India. Reach out to us at [email protected] or ask your questions in the comments section below.

Please note: The above information was first published by Bharat Inclusion Fellows here: https://medium.com/bharatinclusion/building-for-bharat-df8b12867271