Naavi.org

(This is in continuation of the previous article)

The PDPSI works on three different levels. The core of PDPSI is the standards. The operating part is the implementation  specifications and the visible part is the DTS.

The PDPSI Certifying body will evaluate on the basis of adherence to the standards. The implementing organization will use implementation specifications to meet the standards. The evaluating auditor will convert his evaluation into a DTS which will be disclosed.

All the three aspects namely the Standards, the implementation specifications and the DTS are inter related.

The 11 standards of PDPSI are as follows:

The requirements of each of the standards are self explanatory.

By the very nature of “Standards” these are mandatory for the purpose of certification. However the exact manner in which the standards are implemented my differ from organization to organization.

The Implementation specifications associated with PDPSI provide one suggested set of guidelines. It is open to the organization to accept them as they are or modify them.

However the modification has to be logically supported by a documentation which will create the “Implementation Charter” which becomes the operating instructions of the top management to the operational team.

The responsibility for the Charter lies with the top management which alone can decide on the risk appetite of the organization and decide what implementation specifications may be skipped and why.

A measurable mechanism is included in the standard and the DTS is a mechanism for the purpose.

The implementation is always at the enterprise level and PDPSI. It is open to the organization to create an “Enterprise within an Enterprise” to have focussed implementation in a smaller part of the organization provided it can be suitably segregated into a n independent operating zone with its own people, technology and infrastructure.

The Classification concepts are explained in the earlier articles .

The “Distributed Responsibility” concept envisages that the responsibility for implementation within the organization would not stop at the DPO but extend to every member of the workforce.

The technical controls and policy controls refer to the IT controls and policy formulations adopted by the organization. The “Culture” aspect takes care of the need to ensure that compliance is accepted by all the members of the organization and not restricted to the IS or Data Protection department alone.

The PDPSI certification program will be administered in such a manner that there is a proper documentation of the audit. The standard implementation organizations like the FDPPI may use a system of accreditation of the auditors, reporting of the audit findings, verification of audits etc to ensure that the system is reliable.

Naavi

(Continued from the previous article)

At present, PDPSI is built on 11 standards. We shall analyze what are the 11 standards that comprise of the PDPSI and the implementation specifications associated with it and how they relate to the “Certification” process.

PDPSI has adopted the HIPAA model of “Standards” and “Implementation Specifications”.

By including implementation specifications in a statutory law, HIPAA made 7 standards without implementation specifications  and 23 Required implementation specifications as part of the legal prescription. At the same time it left 22 implementation specifications as “Addressable” meaning that the management of a covered entity can take a view on whether thee 22 implementation specifications need to be implemented and if so whether they can be implemented in a manner different from what is suggested in the law.

In other words, HIPAA prescribes 30 statutory prescriptions on how to safeguard the protected health information by the covered entities and 22 other guidance indications that are optional with the condition that if they are replaced with alternatives, sufficient justification has to be provided through documentation.

PDPSI is currently designed on 11 standards and 45 implementation specifications. But under PDPSI, the standards and implementation specifications are used differently from HIPAA. The PDPSI standards are defined for the conduct of PDPSI audit by a lead PDPSI auditor.

However the implementing company is provided with 45 guidance indications which can be used by the Data Fiduciaries and Data Processors. The documentation of whether these 45 implementation specifications are used in toto or some of them replaced with other controls and if so the reasons thereof, is addressed through one of the  documents namely the “Implementation Charter” which is one of the 11 standards recommended. The PDPSI auditor will evaluate the implementation of the 11 standards reflected in the 45 implementation specifications along with the logic presented in the Implementation charter on why one or more of the suggested specifications are ignored or replaced.

The PDPSI auditor’s responsibility is in verifying the implementation of the standards and the implementation specifications adopted in the Implementation Charter and provides his certificate on whether the implementation system is set to work reasonably. The implementation specification includes what may be called “Controls” in other systems .

While the Standards and the Implementation specifications are created by the PDPSI agency (except to the extent the implementation specifications are modified through the implementation charter), the controls are created by the organization themselves.

A few of the key implementation specifications are explained in the PDPSI specification itself to the next level where they become “Control Descriptions”. But most of the other specifications are left without the subordinate “Control Level Description” because it is felt that the industry already has many best practice alternatives for these specifications. The “Control Descriptions” which are provided as part of the PDPSI documentation are those which may not be commonly used by the industry.

