Send us your submission on the National Digital Health Blueprint to trisha@medianama.com

*

“The National Digital Health Ecosystem (NDHE) will be governed by the Personal Data Protection Bill, when passed into law,” noted the Lakshmi Mittal and Family South Asia Institute, Harvard University in their submission (attached below) on the National Digital Health Blueprint. It anticipates challenges given the existence of several overlapping health specific laws, which determine issues around consent, privacy, and data flow, such as the the Mental Healthcare Act, 2017, to the HIV/AIDS Act, 2017 and the Transplantation of Human Organs and Tissues Act, 1994. The submission was made the institute’s India Digital Health Net.

The Ministry of Health had in July invited public comments on the NDHB, the Blueprint envisions a architecture for data flow, EHR systems, and use of technology in every sphere of healthcare. The ministry held a public consultation on the Blueprint earlier this month, our report here.

The institute’s main points raised in the submission are summarised here:

Privacy and data protection

  • Although the data protection law requires data minimisation, “forcing minimisation may impede the wide-ranging future possibilities offered by AI and ML to influence health, habits and lifestyles.”
  • On inclusivity: The scope of inclusivity defined in the NDHB must account for biases inherent in health data and health delivery systems that go beyond terrain limitations. Moreover, initiatives like telemedicine should not be considered stand-alone technological solutions to delivery problems, but one adjunct to task-shifting and supervision, to improve care in remote regions.
  • Privacy: The transparency and accountability necessary to make NDHM a success is best supported by an accompanying regulatory framework that allows enforceability. “A code of practice in line with the Data Protection Bill that speaks to these challenges while dealing with health data, is warranted.”
  • Recommendations for ensuring accountability of service providers:
    • Wider consultations with patient groups, practitioners, and professional societies will help determine better performance metrics, and
    • Apply design thinking principles while developing data capture mechanisms to measure performance without reverting to provider-initiated electronic forms as the default.

Issues surrounding NDHB’s mandates and PDP Bill

The NDHB states that all registries and databases of the NDHB shall be built as ‘Single Source of Truth’ The institute said that health data should be examined in light of the PDP Bill, not as one subject to the concept of ownership, but subject to control and access.

Also, NDHB recommends use of the H-Cloud for building layers 2 & 3, but this architecture “must be revisited” in the light of data localisation requirements in the Personal Data Protection Bill, said the institute. “Localisation of critical personal data with mirroring or free transfer of non-critical data to hybrid entities may be desirable, to allow domestic and international cloud storage, as would be necessitated to avail of the global ecosystem of digital health services (apps, wearables, etc.).”

Security and Privacy: privacy regulator for health “useful”

State’s capacity to manage privacy and security ops: Since the Security and Privacy operation centres centralise most of the responsility to secure data, and act on consent and privacy breaches, it’s necessary to lay out the state’s capacity to manage, maintain and update such operations, said the institute. “The Operations Centre must go beyond the traditional means of intrusion detection to monitor and respond to breaches and attacks,” and it can do so by using AI and ML, says the submission.

What about privacy ops and the PDP Bill? The institute also points out that its unclear how the POC (privacy operations centre) will interact with the data controller under the Data Protection laws. “There appears to be overlapping subject-matter jurisdiction with respect to data protection and privacy”, the key questions here are:

  1. Will the POC then be set up as an independent and neutral entity?
  2. What powers will it have in case data breaches/privacy violations are detected? At what levels will these audits operate?

Privacy regulator for health: According to the institute, the concept of a sector-specific privacy regulator for healthcare is useful “to ensure that the nuances required in the context of health are appropriately harmonised with the broad principles of privacy set out under the Personal Data Protection Bill.”

Personal Health Identifier: patient control, Aadhaar, and event linkage

The institute recommends a centralised approach for the PHI because according to it, its easier for a single organisation to provide and manage identifiers across the country, and because it evokes higher trust and authenticity, (when supported with adequate institutional mechanisms and checks). “But this would also prevent the patient from opting to have more than one identifier, and to delink certain aspects of their data from the record.”… “Patient MUST have the ability to NOT link a particular record (for example, a visit to an STD clinic for treatment of sexually transmitted disease) to his/her PHR, which is otherwise accessed by a wide network of their care providers,” says their submission.

Recommendations:

  • Use of Aadhaar, and authentication failures: The architecture must also allow multiple linkable IDs. Aadhaar would best serve the purpose of authentication. It must further be clarified here that Aadhaar authentication can, as dictated by current law, be used only for welfare schemes notified under section 7 of the Aadhaar Act, and not generally for the provision of healthcare services. Even within this sub-group, allowing multiple identifiers is necessary given the non-negligible rates of authentication failures under Aadhaar.
  • Event linkage must be voluntary: The linkage of a visit or healthcare event to the PHI must be voluntary, and under patient control. Patients must be allowed to seek some services anonymously, with exceptions being governed by policy or law (say, for example, for notifiable diseases).
  • Recommends the use of Good ID Principles to design the digital ID. This includes legislative backing for its creation, clearly specified actors and purposes, adequate redressal and accountability mechanisms and the avoidance of mission creep.
  • Articulate the NDHM policy about service denial or delays when authentication or identification fails (while needing to build in fraud protection).

