Posted on

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. 

Posted on

The history of technology is about to change radically. India must seize the moment

There are no atheists in foxholes, and there appear to be no capitalists in a global pandemic either. The head of Honeywell’s billion-dollar GoDirect Trade platform, which uses a permission-based blockchain to buy and sell aviation parts, declared on March 20 that American corporations had a “walled-garden” approach to data. “They need to start sharing data, a huge paradigm shift”, said Lisa Butters. Only a couple of weeks ago, Honeywell had been defending the virtues of a permission-based system, saying enterprises “needed some constraints to operate in”. 

What a difference a few days can make. 

Historically, the aviation industry has been one of the most secretive among ‘Big Tech’ sectors, with its evolution tied intimately to the Second World War, and the US-Soviet Cold War rivalry that followed soon after. Concerns around China’s theft of aerospace IP was among the foremost drivers behind the Obama administration’s negotiation of the 2015 agreement with China to prohibit “economic espionage”. It is the ultimate “winner-takes-all” market — but Boeing, its lynchpin, has now approached the US government for an existential bailout. Honeywell’s call for a “paradigm shift” is proof that the sector is not thinking just in hand-to-mouth terms. The aviation sector may get a lifeline for now, but as an industry forged by a global war, it knows more than most that a transformational moment for technology is upon it, which needs to be seized. 

As the economist Branko Milanović has highlighted, the correct metaphor for the Covid-19 pandemic and ensuing crisis is not the Great Recession of 2008, but the Second World War. To win WWII, and retain its military superiority, the United States pioneered technology complexes that placed innovation at the trifecta of a university lab, government, and market. (The blueprint for this model was drawn up in 1945 by Vannevar Bush, founder of Raytheon and director of the Office for Scientific Research and Development, and presented to the US government. The document was titled, “Science: The Endless Frontier”.) This was by no means a Western endeavour alone. Several countries, including India, followed suit, trying to perfect a model of “organised science”. In India, the Council for Scientific and Industrial Research was the totem for this effort and created a centralised network of national labs. The primary difference between Western models and ones in developing countries like India was the role of the state. In the US, the state retained regulatory agency over the process of technological innovation, but gradually ceded into the background as the Boeings, Westinghouses, GEs, Lockheed Martins, and IBMs took over. In India, the state became both the regulator and purveyor of technology. 

India’s attempts to create “national champions” in frontier technologies (think Hindustan Antibiotics Ltd, Electronics Corporation of India Ltd, Defence Research and Development Organisation, etc) failed because the state could not nimbly manufacture them at scale. Even as India pursued “moonshots”, those businesses in the United States that were incubated or came of age during the Second World War began to occupy pole positions in their respective technology markets. Once those markets matured, it made little sense for America to continue creating “organized” technology complexes, although research collaborations between universities and the federal government continued through the National Science Foundation. The banyan-ization of the internet and Silicon Valley — both seeded by generous assistance from the US Department of Defence — into a market dominated by the FAANG companies affirms this shift.

In the wake of the Covid-19 pandemic, however, the tables are turning. The United States is not only shifting away from “moonshots” but also pivoting towards “playgrounds”, settling on a model that India has perfected in the last decade or so.

The United States has often sought to repurpose private technologies as public utilities at key moments in its history. Communications technology was built and moulded into a public good by the American state. It was US law that enabled patent pooling by Bell Labs in the 19th century, leading to the creation of a “great new corporate power” in telephony. A few decades into the 20th century, American laws decreed telephone companies would be “common carriers”, to prevent price and service discrimination by AT&T. Meanwhile, both railroads and telecommunications providers were recognised as “interstate” services, subject to federal regulation. This classification allowed the US government to shape the terms under which these technologies grew. IT is precisely this template that Trump has now applied to telehealth technology in the US. Tele-medicine services could not previously be offered across state lines in the US, but the US government used its emergency powers last week to dissolve those boundaries. And on March 18, President Trump invoked the Defence Production Act, legislation adopted during the Korean War and occasionally invoked by American presidents, that would help him commandeer private production of nearly everything, from essential commodities to cutting-edge technologies. 

Invoking the law is one thing, executing it is another. Rather than strong-arming businesses, the Trump administration is now trying to bring together private actors to create multiple “playgrounds” with an underlying public interest. The Coronavirus Task Force was the first of its kind. The Task Force brought together Walmart, Google, CVS, Target, Walgreens, LabCorp and Roche, among others to perform singular responsibilities aimed at tackling the coronavirus pandemic. Walmart would open its parking lots for testing, Google would create a self-testing platform online, Roche would develop kits, LabCorp would perform high-throughput testing, and so on. The COVID-19 High-Performance Computing Consortium, created on March 23, is another such playground. It includes traditional, 20th-century actors such as the national laboratories but is doubtless front-ended by Microsoft, IBM, Amazon and Google Cloud. The Consortium aims to use its high computational capacity to create rapid breakthroughs in vaccine development. Proposals have been given an outer limit of three months to deliver. 

