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

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

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

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

Data Privacy and Empowerment in Healthcare

Technology has been a boon to healthcare. Minimally-invasive procedures have significantly increased safety and recovery time of surgeries. Global collaboration between doctors has improved diagnosis and treatment. Rise in awareness of patients has increased the demand for good quality healthcare services. These improvements, coupled with the growing penetration of IT infrastructure, are generating huge volumes of digital health data in the country.

However, healthcare in India is diverse and fragmented. During an entire life cycle, an individual is served by numerous healthcare providers, of different sizes, geographies, and constitutions. The IT systems of different providers are often developed independently of each other, without adherence to common standards. This fragmentation has the undesirable consequence of the systems communicating poorly, fostering redundant data collection across systems, inadequate patient identification, and, in many cases, privacy violations.

We believe that this can be addressed through two major steps. Firstly, open standards have to be established for health data collection, storage, sharing and aggregation in a safe and standardised manner to keep the privacy of patients intact. Secondly, patients should be given complete control over their data. This places them at the centre of their healthcare and empowers them to use their data for value-based services of their choice. As the next wave of services is built atop digital health data, data protection and empowerment will be key to transforming healthcare.

Numerous primary health care services are already shifting to smartphones and other electronic devices. There are apps and websites for diagnosing various common illnesses. This not only increases coverage but also takes the burden away from existing infrastructures which can then cater to secondary and tertiary services. Data shared from devices that track steps, measure heartbeats, count calories or analyse sleeping patterns can be used to monitor behavioural and lifestyle changes – a key enabler for digital therapeutic services. Moreover, this data can not only be used for monitoring but also for predicting the onset of diseases! For example, an irregular heartbeat pattern can be flagged by such a device, prompting immediate corrective measures. Thus, we see that as more and more people generate digital health data, control it and utilise it for their own care, we will gradually transition to a better, broader and preventive healthcare delivery system.

In this context, we welcome the proposed DISHA Act that seeks to Protect and Empower individuals in regards to their electronic health data. We have provided our feedback on the DISHA Act and have also proposed technological approaches in our response. This blog post lays out a broad overview of our response.

As our previous blog post articulates the principles underlying our Data Empowerment and Protection Architecture, we have framed our response keeping these core principles in mind. We believe that individuals should have complete control of their data and should be able to use it for their empowerment. This requires laying out clear definitions for use of data, strict laws to ensure accountability and agile regulators; thus, enabling a framework that addresses privacy, security and confidentiality while simultaneously improving transparency and interoperability.

While the proposed DISHA Act aligns broadly with our core principles, we have offered recommendations to expand certain aspects of the proposal. These include a comprehensive definition of consent (open standards, revocable, granular, auditable, notifiable, secure), distinction between different forms of health data (anonymization, deidentification, pseudonymous), commercial use of data (allowed for benefit but restricted for harm) and types and penalties in cases of breach (evaluation based on extent of compliance).

Additionally, we have outlined the technological aspects for implementation of the Act. We have used learnings from the Digital Locker Framework and Electronic Consent Framework (adopted by RBI’s Account Aggregator), previously published by MeitY. This involves the role of Data Fiduciaries – entities that not only manage consent but also ensure that it aligns with the interests of the user (and not with those of the data consumer or data provider). Data Fiduciaries only act as messengers of encrypted data without having access to the data – thus their prime task remains managing the Electronic Data Consent. Furthermore, we have highlighted the need to use open and set standards for accessing and maintaining health records (open APIs), consented sharing (consent framework) and maintaining accountability and traceability through digitally verified documents. We have also underscored the need for standardisation of data through health data dictionaries, which will open up the data for further use cases. Lastly, we have alluded to the need to create aggregated anonymised datasets to enable advanced analytics which would drive data-driven policy making.

We look forward to the announcement and implementation of the DISHA Act. As we move towards a future with an exponential rise in digital health data, it is critical that we build the right set of protections and empowerments for users, thus enabling them to become engaged participants and better managers of their health care.

We have submitted our response. You can find the detailed document of our response to DISHA Act below