To this extent the “Implementation specification with control description” is similar to the “15 Standards with implementation specifications” in HIPAA and the “Implementation specification without Control Specification” is similar to the 7 standards without implementation specifications in HIPAA”.

The structure of PDPSI will therefore look like the following.

Naavi

…. To Be continued

The National Digital Health Mission (NDHM) has issued the Health Data management policy which has been introduced over the previous series of articles. As per the document on the NDHM website, the Health Data Management Policy (HDMP) is the first step in realizing the NDHM’s guiding principle of “Security By Design” for the “protection of the data principal’s personal digital heath data privacy”. This acts as the minimum standard for data protection that should be followed across the board in order to ensure compliance of relevant and applicable laws, rules and regulations.

Participation of an individual or a medical practitioner or a health facility in the scheme is voluntary and the participants when they opt in would be issued a “Health ID” or “Digi-Doctor ID” or a Health Facility ID”. These IDs will be unique as long as the participants are within the system and if they opt out, they will be deactivated and in the case of the individuals may be deleted and erased on request.

 In order that the policy is complied with, it would be necessary for organizations to be compliant with the provisions of the policy along with the applicable laws. Presently, the applicable law is Information Technology Act 2000 as amended in 2008 which under Section 43A addresses the requirements of securing “Health Data”. However, the PDPB 2019 represents the “Due Diligence” and is recognized in the policy itself.

In order to enable organizations to  adopt to the compliance requirements, Naavi suggests the use of the “PDPSI” system which is being developed  in the context of  PDPA of India or PDPAI (Proposed). As we await the PDPB 2019 to become a law, we can apply the PDPSI to the NDHM policy implementation as is briefly explained here.

PDPSI stands for “Personal Data Protection Standard of India” and is meant to assist SME/MSME s to adopt PDPA (proposed) as also to develop a Certifiable standard along with an assessment system for Data Trust Score (DTS) evaluation.

After the undersigned presented the concept of PDPSI and DTS about 2 years back, the two systems have been widely discussed with the professionals associated with the FDPPI movement. (See www.fdppi.in for more information on FDPPI). As a result of these deliberations, the PDPSI has evolved along with the DTS system and these systems would be explained in a series of articles here.

The PDPSI Ecosystem

To start with, we need to recognize that the PDPSI is a complete ecosystem that supports the Organizations that require PDPAI (proposed) to be implemented in their organizations.

PDPSI is developed as a “Unified System” for compliance of multiple Data Protection regimes and is applicable not only for compliance of PDPA of India but also for GDPR or DIFC DPL, Singapore PDPA, CCPA or Brazil LGPD or any other data protection regulation.

Hence PDPSI is also ready as a compliance eco system for the NDHM-HDMP.

The PDPSI Eco system consists of Standards, Implementation Specifications and a DTS system.

The PDPSI serves the requirement of different types of users. The Standards are meant to be used by accredited auditors to Certify an organization. The Implementation Specifications are meant to be used by the implementers as a guideline for compliance. On the other hand, The DTS is meant to be used by Data Auditors who after their audit present their assessment in the form of a DTS.

PDPSI is meant to be used as a unified platform for multiple Data Protection Compliance. The DTS however has to be computed differently for different compliance requirements and therefore, DTS-In will be different from DTS-GDPR for the same organization.

We shall explore the concept of PDPSI further in the follow up articles.

Naavi

(This is a continuation of the previous Article)

The Health Data Protection policy announced by NHD scheme has adopted the Obligations of data fiduciaries and rights of data principles from the Personal Data Protection Bill 2019.

Accordingly the obligations include

1.Accountability,

2.Transparency,  (Including Data Trust Score, Grievance Redressal, Periodical update of changes in the  processing)

3. Privacy by Design . (The system is envisaged to have a decentralized storage of data which could mean multiple data bases at State/UT level introducing the security requirements commensurate with the associated risks. )

4. Choice and Consent driven sharing

5. Purpose limitation

6.Collection, Use and Storage limitation

7. Empowerment of the rights guaranteed

8. Maintenance of Data Quality

