We believe that India is at a unique tipping point where only a fraction of its users have gone online, and a majority are yet to do so. Therefore, it is critical that we build the right set of protections and empowerments for these users as they enter the digital world. It is equally important not to limit our thinking to simply “protection” of data. We must also question how we can “empower” individuals, who will be data rich before they are economically rich, with better access to their own healthcare data such that they can become more engaged participants and managers of their health care. 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 this response

1. Digital Information Security in Healthcare Act (DISHA)
iSPIRT’s Response
About iSPIRT
iSPIRT (Indian Software Product Industry Round Table) is a think tank whose mission is to
build a healthy, globally-competitive and sustainable Indian Software Product Industry,
thus making India into a Product Nation.
We believe that India is at a unique tipping point where only a fraction of its users have
gone online, and a majority are yet to do so. Therefore, it is critical that we build the right
set of protections and empowerments for these users as they enter the digital world.
It is equally important not to limit our thinking to simply “protection” of data. We must also
question how we can “empower” individuals, who will be data rich before they are
economically rich, with better access to their own healthcare data such that they can
become more engaged participants and managers of their health care.
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 this response.
1

2. Table of Contents
Part I: Context Setting: India In A Digital World
Part II: Regulatory Aspects of the DISHA Act
A. Recommendations
B. New Considerations
Part III: Technology Aspects of the DISHA Act
A. ​Electronic Consent Manager for Data Owners
B. Health Information Exchanges must be based on Open APIs
C. Health Data must be Verifiable through Digital Signatures and Standardised through a
National Health Data Dictionary
D. Creation of a National Health Analytics Framework through Open Data and Data Sandboxes
2

3. Part I: Context Setting: India In A Digital World
Introduction
As the world hurtles towards a data-driven, digital-first future there is a real opportunity
for India to emerge as a leader in driving policy that simultaneously empowers and
protects the individual. Through engagements with the community, we have developed six
overarching core principles which we believe are most crucial to ensure the dual goals of a
citizen-centric approach to data protection, and data empowerment for the individual.
These six principles are as under, and frame our response to the DISHA Act:
1. Restoring balance between the individual and the data controller
The law must use principles of accountability and empowerment to balance the inherent
positional inequality between the individual and the data controller. This can be achieved
by first and foremost ensuring that the building blocks of the DISHA Act are centered
around safeguarding individual privacy and data, and mitigating against any potential or
existing privacy harms. Placing the individual at the centre of India’s proposed healthcare
data law increases the potential for it to be adaptable and future-proof, capable of
encompassing emerging technologies and data use cases as they evolve.
2. Data should be used to empower and not for harm
Championing transparency increases the likelihood for the law to be carried across various
jurisdictions and in turn drives user consent that is both informed and meaningful. Once
individuals are able to easily comprehend and feel empowered to exert a level of control
over their personal data, their ability to harness the potential of this data for their own
economic benefit (and hence that of the nation) increases. Conversely, in cases where data
sharing has already occured, a higher onus must be placed on the data controller to inform
the user about such activities.
3. Individuals have rights over their data
iSPIRT advocates for a “rights-based model” for data ownership as guided by three
principles: accountability, autonomy and security. Together these principles will ensure
that individuals are provided a right to fair treatment, right to information, right to port
(transfer) data from one data controller to another, right to restrict processing, and right to
the security of his/her data. Classifying data types, whether sensitive, personal, etc. should
take into account social implications and norms in order to best protect the individual
under all possible associations.
3