Personal Health Record: HDAF model by National Health Stack is more passive

The document needs to provide more clarity on PHR, it currently suggests an up-to-date consolidated record, with the patient being able to consent to sharing of data from this record, per the institute’s submission. It also says that every time a record is created, it will be exported to the PHR, and for this, the data would need to be stored in Secure Health Data Repositories maintained by the government.

“While this model has the benefit of Data Integrity assertion (since once generated and issued, the health document is immutable), there is little evidence that civil society will accept the government’s role here as the trustee of their health data (collected also from all non-public service nodes in the ecosystem)”.

Recommendations:

  • It would be advisable instead that the data remains at point of generation and be linked to the PHR, unless storage at point of generation is unreliable. “The PHR should not necessarily aggregate and archive all data, but be an access point or conduit to key elements of the data,” the submission adds.
  • The Health Data Access Fiduciary (HDAF) model proposed by the National Health Stack describes a more passive model, with more patient autonomy. It separates the function of creating a longitudinal patient record, and an accessible PHR for use by patients, and through patients, by providers and third-parties.
  • The NDHB states taht PHR content should allow for evolution, but this is unsafe, duplicative, undesirable and expensive design.
  • The Blueprint suggests (in Layer 3) using a reference link, where data will sit at source, but a reference link to the data will be exported to the Health Locker. This arrangement is far more desirable, provided the linking to the Health Locker is consented.
  • The Blueprint says that PHR will capture data relating to only significant medical and health episodes and events of types to be identified and notified, but this needs for clarity.
  • Problems like physician fatigue and data overload need to be managed at source, and cannot be addressed by manipulating PHR design.
  • If data storage is federated and linked through master references, additional clarification is needed to address situations when the provider ceases to exist (practitioner death, institutional insolvency, etc.); or the data “at source” are archived and offline. If all participants are expected to be online, all the time, the NDHB should articulate who will bear these costs.
  • The NDHB should articulate policies regarding access to data once the patient is deceased, or when the patient cannot provide consent (when unconscious, or critically ill).

Health master directories and registries

Recommendations:

  1. The categories listed in Figure 2.1 in the NDHB could be simplified into providers and facilities. Consider the entire range of actors whose identities need to be maintained and updated.
  2. The emphasis on NCDs, while a national priority, must be replaced by a more agnostic design. These specifics may be better articulated in subsequent implementation plans.
  3. Family Identifiers, while culturally relevant in the Indian context, cannot be a prerequisite. It violates data minimisation principles as well as privacy.
  4. Reference and pointers should also not be considered a given, and must adhere to the same principles of consent, transparency, auditability and reference indexing articulated in prior sections.
  5. Consider maintaining decentralised registries.
  6. Registries need to be constantly notified and updated (push or pull).
  7. Need further clarification on Stipulation D.

Cautions on anonymisation, cites inevitable failure

“Most, if not all, data referred to in this Blueprint will therefore automatically attract the privacy and data security provisions under the Information Technology Act, 2000 (and soon the Privacy Data Protection Bill (Act)),” said the institute in its submission, adding that “If a data processor does not want to be subject to these requirements, they may choose to securely and irreversibly anonymise their data instead.”

The institute notes in its submission that the current state-of-the-art process of de-identification and anonymisation are likely to fail in the near future, given the permanent nature of digital data and rapidly evolving AI tools. Further it points out that anonymisation also damages data and renders it less useful in the future. “Anonymisation must therefore not be a substitute for consent but may be viewed as an inducement in addition to consent. Consent is not without its limitations”.

Recommendations:

  • Aggregating all records in one place and then anonymising them is not a good idea.
  • Anonymisation must be done as close to the source as possible, for secondary use.
  • Secondary uses must be audited and subject to time- and purpose-limitation of data, whether or not the data are anonymised.
  • Even better, the secondary user should delete the data immediately after use and ask for the deidentified data again if they need it. That keeps the patient in the consent loop.
  • Anonymisation must not be assumed to be irreversible
  • Anonymisation must not be considered a substitute for consent, but an adjunct

Consent policy must be based on explicit consent, ability to revoke it

“While we agree with the primacy of consent in this design, we also recognise the limitations of consent – where a growing body of evidence shows that consent is not entirely always understood,” said the institute.

Recommendations:

  • The MeitY standard cited, only provides the technical specifications for recording electronic consent. A detailed consent policy must accompany the NDHB to clarify operational issues.
  • Such a consent policy must be based on explicit consent, and place a fiduciary duty on any data processing entity to protect the privacy and security of health data.
  • Any consent assumed to be implicit (or in rare cases, when waived) must be supported by transparency and auditability. And even if implied, it should be purpose- and time-limited; and revocable.
  • The NDHB should describe how purpose-limitation and time-limitation apply to data, whether identifiable, de-identified or anonymised.
  • The NDHB should also describe what the ability to revoke consent would look like, and how it would be operationalised.

