Healthcare Identifiers Service: Audit report

Date: 1 June 2014

Healthcare Identifiers Service Operator

Information Privacy Principles audit
Section 27(1)(h) Privacy Act 1988

Audit undertaken: December 2013
Draft report issued: March 2013
Final report issued: June 2014

Part 1 — Introduction

1.1 The Australian Government has allocated funding to the Office of the Australian Information Commissioner (OAIC) during 2012–13 and 2013–14 to oversee the privacy aspects of the handling of healthcare identifiers and the functioning of the Healthcare Identifiers Service (HI Service).

1.2 The OAIC is required to conduct up to two privacy audits of the HI Service Operator (HI SO) under its Memorandum of Understanding (MOU) with the Department of Health (Health). The MOU relates to the provision of dedicated privacy related services under the Privacy Act 1988 (Cth) (Privacy Act), the Healthcare Identifiers Act 2010 (Cth) (HI Act) and the Personally Controlled Electronic Health Records Act 2012 (Cth) (PCEHR Act), for the period 29 November 2012 to 30 June 2014.

1.3 The first HI SO audit assessed whether the HI SO’s handling of healthcare identifier information was maintained in accordance with the Information Privacy Principles (IPPs) in section 14 of the Privacy Act, the HI Act and the Healthcare Identifiers Regulations 2010 (Cth) (HI Regulations). Specifically, the audit reviewed the HI SO’s collection (IPPs 1–3), use (IPPs 9–10) and disclosure (IPP 11) of personal information associated with healthcare identifiers.

1.4 This report relates to the second HI SO audit under the MOU and the HI SO’s handling of healthcare identifier information in accordance with IPP 4 (storage and security).

1.5 As part of the HI Service, the HI SO is required to allocate and maintain a register of healthcare identifiers. These include Healthcare Provider Identifier – Individuals (HPI–Is) and related personal information. To obtain an HPI–I, a person must be a healthcare professional involved in providing patient care.

1.6 HPI–Is are maintained by the HI SO within the eHealth Program database (EHP). In addition, the HI Act requires the HI SO to maintain a healthcare provider directory (HPD) of HPI–Is of individuals who have agreed to be included on that directory. The HI Service also leverages the Healthcare Provider Online Services (HPOS) application to enable HPI–Is to interact with each other through the HPD.

1.7 The Australian Health Practitioner Regulation Agency (AHPRA) is a national registration authority for the purposes of the HI Act and is authorised to assign HPI–Is to healthcare providers it regulates. The HI SO has provided AHPRA with approximately five million HPI–I numbers to enable AHPRA to fulfil this function.

1.8 As a result, the overwhelming majority of HPI–Is issued to healthcare providers have been issued by AHPRA, which is also responsible for providing the personal information of those healthcare providers to the HI SO for inclusion in the EHP.

1.9 While AHPRA supply the majority of HPI–Is, they generally do not have a role in addressing queries from healthcare providers in relation to their HPI–Is. This role is fulfilled by the HI SO, who can respond to queries and add to records as required. However, should the query relate to information that was originally supplied to the HI SO by AHPRA, the HI SO cannot update this and the healthcare provider is referred back to AHPRA.

Part 2 — Description of audit

Objective and scope

2.1 The audit was conducted pursuant to s 27(1)(h) of the Privacy Act, which states that a function of the Australian Information Commissioner (Commissioner) is to ‘...conduct audits of records of personal information maintained by agencies for the purpose of ascertaining whether the records are maintained according to the Information Privacy Principles.’

2.2 The objective of this audit was to assess the extent to which the HI SO maintained records in accordance with:

  • the Information Privacy Principles (IPPs) set out in s 14 of the Privacy Act, specifically IPP 4, and
  • the relevant terms of the HI Act and the HI Regulations 2010 (HI Regulations),

which relate to the storage and security of personal information pertaining to HPI–Is.

2.3 Specifically, the objective was to consider whether the storage and security arrangements utilised by the HI SO for HPI–Is and the associated personal information (including security arrangements in relation to the EHP, HPD and HPOS) are reasonable in the circumstances to protect that information from loss, unauthorised access, use, modification or disclosure or other misuse.