In some respects, the United States is turning to an approach that India has advanced. To be sure, we may not currently be in a position to develop such a playground for vaccine R&D and testing at scale. But India is well-positioned to create the “digital playgrounds” that can help manage the devastating economic consequences of the Covid-19 epidemic. There is a universal acknowledgement that India’s social safety nets need to be strengthened to mitigate the fallout. One analyst recommends “a direct cash transfer of ₹3,000 a month, for six months, to the 12 crores, bottom half of all Indian households. This will cost nearly ₹2.2-lakh crore and reach 60 crore beneficiaries, covering agricultural labourers, farmers, daily wage earners, informal sector workers and others.” The same estimate suggests “a budget of ₹1.5- lakh crore for testing and treating at least 20 crore Indians through the private sector.” 

The digital public goods India has created — Aadhaar, UPI and eKYC — offer the public infrastructure upon which these targeted transfers can be made. However, cash transfers alone will not be enough: lending has to be amplified in the months to come to kickstart small and medium businesses that would have been ravaged after weeks of lockdown. India’s enervated banking sector will have meagre resources, and neither enthusiasm or infrastructure to offer unsecured loans at scale. “Playgrounds” offers private actors the opportunity to re-align their businesses towards a public goal, and for other, new businesses to come up. Take the example of Target, which is an unusual addition to the Coronavirus Task Force, but one whose infrastructure and network makes it a valuable societal player. Or Amazon Web Services in the High-Performance Computing Consortium, which has been roped in for a task that is seemingly unrelated to the overall goal of vaccine development. 

If digital playgrounds are so obvious a solution, why has India not embraced it sooner? None of this is to discount the deficit of trust between startup founders and the public sector in India. Founders are reluctant to use public infrastructure. It is the proverbial Damocles’ sword: a platform or business’ association with the public sector brings it instant legitimacy before consumers who still place a great deal of trust in the state. On the other hand, reliance on, or utilisation of public infrastructure brings with it added responsibilities that are unpredictable and politically volatile. To illustrate, one need only look at the eleventh-hour crisis of migrating UPI handles from YES Bank in the light of a moratorium imposed on the latter earlier this month. On the other hand, the government retains a strong belief that the private sector is simply incapable of providing scalable solutions. In most markets where the India government is both player and regulator, this may seem a chicken-and-egg problem, but c’est la vie.

Nevertheless, there are milestones in history where seemingly insurmountable differences dissolve to reveal a convergence of goals. India is at one such milestone. A leading American scientist and university administrator have called the pandemic a “Dunkirk moment” for his country, requiring civic action to “step up and help”. By sheer chance and fortitude, India’s digital platforms are poised to play exactly the role that small British fishing boats played in rescuing stranded countrymen on the frontline of a great war: they must re-imagine their roles as digital platforms, and align themselves to strengthen the Indian economy in the weeks to come. 

Arun Mohan Sukumar is a PhD candidate at the Fletcher School, Tufts University, and a volunteer with the non-profit think-tank, iSPIRT. His book, Midnight’s Machines: A Political History of Technology in India, was recently published by Penguin RandomHouse.

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

Posted on

#3 What does the Health Stack mean for you?

The National Health Stack is a set of foundational building blocks which will be built as shared digital infrastructure, usable by both public sector and private sector players. In our third post on the Health Stack (the first two can be found here and here), we explain how it can be leveraged to build solutions that benefit different stakeholders in the ecosystem.

Healthcare Providers

  • Faster settlement of claims: Especially in cases of social insurance schemes, delay in settlement of claims causes significant cash-flow issues for healthcare providers, impacting their day-to-day operations. The claims and coverage platform of the health stack is meant to alleviate this problem through better fraud detection and faster adjudication of claims by insurers.
  • Easier empanelment: The role of facility and provider registry is to act as verified sources of truth for different purposes. This means a convenient, one-step process for providers when empanelling for different insurance schemes or providers.
  • Quality of care: The use of personal health records can enable better clinical decision making, remote caregiving and second opinions for both patients and medical professionals.

Insurers

  • Faster and cheaper settlement of claims: claims and coverage platform, as described above
  • Easier empanelment of healthcare providers: registries, as described above
  • Diverse insurance policies: In addition to the above benefits, the policy engine of the healthstack also seeks to empower regulators with tools to experiment with different types of policies and identify the most optimum ones

Researchers and Policymakers

  • Epidemiology: the analytics engine of the healthstack can be helpful in identifying disease incidence, treatment outcomes as well as performance evaluation of medical professionals and facilities
  • Clinical trials: a combined use of analytics and PHR can help in identifying requirements and potential participants, and then carrying out randomised controlled trials

How can it be leveraged?

While the healthstack provides the underlying infrastructure, its vision can be achieved only if products benefitting the end consumer are built using the stack. This means building solutions like remote second opinions using health data from healthcare systems, as well as developing standard interfaces that allow existing systems to share this data. In the diagram below, we elaborate on potential components of both of these layers to explain where innovators can pitch in.

If you are building solutions using the health stack, please reach out to me 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].