Part 3: Privacy analysis
Our approach
3.1 The OAIC’s Privacy management framework: enabling compliance and encouraging good practice[4] provides guidance and steps the OAIC expects agencies and organisations to take to meet their ongoing compliance obligations under APP 1.2. The privacy analysis in this section of the report considers the way in which DHS implements these steps when handling personal information in the course of providing My Health Record contact services.
3.2 In addition, the analysis in this section has regard to the OAIC’s APP Guidelines[5] which outline the mandatory requirements of the APPs, how the OAIC will interpret the APPs and matters the OAIC may take in to account when exercising functions and powers under the Privacy Act. Our approach also considered the broader legislative environment created by the My Health Records Act, where appropriate.
Privacy protective practices
Governance and culture
3.3 DHS appears to have a good privacy culture. Based on the OAIC’s review of documents and interviews with DHS staff, there is a general awareness of privacy and security issues and a good general understanding of the importance of appropriate information handling practices.
3.4 The OAIC observed a positive culture of privacy awareness within the Digital Health Branch. The team members interviewed during the assessment demonstrated a sound understanding of the Branch’s processes and the privacy implications of their work.
3.5 The OAIC noted that there was frequent interaction and collaboration between teams within the Digital Health Branch, as well as between the Digital Health Branch and the Programme Advice and Privacy Branch.
3.6 The OAIC observed a good level of collaboration between teams responsible for the operational aspects of delivering My Health Record contact services, and teams responsible for policy and legislative work. Service officers in the Digital Health Operations team frequently meet and discuss issues with the Legislation and Project Support team.
3.7 In addition, all new service officers from the Digital Health Operations team spend a day with the Legislation and Project Support team to gain an understanding of the legislative and policy requirements of the My Health Record system.
3.8 While teams and branches at DHS collaborate well internally, there also appeared to be good governance arrangements in place between DHS and the Agency. DHS staff frequently meet with and discuss issues over the phone with staff at the Agency. In addition, DHS’s National Manager (who oversees the work of the Digital Health Branch) holds weekly meetings with their counterpart at the Agency.
3.9 The data integrity team within the Digital Health Branch is responsible for taking corrective action on affected My Health Records where intertwined[6] Medicare records exist. They also respond to any My Health Record-related data breaches. The creation of this specialist team highlights the priority given to data integrity. The OAIC considers the development of this dedicated team to be a good step in ensuring that data integrity is a high priority for DHS and that data integrity issues are efficiently and effectively responded to by staff that have particularly expertise in that area.
Training
3.10 All staff at DHS are required to undertake mandatory privacy and fraud awareness training upon commencement of employment. Each year all DHS staff are also required to complete refresher training on privacy and fraud.
3.11 DHS staff who act as My Health Record service officers are also required to complete training modules specifically on the My Health Record system. These modules detail the steps service officers must take to perform certain functions, and also explain the legislative provisions that protect personal information in the My Health Record system.
3.12 During the fieldwork component of the assessment, the OAIC observed a number of DHS’ training modules, including the privacy training undertaken by all DHS staff and the My Health Record-specific training.
3.13 The training modules clearly and comprehensively explain the privacy implications related to the core work that DHS staff carry out. The modules were engaging and interactive, and had the same ‘look and feel’ as other DHS training modules.
3.14 The OAIC considers the training modules – including the mandatory privacy and fraud yearly refresher training – to be comprehensive and a good step in ensuring that staff are aware of their privacy obligations.
Privacy Threshold Assessment process
3.15 DHS’s Operational Privacy Policy requires DHS staff to undertake a Privacy Threshold Assessment (PTA) for all new projects and for any other activities, which involve changes to the way DHS manages (i.e. collects, discloses, stores or uses) any personal information.
3.16 If the outcome of the PTA is that the project or activity involves a significant change to DHS’ management of personal information, or might have a significant impact on the privacy of individuals, then a Privacy Impact Assessment (PIA) is required unless otherwise authorised by the Secretary or a Deputy Secretary of DHS. Significant matters that do not require a PIA may require a privacy assurance provided by the Programme Advice and Privacy Branch.
3.17 PTAs are generally undertaken to determine, early in a project, whether it is necessary to conduct a PIA or for further assurance to be provided by the Programme Advice and Privacy Branch in relation to new or changed procedures.
3.18 The Programme Advice and Privacy Branch has implemented a process for DHS staff to undertake PTAs, with information and guidance on how to complete a PTA available on DHS’s intranet. The Programme Advice and Privacy Branch also provides support or assistance where required to complete the assessment.
3.19 The OAIC understands that PTAs (including those related to the My Health Record system) are conducted by individual branches and then reviewed by a central project team that is part of the Programme Advice and Privacy Branch.
3.20 The OAIC considers the elevation of PTAs to the Programme Advice and Privacy Branch a good practice as it creates a cross-branch oversight mechanism. Additionally, it helps ensure that the Programme Advice and Privacy Branch can proactively provide guidance on the potential privacy impacts of new projects.
3.21 The level of detail included in DHS’s Operational Privacy Policy provides clarity and certainty about the PTA process required to be undertaken by staff. Additionally, the elevation of approvals for not conducting a PIA to the Secretary and Deputy Secretary level suggests that PIAs are considered an intrinsic part of projects and activities that handle personal information.
3.22 Where the change relates to the My Health Record system as a whole (and not a specific DHS component), the Agency is responsible for commissioning a PIA, as relevant.
Internal policies and procedures
3.23 The OAIC reviewed a number of detailed policies and procedures developed by the Digital Health Branch to assist staff to provide the contact services and to respond to unplanned incidents. These included privacy incident process documents and a risk management plan, identity verification processes and dealing with enquiries to access and correct personal information and complaints made by individuals.
3.24 In developing policies and procedures – such as those related to incident and risk management – the Digital Health Branch noted that it considers how the policies and procedures fit within the broader DHS Privacy Management Framework. This helps to ensure that the management of personal information remains a central consideration when developing relevant policies and procedures. It also facilitates an integrated approach to privacy management across DHS.
3.25 Policy and procedure documents are reviewed regularly, at least once a year, usually as part of a continual improvement process. More significant re-writes are conducted if there has been a significant change to the process or if the Agency requests a change.
3.26 Service officers can provide feedback on policies and procedures through an online feedback process.
3.27 The Digital Health Branch’s risk management plan is reviewed and updated on a quarterly basis, or on a more ad hoc basis if issues arise in between the quarterly reviews. In reviewing the risk management plan, input from internal stakeholders, such as the CIO Group and the Programme Advice and Privacy Branch, is often sought. The Directors of each section within the Digital Health Branch are then responsible for disseminating the plan to staff within their sections.
3.28 The Digital Health Branch’s privacy incident management processes demonstrate a holistic approach to responding to and addressing privacy incidents as relevant branches and teams within DHS are consulted when responding to incidents. The circumstances in which they are consulted are clearly set out in the document, ‘My Health Record – Privacy Incident Process’ and in the related process map.
3.29 DHS provided the OAIC with a Security Risk Management Plan, Part A (dated November 2016) and a Security Risk Management Plan, Part B (dated March 2017) (together, the risk management documents) during the fieldwork. The risk management documents set out the results of a threat and risk assessment and a consequential risk treatment plan relating to the My Health Record system. The risk management documents set out four risks and proposed treatments that on their face seem appropriate. These documents also noted that the generally accepted level of IT risk is considered to be low. All treatments identified were designed to maintain or reach that level.
3.30 The OAIC sought access to DHS’ overarching information security management plan (or equivalent) during the assessment. The OAIC was informed in September 2017 that while DHS does not have a departmental wide information security management plan or equivalent documentation, it has an Information Security Management Framework (ISMF) with a range of linked information security policies, standards and directives (together, the information security policy documents).
3.31 At the same time, DHS informed the OAIC that information security management is analysed and documented at the system level, consistent with the information security policy documents and that the documents relevant to the assessment were the risk management documents.
3.32 The information security policy documents were not provided to the OAIC during the assessment. As a result the OAIC cannot comment on the appropriateness of the information security policy documents from a privacy perspective, in particular from the perspective of APP 1.2.
Access controls
3.33 As outlined above, the Digital Health Branch uses a number of different IT systems to provide My Health Record contact services on behalf of the My Health Record System Operator.
DHS operated systems
3.34 Access to DHS operated systems are set by DHS. Passwords to access these systems must be changed by the users every three months.
3.35 Access controls on the CDMS limit access to information only to service officers with a need to know that information. Managers are responsible for approving access to the CDMS and other DHS controlled systems to each of their staff individually; the level of access is determined by the service officer’s duties.
3.36 The OAIC understands that DHS conducts regular audits and monitors its own systems, such as the Customer Directory Maintenance System (CDMS) for unauthorised or anomalous access.
3.37 The access control policy governing these processes was not made available to the assessors during their fieldwork. Whilst the access controls observed by the assessors in the fieldwork appeared appropriate, OAIC was not able to review the overarching policy against the processes described by DHS staff.
3.38 DHS staff used shared drives and an internal document management system (DMS) to store information. Access to these drives and to the DMS is limited to those staff who need to know to perform their duties. For example, access to the shared drive used by the policy team is limited to members of that team. There are some potential improvements to these processes which are discussed in Part 4.
Non DHS operated systems
3.39 As noted in paragraphs 2.7 and following above, access to the Admin Portal, CRM and IMS is managed through the Agency following a request by DHS. DHS notifies the Agency of the identity of its staff that require access to those systems and the Agency manages that access. DHS cannot audit its staff’s use of those systems.
3.40 The OAIC was informed that there is no segregation of access by its staff to the CRM and Admin Portal based on role or authority. There is segregation within the IMS – staff access is limited to those areas that DHS has nominated its staff have access to. Access to these systems is reviewed every six months. There are some potential improvements to these processes which are discussed in Part 4.
3.41 The auditing arrangements used in those systems are not managed by DHS and therefore could not be further assessed by the OAIC under this assessment.
3.42 While DHS is not able to apply access controls to the systems that are operated by the Agency, the Digital Health Branch has taken proactive steps to implement some level of mitigation in the Admin Portal.
3.43 Authorised service officers use the Admin Portal to process complex registrations. The service officers that respond to My Health Record registrations, enquiries and complaints are separated into different tiers of authority: Tiers 1, 2 and 3. The interim agreement specifies the tasks that each tier is responsible for carrying out, with the more complex cases being escalated to Tier 3.
3.44 In order to mitigate the risk that a Tier 1 or Tier 2 service officer will attempt to perform a task which they are not trained to, or do not have authority to, perform, the Digital Health Branch does not publish documents on its intranet relating to the processes only undertaken by Tier 3 service officers on the Admin Portal.
3.45 In addition, when a Tier 3 function is about to be performed, a warning sign will appear on the screen informing the service officer that they are about to perform a Tier 3 function and to not proceed unless they are a Tier 3 service officer.
Data breach response plan
3.46 The Digital Health Branch’s Data Breach Response Plan sets out procedures and lines of authority for DHS staff in the event that DHS becomes aware of a data breach.
3.47 The Data Breach Response Plan explains the requirements of section 75 of the My Health Records Act, which sets out how participants in the My Health Record system are to address and respond to a My Health Record data breach. The OAIC suggests that the section 75 requirements be mentioned earlier in the document to help ensure that readers of the document immediately understand the legislative underpinnings of the Data Breach Response Plan.
3.48 In addition, the OAIC considers that the clarity of the Data Breach Response Plan could be improved by:
- explaining in the document how it interacts with the incident response processes that have been developed by the Digital Health Branch
- incorporating or referencing the process diagrams that accurately reflect current work flows for handing specific types of section 75 data breaches, including interaction with the Agency, which were discussed separately with the OAIC in November 2016.
3.49 This will help ensure that staff have a good understanding of how the broader incident response processes interact with the specific data breach response process.
Part 4: Areas for improvement
4.1 Overall, the OAIC considers that the Digital Health branch would benefit from reviewing and updating its processes in four areas and has made one recommendation in relation to this below.
4.2 As noted above, the OAIC was not provided with copies of DHS’ access control policy or its information security policy documentation. As a result, the OAIC cannot comment on the appropriateness of the access control policy or the information security policy documents from a privacy perspective, in particular from the perspective of APP 1.2 or compare them against observations from its fieldwork.
4.3 The OAIC is considering how to bridge this gap, possibly by way of a follow-up or subsequent assessment of access control, and logging and monitoring policies.
4.4 The OAIC was provided with a document that the Digital Health Branch developed to provide staff with guidance on storing customer information outside of core systems. This was referred to as the ‘control of customer information plan’.
4.5 During discussions with the staff from the Digital Health Branch, it became apparent that different sections within the Branch have different processes for the storage of information outside of core systems. While it appeared that each section was aware of where their section stored information outside of core systems and how the information was protected, there was no branch-wide register of where information was stored outside of non-core systems. There is a risk that non‑conformance with the plan may arise by human error.
4.6 The OAIC recommends including a register in the control of customer information plan document that outlines where each team within the Digital Health Branch stores personal information outside of core systems to ensure oversight of the storage of information.
4.7 In addition, the OAIC considers that a number of other amendments could be made to the control of customer information plan to improve the clarity and usefulness of the document. These include:
- simplifying the language to make the document more user-friendly
- providing further examples of data breaches under section 75 of the My Health Records Act (currently the plan only refers to intertwined Medicare records as an example of a My Health record data breach)
- updating the reference to Information Privacy Principle 11.1(d) to refer to the relevant Australian Privacy Principle
- referring to the Privacy Act 1988 where relevant to ensure staff are aware that the control of customer information plan is underpinned by legislative obligations to protect personal information from unauthorised collection, use and disclosure.
4.8 As noted in paragraphs 2.7 and following above, in order to register individuals and respond to their enquiries about the My Health Record system, service officers need to access the Admin Portal and the CRM and certain staff require access to the IMS.
4.9 The interim agreement between DHS and the Agency includes a requirement to conduct a biannual review of licences to CRM and the Admin Portal to ensure service officers who have previously been allocated licences to perform My Health Record work still require one.
4.10 The OAIC considers the inclusion of this requirement in the interim agreement to be a good step in ensuring that only individuals with a need can access personal information in the Admin Portal and the CRM.
4.11 As the review of licences is only conducted biannually, the OAIC was informed that, as soon as a staff member leaves the team and no longer requires access to CRM, the Admin Portal and the IMS, managers proactively inform the Agency that the licences of those staff members need to be revoked and their access to the IMS be removed. This process ensures that access is revoked as soon as staff members no longer require access, rather than after a review is conducted every six months.
4.12 The OAIC recommends that this informal process of informing the Agency as soon as staff members no longer require access to CRM, the Admin Portal and IMS is formalised in a Digital Health Branch document. This will help further ensure that there is a clearer process for the Agency to be informed that DHS staff members no longer require access to the incident management system.
Fraud control plan
4.13 DHS’ My Health Record fraud control plan formalises the fraud control arrangements for the aspects of the My Health Record programme that DHS is operationally and technically responsible for. The plan provides a summary of My Health Record fraud risks and identifies key controls in place to manage My Health Record fraud risks.
4.14 While fraud will often involve the unauthorised collection, use or disclosure of personal information, other instances of mishandling personal information will not necessarily be cases of fraud.
4.15 For example, the deliberate creation, manipulation or disclosure of personal information by an individual for the purposes of personal financial gain is likely to be a case of fraud as well as a case of mishandling an individual’s personal information. However, disclosing sensitive information to another person, for example, in and of itself may not be a case of fraud but is likely to be a case of mishandling personal information.
4.16 The DHS My Health Record fraud control plan, however, does not draw this distinction and it is unclear whether a number of risks identified are directly fraud-related or whether they are in fact mishandling of personal information and unrelated to fraud. The plan’s focus on privacy management is therefore not as prominent or as clearly defined as it should be, giving rise to a risk that privacy issues may be overlooked.
4.17 The OAIC recommends clarifying in the fraud control plan what activities and subsequent mitigation strategies relate to fraud and which relate to other instances of mishandling personal information.