2.4 The scope of the audit included a review of HI SO’s policies and procedures applicable to the storage and security of HPI–Is and associated identifying information as provided by the HI SO, as well as the implementation of these policies and procedures.

2.5 The audit did not include a physical review or testing of the technical capabilities of the IT systems used by the HI SO and did not assess the HI SO’s handling of IHI and Healthcare Provider Identifier – Organisation (HPI–O) information.

Timing, location and methodology

2.6 The auditors conducted the fieldwork component of the audit from 9 to 11 December 2013 at the Department of Human Services (DHS) offices at 25 Cowlishaw St, Greenway, ACT.

2.7 The audit fieldwork included:

  • a review of documents provided by the HI SO
  • interviews with staff from the system design and maintenance, ICT, operations and policy areas of the HI SO.

2.8 The auditors referred to the OAIC’s Guide to Information Security[1] when considering the documents and the outcomes of staff interviews. Part 3 of this report sets out more detail on the matters considered in this personal information security audit.

Information obtained during the audit

2.9 The HI SO provided numerous documents prior to and during the fieldwork for this audit. This included recent versions of the HI SO’s internal processes, policies and procedures relevant to the access and use of HPI–I records. A full list of the information obtained is at Appendix A.

Opinion

2.10 The auditors are of the opinion that the HI SO is generally maintaining its records of personal information in accordance with IPP 4 and, in relation to HPI–Is, s27(a) of the HI Act within the scope of this audit.

2.11 The auditors identified two privacy risks and make recommendations in relation to these in paragraphs 5.15 and 5.27 of this report.

2.12 A recommendation is a suggested course of action or a control measure that, if put in place by the agency, will (in the opinion of the OAIC) minimise the risks identified around how personal information is handled against the relevant criterion.

2.13 The use of recommendations to the exclusion of ‘best privacy practice’ is a change in practice by the OAIC made in 2012 when the OAIC published a new manual to guide its public sector audits. The term ‘best privacy practice suggestion’ was used in the previous Healthcare Identifiers Service audit by the OAIC published in August 2012.[2] The use of recommendations by the OAIC in this report does not itself reflect a change in the risk profile of the HI SO.

2.14 The auditors note the Australian Privacy Principles (APPs) commenced on 12 March 2014. The security provisions in the current and reformed Privacy Act are similar, with the only difference between IPP 4 and APP 11.1 being the additional requirement of protection against ‘interference’. APP 11.2 also provides additional specific obligations around destruction of personal information. [3]

Reporting

2.15 To the extent possible, the OAIC publishes final audit reports in full or in an abridged version on its website: www.oaic.gov.au. It is sometimes inappropriate to publish all or part of a report because of statutory secrecy provisions or for reasons of privacy, confidentiality, security or privilege.

Part 3 — Matters considered in relation to information security

3.1 As detailed in the OAIC’s Guide to Information Security, the OAIC considers a number of factors when considering information security. Reasonable steps to ensure information security under the Privacy Act and the HI Act will depend on the circumstances, including the following:

  • the nature of the entity holding the personal information
  • the nature and quantity of personal information held
  • the risk to the individuals concerned if the personal information is not secured
  • the data handling practices of the entity holding the information
  • the ease with which a security measure can be implemented.

3.2 Appropriate security safeguards and measures for protecting personal information need to be fully considered in relation to all of the entities’ acts and practices. While not exhaustive, the guide provides a framework which the OAIC refers to in its information security audits. In this audit, given the scope and information provided, the OAIC has focused in particular on what steps the HI SO is taking to manage the following:

  • governance
  • access security
  • ICT security
  • physical security
  • data breaches
  • personnel training and policies.

Part 4 — Governance

4.1 Entities should establish clear procedures and lines of authority for decisions regarding information security. Entities should have a governing body, committee or designated individual/s that are responsible for managing the entity’s personal information to ensure its integrity, security and accessibility, including defining information security measures and plans to implement and maintain those measures.

4.2 Following interviews with HI SO staff and review of the documents provided, the auditors are of the view that there are clear procedures and lines of authority for decisions, including good operational and strategic governance controls, change management processes and ICT governance protocols. There are no privacy issues in relation to this part of the report.