4. 4. Data controllers must be accountable
Regardless of data type, whether it be personal or even sensitive, the law must hold data
controllers accountable for any and all privacy harm caused by their actions. The “data
controller” is the entity that has legitimately been provided control of the data, and hence
determines the primary purpose of the data collection and therefore also holds primary
responsibility for upholding an individual’s right to privacy and rights to protection against
harms via data.
5. Times of disruptive change require agile regulators
The law should empower regulators by providing a framework with a set of principles
which are timeless, along with a mechanism that can change with the times and a context to
provide suitable intervention. Regulators should have the flexibility to oversee all data
processing activities that are primarily digital in nature. In cases where the law provides
exemption, such as data collection for purposes having a well-defined and overwhelming
public benefit, the regulator should be properly equipped to evaluate and adapt
accordingly.
6. Balancing India’s needs for privacy, transparency and development
Overall, the law should strive to create a balance between protecting personal privacy,
providing transparency and accountability for institutions (including government), and
ensuring development, growth, and empowerment for the individual and other market
participants. By harmonizing various existing laws, balancing surveillance efforts, and
striving for a practical approach to balancing privacy and development, particularly among
social sector players, Data Protection laws can ultimately drive sustained growth.
It’s welcoming to observe that the proposed DISHA Act aligns broadly with the above
principles. As a community we are highly optimistic for India’s adoption of a visionary and
comprehensive framework for healthcare data protection and empowerment and thank the
MoHFW for their efforts in spearheading the same. We look forward to a continued
engagement in bringing these policies to the forefront.
4

5. In the recent past, iSPIRT has engaged deeply with various stakeholders in the
community and here’s our response to the relevant public consultations:
● iSPIRT’s Response to TRAI’s Consultation Paper on Privacy, Security and
Ownership of the Data in the Telecom Sector:
http://www.trai.gov.in/sites/default/files/iSPIRT%27s_Response_07_11_2017.p
df
● iSPIRT’s Response to the Justice Sri Krishna Committee’s White Paper on Data
Protection Framework for India:
http://pn.ispirt.in/ispirt-response-to-justice-krishna-committee/
5

6. Part II: Regulatory Aspects of the DISHA Act
A. Recommendations
Reference
Section Number
Reference
Section
iSPIRT Recommendation
Section I, Clause 3
(c)
Definition of
Consent
‘Consent’ must be based on the ORGANS
Principles:
O​pen Standards: The framework should use
open technology and legal standards available in
the country.
R​evocable: Users must have the ability to revoke
consent at a later date, by requesting the data
provider, the data consumer or other entities.
G​ranular: The framework should allow users to
set permissions and rights for data access at a
granular level.
A​uditable: All events in the consent flow and
data flow must be digitally signed and logged
using the MeitY Consent Log artifact . Two types1
of consent flow events must be logged -
CONSENT-CREATED and CONSENT-REVOKED.
For data flow events, logs must be created for
DATA-REQUESTED (when a new data request is
received by the data provider), DATA-SENT
(when data is sent by data provider to data
consumer) and DATA-DENIED (when data
request is denied by data provider). Additionally,
for DATA-SENT event, the list of data items
shared by the data provider / received by the
data consumer must also be logged. These
non-repudiable transaction trails shall lead to
higher trust and stronger accountability.
N​otice: The user must be notified through Email,
SMS, In-App Notice, and other notification
1
MeitY Electronic Consent Framework:
http://dla.gov.in/sites/default/files/pdf/MeitY-Consent-Tech-Framework%20v1.1.pdf
6

7. mechanisms when consent is created or revoked
and when data has been requested, sent or
denied.
S​ecurity By Design: The internal and external
software and systems must be designed from the
ground up to be secure. There must be
end-to-end security of data (PKI, DSC, tamper
detection) and it must be network agnostic and
data centric.
Section I, Clause 3
(1, A & D)
‘Anonymization’,
‘De-identificatio
n’
The Act should draw a distinction between
anonymized data, de-identified data, and
pseudonymous data:
● Anonymized data is data from which
absolutely nothing can be inferred about
the individual.
● De-identified data is that from which
identifiers/PIIs have been removed:
inferences may still be possible in
de-identified data.
● Pseudonymous data is that in which
identifiers have been substituted with
pseudonyms: inferences are still possible
on such data.
Section IV, Clause
29 (5)
Purposes of
collection,
storage,
transmission
and use of the
digital health
data
Since individuals are in control of their
healthcare data, they must be given control and
empowered to consent and share it for
commercial purposes so that they can access
value added services that benefit them. This is an
extremely critical aspect of Data Empowerment
both individually, and as a society.
Instead of having a blanket restriction on sharing
data for commercial purposes, certain
restrictions can be placed while processing data
for commercial purposes like using data to effect
gender or caste based discrimination.
Chapter V, Clause
37 and 38
Breach of digital
health data,
Serious breach
of digital health
data
"Any person" should be replaced by "any entity"
7