9. Reasonable Security Practices and Procedures

As could be expected, the Ministry of Health which is in love with ISO standards has stated that “The data fiduciaries will implement the International Standard IS/ISO/IEC 27001 on “Information Technology – Security Techniques – Information Security Management System – Requirements” as well as any other standard as may be applicable to them”

Naavi.org has extensively discussed the desirability of the regulations not to suggest a particular proprietary standard to be implemented.

To reiterate, this means that every Data Fiduciary is being forced by the regulation to buy an ISO 27001 certificate which has a payment tag.

It is impossible to avoid a perception that this is being suggested for reasons other than the necessity and it is suggested that the Ministry drops this provision.

It must be also pointed out that ISO 27001 does not support the DTS system and is not comprehensive enough for the compliance of the Techno Legal requirement.

The policy suggests a NDHM-CISO and NDHM-DPO to be appointed by the organizations.

Obligations of Data Processors are similar to PDPB 2019 as entities bound by contractual agreements.

The Data Fiduciary needs to conduct a Data Protection Impact Assessment and maintain appropriate records. They should also conduct periodical review audits.

Sharing of Data

Sharing of de-identified and anonymized data may be permitted while sharing within the community of Health Information Users who will have obligations similar to the Data Fiduciary.

Grievance Redressal

The policy envisages that the Data Fiduciaries shall have a Grievance Rederssal mechanism and the DPO will be accountable to redress the grievances.

Data Breach Management

The National health Authority (NHA) is expected to notify the time limits related to the notification of data breaches. The NHA will report the breaches to the Cert-In for the time being.

NDHM Sandbox Environment

It is interesting to note that the Ministry is providing a sand box arrangement for software systems to be tested in a controlled environment. The Sandbox hosts APIs for Health ID service, Consent Manager gateway etc.

Penalties

Any non compliance of the regulations may attract cancellation of the registration and stoppage of contracts.

Summary

While the policy is an attempt to implement the provisions of the PDPB 2019 to the health sector, once the PDPA comes into being, it would be better if this policy is simplified to avoid overlapping with the PDPA provisions.

Further the references to the ISO audit as if it is mandatory must be removed and the security inconsistencies need to be addressed.

We keep our fingers crossed to see how the Ministry would respond.

Naavi

All Articles in the series:

1.National Digital health mission shows the way… Be Ready before PDPA becomes effective

2.NDHM is a trend setter… Get started early on the Privacy Protection journey

3.Consent Management under NDHM

4. NDHM-Health Management policy Objective need not be linked to ISO standard

5.Managing IDs in NHD ecosystem

6. Data Fiduciaries under NDHM

(This is a continuation of the earlier article)

Presently most of the Government’s schemes use the Aadhaar ID as the identity determinant of the citizens. It is the attempt to link Aadhaar ID to property registrations to prevent benami properties which triggered the big Privacy movement in India which lead to the Puttaswamy judgement. At the same time, Aadhaar IDs have been subjected to many security breach incidents to the extent that the dark web may be having the Aadhaar information of a very large number of Indian citizens. Also when the Aadhaar ID were first issued, the security systems were so weak that many fake Aadhaar IDs have been issued because the enrollment was done by agents. There have been instances of enrollment laptops being stolen and probably every enrolling agent kept a copy of his work. As a result Aadhaar information is no longer the secret it is supposed to be. If any privacy leak is possible through a linkage to Aadhaar ID, perhaps it has already occurred.

The Government is therefore under a dilemma on whether they should use the same Aadhaar ID as the identity of the individuals in the NHD system. Under HIPAA US government used the social security number for individuals and tax registration numbers for covered entities to create the HIPAA data base. But NHD has decided to issue new IDs to the stakeholders in the NHD ecosystem.

Accordingly, several unique IDs are being suggested to be created to identify the users of the NHD ecosystem.

The IDs are