Observations

Operational and strategic governance

4.3 In 2006, Council of Australian Governments funded the National E–Health Transition Authority (NEHTA) to develop and implement national eHealth infrastructure. NEHTA has a service level agreement with the HI SO to deliver the HI Service. This arrangement establishes an effective governance framework to deal with operational and strategic matters in relation to the HI Service.

4.4 There are three levels of meetings:

  • weekly meetings at the director level between the HI SO, NEHTA and Health to discuss joint operations matters, systemic issues and incidents
  • monthly meetings at the senior executive service level between the HI SO, NEHTA and Health to oversee operational performance
  • quarterly meetings at the senior executive level between the HI SO, NEHTA and Health to provide strategic oversight and monitor joint programs, projects and initiatives.

Change management governance

4.5 HI SO staff described a robust change management process that is initiated within the relevant HI SO business areas when a request from NEHTA for a change to the HI Service is received. This includes consideration, at an early stage, of any privacy impacts that might result from a proposed change.

4.6 The Change Control Board (CCB), comprised of teams from across the HI SO, Health, NEHTA and the National Infrastructure Operator, reviews any proposed changes to ensure these do not impact other areas of the HI Service or Personally Controlled Electronic Health Record (PCEHR) system. DHS’ ICT group then costs any necessary IT development.

4.7 The auditors were informed that any change is put through extensive testing to ensure no adverse effects will arise in production.

ICT governance

4.8 The Auditors were informed that the ICT governance protocols for managing the HI Service are leveraged off and identical to those for other areas of DHS, and are described in the Enterprise Information Security Management Process (ESMP). This process defines the roles and responsibilities of the ‘business owner’ (the HI SO) and the seven discrete areas within the DHS Enterprise Architecture Branch.

4.9 The Healthcare Identifiers Branch is responsible for: requesting accreditation, attesting that controls are in place and effective, generating and monitoring system logs and executing incident response plans.

4.10 The DHS Enterprise Architecture Branch’s responsibilities include:

  • critical involvement in the change management process, including determining whether or not new technology is required, development of that technology, consideration of its effect on other business areas and testing that technology before production
  • assessing and verifying the effectiveness of controls and generating threat landscape reports (see Audit Logs in Part 6).

Risk Management, Business Continuity Plans

4.11 Within the HI SO, each business area is responsible for developing risk management plans. The auditors were provided with two risk management plans: one for the Healthcare Identifiers Branch and one for HPOS security. Both plans include potential risks and associated resolutions associated with inappropriate/unauthorised access and acknowledge privacy compliance as a risk issue requiring controls and mitigation strategies.

4.12 The auditors were provided with business continuity plans for three distinct areas of the HI SO: the Healthcare Identifiers Branch, the eHealth and Government to Business Systems Branch and PKI/Certificate Issuance Management System area. These plans include potential areas of concern and set out high level response procedures.

Part 5 — Access security

5.1 Appropriate access controls are essential to protect personal information from loss, unauthorised access, use, modification or disclosure, or other misuse. Effective access controls adequately protect information by only allowing access to those who are authorised.

5.2 Authentication to a system usually occurs when the user provides one of three types of information: something one knows (eg passwords), something one has (eg a security token) and something one is (eg biometric information). Multi-factor authentication requires at least two types of information.

5.3 Following interviews with HI SO staff and review of the documents provided, the auditors are of the view that the HI SO generally has appropriate access controls in place. However, the auditors noted two privacy risks and sets out recommendations below.

Observations

5.4 Access security controls use multi-factor identification and apply to persons seeking to access the EHP:

  • HI SO staff
  • external parties (eg HPI–Is or other authorised users).

HI SO staff

5.5 Staff are nominated to receive access to the EHP, with approval for access based on business requirements. When authorised, Healthcare Identifiers branch staff require a user name and password to access the EHP. This establishes effective authentication.

5.6 All interactions with the EHP are recorded in an audit log; however, the log is not subject to proactive monitoring as detailed in paragraph 6.7 below.