8. Chapter V, Clause
38 (1 B)
Serious breach
of digital health
data
Re Identification from De-identified data or
Pseudonymous data and used for malicious
purposes must be considered a type of breach.
(However, there must be a safe mechanism for
ethical reporting of the possibility of
re-identification to the concerned entities.)
Chapter V, Clause
38 (2)
Fees/penalties
in cases of
breach
There must be a provision to score clinical
establishments (monetary fine, suspension of
license, etc) based on their level of compliance
using Data Trust Scores.
Also, there must be a provision for penalising
clinical establishments for non-compliance. For
example, hospitals that share personal data
without the owner’s consent should get their
license (to operate as a clinical establishment)
suspended.
8

9. B. New Considerations
New Consideration iSPIRT Recommendation
Localisation of Electronic Health Data It is feasible and recommended to localise
critical health data within a span of five
years from when regulations are published.
There are three fundamental reasons:
● National Security: Fiber connections
from India to the world are fragile
and go through open waters
eminently subject to malice with
minimal effort. If critical services in
India are digital (e.g. health,
payments, health, commerce,
finance), then we put the country at
risk until such critical services are
fully local.
● Data Security: Data that flows
through pipes and hardware not
subject to Indian laws and
certification is under threat of
unauthorised snooping, diversion or
hacking - it is much easier due to
physical access to hardware or
networks. It is India’s duty to
protect the physical and legal
integrity of its citizens their
organisations governance data, core
financial data, legal agreements, as
well as deeply personal data like
health. To deliver on this right, it is
incontrovertible to have data and
network tenancy of such data
remain in India.
● Legal Sovereignty: Data in
international data centers even of
verified Indian residents is subject
to laws of the resident country
including continuous inspection,
search, seizure with or without
consent of courts in those countries.
Private and personal data may be
allowed to be mirrored or jointly
served from India and only from
9

10. those countries which have
explicitly agreed to honor Indian
law, and that country can be trusted
to keep its contract through adverse
times.
Therefore, the right framework for
ensuring sovereign data access involves:
● Consent
● Security
● Data Residency
Community Owned Data and Community
Rights to Crowdsourced Data
We must recognise the rights of community
ownership in crowdsourced data.
● Raw data belongs to a community -
open unless significant part of the
community, majority of at least 33%
vote otherwise, weighted by
contribution. Smaller storages are
exempt until their databases reach
community scale (to prevent undue
load on small experiments)
● Enhancements belong to innovator,
subject to publishing of user
contributions in the same
structured form and schema they
have processed or stored.
● Individual users may choose to
withhold their contributions
publicly (or anonymise) Subject to
their contributions not being
incremental and being independent
of others, if there are other
contributions materially on top of
theirs, those cannot be withheld in a
commons metaphor. In a sensor
driven world, raw contributions will
become more and more
comprehensive and eliminate data
monopolies.
10