From manifesto to budget to delivery

The 2014 election manifesto of the Bharatiya Janata Party (BJP) outlined how innovation, research and technology can transform India into a superpower by empowering, connecting and binding all stakeholders.

The decisive mandate given to the BJP-led National Democratic Alliance, under the leadership of Narendra Modi, in the general election marked a paradigm shift in the Indian political landscape; the people of India reposed their complete faith in Prime Minister Modi and his team.

Finance minister Arun Jaitley and his team must be complimented for taking forward the visionary BJP manifesto and turning it into actionable budget proposals, and also for setting the direction towards building a “Digital India” where innovation, research and technology will play a major role.

Rural broadband and e-highways

A pan-India programme called “Digital India” has been proposed in the 2014 budget to bridge the divide between digital “haves” and “have-nots”. This would ensure broadband connectivity at the village level, improved access to services through information technology (IT)-enabled platforms, greater transparency in government processes, consumption of local content and a host of other services. The railway budget proposed providing Wi-Fi connectivity at train stations, on premium trains and “Office on Wheels”.

An ambitious plan to integrate all government departments through an e-platform will create a business- and investor-friendly ecosystem in India, by making all business- and investment-related clearances and compliances available on a single 24×7 portal, with an integrated payment gateway.

An ecosystem for innovation: from ‘Sell in India’ to ‘Made in India’

India, since the beginning of civilization, has been a leader in science and technology. Lack of a favourable ecosystem for spurring innovation, however, has dented its position post-independence.

Today, India produces only around 2% of IT products that it consumes. This is having an adverse impact on its economy. The need of the hour is to make India an innovation-driven manufacturing hub from a consumption market, by creating an enabling ecosystem for nurturing product start-ups. Entrepreneurship needs to become part of the national culture instead of being the success story of a few.

The new government has recognized the need to create an ecosystem for fundamental research and innovation for India to become a global manufacturing giant with specific programmes for small entrepreneurs, start-up villages and incubation centres. The nationwide district-level incubation and accelerator programme can promote frugal innovation ground-up.

Special focus on software product industry

IT services will remain important for economic growth, but India needs new growth drivers as well. Global Indians educated in Indian universities, in Indian Institutes of Technology and Indian Institutes of Management have used foreign soil to make inventions and innovations that have benefited the world.

With the right impetus, it is quite possible to create the next Google, Facebook, WhatsApp out of India. The budget makes a big start by launching a fund for promoting product-led start-ups, a much desired innovation in the thinking of the government.

E-Healthcare and e-Education

Much of real India, Bharat, still lives in villages. Unfortunately, the past government’s average spending on healthcare and education was just 1% and 3%, respectively, of gross domestic product. As a result, basic health and education infrastructure is in bad shape.

The budget does a great job in recognizing the enormous opportunity that lies in improving healthcare and basic education access by using IT. Use of telemedicine, virtual classrooms, open online courses and e-education can be the kick-starter to achieve size and scale to improve the primary healthcare network and basic education standards.

Content localization and digitization

India has more Internet users than English language speakers; as a result, regional language keyboards are vital for deeper Internet penetration. Local language content needs to get digitized. China has already successfully developed and standardized local language keyboards.

Government can help by providing the standard templates for every language that can then be commercialized by using the public-private partnership model.

Now it’s time to deliver.

Technology, needless to say, will play an important role in effective delivery of services, monitoring performance, managing projects and improving governance.

An Integrated Office of Innovation and Technology to achieve the same, and for problem solving, sharing applications and knowledge management will be the key to rapid results, given that most departments work in their own silos. Tracking and managing the projects assume significance because India has been busy spending money in buying technology that it has not used effectively or in some cases not even reached implementation stage. Sharing knowledge and best practices across departments need to be driven by this Office of Technology.

India needs interventions across sectors to become a global knowledge hub by 2022. The Prime Minister is a very technology-savvy leader and the country looks forward to his leadership to drive this next phase of revolution in innovation and technology with a renewed vision and vigour.

This article first appeared in LiveMint