1. Health ID to every individual user of the system. All consents would be linked to this Health ID. It is stated that the participation in the system is voluntary so that Health ID will only be unique as long as the individual is using the system and may be cancelled at his option. As a result the person may seek re-allocation of the ID if he opts in at a later time. Aadhaar number may be used for registration but the allocation of Health ID is not excluded for persons not having Aadhaar ID. As a result this data base will be independent of the Aadhaar data base. The ID will be issued by the Data Fiduciary who is registered with the NHA similar to the agents of UIDAI who issued the original Aadhaar IDs and could be a point of security weakness in the days to come.
2. Health Practitioner ID to every doctor to permit him to work under the system. This will also provide an opportunity to opt out . Authorized registrars would be appointed for the purpose of registration.
3. Health Facility ID to every health care facility which could be hospitals, pharmacies, diagnostic centers etc. The procedure for registering the health facility ID would be provided in due course.

Some of the states are also creating “Family IDs” and it may be linked to the Health IDs under this project. These two IDs will soon be added to the Aadhaar ID and PAN card for the individuals besides the Voter ID, Senior Citizen ID etc creating a host of Government IDs which an individual need to maintain.

The registration, de-registration as well as re-registration  will result in submission of personal information, need to delete the same and re-enter the same, maintaining the accuracy of the information, avoiding fake information being uploaded are issues that need to be addressed.

In the scheme now envisaged there is scope for fraudulent double registrations particularly if Aadhaar is not linked to the Health IDs. I hope this would be properly addressed during implementation.

(To Be continued..)

Naavi

All Articles in the series:

1.National Digital health mission shows the way… Be Ready before PDPA becomes effective

2.NDHM is a trend setter… Get started early on the Privacy Protection journey

3.Consent Management under NDHM

4. NDHM-Health Management policy Objective need not be linked to ISO standard

5.Managing IDs in NHD ecosystem

6. Data Fiduciaries under NDHM

(This is a continuation of the earlier article)

Before we dive deeper into the NDHM’s Health Data Management policy, there is a need to discuss one philosophical issue about what should be the objective of such policy and even the laws such as PDPA.

For the time being we shall assume that this “NDHM-HDM Policy is a directive from the Ministry to all the participants of the NDHM eco system and hence has the force of a near statutory regulation. Presently it is aligned to Section 43A of the ITA 2000 and once PDPA comes into existence, this policy will get aligned to the PDPA and get a real legal force.

Hence we need to discuss what should be the objectives of such laws/regulations.

The ITA 2000 objective was to promote E Commerce and to protect data through various measures of information security and cyber crime control. The objective of PDPA is to protect the “Privacy of an Indian Citizen”.

The policy declares that it is the first step in realizing NDHM’s guiding principle of “Security and Privacy by Design” for the protection of individual’s data privacy. This statement is in alignment with the objectives of PDPA. The policy is also careful to declare that it is subordinate to other applicable laws.

However, in Paragraph 3 of the Policy, the policy has stumbled to declare that one of the key objectives of this policy includes

“to create a system of digital personal and medical health records which is easily accessible to individuals and health service providers and is purely voluntary in nature, based on the consent of individuals, and

in compliance with international standards such as ISO/TS 17975:2015 (defines the set of frameworks of consent for the collection and processing of health data by healthcare practitioners and other entities) and

other relevant standards related to data interoperability and data sharing as may be notified for the implementation of NDHM from time to time”

It is difficult to understand whether the second para above was required or could have been deleted altogether since it indicates as if it is one of the objectives of this policy to be compliant with an ISO standard.

It appears that there is no need to frame a law or a regulation to be compliant with a “Standard” unless the “Standard” itself is a law as it happens in a prescriptive law such as HIPAA.

In other laws, the law sets down a principle which is expanded in the regulatory notifications. After this it is for the industry to develop their own best practices which may be called “Standards” or by any other name.  Those who develop “Standards” align the standards to the law and not the other way round.

ISO standards some times are mistaken as “Regulatory Standards” and this perception needs to be changed. ISO standard is subordinate to law and is a tool of compliance. Law cannot be a tool of compliance of an ISO standard.

It would be better to correct this aspect in the policy.

(To Be continued)

Naavi

All Articles in the series:

1.National Digital health mission shows the way… Be Ready before PDPA becomes effective

2.NDHM is a trend setter… Get started early on the Privacy Protection journey

3.Consent Management under NDHM

4. NDHM-Health Management policy Objective need not be linked to ISO standard

5.Managing IDs in NHD ecosystem

6. Data Fiduciaries under NDHM