5.7 To ensure that access to the EHP is limited to those who have a business requirement, the auditors queried whether procedures are in place to remove access to the EHP when it is no longer a business need.

5.8 Following the closing meeting for the audit, the auditors were provided with a copy of DHS’ Access Control Standard (control standard). The control standard provides that:

  • a user’s account is limited to specific ‘authorisations’ granted to that user
  • accounts are disabled if an employee leaves DHS, is seconded to another organisation or commences long service leave
  • authorisations granted to accounts can only be modified through the authorised provisioning system.

5.9 The control standard does not specify what occurs when a DHS staff member moves areas or changes responsibilities within DHS, such that they no longer have a business need to access the EHP. The HI SO has since confirmed with DHS ICT that there is an access control process to deal with movements that is implemented in practice.

5.10 We were informed that when a staff member leaves one business area for another, DHS ICT will liaise with the business area the staff member has moved from, and confirm access is no longer required. Therefore, when an existing DHS staff member commences with the Healthcare Identifiers Branch, their old system accesses are revoked. The same would apply if a Healthcare Identifiers branch staff member was to leave to go to another business area.

5.11 During our interviews, the auditors were informed Healthcare Identifiers branch staff had noticed authorisations applicable to other branches remaining active after staff had moved between branches.

5.12 The auditors were informed that as a secondary control measure the HI SO has implemented a process to confirm access controls within the Healthcare Identifiers branch every three months.

5.13 This was achieved through requesting a list of former and current HI SO employees with access to the EHP database, and manually checking whether each employee still required access. If an employee had left the branch or the agency, the staff members would inform DHS ICT. The auditors commend this initiative and suggest that the process be put in writing.

Privacy issues

5.14 The auditors note the process created by the Healthcare Identifiers branch has been a useful method to confirm authorisations have been removed as required. However, we believe the HI SO should review its staff access controls to ensure the access is limited to branch or role needs.

Recommendation 1 — review of access controls

5.15 It is recommended that the HI SO review its staff access control mechanisms to ensure it is satisfied that they limit access to those required for the staff’s role.

PKI Certificates — access to EHP

5.16 Access to the EHP is dependent on a person’s authorisation and authentication of that authorisation. Authentication for third parties is managed through a Public Key Infrastructure (PKI) certificate. This is a system of cryptographic technologies, standards, management processes and controls governing the use of digital certificates.[4] When accessing EHP via HPOS, the person must enter the password associated with the PKI certificate for each session. Users of the third parties’ may also be required to log onto their computer prior to using HPOS, or commercial software.

5.17 To access the EHP, a user’s PKI certificate must have the appropriate authorisation for the request being made. If the PKI certificate does not have the relevant authorisation for the requested action, the user’s request will be rejected by the gateway.

PKI Certificates — Certificate Issuance Management System

5.18 DHS issues PKI certificates through the Certificate Issuance Management System (CIMS). DHS has the authority to do so as the holder of Gatekeeper Accreditation from the Australian Government Information Management Office.

Access security of electronic HPI–I applications

5.19 The auditors were informed that most HPI–Is are assigned by AHPRA. However, there are a small number of healthcare providers whose healthcare profession is not regulated by AHPRA who apply directly to the HI SO. At the time of the audit, just over one hundred healthcare providers had applied for a HPI–I directly to the HI SO.

5.20 To request a HPI–I from the HI SO, a healthcare provider completes an application form and faxes this form to the HI SO. The HI SO receives this application form as an email, and the form is saved in an email folder marked ‘action’. Following processing of the application form and creation of a HPI–I, the original email is moved into an email folder marked ‘actioned’.

5.21 The auditors were informed that while the personal information contained within the database used to create HPI–Is is stored in redacted form, the original email is stored in the folder marked ‘actioned’. Neither the email nor the application form attached to it is de-identified. The auditors understand that all HI staff at the Tier 2 level and above have access to this folder.

5.22 The auditors were informed that the HI SO archive and destruction policy does not instruct staff to delete the email after the HPI–I has been created and relevant information has been redacted and stored on the database.

Privacy issues

