Activity 2. 1st August 2018: Submission of Feedback on NHS Consultation Paper:

Date: 1st August 2018

Some Feedback on the Consultation Paper on the

National Health Stack-Strategy and Approach

  1.  Managing Public Perception is key to reduction of delays

The National Health Stack (NHS) is the technical foundation for the ambitious Ayushman Bharat program. The success or failure of the Ayushman Bharat program and the consequences thereof would be dependent on  the success or failure of the NHS. Hence this is a project of critical national importance on which the destiny of the nation rests.

However, the program is likely to attract focussed criticism from the biased media and any shortcomings would be blown out of proportions.

The need to manage the public perception of the uniqueness of the program should be properly assessed and should be part of the implementation program. If the public perception management is not addressed, the technical implementation would be stalled at every level and the program will not make necessary progress. The opposition to the Aadhaar scheme is an indication of the underlying potential for delays arising due to mismanagement of public perception

“Creating Public Awareness” and “Preparing the public for using the system effectively” should therefore be an important part of the technical aspects of the project.

2. Key Concerns

Two key concerns that would shape public perception as soon as the project hits the road are

a) Privacy

b) Security

Since Health Information is a sensitive personal information, components of the NHS which involves collection, storage and processing of information fall under the umbrella of the newly proposed “Personal Data Protection Act 2018” (PDPA 2018).

The project expects the participation of the Private Sector which would be concerned with the possible breach of personal data and its consequences.

If this concern is not properly addressed, the private sector would hesitate to join the program.

The emphasis on “Anonymization”, “De-identification”, “Encryption” and other technical measures to ensure security of sensitive information is therefore a top priority. Any perceived lack of security would be not only a subject matter of criticism by the public but also potential for legal hurdles.

The project should therefore notify

i) A Data Protection Officer with overall responsibility for Privacy and Data Protection whose role has to be highlighted right from the day the project is rolled out.

ii) Declaration of the main technology components as “Critical Information Infrastructure” under Section 70 of Information Technology Act 2000 as amended in 2008(ITA 2000/8)

iii) Declaration that any attempted disruption of the NHS would be considered as an attack on the citizens of the nation and likely to cause death and destruction that would qualify the offence to be classified as an offence under Section 66F of ITA 2000/8

iv) Mandating that the Health Subjects shall be protected by a “Cyber Insurance Program” that covers any loss that may arise to any individual as a result of contravention of any law. The loss may be covered similar to the existing accident insurance policies or similar newly constructed policies for both health hazards caused and death.

3. The Registries

The registries are an essential part of the system and cannot be avoided. From the zero date, Digital Health IDs may be created as “One permanent  Digital health ID” for the individual and Virtual Health IDs for transactional use.

The seeding of the identity can be through Aadhaar but subsequent to the generation of the Digital Health ID, it should not be indiscriminately used. Only the Virtual health ID should be used for all transactions.

The Digital Health ID should be generated in a central server and the user should be provided only with a physical instrument such as a “Card” with his name and a secretly encoded customized machine readable code embedded in the card.

The user should not be able to therefore share any “Digital Health ID Card Number”. The card will have the name and address with a photograph. For card present transactions, the hidden machine readable code should be used for linking the data to the centralized unique health ID. For Card not present transactions, a virtual Health ID could be used along with a KYC type authentication.

Service providers will store only the virtual health IDs and not be able to view or see the embedded code as a number. Since this is only an embedded code read by the machines, it can be a combination of alphanumeric or other characters making it nearly impossible to be broken.

The system of Digital Health ID management would be as elaborate as the Aadhaar system but the enrolment may be done at designated the health care delivery centers such as the hospitals.

IDs for organizations may be simpler since Privacy may not be an issue here.

4. Consent

It is encouraging to note that the NHS has recognized a role for Data Fiduciaries. Their role would be crucial in managing consents of data subjects.

The  “Data Trust Fiduciaries” may create three streams of data one which is identified and used by the health care operators, second which is used by marketing agencies which would be a limited data set and the third would be the set used for statistical purpose which could be anonymized.

The Data Trust Fiduciaries should be licensed on the lines of trusted intermediaries used in the Digital Signature eco system where there is a Controller of Certifying Authorities who licenses Certifying Authorities who may engage trusted Registration Agencies.

The data subjects would entrust their personal data with a chosen Data Trust Fiduciary which would provide them the Digital Health ID card for further use.

The Health care intermediaries may get the required data through the Data Trust Fiduciaries to the extent they need for providing the required service.

5. Use of Smart Contracts and Block Chain