11. Part III: Technology Aspects of the DISHA Act
A. Electronic Consent Manager for Data Owners
In the MeitY Whitepaper on Data Protection for India , the Consent Dashboard has been2
suggested as one of the technological innovations for managing consent. In February 2017,
an Electronic Consent Framework (Electronic Consent Framework - Technology
Specifications Version 1.1 ) for enabling consent for sharing of data has been released by3
MeitY. A similar concept may be adopted in DISHA for management of consent.
Example of Consent Manager in the Financial Sector - NBFC Account Aggregator
The Reserve Bank of India has taken a major step forward in this regard by adopting the
Electronic Consent Framework and creating a new entity – the NBFC Account Aggregator
(NBFC-AA) in its Master Direction DNBR.PD.009/03.10.119/2016-17 . As per the4
regulation, an account aggregator is a specialized entity meant to serve as an
intermediary between a customer and different financial service providers for managing
consented sharing of financial information.
Proposed Technical Approaches based on the MeitY Electronic Consent Framework5
for Electronic Consent Flows and Data Flows:
● Approach A: Centralised Approach : In this approach, the Consent Collector manages
the consents from the users to any data request. When Data Consumer requests for
data the Consent Collector validates it against the consent artefacts; collects the data
from the required Data Providers and route it to the Data Consumer. The Consent
Collector acts as trusted central entity and required to ensure the security of data
and the privacy of the Data Owner.
● Approach B: Centralised Approach (with Central Switch) : In this approach Consent
Collector manages the consents provided by the user for any data requests. When a
Data Consumer sends a data requests, the Consent Collector validates it against the
consent artefacts and sends that requests to the Data Provider which provides the
2
http://meity.gov.in/writereaddata/files/white_paper_on_data_protection_in_india_18122017_final_v2.1.pdf
3
​http://dla.gov.in/sites/default/files/pdf/MeitY-Consent-Tech-Framework%20v1.1.pdf
4
​https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=10598&Mode=0
5
​http://dla.gov.in/sites/default/files/pdf/MeitY-Consent-Tech-Framework%20v1.1.pdf
11

12. data directly to the Data Consumer. Here the consent and the data flow are separate.
Data flow happens directly from Data Provider to the Data Consumer.
● Approach C: Decentralised Approach: In this approach the Consent Collector
manages the consents and stores the hash of the artefact in a distributed ledger.
Data Consumer requests the data directly from the Data Provider which then
validates the consents and serves the data. The data hash is also recorded in the
ledger. The ledger helps in maintaining integrity, traceability and non-repudiability
of all transactions.
In both the Decentralised and Centralised (with a switch) approach the presence of data
consumer should be established but its identity should not be revealed. Also, all consent
and data flows must be rigorously logged and there should be regular audits performed on
these logs.
B. Health Information Exchanges must be based on Open APIs
The framework for Health Information Exchanges should provide an ​open ​and standard ​set
of application programming interfaces (APIs) for creating, accessing and updating records
in EHRs, as proposed in the Policy for Open APIs by MeitY . The API definitions should be
6
simple and follow the principles of minimalism and privacy by design.
In February 2017, the Ministry of Electronics and Information Technology (MeitY) put
forward the Digital Locker Framework (Digital Locker Technology Framework - Version
1.1 ) as a national standard for federated storage and exchange of data. The same may be7
considered for the Open API definitions of Health Information Exchanges, Data Providers
(Clinical Establishments), and Data Consumers (Clinical Establishments and other Entities).
C. Health Data must be Verifiable through Digital Signatures and Standardised
through a National Health Data Dictionary
All health data must be digitally signed by the source. This ensures integrity and
non-repudiability of the data, creating transparency and accountability in the entire
ecosystem. Also, all healthcare data must be published in an approved machine readable
format with link to a deemed schema or schema bundled with data (UDL).
6
​http://meity.gov.in/sites/upload_files/dit/files/Open_APIs_19May2015.pdf
7
​http://dla.gov.in/sites/default/files/pdf/DigitalLockerTechnologyFramework%20v1.1.pdf
12

13. D. Creation of a National Health Analytics Framework through Open Data and
Data Sandboxes
The National Health Analytics Framework must enable the creation of anonymised and
aggregated datasets that assist in the creation of dashboards, reports, and other types of
statistics. These aggregated datasets should present the overall direction of health of the
country/state/district leading to data-driven decisions and targeted policymaking in the
health sector.
In alignment with the National Data Sharing & Accessibility Policy (NDSAP) , open datasets8
should be published as part of this framework to increase transparency, accountability,
civil society engagement, and innovations in service delivery.
The creation of an open data sandbox containing anonymised datasets would be a very
positive step in the enablement of new data-driven businesses as well as introduction of
newer services that deliver better customer value. Also, the regulators and government
have a significant amount of data that can be anonymised and included in the open data
sandbox that would further improve transparency and development of newer services.
8
Reference to ​MeitY’s National Data Sharing & Accessibility Policy (NDSAP)
13