5.23 Storing personal information that is no longer required can increase the risk of loss or misuse of that information. Under IPP 4, one reasonable step to ensure security is to de-identify or destroy personal information when it is no longer required.

5.24 The requirements for de-identifying and destroying information that is no longer required is more explicit after 12 March 2014. Under APP 11.2 (which will replace IPP 4), an APP entity must take reasonable steps to destroy personal information or ensure it is de-identified if it no longer needs the information.[5]

5.25 However, the requirement to take reasonable steps to destroy or de-identify under APP 11.2 does not apply if personal information is contained in a Commonwealth record, or if an Australian law or a court/tribunal requires it to be retained.

5.26 Documents containing personal information collected by an agency are likely to be Commonwealth records for the purposes of the Archives Act 1983 (the Archives Act).[6]

Recommendation 2 — management of retained information

5.27 It is recommended that the HI SO ensure that it has taken steps that are reasonable in the circumstances to protect personal information contained within the original HPI–I applications.

5.28 If the applications are Commonwealth records that can be destroyed or de-identified in accordance with the Archives Act, it should consider doing so, if the information is no longer needed for a permitted purpose or required to be retained under another law. If not, the HI SO should consider other ways of securing the records.

Part 6 — ICT security

6.1 Effective ICT security requires protecting computer hardware, as well as the data the hardware holds, from unauthorised use, access, theft or damage. Entities should regularly monitor the operation and effectiveness of their ICT security measures to ensure they remain responsive to changing threats and vulnerabilities and other issues that may impact the security of personal information.

6.2 The auditors are of the view that at the time of the audit the HI SO had reasonable ICT security steps in place in relation to the EHP. There are no privacy issues in relation to this part of the report.

Observations

6.3 ICT security is a major component of the HPI–I system and includes the design of the EHP system and its protections, the use of active and passive security features and strong protocols over the protection of hardware.

EHP System specifications and protections

6.4 From our interviews with DHS ICT security staff, the auditors understand that the EHP:

  • is built to the standards specified in the Australian Government Information Security Manual (ISM), which governs the security of government ICT systems
  • undergoes incremental backup continuously, with data replicated and stored at remote sites with the capability of functioning in a cached manner
  • is protected by layered security mechanisms
  • sits in an internal zone with access to the content of the EHP being through applications, which are housed in their own database with separate security provisions
  • has the benefit of a further layer of external protection which can block internet traffic into the HI Service if suspicious internet activity is noticed.

Penetration testing

6.5 Based on interviews and consideration of a report sighted, the auditors were satisfied that the HI Service is subject to regular, active and independent vulnerability tests, termed ‘penetration tests’ (pen tests). This involves an attempt to ‘ethically hack’ the HI Service to test the integrity of the system’s architecture by an external party. Pen testing utilises the Open Web Application Security Project (OWASP) framework. [7]

Audit logs and monitoring

6.6 System logs record all transactional accesses to HI Service data, including the type of access and transaction or attempted access to that data, which are kept for seven years. Where DHS staff access the EHP at the request of an authorised person (eg actioning the request of an identified HPI–I), the activity will be captured as both the activity of the DHS staff member and the requesting authorised person.

6.7 DHS uses proactive/intelligent monitoring in relation to the consumer directories database (where individual healthcare identifiers’ are stored) and consideration is being given to constructing and implementing a similar tool with the EHP.

6.8 As noted in paragraph 1.9 above, the HI SO can respond to queries from healthcare providers in relation to their HPI–Is, unless the query relates to information that was originally supplied by AHPRA. If a healthcare provider were to notice an unrequested change in the details AHPRA originally provided to the HI SO, the healthcare provider would be instructed to contact AHPRA to have the issue amended.

6.9 AHPRA may be seeing patterns of complaints/queries of unauthorised changes to addresses, and changing them, but the HI SO would not recognise this pattern as they would see it as a routine address change. The HI SO confirmed that any report of unexplained activity in an HPI–Is audit log made to AHPRA would not be notified to HI SO as a matter of course. As such, there is a possibility the HI SO may be missing opportunities to recognise potential problems with the EHP.

