There are constraints around the use and disclosure of identifiers and identifying information (both real and perceived) that are limiting the potential of the HI Service to fully meet its objectives. The Act and the Service were introduced with the aim of facilitating communication between providers and organisations to promote widespread adoption of e-Health. At the time the Act was drafted the detail of potential uses of the HI Service and the design were not known, nor was the identity of the Service Operator or the privacy controls that would be implemented to manage access to the PCEHR system. To mitigate risks that may occur given this level of uncertainty the Act and the design incorporated very tight restrictions on use and disclosure.
This sets a very high standard of privacy protection, but introduces practical issues for use at a clinical service level that are impacting confidence in the system and limiting its full adoption.
Individual Health Identifiers
In 2009 DOHA proposed that exact matching for an individual’s IHI was the preferred option in the design of the HI Service. This proposal was initially taken to the NEHTA Identifiers Authentication and Access Reference Group stakeholders in March 2009 and then presented to the NHIRF working group, the National Health CIOs Forum and NEHTA at a combined meeting on 22 April 2009. At these forums specific search criteria for IHI were agreed together with the requirement to have only a ‘single exact match’ returned. It should be noted that at the time this decision was made the scope of privacy controls and protections within the PCEHR system were unknown, and it was in this context that decisions were made about the privacy controls in the HI Service.
The rationale for the use of an exact match was that the information fields which are used to verify the identity of an individual when retrieving their IHI comprises personal information. When a healthcare provider is already in possession of the data fields required to successfully retrieve an IHI, the confirmation of those data fields by the Service Operator would not constitute a breach of the healthcare recipient's privacy.
By using probabilistic search functionality for a failed search, a search result may confirm that some of the information submitted by the healthcare provider about the healthcare recipient was correct, therefore disclosing personal information or inadvertently disclosing personal information about a third party consumer.
The disclosure of personal information in this way would constitute a privacy breach by the Service Operator unless the individual has consented to the disclosure, or the disclosure is authorised by law.
The outcomes of these discussions were then taken to OAIC who supported this outcome and indicated that this approach would enable agencies and organisations to meet their privacy obligations. This information was communicated to NEHTA in August 2009 with the purpose of revising and updating the Detailed Business Requirements, Policy Register and other HI Service related documentation.
While the HI Act does not specify the type of search to be performed6 the Explanatory Memorandum for the Act indicates that:
An individual’s healthcare identifier will only be disclosed back to the healthcare provider where an exact match is available. Where an exact match is unavailable, an error message will be sent to the healthcare provider from the HI Service Operator.7
Collection of IHIs is occurring through a combination of batch downloads and opportunistic collection when a patient presents for a service. The match rate for IHIs collected through a batch process is variable across services, ranging from 30 – 90% and is much higher for patients who have recently presented at a service.
To be widely adopted by healthcare services Healthcare Identifiers must be allocated to all patients and readily available and accessible for authorised uses, primarily to support clinical information flows. The mechanisms used to access identifiers must support both system level functions where there is no direct interaction with users as well as user level functions.
Jurisdictions have identified a number of concerns with the current implementation of IHIs. Until processes for newborns and other healthcare recipients without an IHI are implemented IHIs will only be able to be used as a secondary identifier as otherwise it will inhibit core business processes. The implementation costs are high and this is a deterrent while IHIs cannot be used for all transactions. In addition current match rates result in a large number of individuals for whom an IHI cannot be retrieved, particularly for older records, both as a result of the matching technique used and variable data quality across the sector.
Frustration with search and matching processes was raised in all interviews with clinical and jurisdictional users and was perceived as a significant barrier to use of the Service within day to day clinical business processes. Constraints around disclosure mean that minimal information is provided back to end users in situations where they conduct a search that does not return a result. For example, there is no indication in a failed search which field has failed to match. This information would allow the user to confirm just one detail with the healthcare recipient rather than having to try multiple searches to identify which field was incorrect (not a practical approach in a health service dealing with a high throughput of patients).
The majority of clinical systems use a probabilistic algorithm that may return more than one close match if an exact match cannot be made. These systems are not subject to the same constraints as they are not regulated by the HI Act which has more onerous privacy controls than the Privacy Act 1988 (Privacy Act). Privacy requirements in most healthcare provider organisations are governed by the National Privacy Principles, which provides a broader authority to use personal information than the Information Privacy Principles. In particular, National Privacy Principle 2.1 provides that personal information collected about an individual can be used for a secondary purpose related to the primary purpose of collection, "if the individual would reasonably expect the organisation to use or disclose the information for the secondary purpose".
There are a number of factors that contribute to a low match rate:
- Age of the records – the highest match rates were for individuals who had a recent presentation at a health service (within the last 2 years). Match rates were significantly lower when an individual had not attended a health service for more than two years.
- Nature of the matching algorithm resulting in rejections occurring because abbreviations, upper/lower case have been used.
- Data quality issues in provider systems.
- Discrepancies between the data held by the healthcare provider and DHS. Any variation will cause a record to be rejected. Although the current process asserts that DHS is the source of truth for all data about healthcare recipients, in many cases healthcare providers will have more up to date information.
The risks of an unauthorised disclosure would be limited, but the likelihood of a match improved, if probabilistic search functionality was implemented but confined to 'almost exact' matches where the HI Service Operator could have a very high level of confidence that the healthcare provider requires the IHI and the healthcare recipient in question is in their care (i.e. an existing or attending patient).
For example, the search functionality could require that the Medicare Card Number (which the healthcare provider will usually have on file or ready access to) and the date of birth and gender fields return exact matches, but that the name field have an acceptable tolerance (e.g. last name not case sensitive and not 'character', e.g. hyphen-, sensitive). If probabilistic search results were limited to entries which had an exact match on Medicare Card Number and date of birth, and a 'very close' match on name, the risk of returning multiple or incorrect search results would appear low.
This approach would be more consistent with DHS services accessed by Healthcare Providers, such as the Online Patient Verification process. If providers access the Online Patient Verification service they can get a result if there are minor discrepancies in some fields and can also access updated information.
There was a common view among clinical groups that if constraints around searching as a consequence of these more stringent privacy protections result in low match rates, this will impact confidence in the system and will impact adoption of the PCEHR system.
A number of options could potentially mitigate this risk and improve the useability of the Healthcare Identifiers system, but each would need to be assessed against the cost of modifying the system and risks of degradation of service:
- Review the search algorithm and methodology to align more closely with health system current practice of probabilistic matches using mandatory and other locally held data. Alternatives include:
- Enhance the HI Service to support probabilistic matching for calls to the current Service interfaces
- Implement a new HI Service interface supporting patient searching which returns a list of possible matches to the user, with a high percentage match cut off
- Implement a probabilistic search only when a deterministic search had failed
- Introduce a 2 step process so that if there is not an initial exact match the HI Service performs a probabilistic match at the back end, resolves it and returns matched records
- Use a single search utilising all relevant locally held data
It is recommended that a feasibility assessment for implementation of a probabilistic search as described above be undertaken, taking into consideration the functional changes that would be required, the cost of these changes to the HI Service and vendor systems, and the privacy risks and impacts that would need to be addressed. If considered feasible the legislative and legal barriers to adopting probabilistic search functionality for IHI searches conducted by healthcare providers could be overcome by amendments to the HI Act which expressly authorised the disclosure of certain identifying information to a healthcare provider in connection with the disclosure/collection of an IHI8.
It would also facilitate usage if a failure to match returned an error message that indicated which field was in error to assist the user to check one, not multiple details. This is not permitted within the current privacy settings in the HI Act as by confirming which field was incorrect the Service Operator would be confirming the accuracy of the other information submitted. The return of a meaningful error message would require the Service Operator to be authorised (under an amendment to the HI Act) to disclose the relevant information for the purposes of the retrieval of an IHI9.
Recommendation 11 – Search functionality
It is recommended that an evaluation of implementation of a probabilistic search be undertaken, taking into consideration the functional changes that would be required, the cost of making these changes to HI Service and vendor systems and the privacy risks and impacts that would need to be addressed.
Disclosure of IHIs to the OAIC and NEHTA
In the context of complaints handling, there may be circumstances where either DOHA (for the PCEHR system) or DHS (for the Healthcare Identifiers Service) will pass on IHIs to the OAIC for the purpose of handling a complaint or to NEHTA for investigation of an issue. However, the OAIC believe that they are not authorised to collect IHIs under the HI Act. Division 2A of the HI Act authorises the System Operator, repository operators and portal operators to collect Healthcare Identifiers for purposes of the PCEHR system in particular circumstances. It does not authorise the OAIC to do so, for the purposes of complaints investigation.
Consequential amendments have been made to the Act to allow the PCEHR System Operator to collect IHIs, as there were concerns that such collection would not have been allowed under the existing use and disclosure provisions. Similar amendments should be considered to allow the OAIC to collect IHIs for the purpose of investigating and handling privacy complaints and NEHTA for the purposes of investigation.
Disclosure of IHIs for incident investigation and quality assurance
It was reported by DHS and NEHTA that disclosure of Healthcare Identifiers for the purposes of investigation are not permitted under the Act. In the event that an issue is found with a record, for example a duplicate or replicate, it is critical that this can be resolved quickly to ensure the clinical safety of the system. It is not uncommon for multiple parties, including vendors, to need to be involved in resolution of errors. However section 24(1)(a)(ii) of the Act does enable investigation to be undertaken, and section 36 extends this authority to Contracted Service Providers (CSPs) where the duties of the CSP under contract to the healthcare provider involve provision of information technology services relating to the communication of healthcare information or health information management services. The issue appears to be more a lack of understanding of what is permitted than a real legislative impediment. The circumstances in which disclosure for investigation occur should be well defined and should occur within a defined access framework and processes.
Disclosure to aged care, disability services and insurers
A number of other issues and queries were raised during the consultations that indicated there needs to be clearer guidance available on circumstances where disclosure is permitted to address the concerns people have about using IHIs in case they inadvertently commit a breach of the Act. There also needs to be a process to assist people in situations where it is not clear whether disclosure is permitted or not.
The definition of a “health service” was seen as unclear or too restrictive in a number of interviews, particularly in services providing a mix of health and social care, such as aged care and disability services. The clients of both types of services are heavy users of the health system and will be major beneficiaries of the improved co-ordination and integration of services that will be made possible with e-Health. Concerns were raised about staff who are not healthcare providers in these facilities being able to access IHIs. It should be noted that this situation is already common in the clinical systems environment and is managed through role based access and other security settings.
Healthcare Provider Identifiers
Restrictions on disclosure of HPI-Is and the opt in basis for participation to the Healthcare Provider Directory (HPD) is also creating a barrier. Current functionality makes it very difficult to search for a healthcare provider or validate a provider’s Healthcare Provider Identifier. This is an impediment to implementation of functions such as electronic referrals, discharge summaries, electronic transfer of prescriptions etc. It is noted that a change request is in progress that will enable searches for HPI-Is and HPI-Os to be conducted on the HI Service regardless of whether an individual has opted in to the HPD.
Basis of participation in the Healthcare Provider Directory
The HPD is a consent based directory of healthcare providers. The opt in basis for the HPD has been identified as a significant barrier to participation in the directory, and by extension to other e-Health services that are dependent on the HPD, such as secure messaging.
The HPD is needed to link providers and organisations with the end point location service and certificates to support the following use cases:
- Addressing clinical documents to a specific provider e.g. a referral to a private specialist
- Accessing the PCEHR system provider portal when a hard linkage is required between the organisation and individual provider.
Other use cases are supported by directly looking up the HI Service.
The participation rate is currently low which will undermine the objectives of the Act. There is not a common level of understanding about the purpose of the HPD, nor its criticality for e-Health. Medicare Locals reported that once GPs understood the purpose, the information held and that it was limited to the provider community, GPs had no issue with participating. If the HPD does not work effectively it will potentially have an even more significant impact on the acute sector which does not have the same level of control over their referral base as GPs, who tend to work with a smaller network of other healthcare providers.
It is understood that the opt in model was adopted as clinicians were concerned about the risks of exposure of their contact details. The HPD requires the providers’ business address and does not contain details of providers’ personal address or contact details (unless they provide their private address as the business address), and details can be amended by healthcare providers using Health Professional Online Services which gives individuals a high level of control over the information that is displayed.
Given the impact of the current consent model and the risks that low participation pose to the e-Health agenda, and considering the low risks to healthcare providers that would result from having their details included in the HPD, it is recommended that the opt in provisions be removed for HPI-Os at a minimum.
The potential for changing the basis of consent for HPI-Is to mandatory inclusion or opt out participation in the directory for providers wishing to utilise any e-Health system was strongly supported by the majority of people interviewed. Given the dependency between the HPD and utilisation of e-Health there is a strong justification for automatic inclusion of at least a minimum set of mandatory information for providers who register for the PCEHR system or other e-Health programs in the HPD.
Merely exposing details held by the HI Service in the HPD would not necessarily resolve the issues that providers are experiencing in performing a reliable search as there are limitations in the minimum dataset exposed in the HPD for this purpose. The majority of the information that is held in the HPD is already available through the AHPRA website. In relation to HPI-Is it is recommended that consideration be given to a return to the model originally contemplated in the design of the HI Service and list the HPI-I on the public register published by AHPRA. The data published by AHPRA is more suitable for searching than the minimum data available through the HPD.
Recommendation 12 – Healthcare Provider Directory participation
It is recommended that:
- Section 31 of the HI Act be amended to distinguish between healthcare provider organisations and individuals
- The requirement for consent for Healthcare Provider Organisations to be included in Healthcare Provider Directory be removed; and
- Consideration be given to implementation of the model originally contemplated in the design of the HI Service to list the HPI-I on the public register published by AHPRA.
Constraints relating to disclosure/authority to act
The ability for Medicare Locals to actively support local GP Practices is expected to increase registration and adoption of e-Health. Medicare Locals are supporting practices by preparing the paperwork to set up HPI-O seed and network structures and are submitting this to DHS on behalf of GP Practices.
There appears to be a lack of clarity among Medicare Locals about what they can do on behalf of the practices in their areas. A number of organisations interviewed identified legislative constraints relating to disclosure as a concern as information on HPI-Os is not being fed back to Medicare Locals by DHS once an HPI-O is assigned (even if the practice has provided a written authority for the Medicare Local to act on their behalf in completing registrations).
Difficulty in accessing a healthcare provider’s HPI-Is (both their own and other providers’) was raised as a significant risk for adoption and use. The intent behind the allocation of HPI-Is is to facilitate communication between healthcare providers, but the current controls around use and disclosure of HPI-Is are undermining this objective.
Healthcare providers were notified of their HPI-Is at the commencement of the HI Service, but potential uses for this are only now coming into effect. It was reported that many healthcare providers are not aware of their HPI-I, nor how they can locate this number. The Medicare Locals have tried to facilitate this process and do this on behalf of the GPs, but currently legislation prevents DHS from disclosing HPI-Is to the Medicare Locals, although the Medicare Locals hold all other details about the GPs. This is likely to be an even more significant issue for the acute sector.
Legal advice was sought on options to support the disclosure of HPI-Is to organisations such as Medicare Locals to facilitate these organisations to act on Healthcare Providers’ behalf for the purposes of managing their identifiers. This advice10 indicated that currently the Service Operator's authority to disclose HPI-Is is narrowly confined under the HI Act and is limited to disclosing an HPI-I, subject to use for specific purposes to:
- The individual healthcare provider who has been assigned the HPI-I11
- A registration authority (being an entity that is responsible under a law for registering members of a particular health profession) for the purpose of the registration authority registering the individual healthcare provider12
- The PCEHR System Operator13
- Chief Executive Medicare14
- DVA and the Defence Department (or such other Department as is prescribed)15.
In order for the Service Operator to disclose Healthcare Identifiers to Medicare Locals and other non-healthcare provider organisations, the Act would need to be amended to expressly authorise the Service Operator to do so. The amendment would need to specify the purposes for which Medicare Locals (or any other third party) are permitted to use the HPI-I.
This could be done by including additional provisions in Division 1 of Part 3 of the HI Act which enable the making of regulations in respect to the prescribing of additional organisations to which Healthcare Identifiers can be disclosed for prescribed purposes/circumstances.
Disclosure and performance of AHPRA’s role
The purpose of HPI-Is is to be a unique identifier for providers. It would facilitate AHPRA’s interaction with key partners, such as State and Territory health departments, if HPI-Is could be used to exchange information (e.g. to inform an employer should a provider employee cease to be registered) but this is not a permitted use for AHPRA. If this was permitted, it would increase HPI-Is adoption as it would integrate these identifiers into key business processes within the health sector. It would also support AHPRA’s obligation to inform employers of changes in provider details and confirm that they are providing an update on the correct person. This transaction is currently conducted via AHPRA’s provider information exchange system, but could be managed via the HI Service. The benefit would be a reduction in duplication between systems as well as providing an incentive for health services to adopt the HI Service.
Other strategies to increase adoption could include the provision of HPI-Is on the annual renewal cards sent to providers to increase its accessibility, and to record HPI-Is on AHPRA’s public register. This is not currently supported by the Act. To better leverage AHPRA’s relationship with providers and enable the organisation to facilitate the notification of HPI-Is an amendment would be required to the Act to enable disclosure in this way.
To date AHPRA has been unable to view records in the Healthcare Identifiers system to confirm provider details. This has been a result of both perceived legislative and functional impediments. As AHPRA are not providers of healthcare this was not a permitted disclosure, even though they are the original source of the information. Subsequent legal advice has supported this disclosure and a system change request is being implemented in June 2013 to provide access to AHPRA.
Access to HPI information
One of the major issues arising from interviews related to limitations in searching for provider information, and the impact of this on utility of the HI Service. The user requirement is that when an HPI-O is sent to the HI Service details of the providers associated with that healthcare provider organisation would be returned.
The current built functionality of the system has been limited by the Act which prohibits the disclosure of ‘identifying’ information relating to IHIs, HPI-Is and HPI-Os by the Service Operator, unless the disclosure is for the purpose for which the information was provided to the Service Operator under Part 2 of the Act (section 15(2)), which is for the purpose of assigning the HPI-O. Given this constraint the functionality that has been built is limited to returning the HPI-O number and status, with no details of the organisation. It is noted that Change Request (CR) 77 will partially resolve this but there needs to be stakeholder validation of the solution before this can be confirmed.
Legal advice provided in the course of this Review indicated that section 17 provides the Service Operator with authority to disclose an HPI-I to a healthcare provider organisation where that disclosure is necessary for the purposes of communicating and managing health information as part of providing healthcare to a healthcare recipient.16 The Act does not provide specific guidance on the meaning of 'communicating or managing' and definitions provided in the Act for 'health information' and 'healthcare' are broadly framed and designed to capture most information and activities arising in connection with the delivery of healthcare.
The Service Operator is implementing functionality to support improved HPI-I searches. To support this and for the avoidance of doubt, it is recommended that the HI Act is amended to expressly authorise the Service Operator to disclose an HPI-I to a healthcare provider organisation and expressly authorise the organisation to collect and use the HPI-Is.
This amendment would ensure that there can be no dispute about the scope of the Service Operator's authority under section 17 and, if necessary, enable privacy controls associated with the disclosure and use of HPI-Is to be clearly identified.
There is some ambiguity in the scope of reference of section 15 on Service Operator’s duty of confidentiality. The heading of the section implies the section applies only to the HI Service Operator, but the reference in 15 (1)(a) to “or this Division” implies a broader application.