Health locker, should promote data minimisation

  • Prototype and test the HDAF model proposed by the NHS as the architecture that undergirds the PHR and consented access across various nodes in the health delivery ecosystem. Data Minimisation is key.
  • The proposal for using the design of the DigiLocker as the default intermediary needs some clarification. While it can certainly be one option, other options that may be provided by the states or the private sector should also be allowed.
  • The Health Locker must be designed to promote data minimisation. A reference link avoids having all data aggregated centrally and while there is the risk that poor connectivity will result in some remote data not being accessible from time to time, it also means we are not creating a repository that will become a single point of failure from a privacy and security standpoint.
  • The Blueprint is unclear on the scope of the Health Locker. It could host some or all of: “original” documents, a clinical database (personal EHR), an authorisation server, access logs, and a relationship locator service (the links). The open API must be designed to support any of these even if all are not implemented in a particular Health Locker at the same time.
  • Further clarification on how the Health Locker will receive and share structured data is necessary. A simple import and export of pdf files will keep India in the dark ages, precluding patients from benefiting from third-party applications.

Heavy reliance on internet access and smartphones

Recommendations:

  • The Blueprint’s heavy reliance on smartphones is not advisable. On the contrary, the Access and Delivery layer, in addition to digital services, may want to consider an analogue adjunct, like a chip-based health ID card as both a redundancy, and a bridge to the future.
  • The system should allow for Proxies or Delegates to represent children, incapacitated adults, family members that share technology, or those that are digitally naïve.
  • The distinction between Layers 4 and 5 are not self-evident, since the web-portal and apps may also be considered applications built on the health data grid.

Standards for consent management

“Consent needs to be looked at carefully in light of new machine learning technologies, big data use, and phenomena such as consent fatigue and the inadequacy of informed consent,” said the institute. “There is need to conduct a thorough review of all relevant existing and evolving laws that may have overlapping and sometimes incongruous impact on data exchange as envisioned here (for example, The HIV/AIDS Act 2017, The Mental Healthcare Act, 2017, DNA Technology (Use and Application) Regulation Bill, 2019, the PDP Bill.” There must be strong lateral linkages with other policies like National Data Sharing and Accessibility Policy (NDSAP), Department of Biotechnology’s Biological data storage, sharing and access Policy.

Recommendations:

  • The recording of consent must not be exclusively reliant on Aadhaar, and alternatives to Aadhaar e-sign must be included in the NDHB. The consent policy must account for situations where proxy consent may be needed (for instance where the patient is unconscious).
  • MeitY consent specs not enough: A sophisticated system is needed to effectively evaluate the implementation of the digital consent artefacts for core privacy principles such as data minimisation. MeitY’s consent specifications are inadequate for this purpose.
  • Patients should not be asked to share their consent policies via API. Rather, the personal stack should include a standards-based authorisation service such as User Managed Access (UMA) that centralises the policy decision point and distributes the authorisation enforcement.
  • The statement that discusses “managing consent” may be rephrased to state that consent must be meaningfully obtained, ensured and upheld (rather than managed).

Open source

“The notion of Core and Reusable Applications and Services as part of the Application Layer may be further strengthened by maintaining them as Free and Open Source Software (FOSS), supported by an active open source community,” said the institute in its submission.

Standards take time to roll out across the ecosystem and are subject to “regulatory capture” – a prominent problem in the US system. By mandating open source standards, adoption does not become a competitive risk because vendor lock-in is impractical. This also accelerates standards development. Open source and standards complement one another and should both be mandated

Recommendations:

  1. An effective open source solution must be governed, managed and maintained by a dedicated community. The NDHB must articulate how the NDHM will seed and foster such communities across India.
  2. If the applications developed in the Application layer are expected to be open source, with the attendant publication of the source code, adequate mitigation strategies will be essential to avert potential security threats. Publishing the source code as open source also ensures significant peer review and scrutiny from the wider ecosystem thus making it stronger and less vulnerable. Security standards have to be published to ensure that application
  3. NDHE should also make provision to accommodate applications that are not open source in the Application Layer as long as the open standards and OpenAPI requirements are met and that interoperability is ensured. This will also spur innovation from private providers in this space.

Other recommendations

  • It may be advisable to create Regulatory Sandboxes in various jurisdictions across India, to rapidly test prototypes that are being proposed by the National Digital Health Blueprint (NDHB), before they are adopted at national scale.
  • NDHB must define Health Data, such that it allows for novel new data sources to be included and aligns with key domestic laws especially the Personal Data Protection (PDP) Bill.
  • Among their recommendations regarding NDHM’s objectives are explicitly also include the protection of patient privacy, security of health data, continuity of care and transparency of functioning in its stated objectives, and it should describe the timelines, incentives, budgets, maintenance plans for directories and registries