6.10 The auditors understand that the HI SO does not consider its lack of knowledge of HPI–I queries made to AHPRA affects the integrity of the EHP database, given the low risk of an attempt to use HPI–I data for unauthorised purposes that would not be detected by the HI SO through other means. If this view changes, the HI SO may wish to discuss with AHPRA the possibility for disclosure to HI SO of any complaints AHPRA has received regarding unauthorised access to HPI–Is.

IT hardware

6.11 The HI SO has implemented a number of system polices to protect the HI Service IT hardware. These include a prohibition on Bring Your Own Devices (BYOD), with appropriate hardware supplied by the HI SO to its specifications; allowing only permitted software onto its systems; and preventing ‘untrusted’ devices being recognised by IT hardware (eg external thumb drives).

Part 7 — Physical security

7.1 Physical security is an important part of ensuring that personal information is not inappropriately accessed. Entities should consider whether the workplace is designed to facilitate good privacy practice, and ensure that physical copies of personal information are secure.

7.2 Based on our interviews, the auditors are of the view that the HI SO has in place reasonable measures to ensure appropriate physical security in relation to its data centres. There are no privacy issues in relation to this part of the report.

Observations

7.3 Access to the data centres containing HPI–I and associated personal information is only provided to authorised persons. Access to the HI data stacks follows the guidelines provided by the Australian Signals Directorate: each data stack is secured with locks; each rack within the data stack is secured with locks requiring additional keys; and each data server is individually locked with further locks and keys.

7.4 Access to the data stacks containing CIMS information is only provided to authorised persons with a negative vetting 1 security clearance. The application and database that make up CIMS are physically isolated, both from each other and from other data stacks, and are kept partly in secure racks in various data centres, and partly in a separate secure room.

Part 8 — Data breaches

8.1 In the event of a data breach, having a response plan that includes procedures and clear lines of authority can assist entities to contain the breach and manage their responses.

8.2 The auditors note that DHS has an ICT Security Incident Detection and Response Plan that incorporates the HI Service.

8.3 As the plan was provided after fieldwork was conducted, the auditors were unable to test its implementation. There are no privacy issues in this part of the report.

Observations

8.4 The HI SO has an ICT Security Incident Detection and Response Plan, which the HI SO provided to the auditors after the fieldwork was conducted. The plan encompasses four discrete sections: an incident detection and response framework; a security incident response framework; a security incident response plan; and an incident response process.

8.5 The document details procedures and establishes clear lines of command. Any incident will be escalated as appropriate, with critical issues escalated to the secretary and ministerial level.

8.6 Should an incident occur, the ‘detect’ branch within the cyber operations area advises the ‘response’ area and the relevant business areas, who work together to determine who should take the lead in resolving the issue. The area tasked with leading the incident response follows the processes established in the incident response plan.

8.7 The response and business areas also notify relevant stakeholders. The auditors were told that business areas will engage with the privacy team in the event of a data breach.

8.8 The auditors were informed that the HI SO has ministerial reporting obligations in the case of significant data breaches. While the auditors did not see the incident response plan, they were informed that the plan details the ministerial reporting requirements.

8.9 In regards to the HI SO, the auditors were informed that there have been no data breach incidents.

Part 9 — Personnel training and policies

9.1 Human error can cause security breaches and undermine otherwise robust security practices. It is therefore important that all staff members understand the importance of good information handling practices. Privacy training may help staff to avoid practices that would breach the entity’s privacy obligations by ensuring that they understand their responsibilities.

9.2 Following interviews with HI SO staff and review of the documents provided, the auditors are of the view that the HI SO staff have a good understanding of information handling practices and operate within a strong culture of protecting personal information. There are no privacy issues in this part of the report.

Observations

9.3 Employees are required to complete training upon commencement of employment, which includes privacy and confidentiality requirements. Completion of these training packages is recorded against staff members’ profiles. DHS Legal Services is working with DHS Training and Development area to create a new e–learning package based on the APPs which will apply from 12 March 2014.

9.4 ICT have recently implemented annual training for staff. This requirement was initiated to comply with the Attorney General’s Protective Security Policy Framework.

