 This session is going to review the key privacy and security considerations around the personal and sensitive data that are stored in DHS2 with a particular emphasis on individual level data. We'll try to identify the activities recommended for developing and ensuring good practice regarding privacy and security during the implementation of a DHS2 program. So we'll be doing an overview of the key concerns regarding privacy, an overview of relevant legislation and norms, and some practical recommendations for ensuring good practice, starting with the key concerns. By their very nature, health information systems contain sensitive data related to the identity of the individual related to their health status related perhaps to their location. It also contains data relevant for the management of the health system that can often be politically sensitive. So there are a number of key concerns about how to manage and take care of this data. We have the countries that we seek to support with DHS2 do not have well established policies or norms that protect this sensitive data. In particular, individual level data or personally identifiable information is both sensitive and underrepresented at the policy and practice levels in many of the countries where we work. In practical terms, individual data can be used inappropriately by accident or intent and bring about harm. Regarding personal data and DHS to configuration tools can be used to reduce the risk of misuse or inappropriate access to sensitive data. It's important to remember that data privacy doesn't happen by accident must be planned for budgeted processes established and should be a key part of any implementation. I just mentioned some of the data types with India just to and the privacy concerns related to them within the health management information system and at the aggregate level. The performance of the public health sector can be politically and culturally sensitive, for example, HIV case metrics, and it can impact people's jobs and raise concerns globally if this information is shared inappropriately or accessed by individuals that were not meant to have access. The presentation of aggregate data should be dependent on internal processes and not shared outside of those processes without approval. When it comes to individual level data, the concerns are even greater individual level data is represented in DHS to in two ways and often includes personally identifiable information and falls into a higher category for protection. Data often contains specific data relating to campaigns, individual health events or treatment, etc. Tracker data, which is associated with an individual or attract entity is intended as longitudinal record and it's often following patients or clients over time either within individual programs or in a more sophisticated registry. Access control is one of the key tools in DHS to to protect the privacy and security of data. The designation of who and under what circumstances can access either viewing and entering or editing data should be based on documented policy agreed to by the proper authorities. The policy should take into consideration the various roles and responsibilities inherent in the health program using the DHS to system, including things like the turnover of staff and the hiring of new individuals. So that the training and the establishment of user access is something that is consistently monitored and taken care of DHS to as a platform provides several layers of access control. User roles which can be designated based on the specific job functions and access levels of a certain type of user, whether they be a healthcare provider or a secondary data entry clerk, a supervisor or somebody at the national level. It should be assigned to specific user roles and given access based on those roles. The data access is what can grant access to specific components within DHS to these can be very granular, whether they are to specific programs or even components of those programs such as just individual stages or even certain data elements. So you have the tools available to make the limitations that are going to match up with the responsibilities of the individual. And of course the user should be assigned to specific organization units. These organization units are what represent the level of the system they're working at and the location. They should have access to data that are relevant to the location where they work and the responsibilities that they have within that location, and that this will be based on these three access control mechanisms. So let's look at some of the relevant legislation and norms that we would encounter in establishing a DHS to system legislation on personal data and privacy will vary by country. Local laws and regulations should be reviewed during the planning process for DHS to system, particularly where individual level data is involved. So from the outset what the requirements would be in the location where you are setting up the DHS to system, and this would figure into how the system ends up being configured what user roles are designed how data access is granted. The lack of such legislation in a given country will not make this easier. Actually, it would be a burden of those that are implementing the DHS to system to take the extra steps required to institute new guidelines policies and practice. So we'll take a look at some key concepts that you may want to take with you. Trying to push for new regulations or policies related to privacy and security by looking at the concepts from GDPR the General Data Protection Regulation Act for the European Union and European Economic Area. One of the key concepts is the concept of personal data. Personal data means any information relating to an identified or identifiable person, a data subject and identifier can be a name and identification number location data or an online identifier. And there are special categories of personal data that require additional protection, special categories of personal data include but are not limited to data on an individual's racial or ethnic origin, political opinions, religious or philosophical beliefs, sexual orientation, health, genetic and biometric data. Often in health information systems, there are various parts of these special categories, which are relevant to the health analysis that is being done, or that may end up being relevant in the future. So there's often an intention to collect data that would be fitting into these special categories. If you do so, you would need to make sure that you're staying compliant with any existing regulations, as well as taking the appropriate actions to restrict access to any such data. A data controller is defined in GDPR as someone who either alone or jointly with others will determine the purposes and means of the processing of personal data. The controllers are those that bear the primary responsibility for compliance. Many countries will not yet have identified or outlined the responsibilities of a data controller and it may be necessary to do so when the DHS to project is implemented. The consent is defined in the GDPR as the consent of a data subject, given freely with specific informed and unambiguous indication of their wishes by which by statement or clear affirmative action, they will proclaim agreement to the processing of their personal data. Privacy by design means that each news service or business process that makes use of personal data must take the protection of that data into consideration. This gets back to that concept of something that doesn't happen by accident privacy is something that must be planned for privacy by default also fits into this concept, recommending that the strictest privacy settings automatically apply once a customer requires a new product or service or in our case clients or patients. The data controllers or processors are only allowed to store data for the shortest possible time it takes to provide a product or a service. Minimization is the concept that the data administration must be adequate relevant and limited to what is necessary in relation to the purposes for which they're processed. Again, this is often a key challenge in DHS two settings where the data systems are meant to be maximized for the amount of information that they can collect. But it's important to keep in mind that when collecting information that could be construed as unnecessary that you would be falling afoul of some of the norms and expectations with regards to data privacy. pseudonymization is often needed in the health sector where we must still be able to identify an individual in order to support the continuum of care or be able to provide them adequate services, but still need to be able to identify identity pseudonymization refers to a privacy enhancing technique where personal data is processed without the ability to link it to a specific person. This can be achieved by making the information non attributable without additional information, which must be kept separately and is subject to various technical and organizational controls. When personalized information is still a form of personal data, its usage is heavily encouraged by the GDPR. It's even identified as a viable security measure. So we'll take now a look at several countries and how they have used principles from GDPR and encoded them into their own legislation and what their interpretations might be looking first at the United Kingdom. They outlined the seven principles of their underlying privacy regulation stemming from the GDPR starting first with lawfulness fairness and transparency, arguing that personal data should be processed lawfully fairly and in a transparent manner in a relation to individuals. In order to make purpose limitation personal data should be collected for specified explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes. This is an important consideration when we're talking about health where many countries may have a concept of storing health data long term. In order to continue to be able to do research on said data, be able to use it as a registry such as happens in Scandinavia countries for things like cancer or pregnancy. The GDPR and the UK system and interpretation of it has argued that further processing of such data for archiving purposes in the public interest, scientific or historical research purposes or statistical purpose is not considered incompatible with the initial purposes, but it would be important to be able to define what those purposes might be and have a policy around approving those purposes before they are taken action. The data minimization, the data administration in the UK must be adequate relevant and limited to what is necessary in relation to the purposes for which they're processed accuracy. Personal data should be accurate and where necessary kept up to date. Every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they're processed are erased or rectified without access. This is an aspect of privacy and security that is often under recognized when implementing DHS two systems where the individuals who have given their consent to be registered into the health system are also have an expectation that their data would be accurate, and that the data would be able to provide them adequate services or report accurately on the services that they received. So a key part of any privacy and security plan within a given country should have steps for rectifying duplicates, updating information that is incorrect, removing data that are inaccurate. Personal data should be kept in a form which permits identification of data subjects for no longer than is necessary for the purpose for which the personal data are processed. Personal data may be stored for longer periods in so far as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes. Or statistical purposes subject to implementation of the appropriate technical and organizational measures required by the GDPR in order to safeguard the rights and freedoms of individuals. This again gets back to the concept of collecting the data that you need, using it for the purposes that are already outlined, not storing it for longer than is necessary. Again this is a consideration that often hasn't been taken into account when setting up a health management information system. There's often not specific regulation about when to remove data and how long in the past data can be useful for. Again, there are exceptions outlined that would allow you to continue to use data for longer periods when there is a public interest or a scientific approach associated with it. Again, this should probably be defined and laid out clearly in a plan with the country integrity and confidentiality. The personal data should be processed in a manner that ensures appropriate security, including protection against unauthorized or unlawful processing and against accidental loss destruction or damage using appropriate technical or organizational measures. Again, the first part of this definition is something that is probably well understood, but inherent as well with data security and data privacy is that the data would be protected against accidental loss destruction or damage. This can also help bolster the argument that these systems in place and countries should have appropriate backups, offsite storage plans for continuous electricity and non interruption of data access. Again, the person and the individuals that have given their consent to be a part of this system, the expectations from the government that they would have access to necessary information, all should play into your privacy and security plan. Another country, which is a DHS to country, just looking at some examples of their data protection act passed in 2021 and the concepts that they use. It established the office of a data protection commissioner, which could be analogous to this concept of data controllers. The person shall not control or process personal data without registering as a data controller or a data processor under this act. And the expectations for the data are that they would be processed lawfully fairly and transparently the same language that was used in the UK legislation. The data would be collected for explicit specified and legitimate purposes, and not further processed in a manner incompatible with those purposes. The data would be adequate relevant and limited to what is necessary in relation to the purposes for which it is processed. The data would be accurate and where necessary kept up to date with every reasonable step taken to ensure that any inaccurate personal data is erased or rectified without delay. The data would be stored in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data is processed. The data would be processed in accordance with the rights of a data subject and processed in a manner that ensures appropriate security of the personal data, including protection against any unauthorized or unlawful processing and against any loss, destruction or damage using appropriate technical or organizational measures. You can see that much of this language is again repeated from the original GDPR and the UK legislation. The data protection act, a person shall not process sensitive personal data unless the processing is necessary for the purposes of preventive or occupational medicine. For the assessment of the working capacity of the employee for medical diagnosis, where the provision of health or social care or treatment or the management of health or social care systems and services. So the data protection acts gives specific authority for the kinds of purposes that DHS to is often used. But again, this is a clause that should be understood and referenced specifically in a data protection and privacy plan for the country. Now we'll take a look at some of the practical recommendations for ensuring good practice in your implementation of DHS to the first step for the project would be the development of a security management plan. The plan would create a high level executive security statement with a scope principles and commitments related to security. The plan should appoint or assign the role of a security manager at a management level with responsibilities across the data admin team. There's going to be a standing agenda item in the management group meetings on the progress with the security plan, and making sure to add privacy and security components to training curricula for users. Often the concepts that have outlined previously coming from GDPR our concepts that the users may not even be familiar with would be a good idea to go over those concepts and stress the importance of the different security practices that have been outlined in your security management plan. As mentioned one of the key roles that could be included is the data controller or security manager. This would be the person who has responsibility for the personal data in the system. Just to emphasize this is not simply a data administrator or somebody doing data analytics. This is a named individual who has the named and outlined responsibility for this personal data. They would be responsible for conducting routine security checks, data privacy impact assessments and working with all DHS to another systems introduced in the future. Under GDPR the level of responsibility here includes illegal responsibility to respond to all data breaches within a named timeline. So this could be something that is also considered for the policies under your data security management plan. Another initial step that would be important to take would be to do a landscape review, working with the Ministry of Health to identify the relevant policies or legislation. If that legislation exists such as in Zambia, you would conduct a data privacy impact assessment of the proposed or existing system with regards to that specific legislation. You can document the risks and mitigation measures that will keep the system in compliance in many countries they will not have legislation. You could work with the Ministry of Health to form a working group with a recognized responsibility to develop privacy and security guidelines for that system. You could seek approval for the proposed guidelines from the highest possible authority and then conduct a data privacy impact assessment as before. Now we'll take a look at what the data privacy impact assessment is, as defined in the GDPR and a practice which would be a good idea to include in your implementation. The PIA is a process designed to describe the data processing, assess its necessity and proportionality and help manage the risks to the rights and freedoms of people resulting from the processing of personal data by assessing them and determining the measures to address them. Essentially walking through your security management plan, identifying the processes corresponding to those assessing again the original intent of the system and the reason for collecting the data and ensuring that your practices are aligned with all of these original decisions. DPIAs can be started as early as is practicable in the design of the processing operation, even if some of the operations are still unknown. You can start very early in the process and update the DPIA throughout the life cycle of the project to ensure that data protection and privacy are considered and will encourage the creation of solutions which promote compliance. Just taking a look at what the cycle can look like for the DPIA and as you can see it's an ongoing and continuous cycle that can be built into your project planning. We'd start with describing the envisaged processes, assess their necessity and proportionality, take a look at what your metrics and measures would be, assess the risks to rights and freedoms of individuals associated with your system. Take a look at the measures that you have outlined and defined to address those risks, make sure everything is included in the documentation, continue with a process of monitoring and review, and always be ready to start this process again throughout the life cycle of the project. We're going to take a look at the configuration and implementation of DHS2 and how that can impact your privacy and security of your system. The DHS2 software is pre-built with a number of available features which we have discussed around data access and designing the user roles, as well as the underlying architecture and platform technology which is designed to protect your data. But this DHS2 software can be configured well or poorly. Where personal data is involved, poor software configuration can lead to increased risk of inappropriate access, which can compromise individual privacy. When it comes to the system architecture, appropriate hardware and environment for sensitive data is very important. It's important to stay up to date with routine updates of the DHS2 platform which happened twice a year and always contain additional security features as well as fixing of bugs and closing of any gaps in the technology. Access controls, as discussed before, should be designed with the roles and responsibilities relevant for the health program and will probably require input from many individuals that know the different roles of the workers and users of the system and help inform how the access controls should be applied. The system design is very important, specific efforts to reduce the data needed and avoid collecting highly sensitive data wherever possible is important. And you should have a plan for long term security oversight for doing routine security reviews, the DPIA, looking at responsiveness to any breaches that are reported or concerns that are raised. It's important to consider the impact on the project budget when you're taking into consideration privacy and security. Implementing DHS2 in accordance with privacy regulations and best practices can involve adding budget lines for conducting privacy reviews, hiring a data controller, conducting privacy trainings for administrative staff, using appropriate hardware and system environment, which will be discussed more in the hosting module. And some costs will be recurring and need to be planned for such as funding data backups so that personal data is available and can be restored in case of compromise or data loss and periodic data integrity audits and reviews. In summary, privacy and security are important considerations for DHS2. All health data should be considered sensitive, especially individual data. DHS2 implementation should be planned in compliance with local laws and the absence of legislation frameworks such as GDPR offer useful concepts for best practice. It's important to ensure that plans, procedures and people are in place and budget for this when planning. It's also important to have proper configuration of DHS2 in order to reduce the risk of privacy and security breaches.