Care should be taken not to adopt untested technologies despite the hype that may be going around some of them including the Smart Contracts and Block Chain.

6.Open Source Technology

It is welcome that NHS emphasizes Open Source technology where available. However an appropriate source code audit system should be implemented both for Open Source and Proprietary software and hardware used in NHS with appropriate security considerations in mind.

7. Miscellaneous Suggestions submitted by members of IADPP

a) Use strong and dynamic encryption as default for all move & rest cases across the health stack

b) Implement tokenisation and randomisation as default to make it difficult for hackers to discover the entire HID. Each set of 4 characters should be separately tokenised and randomised and stored in different storage arrays so that it becomes difficult or almost impossible for a hacker to uncover the complete HID

c) Impose strict and stringent penalties, including heavy fines and non bailable warrants on management of providers for misuse of Health and Patient Data

d) Use HIPPA or stricter guidelines as prescribed in GDPR for protection of Security and Privacy of Health records

e) Treat HID, Personal Health Records (PHR) as Sensitive Personal Data for purposes of Privacy

f) Explicit consent must be obtained from patients for using and sharing health data and records. It should include a clear procedure for provider to explain the reasons and implications for obtaining consent. This should be mandatory like flight safety procedure explanation by Air hostess’s prior to flight commencement. This procedure should be explained in the local language of the patient.

g) Right to recall consent by the patient must be a fundamental aspect of the Health stack.

h) Minimise and strictly limit access to individual patient health record including nature of illness etc. on a Need to Know basis.

i) Patient health data, records and archived meta-directories cannot be used for Marketing purposes.

j) Automated security checks for OS updates and adherence to prescribed security standards must be mandatory for Users and providers of the Health stack across all form factor of devices includes IOT, Embedded, Personal Computers and Mobile devices. Any device found non compliant at the initiation of the session should be blocked for access. This will force the user to update and create pressure on the software and hardware vendors and ecosystem to roll out patches quickly to close security backdoors and vulnerabilities.

k) Blockchain based smart contracts if used must be of open source like Hyperledger and use a Permissioned and scalable platform. Certain implementations of Blockchain like Bitcoin suffer from a “51% attack” which means that more than half the users can manipulate it their way by acting in concert. Care should be taken in deciding on the design and type of blockchain platform to avoid such type of attacks.

l) Information/Cyber Security tenets dictate that breach notification is the cornerstone of any law/rules and this is a globally accepted practice as well. The proposed legislation should borrow good things from various legislation of similar nature from across the globe including section where breaches under the HIPAA are classified as 1) involving 500 or more individuals and 2) Less than 500 individuals.

The proposed Indian legislation should differentiate breaches as the HIPAA does.

The proposed legislation should also propose compensation for severe breach to the affected individual.

It should also allow class-action suits for large scale breaches (thresholds to be defined in consultation with Privacy and Cybersecurity professional bodies and groups) similar to US law.

The above are the preliminary views which may be expanded in due course.

Submitted on behalf of Indian Academy of Data Protection Professionals by Na.Vijayashankar  (Naavi)

Activity 1: 29th July 2018: Webinar on National Health Stack

As one of the first activities of IADPP, IADPP held a webinar on 29th July 2018, on National health Stack (NHS).

The objective was to flag the importance of NHS as the digital back bone for the health care data in India and use the opportunity to place some suggestions with the Niti Ayog as requested by them.

Accordingly, Naavi briefly presented the NHS proposition which involves building a framework for enabling creation of a national health care data exchange to enable the smooth functioning of the Aysushman Bharat scheme under which 1.5 lakh health care service centers need to be connected with over 10 crore insurance beneficiary families. Additionally, the framework could support other heath care beneficiaries outside the Aysuhman Bharat scheme also along with the health care industry in general.

One of the key aspects of the NHS is the creation of “Registries” for beneficiaries, the health care providers etc and API s for transfer of transaction information. The data base would also assist the Health Insurance industry to prevent frauds and therefore has to support data analytics.

Once the framework is in place, even the DISHA 2018 and PDPA 2018 may adopt the framework for defining the permitted method of processing health care data.

Considering the Privacy concerns particularly in the aftermath of the PDPA 2018 draft which has been released just now, it was necessary to raise the general concerns of the Data Protection professionals regarding the security of the health data and privacy issues inherent in the proposed  scheme.

Hence IADPP collected some views of its members and submitted the following brief feedback.

This report was collated in a hurry to meet the deadline and in the event the dead line is extended or NITI Ayog organizes any public contact program, we may use the opportunity to expand on the proposition.

Members who have some views, may continue to send their information to us so that they may be published or forwarded to Nit Ayog for their information.