9.5 HI SO staff must sign a Privacy and Confidentiality Declaration on commencement of employment. The declaration outlines what constitutes appropriate access, disclosure and a breach of privacy and/or confidentiality. It also outlines legislation that is applicable to the different business areas of DHS.

9.6 The auditors note the declaration contains reference to the IPPs, and will need to be amended for the introduction of the APPs.

9.7 The declaration is silent on eHealth legislation. Under the HI Act, there are significant penalties for unauthorised use and disclosures of healthcare identifiers by ‘persons’ (which will include HI SO staff). This includes criminal sanctions of up to two years imprisonment.

9.8 The auditors suggest the HI Branch liaise with the Human Resources branch to include a reference to the HI Act and possible sanctions in the declaration as part of the amendments to be made for the introduction of the APPs. Similarly, amendments could be made to make specific reference to the PCEHR Act (as Healthcare Identifiers branch staff are also involved in services relating to the PCEHR Act).

Part 10 — Summary of recommendations

Recommendation 1 — review of access controls

It is recommended that the HI SO review its staff access control mechanisms to ensure it is satisfied that they limit access to those required for the staff’s role.

Auditee response

DHS accepts the recommendation.

A quarterly review of staff with access to the HI Service system has been implemented.

The process has been formally documented and two reviews have been undertaken to date.

Recommendation 2 — management of retained information

It is recommended that the HI SO ensure that it has taken steps that are reasonable in the circumstances to protect personal information contained within the original HPI–I applications.

If the applications are Commonwealth records that can be destroyed or de-identified in accordance with the Archives Act, it should consider doing so, if the information is no longer needed for a permitted purpose or required to be retained under another law. If not, the HI SO should consider other ways of securing the records.

Auditee response

DHS accepts the recommendation.

The existing redacting and storage process in place for individual healthcare provider registration documentation has been extended to include the deletion of emails once the registration is complete.

Appendix A — Information obtained during the audit

The OAIC obtained the following information from the HI Service prior to and during the audit:

  • Most recent versions of process documentation:
    • Healthcare Provider Directory for HPI–I and HPI–O
    • Healthcare Identifiers Business Continuity Plan — May 2013 v1.5 (3)
    • PKI/CIMS Business Continuity Plan — September 2013 v1.0
    • Healthcare Identifiers Risk Management Plan 2013–14 v0.5
    • HPOS fact sheet August 2013
    • Healthcare Identifiers Service Information Guide: Introduction and Overview — 48203.06.11
    • Business Continuity Plan — Healthcare Identifiers Branch — November 2013
    • Health eBusiness Division: Business Verification Testing (PVT/VVT) Process. V0.14 Draft
  • Most recent versions of Healthcare Identifier security specifications:
    • System log v8.30 — FR.COM.SPEC.03.159
    • EHP Authorisation Specification v8.6 — FR.HI.SPEC.01.347
    • Healthcare Identifier Authentication v8.6 — FR.HI.SPEC.01.075
    • Web Service Security v8.0 — FR.HI.SPEC.02.277
    • Enterprise Information Security Management Process flowchart
    • ICT Security Incident Detection and Response
  • Most recent version of architecture documentation:
    • Software Architecture Document — HPI v0.9
  • Most recent versions of HPOS specifications:
    • Manage Authorisation Links v2.13 — DHS PCEHR SPEC 058
    • PCEHR Provider Register User Interface v2.9 — DHS PCEHR SPEC 060
    • Provider Participation Register and Maintenance via HPOS v2.8 — DHS.PCEHR.SPEC.057
    • Web service logging specification v0.3 — DHS.PCEHR.SPEC.671
    • HPOS — Manage providers — Business Specification v7.2 — OLSUHI088
    • Deactivate Provider v8.0 (PCEHR) — OLSUHI089
    • HPOS — Manage HI provider directory service entry for individual — Business Specification v6.4 — OLSUHI090
    • HPOS — Search HI provider directory service for individual (DRAFT R3) v3.14 — OLSUHI091
    • HPOS — Search for Provider Individual v1.7 — OLSUHI108
    • HPOS — View HI provider directory service entry for individual — Business Specification v4.14 — OLSUHI092
  • Most recent versions of EHP specifications:
    • Create—Amend EHP Address V8.2 — FR.COM.SPEC.01.309
    • Create—Amend EHP Individual Name V8.2 — FR.COM.SPEC.01.328
    • Create—Amend EHP Electronic Communication Details V8.3 — FR.COM.SPEC.01.330
    • Create—Amend HI PDS Entry v6.5(Dec) — FR.COM.SPEC.01.336
    • Record EHP Inquirer Details by MSO V4.9 — FR.COM.SPEC.01.343
    • EHP Certificate Issuance V8.0 — NASH — FR.COM.SPEC.01.324
    • Search HI Record by MSO (excl. IHI) V4.26 — FR.COM.SPEC.02.030
  • Most recent versions of web service specifications:
    • Manage Provider or Administrative Individual Details v8.1 (PCEHR) — TECH.SIS.HI.13
    • Read Provider or Administrative Individual Details — v6.10 — TECH.SIS.HI.15
    • Search for Individual Provider Directory Entry — v6.7 — TECH.SIS.HI.17
    • Search for Provider Individual — v1.11 — TECH.SIS.HI.31
    • Search for Organisation Provider Directory Entry v6.18(Dec) — TECH.SIS.HI.18
    • Manage Provider Directory Entry v6.13(Dec) — TECH.SIS.HI.19
    • Trusted Data Source — Manage Provider Individual Details v8.0 — TECH.SIS.HI.20
    • TDS — Notify of Duplicate or Replica Provider Individuals — v5.0 — TECH.SIS.HI.21
    • Search Provider Individual Batch Async v1.9 — TECH.SIS.HI.33
    • Trusted Data Source — Provider Individual Search — v0.25 — TECH.SIS.HI.35
  • Diagrams outlining: the interactions between the HI Service systems and service; the relationships between databases; the interactions between the HI Service and front end and back end systems; and external interactions with the HI Service via HPOS
  • The most recent version of the eLearning suite encompassing personnel security, physical security, legislation, protectively marking, customer face-to-face, and the classification system
  • The most recent version of the Access Control Standard
  • The most recent versions of PKI policies:
    • Medicare Australia Community of Interest Certificate Policy for Healthcare Individual Certificates v2.2
    • Medicare Australia Community of Interest Certificate Policy for Individual Certificates for Healthcare Provider Individuals via data source (HPI-Is) for Healthcare Identifiers Service (HI Service) v1.1
    • Medicare Australia Community of Interest Certificate Policy for Individual Certificates for an authorised Organisation Maintenance Officer (OMO) under the Healthcare Identifiers Service (OMO) under the Healthcare Identifiers Service (HI Service) v1.1
  • Details of who within the HI Service/DHS has access to healthcare identifier information
  • The most recent versions of privacy/personal information documentation:
    • DHS overview of secrecy provision
    • DHS ethics and values
    • Privacy policy for all officials
    • Declaration for employees regarding handling of personal information
  • The most recent versions of change management protocols:
    • Overview of system change management
    • Change management Policy
    • Change Advisory Board: Terms of Reference
    • Change Advisory Board Rules
    • Change management roles and responsibilities
    • HI Change Management and Governance flowchart.

Footnotes

[1] www.oaic.gov.au/privacy/privacy-resources/privacy-guides/guide-to-information-security

[2] www.oaic.gov.au/privacy/applying-privacy-law/list-of-privacy-assessments/healthcare-identifiers-service-department-of-human-services-audit-report

[3] www.oaic.gov.au/privacy/applying-privacy-law/app-guidelines/chapter-11-app-11-security-of-personal-information

[4] http://www.finance.gov.au/files/2012/04/Gatekeeper_PKI_Framework.pdf

[5] www.oaic.gov.au/privacy/applying-privacy-law/app-guidelines/chapter-11-app-11-security-of-personal-information

[6] www.oaic.gov.au/privacy/applying-privacy-law/app-guidelines/chapter-b-key-concepts#_Toc380575604

[7] www.owasp.org/index.php/About_OWASP

Was this page helpful?

Thank you.

If you would like to provide more feedback, please email us at websitefeedback@oaic.gov.au