ihi pre-implementation project solution architecturedocs2.health.vic.gov.au/docs/doc...initiative....

Department of Health

IHI Pre-Implementation Project

Solution Architecture

HealthSMART Design Authority

of 125

Authorised by the Victoria Government, Melbourne. To receive this publication in an accessible format email: [email protected] © Copyright, State of Victoria, Department of Health, 2011

of 125

Table of Contents

1. Document Overview .................................. ..........................................................4

1.1 PURPOSE ..................................................................................................................................... 4 1.2 SCOPE ......................................................................................................................................... 4 1.3 ASSUMPTIONS .............................................................................................................................. 5 1.4 CONSTRAINTS............................................................................................................................... 5 1.5 INTENDED AUDIENCE..................................................................................................................... 6 1.6 REFERENCES................................................................................................................................ 6

2. Introduction....................................... ...................................................................8

2.1 CONTEXT...................................................................................................................................... 8 2.2 SOLUTION VISION.......................................................................................................................... 8 2.3 IMPLEMENTATION CONSIDERATIONS............................................................................................. 10

3. Architecture Drivers ............................... ...........................................................11

3.1 ARCHITECTURAL PRINCIPLES....................................................................................................... 11 3.2 ARCHITECTURAL CONSTRAINTS ................................................................................................... 11 3.3 ARCHITECTURAL RISKS ............................................................................................................... 12 3.4 ARCHITECTURAL OPTIONS........................................................................................................... 16

4. Current State Overview ............................. ........................................................20

4.1 HEALTHSMART BUSINESS AND ORGANISATIONAL CONTEXT ........................................................ 20 4.2 PATIENT IDENTIFIERS .................................................................................................................. 21 4.3 RELATED PROJECTS ................................................................................................................... 22 4.4 HI SERVICE SUMMARY ................................................................................................................ 22 4.5 IHI OVERVIEW ............................................................................................................................ 24

5. Solution Overview .................................. ...........................................................26

5.1 SOLUTION OBJECTIVES ............................................................................................................... 26 5.2 SOLUTION DEPENDENCIES .......................................................................................................... 26

6. Solution Architecture Definition................... ....................................................28

6.1 ARCHITECTURAL ASSUMPTIONS................................................................................................... 28 6.2 GENERAL ARCHITECTURE PRINCIPLES ......................................................................................... 28 6.3 ARCHITECTURAL CONCERNS RAISED ........................................................................................... 28 6.4 BUSINESS ARCHITECTURE........................................................................................................... 37 6.5 APPLICATION ARCHITECTURE ...................................................................................................... 54 6.6 INFORMATION ARCHITECTURE ..................................................................................................... 85 6.7 REPORTING ARCHITECTURE ........................................................................................................ 96 6.8 TECHNOLOGY ARCHITECTURE ..................................................................................................... 98 6.9 SECURITY ARCHITECTURE......................................................................................................... 105

7. Glossary ........................................... ................................................................112

8. Appendix 1 – Search Criteria ....................... ...................................................115

9. Appendix 2 – IHI Matching .......................... ....................................................117

9.1 REQUIREMENTS ........................................................................................................................ 117 9.2 ANALYSIS ................................................................................................................................. 124

of 125

1. Document Overview 1.1 Purpose The primary purpose of this document is to communicate the essential elements of the overall solution for the integration of national Individual Healthcare Identifiers (IHIs) into HealthSMART health services’ processes and systems. In doing so the document supports the following objectives:

• It defines the overall vision for the solution and describes how it addresses the business requirements

• It defines the key principles for the implementation approach.

• It partitions the solution into components that can be individually specified and allocated to appropriate vendors or providers to enable the detailed design and build of these components to take place

• It provides visibility and exposure of the key architectural decisions to other architects for peer review.

This document does not represent a complete detailed design, nor a catalogue of the application development work required for the project. It does provide the framework upon which these activities can be undertaken during subsequent phases of the project.

1.2 Scope 1.2.1 In Scope - Organisation The use of the Individual Healthcare Identifier (IHI) is intended to extend throughout the health sector, in its broadest meaning and including providers in Aged Care, Community Care, Drug and Alcohol Services, etc. The Healthcare Identifiers Act 2010 supports active use of the IHI by registered healthcare organisations and individuals. Unregistered healthcare providers can receive and store the IHI, but will not be able to access HI Service functions.

The scope of the IHI in terms of its penetration into the health sector will be driven by the business processes and artefacts that use the IHI, including referrals, orders, prescriptions, discharge summaries, and ultimately any form of electronic medical or health record.

The focus for the Victorian IHI Pre-Implementation Project is on the HealthSMART program within the Victorian Department of Health, the HealthSMART application suite, and on health services that use HealthSMART services.

1.2.2 In Scope - Architecture The scope of this architecture is broad, though targeted towards the HealthSMART program and HealthSMART health services. The architecture provides an overview of the IHI Integration solution in the key architecture areas (business, information, application, and technology), but deals with architectural issues and risks in greater detail.

The architecture scope includes:

• Overview of the current state of HealthSMART, the health sector in Victoria, and the HI Service.

• Consideration of business architecture components not covered in other project deliverables.

• Consideration of the Information standards and architecture, to support the IHI Integration solution, including health messaging.

• Consideration of the application architecture given the constraints of the current state, and the nature of the HI Service.

• Consideration of the technology requirements, including major technology components necessary to support the deployment and the ongoing operation of the solution.

• Architecture risks and issues with potential mitigation approaches and options.

of 125

• Consideration of capability gaps, appropriate transition steps & supporting architecture, to enable a measured and controlled progress from the current state to the defined future state.

1.2.3 Out of Scope The scope exclusions are:

• Detailed consideration of health IT architectures significantly different from the HealthSMART model.

• Detailed consideration of several items upon which the IHI solution is dependent, including the Healthcare Provider Identifier – Individual (HPI-I) and Healthcare Provider Identifier – Organisation (HPI-O), the proposed CCA regime, and the Security and Access Framework.

o Any of the above items may alter the scope and/or complexity of any IHI implementation initiative.

• Detailed consideration of services or functions that may become available in the future, such as the HI Service HPOS and MSO channels, the Personally Controlled Electronic Health Record (PCEHR), among others.

• Consideration of the role of the IHI in supporting future capabilities, such as the PCEHR or Electronic Medical Records.

• Detailed consideration of the impact of IHI adoption on health IT systems not supported by HealthSMART (commonly referred to as downstream systems).

• Consideration of the clinical risks associated with adopting and using the IHI (this is covered in the Vic IHI Integration Clinical Risk Assessment Report Final v1.1 deliverable).

• Detailed design, development and deployment of any solution components (including sizing and configuration requirements for the technology components required to support the solution).

• Planning or development of cost estimates for future project phases.

1.3 Assumptions The following assumptions have been made in the preparation of this document:

• All Victorian public health services, not only those that have adopted HealthSMART services, will support the adoption of the IHI.

• The projects’ requirements, design and architecture are based upon integration of the HI Service and the IHI, as specified by NEHTA and implemented by Medicare Australia, into the HealthSMART environment based on the current design and operational parameters.

• Other projects will address changes required to health service systems not under direct HealthSMART management. These projects may be initiated by the respective system vendors, or by health services.

• NEHTA and Medicare Australia will agree to implement a notification service as included in the IHI Integration design.

• Medicare Australia will manage the HI Service in a manner consistent with industry best practice.

• Any perceived concerns with the HI Service will ultimately be resolvable.

1.4 Constraints The following constraints apply to the Victorian IHI Integration design and architecture:

• The IHI Integration design and architecture are tightly bound to Medicare Australia’s HI Service Specification v3.0.2. Any changes to the HI Service Specifications since release 3.0.2 may not be fully reflected in the design and architecture.

of 125

• The NASH remains under development, with required security services having to be obtained from an alternate source (Medicare Australia). Ultimately NASH services will need to be integrated into the IHI solution.

1.5 Intended Audience The key audience for this document includes:

• Victorian Department of Health

• NEHTA

• Health services

• Health professionals

• Other Australian health jurisdictions, and

• Vendors.

1.6 References • Healthcare Identifiers Act 2010

• NEHTA HI Service Concept of Operations v 1.0 FINAL Nov 2009

• NEHTA Individual Healthcare Identifiers Business Requirements v 1.0 FINAL Nov 2009

• NEHTA HI Security and Access framework v 1.0 FINAL Nov 2009

• NEHTA HI Business Use Case Catalogue v 1.0 FINAL Nov 2009

• NEHTA HI Service Catalogue v 1.0 Final Nov 2009

• NEHTA HI Service Glossary v 1.0 DRAFT Nov 2009

• Medicare Australia HI Service - Technical Services Catalogue R3A v3.0.2.doc

• Medicare Australia TECH.SIS.HI.01 - SIS - Common Document for SIS v3.0.2.doc

• Medicare Australia TECH.SIS.HI.02- SIS - Common field processing reference document for SIS v3.0.2.doc

• Medicare Australia TECH.SIS.HI.03 - Update Provisional IHI via B2B v3.0.2.doc

• Medicare Australia TECH.SIS.HI.05 - Update IHI via B2B v3.0.2.doc

• Medicare Australia TECH.SIS.HI.06 - IHI Inquiry Search via B2B v3.0.2.doc

• Medicare Australia TECH.SIS.HI.08 - Resolve Provisional IHI- Merge Records via B2B v3.0.2.doc

• Medicare Australia TECH.SIS.HI.09 - Resolve Provisional IHI- Create Unverified IHI via B2B v3.0.2.doc

• Medicare Australia TECH.SIS.HI.10 - Create Provisional IHI via B2B v3.0.2.doc

• Medicare Australia TECH.SIS.HI.11 - Create Unverified IHI via B2B v3.0.2.doc

• Medicare Australia TECH.SIS.HI.12 - IHI Batch Searching v3.0.2.doc

• FR.SVI.SPEC.01.232 Notify Duplicate Replica IHI via_B2B v3.25 (R3b).doc

• Medicare Australia HI Service - IHI Searching Guide v0.3 Draft.doc

• Vic IHI Integration Business Requirements Specification v1.1

• Vic IHI Integration Simplified Functional Design v2.1

• Vic IHI Integration IHI Exceptions v2.1.doc

• Vic IHI Integration IHI functional design (Care Coordination) v2.1

• Vic IHI Integration IHI functional design (HI Service) v2.1

of 125

• Vic IHI Integration IHI functional design (HIMs) v2.1

• Vic IHI Integration IHI functional design (IHI Processing) v2.1

• Vic IHI Integration IHI functional design (Patient) v2.1

• Vic IHI Integration IHI functional design (Summary & Business Processes) v2.1

• Vic IHI Integration IHI Technical Design v1.1

• Vic IHI Integration Best Practice Guide v1.1

• NHS Number Standard for Secondary Care (England), Full Operational Information Standard 1.0, published on 20/12/2008

• NHS Number Programme Implementation Guidance, To Support the NHS Number Operational Information Standards, 1.0, published on 31/12/2008

• The Open Group Architecture Framework Version 9 (web based documentation at http://www.opengroup.org/architecture/togaf9-doc/arch/).

of 125

2. Introduction 2.1 Context The HealthSMART initiative being undertaken by Department of Health Victoria is the program implementing Victoria’s information and communication technology (ICT) strategy to modernise and replace ICT systems throughout the Victorian Public Healthcare Sector (VPHS).

The HealthSMART program is responsible for managing processes to select applications, configuring these applications to reflect statewide requirements (statewide footprint) and then implementing these applications into participating agencies using the statewide footprint as a base.

The IHI reference design will be incorporated into the HealthSMART Solution Architecture, and used as a checkpoint against current and future solutions that are incorporated into the HealthSMART solution design. The HealthSMART IHI design will also consider the anticipated use of the IHI by other health services in Victoria and the common vendors that deliver applications to the sector.

NEHTA will perform a coordinating role in the development of a single build of applications to suit a number of jurisdictions, initially engaging with iSOFT.

NEHTA’s role in this pre-implementation project has been to provide a consultancy service in regard to the requirements and architecture for IHI, and contribute to practical support, in order to access and learn from a ‘test bed’ for implementation of IHI.

2.2 Solution Vision The vision for the Victorian IHI Integration solution is to enable health services to adopt and use the Individual Healthcare Identifier in the most effective manner possible. The supporting health IT systems (P&CMS, CMS, etc) will automatically retrieve the IHI from the HI Service, and distribute the IHI to other health service systems.

The IHI Integration solution in HealthSMART features tight integration with the current approach for information distribution, based upon HL7 messaging and the HealthSMART Integration Engine, and the Agency Integration Engines in the health services. Some extensions to the current HL7 2.4 HealthSMART standard will be required to support the transfer of the IHI.

The IHI will be a key attribute of each patient’s record, and will be used on a regular basis by health service workers, primarily for identifying or matching a patient, but the IHI will also be incorporated on patient centred communications and other outputs. Over time, the use of the IHI will become more prevalent, and will support a more community wide mechanism for patient identification, when used with supporting demographic information.

The IHI integration solution may be implemented in stages, thereby minimising the adoption risk. Many health services may choose to initially adopt Verified IHIs, perhaps with the intent of including these on Discharge Summaries. Other functions may be implemented as required, though the need for multiple levels of external testing and associated costs (Medicare Notice of Connection and NEHTA Compliance Conformance Accreditation testing) may lead to more holistic implementations.

The Victorian IHI solution is highly exception driven, with successful processes not requiring significant user intervention. The number of errors associated with IHI acquisition is expected to reduce dramatically over time. Health services will require policies that determine their approach to IHI exception management, and how much effort they are prepared to commit.

A high level view of the solution is shown in the diagram below. This diagram shows the P&CMS and CMS applications obtaining the IHI from the HI Service, and then distributing the IHI to other HealthSMART systems (the Clinical System is shown) and on to various application within a health service.

While beyond the scope of this project, the diagram also shows that the Agency Integration Engine and the Practice Mgmt System may also access the HI Service directly. At the time of publication the NASH remains under development.

of 125

Figure 1 - High Level Architecture

The solution approach for achieving this vision is based on several key principles, as described below:

Ubiquity. The ability to acquire, use and manage the IHI must be universally accessible to the participants in the health and human services sector in Victoria, within the constraints imposed by supporting legislation.

Ease of use. Selected health services’ systems will automatically obtain and manage the IHI, and apply the IHI to various outputs as required, such as reports, referrals, discharge summaries, orders, etc). Only exceptions in the IHI process will require human intervention.

Accuracy and appropriateness. In order for the IHI to be effective it must be accurate, and its statuses declared and visible to all. The IHI will not be used for clinical or administrative purposes if it cannot be shown to be accurate for the patient (record). The Provisional and Unverified IHIs must only be used when warranted, and if supported by health service’ policy.

Public confidence and Trust. Policy and regulatory frameworks to protect privacy and confidentiality, coupled with the appropriate security controls, will give health services and patients/clients trust that their information is secure throughout its lifecycle within the system, and cannot be tampered with, or accessed without proper authorisation.

Alignment with national standards. The IHI may be seen as establishing a national standard in itself. More importantly other existing or emerging national standards must support the use of the IHI n the sector, including standards for e-referral, discharge summary, orders (Pathology, Radiology, etc), e-Prescribing, and others. HL7 standards support for the IHI is essential.

Positioning for broader e-Health implementation. While this solution architecture is primarily concerned with the adoption of the IHI, the architecture may be extended to provide detailed support to a range of additional services, such as the use of the IHI in the PCEHR context, or to management of HPI-Is and HPI-Os.

Common Services Framework. The IHI services implemented by Medicare Australia in the HI Service define a core service within the NEHTA e-Health solution architecture. The IHI components of the HI Service are, in turn, supported by common services supporting the HPI-I and HPI-O, and the NASH. The services to be implemented in the HSIE form a suite of services available to support all HealthSMART health services.

Leverage existing solutions. The solution does not seek to replace any existing systems or applications, but rather focuses on leveraging existing tools and infrastructure to make the IHI available to health IT applications and their users in the most effective and efficient manner possible.

of 125

2.3 Implementation Considerations The entire Australian health sector will eventually be required to support the IHI, though the primary focus of this architecture includes IHI implementation in HealthSMART systems and HealthSMART health services. The adoption of the IHI appears to be fundamentally a business change program, with some important IT supporting components. A rigorous approach to change management within health services, including staff training and education, will be essential to success.

It is also essential to recognise that this is not a short term implementation activity which will eventually end. The acquisition and management of the IHI by health service staff and systems will continue for the foreseeable future. As it typically in any change program, it is expected that the effort to implement will be significantly greater than the effort associated to manage the IHI over time.

A staged approach to IHI implementation is recommended, and this may be achieved in a number of ways, including:

1. Use current integration engines to acquire and store the IHI, thereby enabling its use in e-health messages, such as e-Referrals and discharge summaries

• This may present a number of challenges including achieving compliance with Medicare Australia and NEHTA’s requirements, low match ratios achieved, and little ability to correct errors.

2. Enhance the current Patient Administration System to store and use IHIs, while implementing the HI Service interfaces in the current integration engine (in HealthSMART this would be the HSIE).

3. While not relevant to the HealthSMART architecture, the PAS could be enhanced to interface to the HI Service directly, thereby bypassing any integration engine.

4. Perform an initial data load of IHIs into the Patient Administration System, and accept whatever is returned from the HI Service (little data cleansing effort required).

5. Adopt the IHI through operational processes, as patients are referred or present for services.

6. Adopt only Verified Active IHIs in the initial stages, enabling Unverified and Provisional IHIs over time, and as supported by health service policies.

7. Encourage the local GP community to adopt IHIs, and use incoming referrals as a source of patients’ IHIs.

of 125

3. Architecture Drivers The solution architecture combines a high level description of the overall solution with responses to identified technical risks or issues. Project process risks and issues are not the domain of the solution architecture. The business architecture may venture into areas such as the solution’s operating model, governance, and funding, though these have not been considered in detail in this document.

Architectural principles and constraints are highly valuable, and serve to limit the number of options available when designing the solution.

3.1 Architectural Principles The following architectural principles apply:

• The P&CMS or an equivalent PAS in a health service will be the single master application for all patient registrations and therefore allocation of the URN and IHI for a health service, as per the solution design principles of HealthSMART.

• The existing URN used within Victorian health services will be retained as the primary patient identifier. A patient’s IHI will be stored within CMS and P&CMS applications in addition to the current URN, with some modification being required to existing systems.

• All requests for an IHI will be initiated by applications that are nominated as the master for patient management functions, specifically for patient registration. In HealthSMART these are the P&CMS and CMS applications.

o For HealthSMART, the call to the HI Service will be managed via the HSIE, i.e. the HSIE will provide the secure communications channel. Health service applications may be able to request IHI matches directly, however it is recommended that HL7 techniques, consistent with the HealthSMART design, are used to propagate the IHI to other applications.

• The P&CMS or CMS application will be responsible for distributing the IHI to other systems within a health service, such as the Clinical System, Radiology systems, Pathology systems, Pharmacy systems, etc. This leverages the current P&CMS and messaging design.

• Existing patient indexing processes and data will be preserved, thereby limiting the amount of change to be implemented, and enabling a simpler incorporation of IHI data into the HealthSMART systems.

• The potential to support a future transition to using the IHI as the primary patient identifier, replacing the URN, or other patient identifier.

• Changes to health service operational business processes to include support for the IHI must be kept to a minimum, due to funding and personnel constraints.

o Systems should therefore carry as much of the IHI processing load as possible, as fully automated components.

• All communications between HealthSMART and the HI Service must be secure.

• All IHI changes in a local record must be logged and auditable.

3.2 Architectural Constraints The following architectural constraints apply to the integration of the IHI and the HI Service with HealthSMART health services:

• The application being targeted for the initial phase of IHI integration is the Patient and Client Management System within HealthSMART health services. Other application vendors will be provided with this architecture, and the design artefacts.

• The Victorian health messaging standard is HL7 v2.4 HealthSMART. Extensions to this may be considered in order to achieve compliance with NEHTA’s HL7 CDA messaging standard.

of 125

• Oracle Sun JCAPS, as implemented in the HealthSMART Integration Engine (HSIE) and the Agency Integration Engines (AIEs), is the preferred integration layer and business to business communications enabler.

• The project is not attempting to solve the problem of integrating the IHI with all applications in a health service. This will be an activity that the respective application vendors will need to undertake over a period of time. This project will however provide them with design artefacts and the IHI will be operationally available to applications through the HL7 v2.4 ADT messages.

• All system initiated communications with the HI Service, to obtain or to check the IHI, will follow the relevant messaging specifications.

• All requests to the HI Service must follow the HI Service (web services contracts) specification as defined by NEHTA and Medicare Australia.

• All messages returned from the HI Service will follow the HI Service (web services contracts) specification as defined by NEHTA and Medicare Australia.

• Non-functional characteristics of the HI Service and other key elements of the end to end IHI request and response process may impact business process and application design:

o HI Service response times

o Transport and message preparation times

o Retries in the event of an error, and associated time delays

o Limits to the number of records that can be processed in either online or offline batch processing (see Architectural Risks below)

• Funding for change.

3.3 Architectural Risks Architectural risks associated with the IHI integration project have been identified and categorised in the following sections. Architecture risks associated with IHI integration form the primary focus of the architects and the project team in general, in terms of addressing the risks and proposing a workable solution and supporting architecture.

In general the project risks appear centred on the business architecture, in which we consider people. processes, and rules.

Many of the risks identified are consistent with any large business change and IT project. The key risks relating to the HI Service design or implementation, which the project team has raised with NEHTA and Medicare Australia, are documented in Section 6.3 of this document.

The intent is not to mitigate every risk within this design or architecture, but to raise them for attention as organisations move towards IHI adoption.

3.3.1 Business Risks associated with the business architecture include the following.

• A lack of services or processes upon which the IHI is dependent, including the Compliance, Conformance and Accreditation regime and test labs, the Security and Access Framework, and the National Authentication Service for Health.

• Unknown impacts on the legislative or policy framework within which the IHI exists currently from initiatives such as eReferrals, eTP, Orders, Discharge Summaries, and the PCEHR. This suggests that future change is inevitable, with all the associated collateral risks.

• Possibly onerous management roles required to support health service participation in e-health services, such as the Responsible Officer and the Organisational Maintenance Officer.

• Staffing constraints within Victorian health services that will potentially inhibit IHI take-up, and effective use and management of the IHI in an operational context.

• Increased health service staff burden and workload resulting from IHI adoption and its ongoing management.

of 125

• Variance in business processes used in different health services, making it difficult to achieve common approaches for IHI adoption and management.

• Reduced health service staff effectiveness through longer running business processes.

• Long running and potentially manual exception resolution processes, for example when a patient’s IHI cannot be readily obtained.

• Possibility of an enforced compliance and/or adoption regime, forcing adoption/compliance with potential impact on available funding.

• Complex rules relating to the nature of the IHI and supporting management processes.

• Lack of control of IHI management within the health service, eg ability to support a patient through the Unverified to Verified IHI conversion, or to provide a newborn with a Verified IHI.

• Combination of different business domains to support the IHI, one associated with claims / payment (Medicare Australia), and the other associated with care delivery.

• Potential increased clinical risk associated with poor IHI management processes, or inconsistent processes adopted within the sector.

• Change management and training for health service staff, related explicitly to IHI acquisition and management;

• Lack of ability for those responsible for health records management within a health service to be recognised within the HI Service, unless they also happen to be medically qualified;

o This may adversely impact the ability of the HIMs to access HI Service facilities and inhibit issue resolution, and data quality improvement processes.

• Health services are responsible for educating the patient about the IHI and their role in its lifecycle management. This will require resources (brochures for example), training, and change management, and that will ultimately take health service staff away from their primary role(s).

• Funding and incentives for change.

• Lack of obvious benefits to health services in IHI adoption, other than in positioning for future clinical uses, eg e-Referrals, PCEHR, eTP, etc.

• Lack of consistency of operational standards for IHI adoption and management across different health services, making it difficult for them to trust shared information.

o This emphasises the need for a compliance and conformance regime that operates at the business process level within an organisation, such as the program that has been implemented by the UK NHS.

• Incorrect allocation of an IHI to a patient, through inadequate processes, rules and training, thereby rasing clinical risks.

• Management of patients who present with a pseudonym IHI.

• Victorian uniqueness in not having already stated an intent to move towards a statewide Enterprise Master Patient Index (EMPI).

• Lack of comprehensive sector wide governance arrangements for the IHI, and the HI Service.

• Lack of information about alternate channels for IHI acquisition and problem resolution (HPOS, telephone channel).

• Health service management and staff acceptance of responsibilities under the Healthcare Identifiers Act 2010, and recognition of the severe penalties for any breach. Provision of appropriate staff training, and any associated organisational liability in this area.

• Difficulties in achieving a high degree of trust between different parts of the health sector, especially with respect to data quality management.

of 125

3.3.2 Application Risks associated with the application architecture include:

• The component deployment architecture has been optimised for HealthSMART, though this may not suit all health services’ needs or work within their respective application architecture.

• Increased application complexity, through the need to support the IHI and the required management processes and exception reporting.

• Long cycle time to deliver applications with IHI integration, due to the complexity of the IHI design, and the typically long development lifecycles in the health IT sector.

• Lack of SLAs for several HI Service functions, making it extremely difficult to design a solution using those functions.

• Slower application performance, and degrading of user perceivable response times:

o Occurs under situations in which the HI Service calls are synchronous and bound to a user interface event.

• The synchronous nature of the web services implemented in the HI Service, and lack of consistency across NEHTA’s three main web services designs (HI Service, SMD and eTP).

o This means that an organisation implementing all three functions will be required to support three different wen services architectures, thereby increasing complexity and cost.

• Risk of change to the HI Service specification, thereby requiring change to the application design and/or implementation.

• Risk of malfunctioning of downstream health service systems receiving HL7 messages with the IHI included.

• Risk of application change as the NASH is activated, and/or adoption of the HPI-I and HPI-O proceeds.

• Risk that NEHTA’s CCA regime may conflict with, or provide inadequate support, for the Victorian IHI Integration design.

• Potential rework, and hence increased costs, to ensure continued compliance with the NEHTA CCA regime, as new releases of the HI Service are implemented (one every 6 months).

3.3.3 Data Risks associated with the data architecture include:

• Ability for key informational elements to be altered, either by health services or by Medicare Australia, that may result in correctly allocated IHIs being rendered inaccessible and hence unusable.

o Victorian principle is to only use the IHI in any clinical setting if it can be successfully validated against the HI Service, using the Check IHI function.

• IHI matching is based upon string comparison only, with no probabilistic matching possible, meaning that a minor typographical error will result in an IHI match failure.

• Variable quality of information, essential to successful IHI searching, in the health services’ patient administration systems, resulting in a less than ideal IHI matching success ratio.

• Variable data quality processes, and user commitment to these, for information acquisition (Admissions, Registrations, etc) within a health service.

• Multiple domain data comparison to achieve IHI matching, e.g. between health services and Medicare Australia. Data structures, implemented standards, data quality processes and tools, data management processes, etc appear to be different, based on Victoria’s analysis.

• Lack of a sector wide information model for patient or client information, which has been agreed to and adopted/implemented.

o Note the presence of the National Health Data Dictionary, which is conceptually supported, but is not universally implemented in health IT applications.

of 125

• Lack of disclosure of HI Service (internal) IHI matching algorithms.

• Complex IHI state model and state transition processes.

o Addendum for Solution Architecture Release 2. The project team understands that Medicare Australia have requested an additional IHI Status be permitted to apply to the IHI. Details are unknown however this would have impacts due to the change required (new design components), and also increased complexity.

• Possible variable quality of Medicare Australia data.

• Retention periods for IHI logs and audit trails are potentially well beyond any existing audit or data retention requirement.

• Unresolved challenges in managing data quality, and achieving a degree of convergence, across a community of health services and Medicare Australia.

3.3.4 Technology Risks associated with technology architecture include:

• A lack of a robust and long term security architecture (SAF) to support access to the HI Service and transfer of patient information and the IHI.

• Availability of all components of the HI Service, including the service desk, to support HealthSMART health services in their usual 24 x 7 operations.

• Ability of the HI Service to scale to meet increasing demands, or busy periods.

o Addendum for Solution Architecture Release 2. Medicare Australia has stated that the HI Service is inherently scalable at the infrastructure and application levels. The triggers for an increase in capacity and the time to implement remain unclear.

• Ability of the HI Service to recover from any period of non-availability and process a backlog of requests.

• Separation of transactional and batch processing within the HI Service to provide optimal transactional performance and batch processing turnaround times.

• Requirement for a temporary TLS PKI certificate to enable HealthSMART applications and/or the HSIE to connect to the HI Service.

• Performance concerns about the burden of TLS handshaking required to enable access to the HI Service.

• Increased Internet traffic volumes, and hence costs, from HealthSMART to support IHI acquisition and management.

• Increased load on the iSOFT i.PM IIE or HSIE, and the need to scale hardware up and/or out.

• Increased storage requirements for IHI logs and audit trails (minor).

• Availability of a Service Desk for the HI Service and the IHI, to support Victorian HealthSMART health services.

• Risk of technology change as the NASH is activated, and/or adoption of the HPI-I and HPI-O proceeds.

of 125

3.4 Architectural Options There are limited architectural options available when undertaking HI Service integration in order to adopt the IHI. From an architectural perspective this is highly desirable, as the fewer options that are available the more predictable and common the results can be.

The Victorian project team has requested a number of enhancements from NEHTA and Medicare Australia that may increase the number of options available and these are also described below.

3.4.1 IHI Adoption Victorian HealthSMART health services stated explicitly their desire to avoid using both Provisional and Unverified IHIs as far as possible. The Victorian IHI Integration design provides support for all HI Service functions, as stated in the project’s objectives, however health services and indeed IT system vendors may selectively implement certain functions.

The diagram below provides a breakdown of mandatory and optional functions, depending on the types of IHI that a health services wishes to adopt, with the light green items being mandatory even in the most basic IHI integration solution.

Legend

The common services listed immediately under the IHI Functional Profile item (top box) are all essential to establishing a consistent and robust operational environment for the IHI. Of special interest are the behavioural elements which seek to ensure that common processes for managing the IHI and related data are consistent across the sector. They do not need to be exactly the same, but there needs to be confidence established that

Functions requiredfor base systems

Optional functions(for all systems)

Functions required tosupport Unverified IHIs

Functions required tosupport Prov’al IHIs

Selected functionsmay be implemented

Not yet implementedIn the HI Service

IHI FunctionalProfile

Unverified IHIs Provisional IHIs

Create Unverified Create Provisional

Reporting Exception Mgmt

Systems Mgmt Security

Common

Search for an IHI

Check IHI(Vic design)

Online Batch Search

Offline BatchSearch

Verified IHIs

Update Verified IHI(Date of Death)

Outputsincluding the IHI

eReferrals

Admission &Discharge docs

Letters

Orders

Prescriptions

PCEHR

Common ApplicationBehaviours

Common UserBehaviours

Notify of Replica

Notify of Duplicate

Send ServiceRequest (Vic design)

Receive all IHI typeson Referrals, etc

Print PatientIHI Advice

Inputs –All IHI Record

Statuses accepted

Update Unverified

Update Provisional

Resolve Provisional– Merge

Resolve Provisional– Create Unverified

IHI FunctionalProfile

Unverified IHIs Provisional IHIs

Create Unverified Create Provisional

Reporting Exception Mgmt

Systems Mgmt Security

Common

Search for an IHI

Check IHI(Vic design)

Online Batch Search

Offline BatchSearch

Verified IHIs

Update Verified IHI(Date of Death)

Outputsincluding the IHI

eReferrals

Admission &Discharge docs

Letters

Orders

Prescriptions

PCEHR

Common ApplicationBehaviours

Common UserBehaviours

Notify of Replica

Notify of Duplicate

Send ServiceRequest (Vic design)

Receive all IHI typeson Referrals, etc

Print PatientIHI Advice

Inputs –All IHI Record

Statuses accepted

Update Unverified

Update Provisional

Resolve Provisional– Merge

Resolve Provisional– Create Unverified

of 125

when health service A receives an IHI on a Referral, or other communiqué, from health service B that the IHI and related data can be trusted.

Health services may receive any type of IHI (IHI Record Status – Provisional, Unverified or Verified) on a referral or other patient communication, and they may have no control over this. Systems must be capable of receiving and managing all types of IHI even if they do not provide direct support for creation of Provisional or Unverified IHIs.

The extension to this requirement is that the Unverified and Provisional management functions may be essential rather than optional. This would include all functions in the Unverified and Provisional lists except for Create Unverified and Create Provisional. The Victorian design does not ever perform an update on a Provisional IHI record, as this would render the record inaccessible to other health services. Instead the Victorian design leverages existing patient management processes, with the focus being on identifying the patient and finding their Verified IHI (in most cases).

The outputs functional grouping reflects the usage of the IHI in patient centred communications, and ultimately to support the use of the PCEHR. It is expected that health services adopting the IHI will wish to use the IHI on a range of outputs, some of which are listed. There seems little point adopting the IHI if it isn’t going to be used.

The element missing from the diagram above is any mechanism for declaring the IHI processes and services supported within an organisation and application, and where any IHI processing or management options are available a declaration of the organisational profile. This could be addressed through a compliance type entry on a PKI certificate (organisation level).

Recommendations:

1. The project team recommends that organisations plan to receive and process Provisional and Unverified IHIs, even if they make a policy decision never to create these IHIs. This recommendation is made on the basis that it may be difficult to control the policies established by other health service.

3.4.2 Interface to the HI Service There are two main options for the application interface to the HI Service, including:

1. An HI Service interface that is closely integrated with the respective PAS application and probably available from the PAS vendor.

2. An HI Service interface that is not integrated closely with the PAS, and which must use a messaging layer, such as HL7, to enable the exchange of IHI related information.

The second option has been selected by HealthSMART for this solution architecture, as it provides the optimum alignment with the defined HealthSMART architecture.

Note that the option of distributing the IHI acquisition and management to a third party, such as a health messaging distributor, is not considered here, though it is theoretically supported by the legislation. A requirement for this project is to make the IHI available to the health service workers, in their PAS, hence the deprecation of this option.

Integrated HI Service interface

In this option the HI Service interface is integrated within the PAS, or other application. This provides a straight forward IHI integration path, as the acquisition of the HI Service interface component will enable adoption and management of the IHI. This option may also enable information exchange more tuned to the IHI requirements than is possible in a disconnected HI Service interface, using HL7 as the transport.

This solution will ideally incorporate message queuing techniques as defined in the Vic IHI Integration Technical Design.

Firewall security settings will need to be established to enable communications between this integrated component, and the HI Service. A tiered security environment is recommended, with the exposed HI Service interface components implemented in the network DMZ. This implies a degree of separation between the application components that manage the IHI and the HI Service interface components, hence the Victorian decision to adopt the separate HI Service interface.

Note also the importance of managing the synchronous web services interfaces (memory and CPU impacts for long running or failed transactions), in this scenario.

Essentially the integrated HI Service interface will be expected to demonstrate attributes of commercial Enterprise Application Integration (EAI) or Enterprise Service Bus (ESB) type tools.

of 125

Separate HI Service interface

In this option, the HI Service interface is separate from the PAS application, and an application to application level interface is used to relay IHI related information between the two applications, including IHI requests, HI Service responses and audit/log/exception data.

This option enables the implementation of the HI Service interfaces in a commercial EAI or ESB tool, thereby enabling effective use of the in-built services, such as B2B functionality, simple web service implementation, queue management, exception handling including the ability to retry requests, etc.

While the application to application messaging architecture could be based on web services, HealthSMART plans to use HL7 messaging techniques to enable the exchange of information between the two applications.

The main benefit of this approach is that it aligns closely with the implemented HealthSMART architecture, and it moves much of the HI Service interface complexity from the PAS application to the integration engine, which is designed to support interfacing functions.

Recommendations:

1. HealthSMART will implement the separate HI Service interface.

3.4.3 Secure Access to the HI Service The Victorian IHI Integration project team also raised the possibility with NEHTA and Medicare Australia of HealthSMART having a secure permanent VPN type connection to the HI Service to enable highly efficient communications.

The Victorian design complies fully with the HI Service specification, and the use of TLS to ensure the security of requests to the HI Service, and the returned responses.

The disadvantages of TLS are:

1. Establishing a TLS connection between two servers involves up to 24 network interactions, not including any checks against a Certificate Revocation List or OCSP service to ensure that the PKI certificates are valid. This serves to increase the transaction time, and increase the net cost of the transaction. A TLS reconnection involves much fewer network interactions (typically between 4 and 8) and hence is to be preferred.

2. A TLS connection is transient, and intended to be used transactionally. That is the TLS connection will be established, the message sent, a response received (may involve a reconnection), and the connection closed. A subsequent transaction will follow the same process.

The SSL/TLS timeout setting is at the control of the system developer or architect, and it can be modified to suit a given situation, though best practice guides are available that constrain the options available. Further analysis will be required to determine the optimum setting for use within the HealthSMART environment.

As the TLS connection is at the server to server level, different settings on the servers involved (ie HealthSMART and HI Service systems) will result in the connection being timed out at the lower setting on either server.

The HealthSMART environment is expected to process a large volume of HI Service requests, certainly in the tens of thousands per day. Endeavouring to open and close TLS connections for this number of transactions is undesirable, and ultimately costly.

Options for consideration:

1. An option raised with NEHTA and Medicare Australia is to establish a permanent VPN connection between HealthSMART and the HI Service. This would remove the need for any TLS connection negotiation, and enable HealthSMART (and the HI Service) to simply stream requests and responses across the private network. There are real costs associated with this proposal, and also potential impacts on other users of the HI Service. The detailed cost benefit analysis is not within the scope of this project.

2. A second option is to manipulate the TLS timeout settings to open a connection between HealthSMART and the HI Service and stream multiple requests over the link until the TLS link has to be released, at which point another TLS connection would be opened, and the process repeats.

of 125

This limits the number of TLS negotiations that must occur, and makes better use of an established connection.

Recommendations:

1. Victoria recommends option 1 above, a dedicated HealthSMART to HI Service VPN connection. NEHTA will reconsider the Victorian request as IHI request volumes rise.

3.4.4 Synchronous vs Asynchronous Operation Victoria has requested that NEHTA and Medicare Australia consider an alternate implementation of the HI Service functions in a fully asynchronous web services model, consistent with NEHTA’s Secure Messaging specification.

This option will suit organisations who have implemented moderate to large scale messaging or enterprise application integration solutions, as the asynchronous model is inherently more efficient from a client perspective offering memory, CPU and other benefits. This would also enable organisations to implement one web services architecture to support both e-health messaging (eReferrals, Discharge Summaries, etc) and requests to the HI Service, thereby reducing complexity and costs.

Conversely, from a small health service perspective asynchronous web services are potentially highly complex to implement, though if health services wish to send or receive e-Referrals and discharge summaries they will have to implement asynchronous web services.

The Victorian IHI Integration design uses the synchronous web services approach dictated by Medicare Australia, even though this is undesirable from an implementation perspective. Victoria will continue to pursue this item with NEHTA and Medicare Australia until a satisfactory solution is agreed.

Recommendations:

1. NEHTA and Medicare Australia to implement an asynchronous web services interface to support the HI Service, consistent with the SMD specification.

of 125

4. Current State Overview 4.1 HealthSMART Business and Organisational Context The information below is reproduced from the HealthSMART website at http://www.health.vic.gov.au/healthsmart/about.htm.

HealthSMART is the program implementing Victoria's $360 million whole-of-health information and communication technology (ICT) strategy to modernise and replace ICT systems throughout the Victorian public healthcare sector. The ICT improvements provide healthcare agencies with the tools required to meet the growing healthcare demands expected in the future.

HealthSMART is providing the tools that will assist agencies to:

• Increase the quality and safety of care and improve health outcomes

• Develop more consumer-oriented healthcare

• Increase the efficiency of healthcare provision

• Improve the management and utilisation of resources

• Attract, retain and support a highly-skilled workforce through the strategic application of information and communications technologies.

HealthSMART is achieving these outcomes by:

• Replacing obsolete, unsupported core applications with capable, industry-standard products

• Introducing new systems capable of supporting the transformation of healthcare

• Refreshing and developing the ICT infrastructure

• Delivering ICT services through a shared service model featuring the use of core infrastructure across a sophisticated telecommunications network.

4.1.1 HealthSMART's guiding principles Applications & technology

• Cost of building, upgrading and customising technology to be reduced by appropriate standardisation.

• Applications and data to be hosted centrally in a shared services data centre

• Shared infrastructure designed to address concerns about the security of data.

Implementation

• HealthSMART managed as a single program by the Office of the Chief Information Officer within the Department of Health

• Agencies follow OCIO program guidelines when managing ICT projects, including contributing agency funds.

• Government financial support given to healthcare agencies using HealthSMART products supported by HealthSMART Services

• Existing government arrangements and collaborations used to maximise purchasing power

• Agencies responsible for ongoing support and maintenance costs

• This approach is intended to include, as much as possible, ICT investments to date and to target the removal of the significant risks and exposures that have been identified in the existing ICT environment.

of 125

4.1.2 HealthSMART Delivery The HealthSMART program (the Program) is responsible for managing processes to select applications, configuring these applications to reflect state-wide requirements ('state-wide footprint') and then implementing these applications into participating agencies using the state-wide footprint as a base.

Additionally, the Program is responsible for establishing and managing the shared ICT infrastructure that is required to support these applications and agencies use of them.

The portfolios that were established to manage the scope of work required were:

1. The Resource Management Systems portfolio, includin g:

• the finance and material management systems (FMIS) project

• the human resource management systems (HRMS) project

2. The Technical Services portfolio, including:

• HealthSMART Services

• Integration Services

3. The Patient & Client Management Systems portfolio, including:

• the integrated patient & client management systems project

• the client management systems project

4. The Clinical Systems portfolio.

A few changes to the functional scope of the Program have occurred throughout its life, the major ones being:

• Addition of a Picture Archive and Communications (PACS) project to provide health services with the capacity to manage their imaging services electronically and remove the need to print film.

• A payroll and human resource reporting project (HRMS Payroll) was established, in addition to the HRMS Rostering project.

• A Rural & Regional FMIS project to deploy FMIS functionality across all Rural Alliances.

As at September 2010 significant progress had been made across the Program with the PCMS, CMS HRMS, FMIS and PACS portfolios having closed after successfully completing the implementation stage of the projects. The technical infrastructure, including HealthSMART Services and HealthNET has also been established.

Clinical System Release 1 has been implemented in the two lead agencies Eastern Health and Royal Victorian Eye and Ear Hospital. Remaining activity is focussed on the remaining Clinical System implementations as well as a new Common Technology Infrastructure initiative aimed at reducing the overall cost of ICT service delivery across the sector. The growth of HealthSMART Services and HealthNET continues to be incremental and in support of agency implementations.

4.2 Patient Identifiers The usage of patient identifiers in Victoria is highly siloed, with each health service using an organisation specific patient identifier. Victoria does not currently have a statewide Enterprise Master Patient Index (EMPI), though some health services have implemented this service.

Consequently, patient identifiers are available, and highly valuable, within a health service, though of little use beyond the health service, except as an external reference identifier.

The major public health services typically use a Unique Record Number (URN), or the Medical Record Number (MRN) as the patient identifier though formats and lengths can vary. This identifier may be episode specific, though there are strong processes within the health services to ensure that these identifiers apply across multiple episodes.

The Medicare number, while not truly regarded as a patient identifier, is being captured more rigorously by Victorian health services. GPs and specialists have a long history of capturing the Medicare details, due to the funding relationship. The public health services are now also capturing the patient’s Medicare number and associated demographic details, which is hoped to optimise IHI searching.

of 125

4.3 Related Projects A number of existing or planned projects may have an impact on the Victorian IHI Integration solution architecture and design, or may need to leverage the project deliverables.

1. Victorian Wave 1 project, funded by DoHA, to implement key elements of the PCEHR, including the IHI.

a. The Victorian Wave 1 project involves the Melbourne East GP Network, Eastern Health, and the department.

2. Enhancements to the Victorian Human Service Directory, which doesn’t impact the IHI directly, but impacts the HPI-I, HPI-O, ELS and possibly the NASH.

3. Health IT vendor initiatives to interface to he HI Service.

4. Initiatives in other jurisdictions, or with national influence, such as:

a. ACT Health’s work on IHI patient matching, supported by IBM / Initiate.

b. TAS DHHS work on interfacing to the HI Service.

c. NSW Hunter region Wave 1 project.

d. Qld Wave 1 project.

e. Northern Territory secure messaging, EHR and other related projects.

f. Extension or duplication of the HSD to provide a national service.

g. Wave 2 projects, in Victoria and other jurisdictions.

h. NEHTA’s continuing work on packages, including discharge summary and electronic referral.

i. NEHTA’s continuing work on compliance and security frameworks to support the ehealth agenda, including the CCA and SAF.

j. NEHTA’s and IBM’s development of the NASH.

4.4 HI Service Summary The HI Service is one of the core e-health services identified by NEHTA as essential to enabling e-health in Australia.

The HI Service provides functions to support the adoption, use and management of healthcare identifiers for organisations (HPI-O), healthcare professionals (HPI-I) and individuals (IHI) who may seek healthcare.

The reader should be familiar with the NEHTA HI Service Concept of Operations V2 document, and with the Healthcare Identifiers Act 2010.

For the purposes of the IHI Integration requirements and design, the following services, or functions, available through the HI Service are of primary interest.

4.4.1 Update Provisional IHI via B2B This function enables the updating of an HI Service record with a Provisional IHI. This function is available to all HI Service users and is intended to be used when more accurate information becomes available for the previously unidentified patient.

The Victorian design caters for this function, though the recommendation is that configuration settings be used to prevent this function from ever being used. This is for two reasons:

1. Health service staff should make all efforts to identify the patient, and take subsequent steps to update the patient record and obtain a Verified or Unverified IHI.

2. Changing the details of an HI Service record with a Provisional IHI may render it inaccessible to other health services with which it has been shared.

of 125

There is no uniqueness checking for this update.

4.4.2 Update IHI via B2B This function supports the updating of both Unverified and Verified records, with only the notification of death available for a record with a Verified IHI. All data in a record with an Unverified IHI may be updated.

All updates are subject to uniqueness checking, within the HI Service.

4.4.3 IHI Inquiry Search via B2B This function enables health services to search for a patient’s IHI, and to check it periodically once the IHI has been obtained. The search relies upon a text string based comparison, so it is vital that the patient information used in the IHI search is of high quality and accuracy.

NEHTA and Medicare Australia recommend using the search with one of the numeric identifiers; either the Medicare number the DVA file number or the IHI for optimum results.

Records with Provisional IHIs may not be searched for without the IHI included in the search criteria.

4.4.4 Resolve Provisional IHI- Merge Records via B2B This function enables the health service to request that a record with a Provisional IHI be merged with a record having an Unverified or Verified IHI.

This will occur when the previously unidentified individual can be identified and a search using their correct details returns a Verified or Unverified IHI.

The HI Service record with the Provisional IHI has its Status updated to Resolved.

4.4.5 Resolve Provisional IHI- Create Unverified IHI via B2B This function supports the promotion of a record with a Provisional IHI to a record with an Unverified IHI, following the obtaining of more information about the patient.

In this instance the original provisional IHI number is preserved. A uniqueness check is performed in this instance.

4.4.6 Create Provisional IHI via B2B This function enables the creation of an HI Service record with a Provisional IHI, and requires minimal information.

There is no HI Service uniqueness check for this function.

4.4.7 Create Unverified IHI via B2B This function enables the creation of an HI Service record with an Unverified IHI. There is a considerable amount of information that may be included in the creation request, including multiple addresses and contact information.

There is an HI Service uniqueness check for this function.

4.4.8 IHI Batch Searching This function enables IHI searches to be submitted to the HI Service in a batch mode. The HI Service supports up to 100 searches via the online batch, and up to 2000 per file in the offline batch, with multiple files able to be included in a single batch submission.

The offline batch employs a secure USB stick and courier or registered email to move the batch between the health service and the HI Service operator.

of 125

4.5 IHI Overview The Individual Healthcare Individual (IHI) is the national identifier for all recipients of healthcare in Australia. It is a 16 digit number, in accordance with international standards. All Australian residents actively enrolled with Medicare and DVA were assigned their identifier on the 1st July, 2010.

There are three types of Individual Healthcare Identifier (IHI), identified by the Record Status field held by the HI Service, and which will be stored with the IHI in a PAS,

A Verified IHI – when an IHI record is Verified it means that the person is a known customer of Medicare Australia or DVA or has provided evidence of identity information that has been recorded in the HI Service by the Service Operator to establish the identity of the Healthcare Individual.

An Unverified IHI – when an IHI record is Unverified it means that the identifier was created from a request made by a healthcare facility and the individual has not contacted the HI Service to verify the IHI by providing evidence of identity. Unverified IHI records can be merged to another verified IHI record.

A Provisional IHI – when an IHI record is Provisional it means that the identifier was created at a healthcare facility when the individual was not able to be identified. Provisional records are able to be promoted to an Unverified IHI record or merged with an existing Unverified or Verified IHI record via a healthcare facility or updated to a Verified IHI via the HI Service by providing evidence of identity.

There are five possible IHI statuses of the Individual Healthcare Identifier (IHI):

• Active IHI – this is the preferred state of the IHI when considering its use within a health service, and this status indicates that the IHI record is for a person who is actively involved in receiving healthcare, i.e. they are not deceased. Applies to Provisional, Unverified and Verified IHIs.

• Deceased IHI – an IHI has a status of Deceased when a health service sends notification of death to the HI Service. This is has not yet been matched with Fact of Death Data (FoDD) from Births, Deaths and Marriages Registries.

• Retired IHI – an IHI has a status of Retired when the record has been matched with Fact of Death Data from Births, Deaths and Marriages Registries and has had no activity for 90 days; or the has reached an age of 130 years (Verified only).

• Expired IHI – an IHI has a status of Expired when it is either Provisional and there has been no activity on the record for 90 days; or Unverified and has reached an age of 130 years.

• Resolved IHI – an IHI has a status of Resolved when it is linked with another record which has been identified as the primary record. The Resolved status is only used within the HI Service and will never be seen by health services.

The diagram below presents a view of the possible IHI statuses and the processes that support or enable transition between the different statuses.

of 125

Figure 2: IHI State Diagram, by Medicare Australia, Healthcare Identifiers (HI) Service

IHI Searching Guide DRAFT Version: 0.3 - 20 Sep 2010

of 125

5. Solution Overview 5.1 Solution Objectives The overarching objective of the solution is to enable the seamless integration of the IHI and the HI Service into HealthSMART health services systems and processes.

Many benefits have been identified as flowing from the use of the HI Service and the IHI, however the most prominent is the ability to reliably and consistently identify the patient through the use of their IHI and selected demographic information. This has a suite of flow on benefits, such as:

1. Reduced clinical risk as a result of reducing the incidence of patient misidentification

2. Enhanced confidence in patient identification in e-health messages, such as referrals, orders and discharge summaries. The national approach to the IHI supports enhanced patient identification on inter-jurisdictional patient transfers / referrals.

3. Enhanced capability to establish a longitudinal health record for any given patient, using the IHI to link elements of the patient’s record from disparate health services (ultimately results in enhanced clinical care).

The IHI Integration solution has a number of other objectives, as follows:

1. Comply with all relevant legislation, including the Healthcare Identifiers Act 2010.

2. Minimise the clinical risks associated with potential IHI misuse.

3. Leverage the facilities available through the HI Service to the maximum degree possible.

a. The project team understands that health services are unlikely to adopt all types of IHI and hence all HI Service functions at one time.

4. Cater for any identified deficiencies in any component of the end to end solution.

5. Identify any serious risks or issues that require resolution for IHI integration to deliver the maximum benefits possible.

6. Provide users with an effective approach to adopting, managing and using the IHI.

7. Leverage to the maximum degree possible existing HealthSMART services, applications, processes and infrastructure.

5.2 Solution Dependencies The major solution dependencies include:

1. A comprehensive sector wide change management program to facilitate adoption of the IHI.

2. Health service focussed change management programs to enable change within the respective organisations.

3. Participating health service allocation of RO and OMO roles, obtaining of one or more HPI-O’s, registration of HPI-Is associated with the organisation, registration of HI Service users not entitled to an HPI-I, acquisition of appropriate PKI certificates, and maintenance of all of the above.

4. A public education program to inform Australians about the IHI, including their rights and obligations.

5. Enhancements to all health IT systems that need to acquire, store and/or use the IHI.

6. Development of application components and implementation of infrastructure to support interactions with the HI Service.

7. A robust security environment in which systems, services and information are protected to the required degree.

a. Implementation of the NASH is an important step.

8. A comprehensive compliance, conformance and accreditation framework to ensure common application and user behaviours in IHI management and usage. This is essential to ensure that the sector converges towards a common goal and trust is achieved.

9. The establishment of a strong governance body to support and control the IHI and the HI Service.

of 125

10. A security and access framework to ensure that the IHI and related information is adequately protected both in messages and in systems, and that only authorised users are permitted to access information.

11. The availability of testing facilities for use by solution providers to enable the validation of software components for compliance with Medicare Australia’s and NEHTA’s specifications and standards.

12. Robust, available and scalable e-health core services, especially the HI Service and NASH, able to meet the needs of the sector at all times.

of 125

6. Solution Architecture Definition 6.1 Architectural Assumptions The following assumptions have been used in the preparation of this Solution Architecture:

• HealthSMART infrastructure will be able to support any additional workload resulting from IHI acquisition and management processes, possibly with incremental capacity uplift being required. This would be subject to health service IHI adoption schedules and the analysis of expected transaction volumes.

• HealthSMART applications and tools (at the infrastructure level) will be able to support IHI related functions without requiring significant change. Development of HI Service interface components will be required.

• Only minor changes will be required to any HL7 messages required to support IHI acquisition and management processes.

• Health IT system vendors will support the Victorian IHI integration design, and for vendors of HealthSMART systems, the solution architecture and technical design will also be supported.

• Change in the sector will be gradual - various sector participants will progress with the adoption of the IHI “at their own pace”.

• Any major architectural concerns or risks will be resolved to a satisfactory conclusion, in a timely manner.

6.2 General Architecture Principles A number of common and high level principles are commonly applied when developing any solution architecture:

1. Maximise reuse and minimise rework.

2. Reuse before buy, buy before build.

3. Protect end user systems from high levels of complexity (and hence higher costs) where possible and feasible.

4. Plan for the future, through enabling change within agreed and established parameters.

5. Consider all aspects of the solution lifecycle, from analysis, through design and implementation, to operations. The architecture must enable implementation, but also ensure ongoing sustainability.

6. Use loose coupling techniques (eg web services) to meet application to application integration requirements.

7. Keep it simple.

6.3 Architectural Concerns Raised The Victorian IHI Integration project team submitted a list of concerns to NEHTA and Medicare Australia, with agreement being established on how these items would be handled in the Victorian design. These concerns were subsequently provided, on request, to the NHCIOF, and a briefing provided.

These concerns, with minor wording changes, are provided below.

A number of important constraints, as identified by Victorian HealthSMART health service representatives, are included below:

1. The IHI will not replace the UR number as the primary patient identifier, within a Victorian HealthSMART health service in the medium to long term. The current health service environment and the current NEHTA/Medicare IHI design precludes this from being achieved in the immediate future.

of 125

2. Victorian HealthSMART health service representatives would prefer not to use Provisional or Unverified IHIs under ANY circumstances.

3. Victoria has a principle whereby the IHI Status and IHI Record Status must be shown wherever the IHI number is used. This was to provide full qualification of the state of the IHI at the point in time when the IH was “used”.

6.3.1 Structured Address format For discussion with NEHTA and Medicare Australia, with the focus being to understand the feasibility of relaxing the existing rules for mandatory address fields, in the HI Service.

This item applies particularly to the structure of the IHI demographic search and also the request for creation of an Unverified IHI. Victoria would be unable to use either of these services given the structure of address data in HealthSMART applications, and the inherent dangers of parsing data.

A variety of options are available, including:

1. Victoria adopts QAS or GNAF across HealthSMART and moves to using standard address formats within the PAS environment.

2. NEHTA and Medicare Australia relax the rules in the HI Service so that the street address fields become optional (suburb, state, postcode and country remain required).

3. NEHTA and Medicare Australia agree to alter the HI Service to accept Address line 1 and Address Line 2 data.

Assumptions / Resolution / Mitigation

1. Victoria has based the IHI Integration design on the relaxation of rules currently requiring a full structured address, especially for the IHI Inquiry function(s).

2. Medicare and NEHTA will agree to relaxing the rules for the address format to provide better support for the current state of address data in the sector. This will enable the street address fields to be optional under all conditions, but will allow suburb, postcode, State and Country to be included. This may be extended to accepting address line 1 and 2 formatted data.

3. The change applies to all instances where an address is used, i.e.:

• IHI Inquiry (detailed demographic search)

• Create Unverified IHI

• Update Unverified IHI.

4. Victorian health services may elect to implement QAS, or a similar service, though this is not currently within the forward plan for the HealthSMART program. Timeframes, costs and the breadth of deployment are unknown.

Recommendation • Item 2 above

Addendum for Solution Architecture Release 2: Item 2 is the subject of a change request currently under consideration by Medicare Australia and NEHTA.

6.3.2 HIMs access to the Service Desk Medicare Australia’s view on the ability of Health Information Managers, and other administrative staff, to access the HI Service Operator is reflected in the following statement, though a workaround for this may be possible: “At this point in time HIMs will not be able to access the telephony channel for these types of enquiries. Proposed changes to the authentication model may enable this to occur, but these are some months away. Right now the only individual able to access the telephony channel for this sort of enquiry is a HPI-I.””

The legislation suggests that, provided an employee of a healthcare organisation is duly authorised and the service operator is notified of this authorisation, they should be able to access Healthcare identifiers from the HI

of 125

Service, and the supporting services such as the help desk. Reference section 17(b) in the Healthcare Identifier Act 2010, and the supporting definitions.

Areas for clarification include the nature of the authority that should be provided to Medicare Australia, the turnaround time for processing, and the possibility of having an online service desk request system, so that a health service staff could raise a request electronically, rather than having to call the service desk.

As the logical extension to the above, the Victorian IHI integration design includes a web service based service request mechanism (for SR’s to go to the HI Service operator), which Victoria will continue to pursue with Medicare Australia and NEHTA.


2. Medicare and NEHTA will enable, through appropriate authorisation, HIMs and other health service administrative staff to access the HPOS facility and to the service desk supporting the HI Service.

3. Medicare Australia or NEHTA will provide information about the nature of the authority to be provided by the health service (RO) to the HI Service operator to grant HI Service access to a staff member without an HPI-I, i.e. an Organisational User.

i. An automated authorisation mechanism would be preferred by Victoria, i.e. a web service based call, and a function on the HPOS.


Information from NEHTA suggests that, for B2B access, it is sufficient for the user’s name / identifying information to be included in the B2B message, and that no separate and formal notification is required. This is not the case for HPOS or MSO level access.

Addendum for Solution Architecture Release 2: No further information on this concern is available.

6.3.3 Scheduled outages and notifications Many Victorian health services, and especially the major public hospitals, operate on a 24 x 7 basis, and any inability to access the HI Service or the service desk may become an issue.

Areas for discussion include frequency and duration of scheduled outages, outage scheduling, techniques for managing the HI service being unavailable, service desk hours, notifications to users and consideration of industry best practice.


1. Medicare Australia to consider adopting, and publishing, a standard scheduled outage window for all HI Service maintenance activities, even if they subsequently elect not to use the outage window.

2. Victoria hopes that NEHTA and Medicare Australia will work towards a high availability solution for the HI Service, so that even scheduled outages do not result in the service becoming unavailable.

Addendum for Solution Architecture Release 2: Information from Medicare Australia suggests that scheduled outages will no longer result in the HI Service being unavailable.

6.3.4 Access Control and Auditability Access control requirements in relation to auditing, user notifications to HI service, certificates etc. No current standards are expressed. CCA requirements for application and Organisation performance requirements are needed.

This item should be considered in the context of Item 6.3.2 above, where users of the PAS not entitled to an HPI-I will need to have an authorisation sent to the HI Service operator to register their use – for HPOS and MSO access only according to the update in Section 6.3.2.

of 125

It has recently come to Victoria’s attention that, according to the Healthcare Identifiers Act 2010, audit records must be kept while the staff member accessing the HI Service remains on the staff, and for 7 years after they leave. For a person who joins at 20 and resigns at 60, the audit records will then need to be kept for 47 years, which would appear to be well beyond any statute of limitations applying to the retention of patient information.

Assumptions 1. Victoria will continue to create audit records in keeping with current practice.

2. Victoria will additionally create audit records, including the user information, relating to a call to the HI Service.

3. Victoria would appreciate NEHTA and Medicare Australia reviewing the audit log retention requirements.

Recommendation • NEHTA and Medicare Australia to review audit log retention requirements, and align these with current medical records requirements.

6.3.5 Using Unverified and Provisional IHIs Victorian HealthSMART health services are keen to avoid the use of Unverified and Provisional IHIs in e-health messaging and hence in the PAS, and this has been catered for within the Victorian IHI Integration design.

On the use of the Unverified IHI, in warranted circumstances, the following items have been raised and guidance requested:

• Uniqueness requirements for Unverified IHIs and guidelines on how to achieve them, especially for people who wish to remain anonymous.

• Victorian health services’ (current) inability to create an Unverified IHI with address information, as we do not have address data in the correct format.

• Our inability to search for an Unverified IHI using address information in the search criteria (may be the only way to get a match).

• Current functionality allows any health service to change details of an Unverified record with no traceability or notification to original source.

• The approach to searching for an IHI using TDS identifier, name, DOB and gender, and the inconsistency when a health service requests to update or merge records, where the action is based purely upon the IHI. This seems inconsistent.

• Our ability to trust Unverified information if received on a referral or other e-health message, and our ability to check an Unverified IHI, and achieve a positive result.

• Use of Unverified IHIs for newborns and other options that may warrant consideration.

Note that HealthSMART applications may still need to cater for other health services using Unverified IHIs in a manner that HealthSMART health services would avoid.

The apparent value of the Provisional IHI record appears to be minimal, as it seems to have most relevance where the IHI is intended for use as the mandatory patient identifier. Given that Victoria will NOT be using the IHI as a replacement for the UR number, there appear to be very few, if any, business scenarios that warrant the use of a provisional IHI.

Victoria has identified one valid scenario in which an unconscious patient is admitted to a health service’s ED, treated and stabilised and then transferred to another health service, while still unconscious and unidentified. The value in using the Provisional IHI however is only realised where other electronic referral standards and protocols are in place, and referral updates flow back to the originating health service to update subsequently identified patient information.

A review of the NEHTA’s Discharge Summary package has highlighted that the IHI is a mandatory data element of the discharge summary message. This requires clarification, because if this rule persists Victorian HealthSMART health services, and other health services across Australia, may have to adopt both Provisional and Unverified IHIs. Note also that the IHI Status and Record Status are not identified as mandatory fields in the Discharge Summary message, which is inconsistent with the Victorian design, and also with best practice. Further investigation of IHI requirements in Referrals and Discharge Summaries (and orders, results,

of 125

prescriptions, letter, etc) is required in the context of transition to a future state in which the IHI is commonly available and in frequent use. The IHI cannot be mandated where it is not able to be retrieved reliably.

Addendum for Solution Architecture Release 2: Victoria’s understanding is that the IHI field will be made mandatory where available, and that work will be undertaken (by NEHTA) to include the IHI Record Status and IHI Status fields in the respective NEHTA specifications.

Victoria is concerned that current HL7 standards do not appear to support status information to be associated with identifiers in the PID segment, with this being an item that will be raised with NEHTA separately. As the PID segment features in all ADT HL7 messages, and also in the Referral and Discharge Summary (I12, I13, I14) messages, this is a concern given Victoria’s principle to include the IHI state wherever the IHI number is used.

Assumptions / possible resolutions

1. Victoria has based the IHI Integration design on currently available functions.

2. Victorian HealthSMART health services will periodically check the state of an assigned IHI against the HI Service. If Medicare Australia will provide a periodic batch file of IHIs with changed or resolved states, this may reduce the transaction volume, but is unlikely to remove the requirement altogether.

3. Victorian HealthSMART health services will ONLY request Provisional and Unverified IHIs in circumstances where their use is essential.

4. Victorian HealthSMART health services will accept referrals and similar that include Provisional or Unverified IHIs, however the patient information provided will not be trusted.

5. Medicare Australia and NEHTA to review the practice of allowing any (HI Service enabled) health service to modify any Unverified or Provisional IHI record, in an uncontrolled manner. Use of appropriate defensive and data quality management techniques would make the Unverified IHI much more acceptable to Victorian health services.

6. Medicare Australia and NEHTA review, similar to the above but related to the basis for the modification of HI Service stored records. In a human activity the user must search for a record, validate that they have selected the correct one, and they may then apply the modification. It appears anomalous that the HI Service would accept a change to a record without previously determining that the health service could successfully search for the record, ie all update and merge requests must include the basic search criteria, and if the search fails the update must be rejected.

7. NEHTA to review the recommended use of Unverified IHIs for newborns with a selection of health services providing neonatal care, with a view to, at some future point, possibly enabling the creation of a Verified IHI for the newborn, or providing greater controls over the Unverified IHI.

8. NEHTA to modify the Discharge Summary specification to make the IHI mandatory, where it is available.

9. NEHTA to review the need for inclusion of the IHI state information (IHI Status and IHI Record Status) in all e-health messaging, and in fact anywhere that an IHI is used. This materially helps in confirming the result of any patient matching process.

10. Addendum for Solution Architecture Release 2: It is also essential to explicitly include the patient demographic data used to acquire or check the patient’s IHI in every e-health message or patient centric communication. Including this information guarantees that the receiver

Recommendation • Health services to establish polices regarding IHI creation and use within their organisations.

• Vendors to establish system settings to support the various policy settings.

of 125

Addendum for Solution Architecture Release 2: Victoria’s understanding is that the NEHTA packages will be modified to make the IHI field mandatory where available, and that work will be undertaken (by NEHTA) to include the IHI Record Status and IHI Status fields in the respective NEHTA specifications.

Addendum for Solution Architecture Release 2: Victoria’s understanding is that the need to include the IHI Record Status and IHI Status fields anywhere that the IHI is used is under active consideration by NEHTA, and it has been brought to the attention of the NHCIOF and the IT-014 Australian Standards group.

6.3.6 Record Merges, and the Lack of an Unmerge Function HealthSMART P&CMS and CMS applications always link records when merging, rather than actually combining the records. This enables records to be unmerged if required at a future time. There would appear to be significant benefits, not least in terms of alignment and consistency, if the HI Service were to behave similarly.

Victoria is also concerned about the suggested process for addressing an incorrect record merge, in that two new IHIs would be created. This, with the lack of a broadcast update, and the future uses of the IHI in supporting clinical information flows, seems risky.

It should also be noted that Victorian health services may continue to merge records even if the patient is deceased.

Assumptions 1. Victoria has based the IHI Integration design on currently available functions.

2. Medicare Australia and NEHTA to review the inconsistency between merges at the health service (linkage of patient records), and the HI Service approach and whether the difference constitutes a risk.

3. Similar to the above, though related to the unmerge function, which is admittedly used very seldom, and hence may not pose a major risk.

Recommendation • Items 2 and 3 above.

6.3.7 Date of Death Handling Attendees at the IHI workshops raised concerns about the automated processing of Date of Death data by the HI Service, and would prefer not to trust date of death information until the BDM confirmation is received.

Victoria has requested that the IHI and the date of death be explicitly included in the Retired IHI record information message returned to the client application.

Victoria is also interested in the processes that Medicare Australia will follow when they get a deceased notification from a health service, but the BDM notification is not received within 90 days, or BDM suggest that the person isn’t deceased.

Assumptions 1. Victorian HealthSMART health services will not trust information included in the deceased message returned from the HI Service, as this information hasn’t been confirmed by BDM.

2. Medicare Australia and NEHTA to investigate further the inclusion of explicit patient information (minimally the IHI, and the search parameters included in the IHI Inquiry call) and Date of Death in the Retired IHI message.

Addendum for Solution Architecture Release 2: Medicare Australia has removed the date of death from any message returned from the HI Service to the original requestor, due to privacy and legal concerns. This constitutes a loss of benefit, in that the date of death is usually required in order for health services to initiate their deceased patient process. Item 2 above is now irrelevant, while item 1 remains valid.

of 125

6.3.8 Service Request to the HI Service Operator The Victorian IHI Integration design assumes that an automated, and web services based, service request lodgement mechanism will be made available, to avoid extended telephone calls, operator queues, issues with user authority to call the HI Service operator, and provide optimum data quality, for information relating to the service request, through the use of an electronic medium.

Assumptions 1. Medicare Australia and NEHTA to review the requirement and consider implementing an automated service request lodgement facility, using web services.

2. Medicare Australia and NEHTA to also consider an online service request lodgement function, via HPOS.

Recommendation • NEHTA and Medicare Australia to agree to implement a service request web service (Item 1).

Addendum for Solution Architecture Release 2: No additional information has been received on this item.

6.3.9 HI Service Response Times Within each 15 minute measurement period the average HI Service response time is to be no greater than 8 seconds. What is the projected average maximum (95th percentile) response time?

Victoria also has some concerns about the ability of the HI Service to scale to meet potentially large uplift in demand, such as when a major public health service takes up the IHI. While Victoria will deploy the IHI integration “solution” to HealthSMART health services in a staged manner, there will be a significant volume of traffic as each agency undertakes the IHI initial data load and then adopts IHI operational processes. Victoria DH needs to provide some assurance to the health services that the HI Service will adequately support their processing needs.

As jurisdictions or health services near IHI implementation, they will need to provide details of implementation schedules and indicative HI Service transaction volumes to Medicare so that the HI service systems can be scaled appropriately. A standard template should be developed.

Assumptions 1. Victoria will provide expected transaction volumes to Medicare Australia and NEHTA as implementation planning progresses in the next project phase.

2. Victoria will await results of the work being undertaken by NEHTA, Medicare Australia and some jurisdictions to investigate the operational characteristics of the HI Service, assuming this will provide information on HI Service response times, with the HI Service under load.

3. (Nice to have). Medicare Australia and NEHTA to provide information about capacity planning and performance management support for the HI Service.

Addendum for Solution Architecture Release 2: The NHCIOF has requested that NEHTA and Medicare Australia reconsider the average response time SLA, looking towards setting the SLA at 3 seconds. It should be noted that this may still represent a 5 to 15 second user perceivable response time, which still requires an asynchronous approach. Consequently the Victorian design and architecture will not change.

6.3.10 Initial Data Load Support & Batch Processing With the results of the IHI matching exercise completed, Victoria has some remaining concerns about HI Service support for large scale batch IHI match request, such as would be required to support an initial data load activity

• WSDL vs CSV type format and effort required to generate the WSDL;

of 125

• Turn around times/SLAs for bulk upload processing.

Batch processing of IHIs is of importance to Victoria, and without any SLAs or turnaround time indications, it is extremely difficult for the IHI Pre-Implementation project team to recommend batch IHI processing to health services. While this remains moderately urgent, it appears that we will need to wait until the IHI matching exercise has been completed before we can progress with this item.

Assumptions 1. Victoria will await results of the work being undertaken by NEHTA, Medicare Australia and two jurisdictions to investigate the operational characteristics of the HI Service, assuming that this will provide concrete information about achieved match ratios, and response times.

2. Medicare Australia and NEHTA to establish SLAs for IHI batch processing, and other items not currently subject to SLAs (eg response to service desk requests), and publish these.

3. Medicare Australia and/or NEHTA to provide details of any HPOS based file upload (for IHI searching) that may become available in the future.

Recommendation • Medicare Australia to provide information on SLAs, or estimated response times, for IHI matching in an initial data load scenario.

Addendum for Solution Architecture Release 2: The IHI Match Investigation project n the ACT has been completed and results made available to a number of stakeholders.

6.3.11 Communications Link to the HI Service A broader discussion about potential opportunities for reducing or eliminating some of the security and TLS overheads associated with the current HI Service B2B architecture.

This item would involve establishing a virtual private network (VPN), preferably IPSec based, between HealthSMART and the HI Service. This would eliminate all of the connection handshaking (11 separate network transactions to establish a TLS connection, 7 to use an existing TLS connection) that must occur under the current architecture. This facility would also be of high value to any jurisdictions that plan to implement a single PAS, or an Enterprise Master Patient Index solution.

Assumptions 1. Victorian IHI Integration design will be based on currently available facilities.

2. Medicare Australia and NEHTA to consider this option as HI Service volumes start to build.


6.3.12 Synchronous Web Services Using synchronous web services has processing (CPU), queuing, persistence and memory management implications for client systems. A synchronous web service requires that the sending system maintain active listeners in memory to wait for a response, for every call made. Each listener consumes a processing thread and memory, thereby presenting some challenges to large environments, such as in HealthSMART. This presents particular concerns when the online batch scenario is considered, in that there is no response time SLA defined yet.

World’s best practice suggests that asynchronous web services are preferred in most circumstances; the exception being where the user must get the response before proceeding to their next task (this is not currently

of 125

an option for HealthSMART health services as the HI Service response time is higher than our health services will accept).

A broader concern arises when we consider the HI Service implementation in the context of the Secure Messaging specification, which specifies deferred, or asynchronous, processing for web services, i.e. the HI Service is not compliant with NEHTA’s secure messaging specification.

Assumptions 1. Victoria’s IHI Integration technical design is based upon currently available facilities, even though this remains undesirable from a HealthSMART architecture perspective.

2. Medicare Australia and NEHTA to consider providing all HI Service function as asynchronous web services, leveraging the NEHTA Secure Messaging specification.

3. Medicare Australia and NEHTA to urgently review the synchronous nature of the online batch request function, with a view to making this an asynchronous service.


6.3.13 Compliance Regime There are a suite of compliance requirements that both HealthSMART and individual health services must meet, some being embedded in the HI legislation or regulations, while others are part of the HI Service access validation process.

We remain interested in the detail of the operational and technical compliance regime under which the HI Service will operate, with particular reference to the CCA and SAF programs within NEHTA, and the software compliance required by Medicare Australia. This is especially important as the CCA elements may impact our design.

Based on the UK model there are significant costs associated with becoming compliant in the first instance, and then smaller annual costs associated with a regular compliance audit process.

The compliance requirements may have a major impact on the change process required to implement tools that draw upon the HI Service within any health service, and also on the health services’ operating structure (the roles of the RO and OMO).

An important element of the compliance requirements are the penalties associated with any misuse of the HI Service or the healthcare identifiers themselves. This will demand a significant education campaign within each health service, as they and their staff are both liable for any breaches.

Assumptions 1. Victoria will adhere to current legislative and compliance requirements, and follow current practices within HealthSMART and Victorian health services.

2. NEHTA to complete and release HI Service organisational compliance requirements as soon as possible, including material from the CCA group, and the SAF. NEHTA to advise of likely release dates. Victoria assumes that impacts on our design will be minimal.

Recommendation • Item 2 above.

Addendum for Solution Architecture Release 2: The first release of the CCA material to support acquisition, management and use of the IHI is expected to be superseded by a subsequent release within months. This presents some concerns to Victoria, in terms of solution design changes, changes to the application source code and additional testing and implementation costs. This is being actively managed through the CCA Governance body.

of 125

6.4 Business Architecture The Business Architecture describes the business level items that make up the IHI Integration solution, including:

• Business requirements (see the Vic IHI Integration Business Requirements deliverable)

• Business processes

• Use cases (user centric rather than system centric)

• Roles and responsibilities.

The Business Architecture may also examine the organisational structure (to support the project), business change management, training, information on resource requirements, and other business focussed areas or activities. Comprehensive coverage of these is beyond the scope of this project. The Clinical Risk Assessment and Best Practice Guide are business level deliverables from the Victorian IHI Integration project.

The business architecture for IHI Integration is covered comprehensively in the IHI Simplified Design and IHI Detailed Design deliverables, subject to constraints due to the agreed project scope. A summary is presented in this section.

Some areas for subsequent consideration include:

1. Business change management within HealthSMART health services to support IHI adoption, use and ongoing management. This is a broad field which is made somewhat more complex due to the legislative compliance required under the Healthcare Identifiers Act 2010.

2. Funding for activities to support adoption of the IHI, such as data cleansing, undertaking an initial data load of the IHI, performing application testing, training, etc.

3. Changes to downstream systems to enable them to store and use the IHI.

4. Definition of roles, and allocation of responsible staff members, that are required within every health service to administer access to the HI Service (Responsible Officer, and Organisational Maintenance Officer).

5. Obtaining of Healthcare Provider Identifiers for the organisation and for entitled employees. Registration of staff without an HPI-I who will access the HI Service. Maintenance of staff registrations over time.

6. Establishing access to supporting services such as the HPOS and the Medicare service desk, including business change management support.

7. Incorporation of SAF requirements into health services that have adopted the IHI, or are intending to adopt the IHI.

6.4.1 Business Requirements The following business requirements were identified by the Victorian IHI Integration Working Group, which had representation from many HealthSMART health services.

Req Number

Item Comments

FR_01 Systems must support processes and services to acquire, maintain and monitor information essential to acquiring the IHI.

Being able to retrieve an IHI for a patient relies on having the search criteria completed in the PAS and as accurate as possible. Processes and rules within PAS type systems may need to be adjusted to support a more rigorous approach to acquisition and management of the data elements below:

• Medicare or DVA number • Family

Name • Given Name • Date of Birth (DOB) • Gender • Address

Similarly, once the IHI and its statuses are obtained, a high

of 125

Req Number

Item Comments

level of rigour must be applied to its ongoing management and maintenance.

FR_02 Systems must support use of both the existing patient identifier and the IHI within health services, for whatever term is required (short, medium or long).

Health service IT systems must cater for individual health services approach and patient record architecture, and enable medium to long term transition to the IHI as replacement for the UR number (if this is supported by the health services strategy).

The IHI should be able to be used wherever a current patient identifier is used (notwithstanding legislative constraints), i.e. for patient identification on a wristband, or for patient searching in the PAS, or any other system.

FR_03 System must store and display the IHI in correct format.

The system will store and display the IHI in correct format including Record type and status:

Three Record types of IHI are provided for: • Verified IHI • Unverified IHI • Provisional IHI

Each type of IHI may also have a varying record status of Active/Deceased/Retired/Resolved/Expired.

The system should record the date captured/retrieved.

The system shall ensure that whenever a healthcare identifier is entered, rendered or transacted, all 16 digits are included.

The system will correctly display the IHI where any current patient identifying information is included/displayed,

FR_04 Systems will actively support the retrieval and storage of the IHI with limited human intervention required

The system must be able to search for an IHI using either the HI Service TDS Identified search or the demographic search (subject to necessary changes to the address format).

On presentation, or registration, where a patient record does not contain an IHI, the system will perform an automated search following entry of mandatory search criteria.

On update/change of patient critical demographic data within the PAS and where an IHI is held, the system should automatically perform an IHI Check with the HI Service. Critical data includes Family Name, Sex and Date of Birth, TDS data.

The System will iterate through available aliases and/or alternate addresses if the search on the primary name and address do not result in an IHI being returned.

The system should queue unmatched responses for later resolution. The system will advise the user where a match is not found and that subsequent searches will be enacted later.

The system will not prevent the user continuing through a workflow where a match is not found.

The system will include a time out function and supporting exception management.

The system will have the capability of responding appropriately to error messages generated by IHI searches. Configurable pathways for exception reporting and processing will be required.

See HI Service specification “TECH.SIS.HI.06 - IHI Inquiry Search via B2B”.

of 125

Req Number

Item Comments

FR_05 Applicable IT systems are capable of automatic resolution of IHI Record (types) and statuses.

IHI fields are to be updated automatically when a single match condition is met, including IHI Status and IHI Record Status.

Where a variation exists between held IHI Record (type) and status and retrieved IHI Record and/or status, then an automated resolution may be possible according to the agreed business rules.

Where an automated resolution is not possible, exceptions will be raised for later manual (human) resolution.

Exception reports and processes will be available for authorised users, which may include HIMs.

Where a patient’s record requires later (human) resolution the user is advised via an alert displayed on the patient record.

FR_06 Systems must include the IHI and its status on all patient centred communications.

The need to include both IHI statuses with the IHI provides immediate qualification of the number, and may influence user or system behaviours.

This requirement includes both internal and external reports/outputs, including all media (print/electronic).

For internal messages/reports, includes wristbands, ward notes, Orders, Prescriptions, transfers, patient reports, all HL7 messages that include the PID segment, etc.

For external reports, includes Orders, Referrals, Discharge Summaries, Prescriptions, in any form (paper, fax, electronic message, etc).

This item should include the ability to be locally configured.

FR_07 Systems should request an Unverified IHI ONLY for qualifying patients.

An Unverified IHI should not be allocated for a patient who is not eligible for a Verified IHI, unless the patient expressly requires anonymity.

The system should support requests for the creation of Unverified IHIs with qualifying information, e.g.

• Medicare suffix indication of ineligibility • Overseas permanent address and local temporary

address • Newborns

A journal entry indicating reason for Unverified IHI request should be provided.

Creation of Unverified IHI, is subject to the policy of the Healthcare Provider Organisation. The system should allow for local configuration over the creation of Unverified IHI.

An Unverified IHI record cannot be created with exactly the same details as another Unverified or Verified IHI record. One of the following fields needs to be unique:

• Family Name (Preferred Name) • First Name (Preferred Name) • Date of Birth • Gender • Address

See HI Service specification “TECH.SIS.HI.11 - Create Unverified IHI Via B2B”.

FR_08 The system must be capable of updating an

The following fields can be amended via the B2B channel for Verified IHI records

of 125

Req Number

Item Comments

Unverified or Verified IHI. • Date of Death • Date of Death Accuracy Indicator • Source of Death Notification

All fields can be updated for a record with an Unverified IHI.

See HI Service specification “TECH.SIS.HI.06 - Update IHI via B2B”.

FR_09 Systems should request a Provisional IHI ONLY under supported circumstances.

The use of Provisional IHIs will only be supported in situations where the patient is unable to be identified.

A Provisional IHI record will be expired after a parameter set period (currently set to 90 days) of inactivity on the record.

The system should include a warning of expiry if a health services uses a Provisional IHI to identify a patient.

Creation of Provisional IHIs is subject to the policy of the Healthcare Provider Organisation.

See HI Service specification “TECH.SIS.HI.10 - Create Provisional IHI Via B2B”.

FR_10 The system must be capable of updating a Provisional IHI.

See the HI Service specification “TECH.SIS.HI.03 - Update Provisional IHI via B2B”.

FR_11 The system must be capable of requesting a Provisional IHI be converted to an Unverified IHI.

See the HI Service specification “TECH.SIS.HI.09 - Resolve Provisional IHI - Create Unverified IHI via B2B”

FR_12 The system must be capable of requesting a merge of a Provisional IHI with a Verified or Unverified IHI.

See the HI Service specification “TECH.SIS.HI.08 - Resolve Provisional IHI-Merge record via B2B”

FR_13 The system must enable the user to view a history of changes to a patients IHI over time.

All IHI related events will be captured and subsequently available for user review.

All valid captured IHIs for a patient over time will be searchable.

FR_14 When allocating an IHI to a patient, the system must raise an exception when the IHI is already allocated to another patient or patients within the PAS.

No automatic IHI allocation to proceed where a potential duplicate IHI allocation is detected.

Exception is to be raised to the relevant health service group (configurable), for subsequent resolution.

A warning should be placed against all relevant records which are the potential duplicates. The warning to be removed only once resolution is achieved by authorised users.

FR_15 Applicable systems must be capable of warning the user that multiple PAS records meet the criteria entered for searching or validation.

No automatic IHI search to proceed where multiple records meet the exact search criteria (user has the ability to override).

Exception is to be raised to relevant health service group (configurable), for subsequent resolution.

A warning should be placed against all relevant records that are the potential duplicates. The warning is to be removed only once resolution is achieved by authorised users.

of 125

Req Number

Item Comments

FR_16 Applicable systems must be capable of periodic checks against the HI Service to validate/update the IHI.

The system must support IHI Checks on a periodic basis to confirm the IHI number and statuses are valid. The period between checks should be configurable within the system,

IHI checking may occur transactionally or via the available HI Service batch facilities.

Local agencies will set parameters for regularity of searches and include different rules for different IHI Record types/status, e.g. rules for checking Provisional and Unverified IHIs may be different from Verified IHI checking rules, or checks based around other non IHI parameters – e.g. a waiting list group.

FR_17 The system should be capable of accepting Date of Death data from the HI Service.

The system will allow local configuration for ‘acceptance’ of Date of Death information from the HI Service.

The HI Service will return both unconfirmed Date of Death and a confirmed Retirement Status (death confirmed by BDM after 90 days from Date of Death notice) against an IHI; receipt of this information may be required to trigger local PAS Death notification processes.

FR_18 IHI Exception processing

The System must generate IHI exceptions to allow for follow-up by HIMS, or other nominated staff.

Exceptions occur when: • Potential PAS duplicates are detected. • Potential HI Service duplicates are detected. • Where validation of IHI cannot be achieved

automatically. The system should alert the user to an exception state on the patient record and prevent the output of any IHI information during this exception state. ie the system prevents the printing of IHI data to any report/document output or message, until the IHI resolution is achieved in the record.

The system should provide exception reports configurable by local health services.

The system should provide exception management workflows to action exceptions within the system.

Workflow screens should enable link functionality to dual or multiple records and dual resolution capability from the one user screen (eg split screen functionality).

FR_19 The system must provide a comprehensive IHI focussed reporting solution.

A range of IHI reports must be supported, including exceptions reports. Some examples include:

• Duplicate IHI report • Unverified IHI report • Provisional IHI report • Resolved IHI Report • Records without an IHI allocated • Records with Deceased notification • Government and statutory reporting including IHI data

if applicable Locally configurable reporting solutions are required.

FR_20 The system must support batch file extraction and loading functions for PAS IHI capture.

The system must be capable of extracting data from the PAS for submission to the HI Service for batch file development.

The system must be capable of loading a batch of matched IHI data, and reporting exceptions, following the batch submission

of 125

Req Number

Item Comments

above.

The system must be capable of supporting a Medicare generated ‘resolved’ IHI report against known PAS held IHI records.

The system should support both online or offline batch processes.

FR_21 Systems will support multiple PAS search functions including the IHI.

The system will allow a search for patients using IHI alone or in conjunction with other demographic data.

FR_22 The software shall permit the manual entry of an IHI.

An IHI may be obtained from the HI Service through other channels such as HPOS or Medicare Australia’s call centre. This will require the manual entry of the full 16 digit IHI, and its statuses, into the PAS.

The system should immediately verify the entered IHI using the Lunh check digit algorithm, and subsequently check the entered IHI against the HI Service.

6.4.2 Business Processes The business processes defined below form the essential core of the Victorian IHI Integration project. The processes should be extended into like areas where appropriate. For example Patient Registration from a Referral may be applied to Patient Registration from a Pathology or Radiology Order. Sending a referral, which is somewhat of a summary process, may be applied to sending orders, discharge summaries, prescriptions, etc.

All business processes have been reviewed and accepted by business users, recognising that the focus has been on processes and use cases that involve the IHI, and upon which the IHI has an impact.

The use cases focussed on Referral may be abstracted to apply to any form of e-health messaging (orders, results, prescriptions, etc), though the use of the Update Referral (I13) and Cancel Referral (I14) HL7 messages are restricted to referrals and discharge summaries.

of 125

BP1:Patient Registration from a Referral

of 125

BP6:Patient Flow

of 125

BP2:Unreferred Patient Presentation

of 125

BP4:Patient Death Registration

of 125

BP7:Create Referral

BP8:Resolve Duplicate Patient Records

of 125

BP9:Perform Batch Process

BP10:Resolve IHI Exception

of 125

BP11: Attend Appointment/Treatment

of 125

6.4.3 Roles and Responsibilities The Business Architecture proposes a “community model”, to illustrate the business context for the IHI Integration solution, reaching well beyond HealthSMART and its associated health services. The key message from the IHI community model, as shown in the diagram overleaf, is the breadth of use of the IHI across the health sector, and the range of organisations and systems impacted.

The concept of community modelling extends well understood Enterprise Architecture modelling techniques into a situation involving multiple organisations and no one controlling (governance) body.

of 125

Human Actors

Provider or Program

Funding or Gov’nce Body

Application or System

Program or Initiative

Business or IT Service

Standard or Artefact

HI Service

Public Hospitals

(HealthSMART)Private

HospitalPrimary Care

Partnership Intersystems

TrakCare

CIS – Cerner

Millenium

P&CMS

iSOFT i.PM

IHI

HSIE

DH

(Victoria)

DoHA

NEHTAMedicare

Australia

SCTT /

VSRF

HL7 v2.4

(HS)

HealthSMART

Client or

PatientPAS User

System Admin

OMO

HIM

PAS

Admin

RO

Human

Actors

HL7 CDA

(NEHTA)

HPOS

Certificate

Authority

NASH SAF

CCA

`

Pathology

Systems

Radiology

Systems

AIE

Health IT systems

(other)

Argus (DCA)

HealthLink

HSD

SpecialistsPublic Hospitals

(not HealthSMART)

Clinician

Acute

Community

Health (non-

Metro)

Allied Health

Providers

Primary Care

General

Practitioners

Medical Director

Best Practice

PCEHR

Community

Services

Providers

Residential Aged

Care Providers

Community Care

Providers Mental Health

Providers

DHS

(Victoria)Community

Health (Metro)

Pathology

Providers

Radiology

Providers

AHPRA

of 125

The IHI community is supported by definitions of roles and the various responsibilities that are associated with those roles.

Human Roles

Role Name Description

Client or Patient Is the “owner” of the IHI and the person to which the IHI refers.

PAS Clerk The PAS clerk may include the Registration Clerk, Admissions Clerk, Ward Clerk, or HIM. This role is a frequent and expert user of the PAS.

PAS User The PAS user includes the PAS Clerk, Clinician, Nurse, Ancillary Workers, Interpreters, ED User, Intake Manager. This role is typically an occasional user of the PAS with other responsibilities.

Health Information Manager

The HIM is a specialised role within the health service with key responsibility for patient data quality and management.

Clinical System User For the Victorian IHI Integration design this role relates specifically to those that enter clinical data, and who are authorised to prepare and send discharge summaries. This is typically a clinician.

Responsible Officer This is the individual with authority to act on behalf of the organisation, on all HI Service related matters.

The RO is able to assume responsibility for all messages sent to the HI Service and for all IHI uses.

Organisational Maintenance Officer

This is an individual appointed to administer HI Service functions for HPI-O. There may be more than one within a health service.

PAS Administrator The PAS administrator is responsible for the business administration of the PAS system, including establishing configuration settings, creating and disabling users, etc.

System Administrator The system administrator is responsible for the technical support and administration of the system.

This role can be extended to include system support personnel.

HI Service Help Desk The HI Service help desk, or service desk, is a facility available to all authorised health service staff to assist in the resolution of HI Service and IHI related issues.

Accreditation body For the defined health service professions AHPRA1 provides accreditation services required by the HI Service.

Definition of detailed individual responsibilities is beyond the scope of this project, however all authorised users of the PAS may cause requests to the HI Service to be initiated. Only select users, responsible for patient data management and the correction of errors (ie HIMs) should have access arranged to the alternate HI Service channels, including the Health Professional Online Services portal.

System roles


PAS In the context of the Victorian IHI Integration design, the Patient Administration System, or its equivalent, is the primary business system for IHI acquisition, management and storage.

The PAS will share IHI information with downstream systems.

Downstream System The downstream systems include health service applications that are not identified as the primary IHI storage and processing system. This may include Clinical systems, Pathology systems, Radiology systems,

1 Australian Health Practitioner Regulation Agency

of 125


Pharmacy systems, and others.

These applications will store and use the IHI but will rely on the PAS to acquire and manage the IHI on their behalf.

HI Service The HI Service is one of NEHTA’s core e-health services, and it provides authorised users and systems with the ability to acquire and manage IHIs, HPI-Is and HPI-Os, over a web services interface.

The HI Service has been implemented by Medicare Australia.

Health Messaging Distributors

Health messaging distributors currently enable the transmission of referrals, and in some cases discharge summaries between subscribing health services.

Their role in IHI management is expected to be peripheral.

NASH The National Authentication Service for Health will act as a certificate authority for the health community i.e. it will issue and revoke digital certificates and provide services to support their use.

Providers’ public key certificates will also be stored within the NASH.

The NASH is currently under construction. It should be noted that the HSD could store public keys for Victorian healthcare organisations and practitioners.

HSIE The HealthSMART Integration Engine is a system that supports information exchange (via HL7 messaging) within the HealthSMART health services.

HSD The Human Services Directory is a DH funded and managed directory of all human services providers within Victoria (including some interstate providers), and the services they provide.

The HSD is supported by a system interface, which enables the integration of HSD information in applications.

of 125

6.5 Application Architecture 6.5.1 Introduction Application architecture defines the nature of the application/s that will support the business requirements and business architecture.

6.5.2 Approach The approach to the IHI Integration architecture is constrained by the HealthSMART architecture and the nature of the applications forming the HealthSMART suite. It is also founded upon the services implemented by Medicare Australia in the HI Service.

These constraints provide us with only two application deployment architectures, which are also applicable beyond HealthSMART:

1. Implement HI Service interfaces in the PAS application(s), and alter firewall and security settings to enable the PAS to call the HI Service. This is similar to how the Eclipse service connection is implemented in HealthSMART.

2. Implement the HI Service interfaces in a specialised ESB or EAI tool, using established mechanisms (HL7 v2.4 messages in the HealthSMART instance) to support HI Service requests and responses being transmitted between the PAS and the interfacing layer.

The solution must comply with all legislative and audit requirements, including identifying the user that is making the request.

In the HealthSMART case the preferred option is to use the HealthSMART Integration Engine, implemented on Oracle/Sun JCAPS. This provides a number of benefits, including:

1. Using the tool best suited to the task to achieve the required outcomes. Messaging is a fundamental capability of JCAPS, and it provides a range of tools, services, and reports to support robust messaging architectures.

2. Leverages existing messaging capabilities built around the HSIE.

3. Can support broadcast of the IHI to downstream systems, when they are ready to receive an IHI, through HL7 messaging and the Agency Integration Engines.

4. Supports multiple PAS solutions, and potentially other type of health iT applications, should this be required.

5. Provides a level of abstraction between the PAS, and other health IT systems, and the HI Service, thereby possibly supporting rapid change should this be required.

6. Enables a degree of information sharing and code reuse, with other jurisdictions that also use JCAPS.

7. Enables one point integration with other NEHTA services, such as the NASH, or other ehealth services that may become available in the future.

8. Can be extended into an EMPI type architecture leveraging the Oracle/Sun eIndex tool, or another EMPI solution.

6.5.3 Implementation Options The P&CMS and CMS applications within HealthSMART, will be the primary repository of IHI related information, including audit and history information. The extended cycle times associated with implementing change in major health IT systems has led to the consideration of other options that would enable Victorian health services to begin using the IHI. This is largely being driven by PCEHR Wave 1 projects.

The PAS applications, or other core patient data applications in specialist providers, must become the primary repository for IHI information.

The main option being considered by Victoria is to implement interfaces to the HI Service within the HSIE, in order to populate the IHI data in NEHTA compliant discharge summaries. This has a number of benefits, including:

1. Establishing the IHI Integration solution.

of 125

2. Proving the solution, technologies and supporting processes.

3. Delivering benefits to the sector through enabling early use of the IHI.

4. Building a library of IHIs for Victorian patients that can subsequently be loaded into the health service’s PAS.

This approach is described in the data flow diagram Figure 9 - Interim Solution - Adding the IHI to a Discharge Summary , on page 93.

Victoria HealthSMART will continue to work closely with vendors to ensure the optimum IHI Integration Solution is delivered.

6.5.4 Design Decisions Decision Number

Item Comments

DD_01 IHI History All HI Service requests for an IHI and returned information will be retained in the IHI history, which will be associated with the patient record in the PAS.

DD_02 Manual Entry of the IHI The Victorian design allows for manual entry of the IHI ONLY when resolving an existing exception. The patient management screens in the PAS should not enable the IHI fields for direct editing.

DD_03 Designing for the use of Provisional and Unverified IHIs

While Victorian health services are not in favour of using Provisional or Unverified IHIs, the functions to create, use and manage these IHIs have been included in this design, for completeness.

DD_04 Notifications to the HI Service (merge)

Notifications will be sent to the HI Service for records merged in the health service PAS, for merges outside the ability of the health service to request (eg two records with different Verified IHIs).

DD_05 Notifications to the HI Service (data errors)

Notifications will be sent to the HI Service when the local PAS, or user, believes that the data in the HI Service may be in error.

DD_06 Notifications to the HI Service (system errors)

Notifications will be sent to the HI Service to report system errors or periods of non-availability.

DD_07 Death notification When an IHI with deceased IHI Status is retrieved from the HI Service the local system will not record the deceased status in the PAS but will record the IHI Status in the IHI history, and raise an exception / alert.

This is to ensure health service workers do not send inappropriate communications.

DD_08 IHI Checking The only IHIs that will be checked against the HI Service (IHI Inquiry) will have an IHI Status of Active.

Once the Retired or Expired IHI Status has been recorded in the PAS there is no further information available.

Health services will never be returned the resolved IHI Status, and the IHI Integration design prevents storing the deceased IHI Status in the PAS.

of 125

6.5.5 Use Cases – Functional Design The use cases defined within the Victorian IHI Integration design are listed below. The reader should refer to the various functional design deliverables for more information.

Patient Use Case List

These use cases focus on patient

ID Name Description UC1 Search for Patient To search for a patient in the master PAS, to determine if they are already registered in the system, and

to locate their electronic patient record. UC25 Match Patient This Use Case attempts to locate a matching patient record for the incoming referral. UC2 Create new Patient To add a patient to the master PAS, using either the full registration or quick registration processes. UC5 Update Patient Details Updates patient information based on new or additional information being available. UC38 Display Alert(s) This use case supports the display of alerts against patient records or other IHI containers (eg referrals)

within the system, such as patient records, referrals, etc. UC33 Generate Output This is a generic use case that covers all operational outputs that may include the IHI.

IHI Processing Use Case List

ID Name Description UC8 Obtain IHI This use case acts as the coordinator for IHI searches to be sent to the HI Service, and will determine

the optimum search given the data available, and manage the iteration through items such as aliases and alternate addresses. This will be a commonly used function across all health services, and is also applicable to batch based IHI search requests.

UC7 Search for IHI The System performs pre-processing before sending a request to the HI Service to locate an IHI for a patient, and then receives a response.

This use case focuses on determining the optimum IHI search type (TDS, Basic, Demographic) to send to the HI Service, and adjusts the criteria data to ensure that a unique local PAS record satisfies the search criteria.

UC10 Update IHI The System updates the IHI fields held in the PAS based on what has been returned by the HI Service.

UC9 Check IHI Initiates a system request to check the validity and status of an IHI.

UC12 Generate IHI Exception The System generates a task for human follow-up when a IHI issue occurs. Different Exception Levels will be routed to different audiences for follow up, with differing expected response times.

UC11 Request IHI Check (Multiple Records) This use case enables the checking of IHIs allocated to patient records to occur in bulk, via the online or offline batch search facilities in the HI Service.

of 125

ID Name Description This process may be Initiated manually by the user or by the System

For record sets of less than 100 items the HI Service online batch may be used. For larger records sets, they may either be segmented into 100 record groups, or submitted via the offline batch service. The maximum number of items in an offline batch file is 2000, and this must be sent to the HI Service Operator using a secure USB device.

UC34 Request IHI Search (Multiple Records) This use case enables multiple IHI Searches to be submitted in one request, using the HI Service online or offline batch processes. The use case may be Initiated manually by a user or automatically by the System.

For record sets of less than 100 items the HI Service online batch may be used. For larger records sets, they may either be segmented into 100 record groups, or submitted via the offline batch service. The maximum number of items in an offline batch file is 2000, and this must be sent to the HI Service Operator using a secure USB device.

UC24 Validate IHI The System checks the incoming IHI against the IHI that is held in the PAS for the patient and determines what to do with discrepancies.

UC46 Load Batch IHI Results This is an automated system process to load the results of an offline IHI Search batch request to the HI Service back into the PAS, and raise any exceptions that occurred.

The current approach specifies that Medicare Australia (the HI Service operator) will return the batch results to the health service using a secure USB device, and secure transport (eg courier, or perhaps registered mail).

Data on the USB stick will need to be persisted in a directory on a secure LAN file system.

UC51 Process Patient Details Update This use case has a dual role in the processing of updates to the patient record that may impact the previously retrieved IHI (ie one or more of the IHI Search criteria are altered), or that require a patient information update to be sent to the HI Service.

UC54 Refresh IHI This Use Case deletes the current IHI number, IHI Status and IHI Record Status in the patient record (without removing the IHI History) and then searches for an IHI again.

UC55 Reset Merge This Use Case re-checks the IHIs submitted as part of the Merge Request that previously failed, and if appropriate re-sends the Merge request to the HI Service.

HI Service Use Case List

ID Name Description UC15 Send IHI Request The System prepares and sends an IHI Search request for the HI Service, and awaits the response.

UC16 Send Unverified IHI Request Enables the creation of an Unverified IHI, with the supporting record in the HI Service, for a patient. It

of 125

ID Name Description should be used sparingly and only in specific circumstances as defined below.

Note that Victorian HealthSMART health services cannot currently make use of this function as current

systems do not support address data in the required format. UC14 Send IHI Update Request This use case supports the updating of records in the HI Service, in accordance with the HI Service

specifications, and includes the ability to:

• update a record with an Unverified IHI, or

• update a record with a Verified IHI with date of death information only.

This is a system function that will automatically update the HI Service whenever the local patient record is updated. Note that the NEHTA CCA group has created a compliance item that requires health services to provide patient data updates to the HI Service.

Provisional IHI records are updated using UC45: Send Provisional IHI Update Request.

UC43 Send Merge Request This use case automates the merge processing of patient records with Provisional IHIs with patient records with Unverified or Verified IHIs.

This will only occur as a result of a patient merge in the local PAS.

This use case relies upon the HI Service function “Resolve Provisional IHI - Merge Records via B2B”.

UC44 Send Provisional IHI Request This use case can only occur in circumstances where the health service has established a policy to enable the use of Provisional IHIs.

The use case will send anonymous data to the HI Service and request the creation of a Provisional IHI. The HI Service will return the created IHI.

Note that there is no uniqueness check in the HI Service for Provisional IHI creation requests (based on Name, DOB and gender data), and that Provisional IHIs expire after 90 days of no activity.

UC45 Send Provisional IHI Update Request This use case enables the updating of data in the HI Service, when name, DOB or gender information is updated in a local (PAS) patient record with a Provisional IHI.

UC49 Send Provisional to Unverified Resolution Request

This use case supports the “promotion” of a Provisional IHI to an Unverified IHI, with the same IHI number being preserved.

UC48 Send Medicare Service Request This use case enables the automated creation and transmission of a Service Request to the HI Service Operator (Medicare). This replaces the current process of lodging a request with Medicare over the telephone, or potentially through the HI Service user portal (the functional profile of the portal is unclear).

This use case supports a broad range of service requests and notifications to Medicare, and enables streamlining of the request process.

of 125

ID Name Description This is a use case not currently supported by the HI Service, though it has become an essential element of this design.

A group of management practices support the reporting on and monitoring of service requests. These are not documented in this functional design.

This is unconfirmed functionality, as it is not yet supported by the HI Service and Medicare Australia.

UC56 Send Duplicate or Replica IHI Notification This use case automates the merge processing of patient records with patient records with Unverified or Verified IHIs.


Care Co-ordination Use Case List

ID Name Description UC18 Send Referral This Use Case represents the Send Referral functionality at a high level only, and is intended for the

purposes of identifying the IHI impacts. Further details are provided as part of e-Referral functional specifications.

UC19 Send Discharge Summary This Use Case represents the Send Discharge Summary functionality at a high level only, and is intended for the purposes of identifying the IHI impacts. Further details are provided as part of Discharge Summary functional specifications.

UC20 Send Order This Use Case represents the Send Order functionality at a high level only for the purposes of identifying the IHI impacts. Further details are provided as part of functional specifications prepared for each functional area and Order type. If the IHI is available it should be included on all orders, whether they are being transmitted electronically, or via paper/fax.

UC21 Process IHI in Referral Performs pre-processing on the IHI included in the referral, by checking it and determining if it matches the IHI held in the HI Service for this patient. This provides a degree of surety that the information included in the referral is accurate, and the IHI is “trustworthy”.

UC22 Send Referral Update This Use Case updates an existing referral, and sends the update to the named destination. It can be initiated either by the originator of the initial referral, or the destination.

UC23 Send Referral Cancellation Sends a cancellation of a referral that was previously sent.

HIMs Use Case List

ID Name Description UC17 Perform Exception Search The Actor searches for an exception by entering the search criteria, including date, patient UR number,

IHI, Scan for Patient Anomalies reference, Exception type, Exception Status.

of 125

ID Name Description A list of Exceptions satisfying the search criteria is presented to the user for subsequent action.

UC35 View Exception Allows viewing of the IHI Exception details and related history, including all resolutions. UC36 Add Exception Resolution Allows resolution details to be recorded against an exception.

UC28 Merge Patient Records Facilitates two patient records to be merged into one or, more accurately, linked together. This use case does not replace existing processes for investigating patient duplicates, and eventually merging the records if required. This use case, and the presence of the IHI and services available through the HI Service, supplement or extend the existing merge process.

UC40 Perform Merge Analysis This use case is an entirely system based function which will obtain or check IHI for the records to be merged, and present results to support the user’s decision making on the record merge. The results of this use case will not prevent the user from merging the local records.

UC29 Unmerge Patient Records Facilitates the separation of a previously merged patient record. The Actor will have complete control over the unmerge function and consistency with the HI Service will not be required.

UC30 Scan for patient anomalies The System performs a scan to detect anomalies in the PAS data.

UC37 Manage Exception Type Provides a facility to enable the setting of exception levels within any given Exception type. The Actor will not be able to create new Exception Types, or delete existing ones.

UC50 Close Exception Enables exceptions raised within the system (relevant to IHI processing) to be closed. UC31 View Patient IHI Report This use case enables the Actor to view a history of IHI requests and updates for the given patient or

client. This supports audit requirements, and will assist in IHI problem resolution. The Actor may optionally select to print the report.

UC52 View IHI Summary Report This report enables the user to obtain a summary level view of the IHI related exceptions in the system, and also a summary of the level of IHI allocation.

Search outputs include:

• Patient IHI Analysis (counts)

a. Patients with a Verified IHI

b. Patients with an Unverified IHI

c. Patients with a Provisional IHI

d. Patients with a Medicare/DVA number, but without an IHI

e. Patients without a Medicare/DVA number, and without an IHI

f. Patients with Verified IHIs, but without Medicare/DVA entitlement

• Multiple patient records that satisfy the same IHI Search criteria (for all 3 levels of IHI Search)

• Exception Analysis

of 125

ID Name Description

a. Multiple patient records with the same IHI

b. Patient records without an IHI

c. Patient records with a failed IHI Search, which may be incorporated in (vii) below.

d. Patient records with an IHI but without either/or IHI Record Status and IHI Status

e. Patent records with IHI Record Status or IHI Status but without an IHI

f. Patient records with a failed IHI Check

g. Patient records with open IHI Exceptions (can be excluded from further exception processing)

of 125

6.5.6 Use cases – Technical Design The use cases in this section are all included in the Victorian IHI Integration Technical Design, where more detail on each use case may be obtained. These use cases tend to be more implementation focussed, and many are related to the management of the IHI using HL7 messaging.

IHI BATCH Loading

These use cases support batch IHI matching processes, using the offline batch process. This is relevant for performing an Initial Data Load of the IHI. The mechanism for reloading data into the PAS is defined in the IHI Integration Functional Design documentation

ID Name Description

UC100 Allocate Batch ID This is a system function to allocate a unique identifier to every offline batch to be submitted to the HI Service. This will facilitate processing of the returned data.

UC101 Extract data for HI Service submission This use case enables extraction of high volumes of patient demographic data from the PAS for submission to the HI Service to search for a patient’s IHI, or to check an IHI already allocated.

UC102 Prepare data for HI Service submission Takes the data extracted in the previous use case and prepares it for submission to the HI Service.

UC103 Manage Batch Submissions Provides a means to manage batch submissions to the HI Service. This is largely intended to be used to support the offline IHI Search and IHI Check batch facility.

Queue Management use cases

The use cases in this section provide functionality that enables proactive systems management of interfaces to the HI Service, focussing on management of exceptions in the HI Service interfaces. Organisations that implement HI Service interfaces in an EAI, ESB tool or similar will find that queue management is standard functionality..

ID Name Description

UC110 Suspend Single HI Service Request Queue

Suspends the sending of requests to the HI Service for a single queue. Does not apply to the offline batch facility.

UC111 Suspend All HI Service Request Queues Suspends the sending of all requests to the HI Service for a single queue. Does not apply to the offline batch facility.

UC112 Resume Single HI Service Request Queue

Resumes the sending of requests to the HI Service B2B channel for a single queue or interface. Does not apply to the offline batch facility.

UC113 Resume all HI Service Request Queues Resumes the sending of requests to the HI Service B2B channel for all local HI Service B2B queues / interfaces. Does not apply to the offline batch facility.

UC114 Lodge HI Service Scheduled Outage This enables the recording of a scheduled outage to the HI Service B2B channel within the local system, enabling all local queues to the HI Service to be suspended for the outage period.

HL7 Message Processing (automated)

of 125

The use cases in this section apply to a situation in which an intermediary messaging solution performs all IHI related processing, based on receipt of a standard HL7 message. These use cases do not currently provide an ability to load the IHI back into the PAS.

UC123 represents the likely Victorian HealthSMART approach for delivery of specific short term outcomes such as for the “NEHTA Wave 1” project, which will enable the IHI to be incorporated into the outgoing discharge summary message (I12). This is an interim solution, and not intended for use over the long term.

The other use cases in this section are presented for completeness and are not recommended as a long term solution for IHI integration, as the volumes of transactions to the IHI service and the fragmentation of patient data management business processes are significant barriers in a sustainable solution.

ID Name Description

UC120 Receive A04, A05 or A28 HL7 Message When an A04 Register a Patient, A05 Pre-Admit a Patient or A28 Add Patient Details HL7 message is sent by the PAS (source of truth for patient demographic data) and received by the HSIE, the HSIE will automatically search for an IHI or check the IHI that is included in the HL7 message. Functionality is inherited from the Use Cases related to UC8 : Obtain IHI in the Functional Design.

UC121 Receive A08 or A31 HL7 Message When an A08 Update Patient Information HL7 message or A31 Update Person Information HL7 message is sent from the master PAS and received by the HSIE, the HSIE will automatically search for an IHI or check the IHI that is included in the HL7 message. Functionality is effectively inherited from the Obtain IHI use case in the Functional Design.

UC122 Receive A40 HL7 Message When an A40 Merge Patient HL7 message is sent from the master PAS and received by the HSIE, the HSIE will automatically search for an IHI or check the IHI for each PID segment included in the Merge request.

Based on the results obtained the HI Service may submit either a merge request or a merge notification to the HI Service.

UC123 Receive I12, I13 or I14 HL7 Message When an I12 Referral or Discharge summary message , the I13 referral update, or the I14 Referral cancellation message is sent from the master PAS or the Clinical System and received by the HSIE, the HSIE will automatically search for an IHI or check the IHI that is included in the HL7 message.

Functionality is effectively inherited from the Obtain IHI use case in the Functional Design.

UC124 Receive HL7 Message with PID segment As with the Use Cases above, this Use Case provides a common, and optional, approach to handling any type of HL7 message with a PID segment. This use case should only be used for external HL7 messages, ie those with a destination outside the health service and HealthSMART.

HL7 Requests for HI Services

This section lists the use cases that are core to the IHI Integration solution in the HealthSMART context, and which may also be applicable in an EMPI type architecture.

ID Name Description

UC130 Request IHI Search via HL7 This is an explicit request from the PAS to the HSIE for an IHI search to be conducted, based on

of 125

ID Name Description

currently available messaging standards. In HealthSMART this is HL7 v2.4 HS.

This use case inherits functionality from UC7 : Search for IHI in the IHI Functional Design, and follows the same flow, except that the implementation is in the HSIE, rather than the PAS.

The PAS application, which is the “source of truth” for patient demographic information, should use the HL7 A19 query message as the more commonly used broadcast messages are not suitable.

HL7 messaging exceptions will supplement exceptions already identified in UC7 : Search for IHI.

UC131 Request IHI Check via HL7 This is an explicit request from the PAS to the HSIE for an IHI Check to be conducted, based on currently available messaging standards. In HealthSMART this is HL7 v2.4 HS.

This use case inherits functionality from UC9 : Check IHI in the IHI Functional Design, and follows the same flow, except that the implementation is in the HSIE, rather than the PAS.

The PAS application, which is the “source of truth” for patient demographic information, should use the HL7 A19 query message as the broadcast messages are not suitable.

HL7 messaging exceptions will supplement exceptions already identified in UC9 : Check IHI.

UC132 Request New Provisional IHI via HL7 The System generates a task for human follow-up when an IHI issue occurs. Different Exception Levels will be routed to different audiences for follow up, with differing expected response times.

UC133 Send IHI Request in HSIE The System prepares and sends an IHI Search request to the HI Service, and awaits the response.

This use implements functionality from UC15 : Send IHI Request in the IHI Integration Functional Design.

UC134 Request New Unverified IHI via HL7 The use case supports the creation of an Unverified IHI, based on an HL7 message from the PAS to the HSIE, and implementation of the required HI Service interface in the HSIE.

This use case inherits functionality from UC16 : Send Unverified IHI Request in the IHI Integration Functional Design

Note that Victorian Health SMART health services cannot currently make use of this function as current systems do not support address data in the required format.

UC135 Send IHI Update Request via HL7 The use case supports the updating of records in the HI Service, based on an HL7 message from the PAS to the HSIE, and implementation of the required HI Service interface in the HSIE.

This use case inherits functionality from UC14 : Send IHI Update Request in the IHI Integration Functional Design

• Record updates catered for in this use case include:update a record with an Unverified IHI, or

of 125

ID Name Description

• update a record with a Verified IHI with date of death information only.

This may be implemented as a fully automated use case, based on receipt of an A08 or A31 HL7 message.

UC136 Send Merge Request via HL7 The use case supports the merging of records in the HI Service, following the local merging of those records within the PAS. This use case is also based on an HL7 A40 message being sent from the PAS to the HSIE, and implementation of the required HI Service interface in the HSIE.

This use case inherits functionality from UC43 : Send Merge Request in the IHI Integration Functional Design

This use case relies upon the HI Service function “Resolve Provisional IHI - Merge Records via B2B”.

UC137 Send Provisional IHI Request via HL7 This use case can only occur in circumstances where the health service has established a policy to enable the use of Provisional IHIs.

The use case will send anonymous data to the HI Service and request the creation of a Provisional IHI. The HI Service will return the created IHI.

UC138 Send Provisional IHI Update Request via HL7

This use case enables the updating of data in the HI Service, when name, DOB or gender information is updated in a local (PAS) patient record with a Provisional IHI.

UC139 Send Provisional to Unverified Resolution Request via HL7

This use case supports the “promotion” of a Provisional IHI to an Unverified IHI, with the same IHI number being preserved.

UC140 Send Medicare Service Request via HL7 or XML

This use case enables the automated creation and transmission of a Service Request to the HI Service Operator (Medicare). This replaces the current process of lodging a request with Medicare over the telephone, or potentially through the HI Service user portal (the functional profile of the portal is unclear).

This use case supports a broad range of service requests and notifications to Medicare, and enables streamlining of the request process. The ability of HL7 to support this type of request message requires further investigation, with an XML formatted message being the most obvious alternative.

The service request design is tightly integrated into the Exception Management component of the Victorian IHI Integration design, and functionality would logically be implemented within the PAS application. An alternative would be to implement the Service Request component in a specialised Service Request Management solution, with this tool then sending the request to the HI Service.

UC141 Send Duplicate or Replica IHI Notification via HL7

This use case automates the merge processing of patient records with Unverified or Verified IHIs, and sends the appropriate message to the HI Service Operator.


of 125

Security Use Cases

This section list use cases relevant to the security settings that are essential to achieving compliance with the Healthcare Identifiers Act 2010, Medicare Australia’s HI Service specifications and NEHTA’s CCA regime.

ID Name Description

UC150 Register User to access HPOS / MSO Registers an employee (may be a contractor or a member of a service provider’s organisation) of the health service with the HI Service operator, to enable the employee to access the HI Service HPOS and telephone support channels.

This use case leverages functionality in UC48 : Send Medicare Service Request, in the IHI Integration Functional Design, to automate the process.

UC151 Deregister User to access HPOS / MSO Deregisters an employee (may be a contractor or a member of a service provider’s organisation) of the health service, previously authorised to access the HI Service HPOS and telephone support channels, with the HI Service operator.

This use case leverages functionality in UC48 : Send Medicare Service Request, in the Victorian IHI Integration Functional Design, to automate the process.

UC152 Maintain Organisation Credentials This use case focuses exclusively on maintaining the currency of the organisation’s information and PKI certificate or certificates, as these play an important role in enabling communications with the HI Service.

Reporting Use Cases

In all case below the queues referred to support the interfaces between HealthSMART systems and the HI Service, as implemented in the HSIE. The majority of the use cases below are technical reports of interest to system administrators. UC165 is user focussed and extends the reporting solution defined in the Victorian IHI Integration Functional Design.

ID Name Description

UC160 Queue Monitoring This use case is optional, and provides the ability to analyse all web services based transactions with the HI Service.

Queue monitoring serves a number of ends, including exception reporting, volumetric reporting, and HI Service response reporting.

UC161 Queue Log Data ETL This use case involves extracting data from the queue monitoring logs and loading it into a RDBMS, to enable a comprehensive reporting solution, and minimise any impacts on the logging process.

UC162 Queue Analysis Report The queue analysis report generates reports based upon the logs captured by the system monitor function, in a summary format, ie counts. The user may filter the reporting data using a variety of search criteria.

of 125

ID Name Description

UC163 Queue Detail Report The queue detail report generates reports based upon the logs captured by the system monitor function, in a list format with a row in the logs being rendered as a row in the report. This is a supplementary reporting function to the standard log viewer.

UC164 Queue Trend Report The use case represents a special instance of the Queue Analysis report use case above, in which a trend analysis is performed for the criteria entered.

This will assist in capacity planning, and may be of relevance when reporting on adoption of the national e-health core services.

UC165 Patient IHI List Report This use case supplements the reporting functions available in the IHI Integration Functional Design, by providing a list based reporting facility.

This will assist in patient data problem analysis, determining required data management activities, and general reporting.

Service Request Management Use Cases

The Victorian IHI design introduces the concept of an electronic service request to Medicare Australia, which may be an exception report, or a notification. The use cases in this section support the service request functionality.

ID Name Description

UC170 Maintain Service Requests The Maintain Service Requests use case provides authorised users with the ability to review and update all service requests made to the HI Service operator.

UC171 Generate Service Request Report The service request report generates a list of service requests that have been submitted to the HI Service operator.

Data Management Use Cases

The Healthcare Identifiers Act 2010 requires detail logging and audit trails be maintained for all HI Service request and responses, potentially resulting in large volumes of log and audit data. The use cases below support management of audit and log data.

ID Name Description

UC180 Archive Audit Data This use case describes the process and rules for archiving audit type data that relates to HI Service calls and IHI processing.

UC181 Retrieve Audit Data This use case describes the retrieval of data that was previously archived.

UC182 Delete Archived Audit Data This use case describes the process and rules for permanently deleting data from the IHI audit data archive.

of 125

Note that audit data must be retained for a minimum of 7 years after the departure of an employee with HI Service access2. Victoria has queried this requirement with NEHTA and Medicare Australia.IHI Integration Solution Component Architecture.

2 If a health service employee starts at age 20 and retires at age 60, some HI Service logs will need to be retained for 47 years.

of 125

HL7

HL7

HL7

HL7

HL7

The diagram above shows the component architecture for the Victorian IHI solution. Note the predominantly one to one relationship between the HI Service function and the interface implemented in the HSIE. The Victorian design draws a clear distinction between the IHI Search function (no IHI currently available), and the IHI Check function (IHI already allocated to the patient record), and this is shown for both online and batch based requests in the diagram.

of 125

The IHI Messaging Business Rules layer will implement system level business rules that ensure no messages are sent to the HI Service that the HI Service will reject. It will also process all responses from the HI Service including system level errors.

Mapping the Functional Design to the Technology lay ers

While seeming trivial it is important to highlight some key points when applying elements of the functional design to the technical platforms:

1. All messaging logic and rules will be implemented in the HSIE.

2. All business processes and business rules relating to IHI acquisition, management, and supporting information will be implemented in the PAS.

3. Data related business rules must occur in both the PAS (user data entry) and the messaging layer (determination of message validity).

4. Rules controlling use of, and access to, Provisional and Unverified IHIs must be implemented in the PAS.

5. IHI related audit data will be captured in the HSIE (message level audit) and distributed to the PAS (business level audit information).

6. IHI related exceptions will be captured in the HSIE and returned to the PAS.

7. IHI exception resolutions will be captured in the PAS.

6.5.7 IHI Service Registry A service registry defines the services available within an enterprise or community, through service profile records.

The following services all need to be implemented in the HSIE, or equivalent, in order to make optimum use of available HI Service functions. All services are composable, meaning that they can be combined to constitute more complex (composite) services.

Service Name Description Parameters Returned information Owning system

Search IHI Request The calling interface to the HI Service IHI Inquiry web service, enabling retrieval of an IHI based on supplied patient demographic information.

Searching for a Provisional IHI is not permitted.

This must (currently) be implemented as a synchronous web service, with a dedicated listener waiting for the HI Service response.

User ID

Organisation ID

System ID

Patient demographic data, including:

• Medicare number or DVA number

• Name

• DOB

IHI number, IHI Record Status, IHI Status and selected information provided in the original search.

Various search failure messages.

HSIE

of 125


• Gender

• Address

Local patient reference

Check IHI Request The calling interface to the HI Service IHI Inquiry web service, enabling confirmation of the IHI number and associated information.


User ID

Organisation ID

System ID


• IHI

• Name

• DOB

• Gender


May return different IHI information under certain circumstances.

HSIE

IHI Search – Batch The calling interface to the HI Service IHI Batch Search web service, enabling retrieval of a multiple IHIs based on supplied demographic information for multiple patients (up to 100 per submission).


User ID

Organisation ID

System ID

Multiple instances of patient demographic data, including:

• Medicare number or DVA number

• Name

• DOB

• Gender

• Address

Local patient reference


HSIE

of 125


IHI Check – Batch The calling interface to the HI Service IHI Batch Search web service, enabling checking of multiple IHIs based on supplied IHIs and demographic information for multiple patients (up to 100 per submission).


User ID

Organisation ID

System ID

Multiple instances of patient demographic data, including:

• IHI

• Name

• DOB

• Gender

IHI number, IHI Record Status, IHI Status and selected information provided in the original check.

HSIE

Update IHI Request The calling interface to the HI Service Update IHI web service, enabling updating of date of death data for a record with a Verified IHI, and all data for an Unverified IHI record.

Subject to test for uniqueness.


User ID

Organisation ID

System ID


• IHI

• Name

• DOB

• Gender

• Address

• Date of death

IHI number, IHI Record Status, IHI Status and selected information provided in the original update request.

HSIE

Create Provisional IHI Request The calling interface to the HI Service Create Provisional IHI web service, enabling creation of an HI Service record with a Provisional IHI.

Not subject to test for uniqueness. Note Provisional IHI record expiry in 90 days from last access.

This must (currently) be implemented as

User ID

Organisation ID

System ID


• Name (anonymous)

IHI number, IHI Record Status, IHI Status and selected information provided in the original creation request.

HSIE

of 125


a synchronous web service, with a dedicated listener waiting for the HI Service response.

• DOB (estimated)

• Gender

Create Unverified IHI Request The calling interface to the HI Service Create Unverified IHI web service, enabling creation of an HI Service record with an Unverified IHI.

Subject to test for uniqueness.


User ID

Organisation ID

System ID


• Name

• DOB

• Gender

• Address

IHI number, IHI Record Status, IHI Status and selected information provided in the original creation request.

HSIE

Update Provisional IHI Request

The calling interface to the HI Service Update Provisional IHI web service, enabling updating all data for a record with a Provisional IHI.

Note that the Victorian design implements this call, but does not use it in any processing.


User ID

Organisation ID

System ID


• IHI

• Name

• DOB

• Gender

• Date of death

IHI number, IHI Record Status, IHI Status and selected information provided in the original update request.

HSIE

Resolve Provisional – Merge Request

The calling interface to the HI Service Resolve Provisional IHI – Merge web service, enabling a record with a Provisional IHI to be merged with the record with an Unverified or Verified IHI.

In the Victorian design this occurs in response to a patient merge in the local

User ID

Organisation ID

System ID

Data defining to records to merge

• IHI for the

IHI number, IHI Record Status, IHI Status of the Verified or Unverified record, and a message indicating successful completion of the request.

HSIE

of 125


PAS.


Unverified or Verified record

• IHI for the Provisional Record

Resolve Provisional – Create Unverified Request

The calling interface to the HI Service Resolve Provisional IHI – Create Unverified web service, enabling a record with a Provisional IHI to be “upgraded” to a record with an Unverified IHI.

Subject to a uniqueness check.


User ID

Organisation ID

System ID


• IHI (provisional record)

• Name (actual)

• DOB (actual)

• Gender (actual)

• Address

IHI number, IHI Record Status, IHI Status of the Unverified record, and a message indicating successful completion of the request.

HSIE

Service Request The calling interface to a proposed HI Service web service to receive service request over the web services (B2B) channel. These are request for the HI Service operator to take action on behalf of the respective health service.


User ID

Organisation ID

System ID

Service Request data, including:

• Request information

• Request category

• Request urgency

A unique service request number should be returned to enable tracking of the request over time.

HSIE

CheckCRL Enables authorised parties to confirm that a certificate is valid by checking the Certificate Revocation List.

This will be conducted with the TLS infrastructure, and does not require

PK certificate

Provider identifier

Valid/invalid indicator HSIE (security layer)

of 125


separate implementation.

PersistMessage An internal technical service/process that saves an HI Service request and/or response message to the local database.

Supports all message formats as listed above.

This supports the audit and logging requirements

HI Service message

Confirmation (success/failure)

PAS, HSIE

GenerateAuditRecord A system function that generates an audit record for all IHI related operations.

Supports all IHI related messages as listed above.

Data

Operation

Audit record created PAS, HSIE

GenerateException Generates an exception record in the event of an error condition.

Depending on the nature of the error condition may return the exception to a CMS/Distributor or services component (e.g. ELS, NASH).

Data

Operation

Exception Identifier

Exception Text

Alternate destination

Exception record created

Exception record sent

CLS, Distributor, Gateway

Validate Data Confirms the structure and content of data provided, and checks for duplication.

Supports all referral message formats, including:

• Referral

• Referral update

• Referral cancellation.

eReferral reporting data

Validation rules

Confirmation

Exceptions

Reporting

of 125

6.5.8 HL7 Messaging Overview HealthSMART has defined an HL7 2.4 standard that is widely used across Victorian health services, and which is published on the HealthSMART website. A key HealthSMART principle is that the P&CMS and CMS applications are the source of truth as far as patient data is concerned, and this will include the IHI.

The general mechanisms to be used for sharing the IHI between health IT applications will leverage the PID segment incorporating the IHI and other necessary information, in addition to the patient information, and UR numbers, that it currently supports. The ability of downstream system to store and use the IHI is a prerequisite and will occur over time. Victoria has requested a change to the Australian HL7 standard, via the IT-014 subgroup of the Australian Standards body, to support explicit inclusion of the IHI Record Status and IHI Status information. This request is still pending.

The HealthSMART HL7 specification does not explicitly provide support for a national healthcare identifier, based on version 44, though in general there is no particular issue with supporting another patient identifier. The HL7 PID segment defines the Patient ID as a repeating field, though the supporting codeset, Patient Identifier Type, should be extended to define the IHI.

A broader concern arises in terms of the handling of the IHI within the various applications. A key principle of the Victorian IHI Integration project is to enable users to make direct and effective use of the IHI. This implies that the IHI will be readily visible on all patient screens, and possibly displayed in the common header section of the screen, with the IHI Record Status and Status fields.

The role of HL7 messaging within the Victorian IHI design includes the following major functional areas:

1. To distribute the IHI from the P&CMS and CMS applications to other HealthSMART and health service systems. This will rely on the current techniques used for distributing patient data, i.e. mainly the HL7 messages A04 – Register a Patient and A08 – Update Patient Information, and any relevant broadcast messages (A28 -Add patient details, A31 – Update person information). However the PID segment is present in almost all HealthSMART HL7 messages.

2. To request that the IHI be obtained for a patient. This will involve an HL7 message request (A19 – Patient Query), from the P&CMS or CMS application to the HSIE. The HSIE will then request the IHI from the HI Service and return the (successful) result to the P&CMS or CMS application.

3. There may be situations that arise where a downstream system needs to request an IHI be provided or an IHI Check be performed. This may be prior to an external communiqué being sent or similar. In HealthSMART this will be achieved through the downstream users accessing the P&CMS or CMS application, updating the patient information, or explicitly requesting an IHI be obtained / validated. If the IHI information is updated it will then be distributed to all downstream systems as per item 1.

4. To support IHI related exception management. There are many exceptions that can occur in requests to and responses from the HI Service, ranging from system level errors to business related errors that users will need to resolve. Typical responses from the HI Service may include a successful response, a “no record found” message, and a “multiple records found, refine your search” response. Error messages, excluding purely system level exceptions, will need to be returned to the requesting application.

5. Request for IHI creation, record merge, or updates will be handled through the appropriate message format, as used currently within HealthSMART, eg an A40 Merge Patient message.

There is final scenario for consideration, which should be regarded as an interim solution, and which is proposed for the Victorian PCEHR Wave 1 project, to use the HSIE to obtain an IHI for inclusion in an HL7 message passing through the HSIE. This is of particular relevance when the message is leaving the organisation. The Wave 1 project is targeting the Discharge Summary (I12) message. This approach is not recommended for urgent messages (eg an internal patient create or patient update message), as the message would be delayed in the HSIE as the IHI search is conducted.

IHI HL7 Principles and Constraints

1. The PAS applications (P&CMS, CMS) as the primary stores of patient data will also become the primary data stores for the IHI and related information.

2. The HSIE will implement the technical interfaces to the HI Service.

of 125

3. The P&CMS and CMS applications will distribute the IHI to downstream systems in accordance with current practices.3

4. All requests to and responses from the HI Service must be persisted and retained in accordance with the audit requirements defined in the Healthcare Identifiers Act 2010.

5. Under no circumstances shall the transmission of HealthSMART ADT messages be delayed through an attempt to acquire or check an IHI.

6. Where P&CMS or CMS records have been merged, and both records have IHIs, an A40 message specific to the HI Service should be created and send to the HSIE.

7. All negative responses from the HI Service must be returned to the calling P&CMS or CMS application, and available to the users to review.

8. System errors impacting the ability to retrieve or check an IHI for a patient must also be returned to the P&CMS or CMS application, so that users understand that a technical failure has occurred.

9. The creation and transfer of service requests to the HI Service requires additional design effort, as this is well beyond the typical capabilities of HL7 in a clinical setting.

HL7 HealthSMART Current State

The HealthSMART HL7 standard defines permitted messaging interactions between applications4, as are summarised below for the ADT level messages, which will directly support the IHI design:

• A04 Register Patient – Outbound from P&CMS and inbound to CS • A08 Update Patient information – Outbound from P&CMS, inbound to CS • A19 Patient Query – Outbound from P&CMS and CMS • A28 Add Patient Details – Outbound from P&CMS and CMS, inbound to P&CMS and CS • A31 Update Person Information – Outbound from P&CMS, CMS and CS, inbound to P&CMS and

CS • A40 Merge Patient – Outbound from P&CMS, inbound to CS.

Messages outbound from P&CMS are delivered to the CS and a number of other health service systems, such as pathology.

Although a focused set of HL7 messages are listed above, all HL7 message with a PID segment should incorporate the IHI, where the IHI is available.

HL7 in general caters well for transfer of information, and for errors that occur at the messaging level. If does not necessarily cater well for the communication of errors that occur within applications as a result of the HL7 message processing.

Error messaging in HealthSMART’s HL7 standard is founded upon the use of the MSA segment, with MSA-1 indicating the error state (AE is message received but it contained an error, AR is message received but has been rejected). For one of these error conditions an ERR segment may be included in the returned message which will contain the Error Code and Location. The only HL7 message, in HealthSMART, that supports the MSA and ERR segments is the A19 Patient Query.

For exceptions requiring more immediate attention, an alerting function is used.

IHI Integration using HL7

Patient creation and update processes

The PAS will implement business rules that determine when a patient record has sufficient data to initiate an IHI search, which will occur in the background via the A19 Patient Query message directly explicitly to the HI Service via the HSIE.

In the patient creation process the most common HI Service request will be to obtain an IHI for a patient. Other options may include requesting that an Unverified or Provisional IHI be created, though these will be subject to health service policy. If the patient presents with their Unverified IHI letter the IHI should be scanned and added to the patient’s record for subsequent checking.

3 Note that defining the requirements for downstream systems to store and use the IHI is beyond the scope of this architecture. The IHI should be available to these applications however.

4 Part1_HealthSMART_Unified_HL7_v44.xls, Message Portfolio Matrix worksheet

of 125

Processing of a patient presenting with a pseudonym and their IHI on a Medicare Australia issued IHI card has not been considered within the scope of this project.

The HSIE will form the request to the HI Service, and return all responses to the calling PAS. In the event of a system level error the HSIE should retry the request for a configurable period. The HSIE may also suspend queue operation for persistent system level errors, and notify technical support staff

For updates to patient data the processing may be complicated depending on the business scenario, as below.

• For a patient record without an IHI a patient update that results in IHI search criteria being met, this will result in an IHI search being initiated as for the patient create.

• When patient data NOT related to IHI searching is changed no HI Service request will result.

• When a patient record has an IHI and data used for IHI searching is changed, this produces a very difficult situation that requires complex processing5. In short the existing IHI is likely to be invalidated unless the patient has also been to Medicare Australia to update their details. A new IHI search may or may not return an IHI.

• Patient updates to record a date of death should result in an update message being sent to the HI Service, containing the date of death. The NEHTA CCA regime will specify whether this is a mandatory requirement, or optional and subject to health service’ policies.6

Patient Creation Scenario 1

In this scenario, as shown in the diagram below, the user is creating a new patient record. As soon as the minimum IHI search criteria data is entered the PAS will initiate the IHI search request to the HSIE, via an A19 message. In this scenario the IHI is returned prior to the user completing the data entry, so an A04 Register Patient message is sent with the IHI and ideally its statuses.

Figure 3 - IHI returned while user still creating patient record

5 This is covered in great detail in the Vic IHI Functional Design documents, though the principle remains that an IHI that cannot be successfully checked against the HI Service will not be used in any external patient communiqué, such as a referral. 6 The project team has not investigated the privacy implications of sharing the date of death data with Medicare, though this particular scenario does not appear to be explicitly supported by the Healthcare Identifiers Act 2010..

of 125

Patient Creation Scenario 2

In scenario 2 shown below, the IHI is not returned until after the user has completed the patient record. The PAS updates the patient record with the IHI and associated information and an A08 Patient Update message is sent to ensure that all other systems have the IHI available.

Figure 4 - IHI returned after patient record created

As has been mentioned previously, HL7 message proliferation, as a result of IHI requests and responses, must be avoided. In addition, message order must be maintained.

Patient Merges

Patient merges will also result in a message to the HI Service, as follows:

Patient record 1 Patient Record 2 Result

No IHI No IHI No notification to the HI Service

IHI No IHI No notification to the HI Service

IHI IHI (same number and statuses) No notification to the HI Service

Verified IHI Verified IHI (different) Duplicate notification (A40)

Unverified IHI Verified IHI (same number) Should resolve the Unverified IHI to the Verified first – notification not required.

Unverified IHI Verified IHI (different) May be able to resolve the Unverified IHI to the Verified – notification not required.

Otherwise, notification sent (A40)

Provisional IHI Verified or Unverified IHI HI Service Merge Request (A40)

Provisional IHI Provisional IHI (different) Processing TBA - this scenario is expected to arise very rarely, if ever (A40)

Patient record archival or deletion will not result in an HI Service message being sent.

of 125

IHI Use in e-Health Messaging

The IHI will become a feature of e-health messaging between one health service and another, such as referrals, discharge summaries, orders, etc.

In order to ensure the accuracy of the IHI, the IHI should be checked prior to transmission of the message, and the patient demographic data used for searching, and the IHI statuses should also be incorporated into the message. This enables effective use of the IHI by the receiver. Similarly, an IHI received on a message / communiqué from another health service must always be checked prior to any reliance being placed on the IHI7.

The Victorian IHI Integration Technical Design defines a suite of system configuration parameters, one of which determines the period within which the IHI does not need to be re-checked. For example, if a patient presents in the morning and their IHI is confirmed at admission, then a message sent (a Pathology Order perhaps) that afternoon may not need a separate IHI check, subject to health service policy.

There is no current facility within the Victorian IHI Integration solution to enable a downstream system to request that the PAS perform an IHI Check, or for the downstream system to interface to the HI Service directly. This is based upon the PAS being the master for patient data, and the PAS data needing to be checked prior to sending any communiqué, perhaps at another stage of the patient episode. There may be some business process changes required to support appropriate use of the IHI in this context.

The Victorian IHI Integration Design allows for an IHI Last Checked date/time field, which will be key to ensuring IHI validity when used on an e-health message.

Message Management and Queuing

The HSIE, or equivalent system, will not just implement the interfaces to the HI Service, but will also implement all services to manage the interfaces. This will incorporate business rules to ensure HI Service requests meet specifications, queue management, exception management, and limited monitoring and reporting.

Message management will include the ability to reject messages that don’t meet the HI Service specifications, resend messages in the event of a technical failure, manage all message responses, and ensure that duplicate requests are appropriate, or prevented when not appropriate,

HI Service interface queues, implemented in the HSIE (using Java Message Queuing) may be halted individually or collectively, the former intended to be used when problems are being experienced with a single HI Service function. All queues may also be stopped, when the whole HI Service is unavailable.

It is only the outward queues than may be halted, ie sending from the HSIE to the HI Service. The message queues will continue to accept HI Service requests from the P&CMS and CMS applications. On restoration of the HI Service connectivity, the queued messages will be transmitted. An optional throttling function may be used to ensure that the HI Service is not overloaded with requests.

7 A key principle of the Victorian IHI Integration design, as identified in the Clinical Risk Assessment, is for health service staff to never rely solely on the IHI number for patient identification.

of 125

Messaging Summary

Action taken Scenario HL7 Message Type Sent to HSIE for IHI processing

HL7 Message Type for successful response

HL7 Message Type for unsuccessful response

Notes

Create patient record Search for IHI A19 (search) A19 (IHI response) A19 (search error) Search IHI request must not be initiated by the PAS until minimum IHI search criteria are satisfied.

PID segment carries the IHI.

Error codes to be defined for error response.

Update patient record Record has verified IHI. Search for IHI

A19 (search) A19 (IHI response) A19 (search error) Occurs if IHI search criteria fields in the patient record are changed

Update patient record Record has Unverified IHI. Update HI Service record.

A19 (update) A19 (confirmation) A19 (update error) Different scenarios result depending on data included. A19 PID segment would need to support a special use alias, to enable inclusion of historical demographic data as well as the new.

Update patient record Record date of death A19 (update) A19 (confirmation) A19 (update error) Depends on health service policy.

Update patient record Remove previously recorded date of death

A19 (notification) A19 (confirmation) A19 (notification error)

This should only happen if the removal of date of death is as a result of a previous error. The HI Service should not be notified if this is being done to perform local functions that would otherwise be unavailable for a patient record with a date of death.

Update patient record Record with Provisional IHI modified to include enough information to obtain a Verified or Unverified IHI

A19 (search)

A19 (create Unverified)

A19 (IHI response)

A19 (confirmation)

A19 (search error)

A19 (create error)

Provisional IHI record in the HI Service will never be updated under the Vic design.

IHI search should occur first.

An Unverified IHI may be requested is justified.

Validate IHI Confirm the validity of an A19 (check) A19 (confirmation) A19 (check error) As above

of 125

Action taken Scenario HL7 Message Type Sent to HSIE for IHI processing

HL7 Message Type for successful response

HL7 Message Type for unsuccessful response

Notes

existing IHI

Request IHI Request an Unverified IHI for a new or existing patient

A19 (create Unverified) A19 (confirmation) A19 (create error) Note extent of data required to support this function (full address required).

May return a duplicate error.

Request IHI Request a Provisional IHI for an unidentifiable patient

A19 (create Provisional) A19 (confirmation) A19 (create error) No duplicate checking for Provisional IHIs so error would be more infrastructure or messaging focussed.

Merge patients Merge patients with Verified or Unverified IHIs


Notification to Medicare Australia only.

Merge patients Merge patients with one IHI being Provisional

A40 (merge) A19 (confirmation) A19 (merge error) Uses the Resolve Provisional IHI – Merge Records function in the HI Service.

Unmerge patients Unmerge patient records previously merged and both having IHIs


Notification to Medicare Australia only.

Delete Patient No action

All functions HI Service not reachable A19 (connectivity error)

May also require a notification to a tech support group.

All functions Messaging errors (WSDL) A19 (messaging error)

May also require a notification to an app support group.

of 125

Exception Management

Most errors defined in HealthSMART8 are specific to HL7 messaging, eg segment missing, incorrect value, unknown message type, unexpected sending application, etc. The Exception types supported within the functional design are shown in the table below.

ID Exception Type EX639 No unique match found. All demographic information was exhausted.

EX662 No match found and no criteria refinement available.

EX663 No match found after merge and updated details.

EX664 No match was found in the HI Service.

EX640 No Match found.

EX641 [Message text varies for each Use Case it occurs in.]

EX642 Request for IHI aborted. Duplicate PAS records found on non-TDS Search.

EX643 Status Hierarchy Mismatch. Held: [Status in PAS], Received [Status to Update]"

EX644 System Failure. Contact Help Desk.

EX645 Provisional IHI

EX646 Another record in the PAS has this same IHI, [with the Secondary URN field populated

with the URN of the duplicate].

EX647 Date of Death: [Date of Death].

EX648 Error [Error Code]: [Error Reason]". (e.g. "Error 00019: The date of birth must not be in the future.")

EX649 Multiple matches found.

EX650 Multiple matches found.

EX652 "Existing Verified or Unverified IHI record with the same details." or blank

EX653 Unknown

EX654 Error [Error Code]: [Error Reason]

EX655 HI Merge Failure

EX656 Inconsistent Referral IHI

EX657 Current Patient IHI Anomaly

EX658 HI Service Processing

Key Activities

The following tasks support the use of HL7 messaging to support acquisition and management of the IHI:

1. Review this document with key stakeholders and gain agreement on the approach to be used. 8 Part1_HealthSMART_Unified_HL7_v44.xls, Errors worksheet

of 125

2. Alter the HealthSMART HL7 Unified specification to incorporate the IHI Record Status and IHI Status fields (PID segment). It would be ideal if the Australian HL7 standard were updated first.

3. Alter the HealthSMART HL7 Unified specification to include explicit support for the IHI in the patient identifier codeset.

4. Review the HL7 Unified Specification with respect to the permitted uses and content of the A19 message, expanding / enhancing this as required to support IHI management.

5. Define an alternative use of the A40 Merge Patient message for HI Service messaging.

6. Define the IHI and HI Service exception codes that will be supported in HL7 2.4 HealthSMART.

7. Complete the technical design of HI Service interfaces, business rules and other components to be implemented in the HSIE.

8. Work with HealthSMART health services to agree system policies, and changes required to HealthSMART systems. Assist health services to understand changes required to the AIE and their internal IT systems.

9. Work with HealthSMART and other IT system vendors to define changes needed to their products to support IHI management in HealthSMART.

10. Implement and test system changes including the HI Service interfaces. Conduct capacity planning exercise.

11. Staged rollout to health services. Include IHI initial data load activities.

of 125

6.6 Information Architecture 6.6.1 Introduction The Information View of the solution architecture describes the key aspects of information assets that will be necessary to support the Victorian IHI Integration solution. These include:

• High level structure and relationships between major data entities;

• Standards defining the structure and content of messages to and from the HI Service; and

• Major Policies & Governance arrangements that may be applicable in the context of management of information assets for the solution.

It is important to note that the information architecture defined here is not concerned with database design. The goal is to outline the business data entities relevant to the solution at the “conceptual” level, not to design logical or physical storage systems – these aspects of the solution have either been adequately defined as part of the HI Service specification, or will be addressed in a subsequent phase of the Victorian IHI Integration project.

The IHI is an addition to currently collected or generated patient data.

Requirements

The following requirements define the information architecture.

• The IHI number, the IHI Record Status, and the IHI Status shall be stored against the patient record in the primary patient management application within a health service, ie the PAS.

• If the IHI is available it should be included on all patient centred documentation and messages, including referrals, discharge summaries, orders, etc.

o The IHI qualifying information shall be included when the IHI number is present. IHI qualifying information includes the IHI Record Status, the IHI Status and the patient demographic information used, most recently, to obtain or confirm the IHI.

• Patient data to be used for IHI searching includes the family name, given name, date of birth, gender, Medicare number, DVA number and address data.

o A patient’s alias(es), historical name(s) and alternate address(es) may be used for IHI searching.

• The possibility exists that duplicate patient records may exist within the HI Service. This must be considered when receiving anomalous results when searching for an IHI.

• All messages to and from the HI Service shall be logged.

• All exceptions and resolutions shall be recorded.

• All HI Service logs/audit files shall be retained for a period of 7 years from the departure date of an authorised employee from the health service.

• The HIMs involved in the Victorian IHI Integration project suggested that maximum data should be used to achieve an IHI match rather than minimum, as this would provide a higher degree of confidence in the result.

6.6.2 Searching for the IHI While Victoria’s IHI Integration design is based upon the HI Service Specifications from Medicare Australia, the project team was also keen to incorporate results from the first actual use of the HI Service, especially as far as IHI searching is concerned.

The HIMs involved in the project stated that they would be more comfortable using an IHI that had been retrieved using the maximum data available rather than the minimum. This is in conflict with Medicare’s original recommendations which suggest that the minimum data should be used, and data fields added to achieve a unique result.

The HI Service search algorithm is based on a string comparison, so probabilistic matching is not possible. This also invalidates any business meaning associated with the data accuracy data, as this will not be factored into

of 125

the search algorithm, i.e. a search using a date of birth that is within the date accuracy range, but which doesn’t match the DOB string held by Medicare will not result in a successful IHI search.

Medicare Australia recommends using IHI searches using the Medicare number or the DVA file number, as these are likely to provide the best chance of achieving a unique match. Given the family use of the Medicare card, it would be desirable to include the given name in any search, or the IRN if available9. This would significantly reduce the risk of potential duplicates resulting from multiple births, or from incorrectly entered DOB data.

Medicare has also suggested that if a successful IHI search result is returned, ie the IHI, then this result can be trusted. In real terms Medicare is suggesting that the data submitted has been matched to a single record in their database, and no other interpretation may be placed upon this result. It does not provide any assertion of identity.

The Victorian functional design is non-prescriptive in terms of the data items to be included in the search, though the ability to process aliases, historical names and alternate address is included. Recommendations about the data items to use for IHI searching are included in this section.

While only the draft data matching report from another jurisdiction is available, there are some recommendations that flow from it:

1. Where available, the data reflected in the individual’s Medicare card/record should be used to obtain the IHI.

2. Given names should always be included in searches. This raises a potential concern in that the advisors to the Victorian project stated that given name data is not trusted, ie it is unreliable. This may also demand greater use of locally held alias data to obtain an IHI match.

3. Address data appears to be of limited use when searching for an IHI. This suggests that any extensive exercise to incorporate address validation, eg via QAS, into HealthSMART systems may not deliver a significant benefit in the area of IHI matching, though other benefits may be delivered.

4. Performance remains a concern with an average response of approximately 1 second achieved. To process 600,000 PAS records in one Victorian health service’s would take 7 days of continuous operation (single threaded), and to do this in an 8 hour overnight window would take 3 weeks of elapsed time. Processing all PAS records in Victorian health services would take years.

a. A single threaded approach is assumed as there would be other calls upon HI Service processing time.

Victorian analysis of locally held data suggests that the Medicare number, family name and date of birth are the fields that contribute most strongly to achieving uniqueness within a PAS environment. Fields that have a reduced impact include gender, and given name. Excluding the Medicare number from consideration, the surname and date of birth fields remain most significant, with lower impact from given name, gender, suburb/postcode. Inclusion of Address line 1 data also had a significant impact, though the reliability of this data is unknown.

Victoria achieved a 99.98% unique result using Medicare number, family name, given name, gender and DOB. And a 99.97% unique result without the Medicare number, but including family name, given name, gender, date of birth, postcode and suburb. There is no conclusion that may be drawn from this data in regard to successfully acquiring an IHI from the HI Service.

The data analysed included Medicare numbers for approximately 60% of registered patients.

Search recommendations

In accordance with statements from our contributing HIMs, and with the findings in the IHI matching study, Victorian recommends the following data be used as the minimum acceptable for searching for a new IHI:

• Medicare number, or DVA file number

• Family name

• Given name, where available

• Date of birth

• Gender 9 Note that i.PM does not currently store the Medicare IRN.

of 125

• IRN if available.

If the patient does not have a Medicare card or DVA file number the following data represents the minimum acceptable:

• Family name

• Given name

• Date of birth

• Gender

• Address

Victoria recommends using the legal/registered name of the patient whenever this is identified. If the patient has one or more aliases or alternate addresses then an HI Service search for all permutations should be completed at least once. This will identify any anomalous data, such as two different IHIs being retrieved for the same patient using different search data. To support this, the HI Service request should have the historical data flag set.

As is explicit in the Victorian functional design, there must be sufficient data in the HI Service search to ensure uniqueness in the local PAS. This will ensure that the returned IHI can only be allocated to one record in the PAS.

Victoria has requested a change to the HI Service demographic search, to allow the use of locality and state, and/or postcode, without the street address. This is due to Victorian systems not supporting address data in the format defined in the Australian Standard.

For IHI Checking, which must include the IHI number itself, the minimum information possible should be used:

• IHI number

• Family name

• Given name

• Date of birth

• Gender.

If family name aliases are recorded against the patient record then the system must use the IHI history data to determine the family name that was used in the previous (successful) IHI search.

If the patient’s date of birth as recorded by Medicare is incorrect, there is a policy question that each health service must answer: is it more important to have accurate data recorded or to align the local patient record with Medicare‘s data (the latter has payment and IHI acquisition benefits)? In the Victorian design we raise a service request to Medicare if they have an incorrect date of birth recorded for a patient, though it would still require the patient to present at a Medicare office to have this resolved.

Search Alignment

It is vital to consider the implication of different organisations using different types of HI Service searches in an attempt to achieve the same result, ie get the patient’s IHI. This produces a potentially anomalous situation, in which different IHIs could be retrieved for the same patient by the different organisations.

Addendum. The National Health CIO Forum has recommended that the number of available of IHI search types be constrained to those that provide the optimum matching reliability. This will help to reduce any risks of inconsistent IHI search results within different organisations.

of 125

6.6.3 Patient Domain A high level view of the patient data model is shown in the diagram below, and this covers the PAS view, rather than incorporating the patient domain in the HI Service. The patient class is the primary repository for locally held IHI information.

class Domain Model

Patient

«column»*PK URN: VARCHAR(12) National IHI: CHAR(16) IHI Status: CHAR(1) IHI Record Status: CHAR(1) Family Name: VARCHAR(40) Given Name: VARCHAR(40) Date of Birth: DATE Sex: VARCHAR(2) Medicare Number: VARCHAR(10) Medicare IRN: VARCHAR(1) DVA File Number: VARCHAR(16) Resi_Address: VARCHAR(50) Resi_Suburb: VARCHAR(50) Resi_PCode: NCHAR(4) Resi_State: NCHAR(1)

«PK»+ PK_Patient(VARCHAR)

«unique»+ UQ_Patient_URN(VARCHAR)

IHI Events

«column»*PK IHI Event ID: NUMBER(8,2)* URN: VARCHAR(12)*PK IHI number: CHAR(16) Event Type: NCHAR(8) Event Date_time: DATE Event message: VARCHAR2(50) IHI Record Status: CHAR(1) IHI Status: CHAR(1)

«PK»+ PK_IHI Events(NUMBER, CHAR)

Referral

«column»*PK Referral ID: NUMBER(8,2) Referral Type: NUMBER(8,2)*PK Referral IHI: CHAR(16) Referral Source HPI-I: CHAR(16) Referral Source HPI-O: CHAR(16) Referral Dest HPI-O: CHAR(16) Referral Dest HPI-I: CHAR(16) Services Requested: VARCHAR2(120) Referral date: DATE

«PK»+ PK_Referral(NUMBER, CHAR)

IHI Exception

«column»*PK Exception ID: NUMBER(8,2)*PK IHI: CHAR(16) Exception Type: NUMBER(2,2) Exception Text: VARCHAR2(100) Exception date_time: DATE

«PK»+ PK_IHI Exceptions(NUMBER, CHAR)

Resolution

«column»*PK Exception ID: NUMBER(8,2)*PK Resolution ID: NUMBER(8,2) Resolution Type: NUMBER(2,2) Resolution date_time: DATE Resolution Description: VARCHAR2(100)

«PK»+ PK_Resolution(NUMBER, NUMBER)

Authorised User

«column» Family Name: VARCHAR2(40) Given Name: VARCHAR2(40) HPI-I: CHAR(16) Local Userid: VARCHAR(16) Employee Start Date: DATE Employee End Date: DATE HPI-I Cert: BLOB

Figure 5 - Patient domain model

The various attributes of the patient information domain are well described in other sources, such as vendor documentation on their respective PAS type systems, and in the National Health Data Dictionary (NHDD), and do not need to be discussed further in this architecture.

The IHI represents a small, albeit significant, addition to the current patient information domain. The legislative requirements for audit and logging represent a higher degree of complexity than the addition of the IHI and its associated information to the patient domain.

The patient record will have many IHI events associated with it over time, from the initial acquisition of the IHI to the retirement of the IHI. Every IHI event will be recorded, as required by the Healthcare Identifiers Act 2010. The IHI History referred to in the Victorian Detailed Design documents is a special instance of the IHI Events class.

Each IHI event must be associated with an authorised user, and an organisation though this is not shown (it may be assumed). An IHI Event may be associated with an IHI Exception, which may in turn be associated with zero to many Resolutions. An IHI Exception may have a recursive relationship, i.e. an exception may result in other exceptions as resolutions are attempted.

Implementations may elect to associate some IHI Exceptions directly with the patient record, such as locating multiple records in the PAS with the same IHI, though in this instance the IHI Event may be identified as a Scan For Anomalies process, for example.

A patient may have many referrals over time, and a referral may only include one patient. The processing of a Referral may result in IHI Exceptions and Resolutions, possibly before a patient record is created in the PAS. In this case the patient class reflects the patient information included in the Referral itself.

The referral class may be abstracted to include other patient centred health communiqués, such as Orders, Discharge Summaries, Prescriptions, Results, letters, etc.

6.6.4 HI Service Message Domain The HI Service message domain covers the messaging that is required to support interactions between the health service and the central HI Service. It works on a straight forward request response mechanism, though as expected all messages feature different structure and/or content.

of 125

The diagram below is intentionally high level, as the detail for each class is typically described in commonly available resources, such as the NHDD and in Medicare Australia’s HI Service Specifications.

class IHI Messaging

IHI Request Class

IHI Request Type Class

IHI Response Class

IHI Response Type Class

Authorised User Class

Organisation Class

Patient Class

IHI Ev ent ClassIHI History Class

IHI Exception Class

IHI Resolution Class

Figure 6 - High Level Message Domain Model

Each IHI request (message) may only be associated with one response, and the response may be an exception, which must be reflected in the IHI Exception Class.

Request Types and Response Types link to the various HI Service functions as implemented in this Victorian IHI Integration design, such as IHI Search, IHI Check, Update IHI, Create Provisional, etc. Where feasible the implementer may wish to incorporate XML schema definitions and/or stylesheets to validate the structure and content of the message prior to transmission.

Various other data is required to support HI Service messaging, including information about the software being used, and its version. This, and the organisational information, is treated as system configuration data.

The relationship between IHI Event, Authorised User and Organisation is open to alternate implementation, ie changes to the linkages. Effectively the model is looking at the IHI Event, and this must be initiated by a user, or by the system as a result of a user action, hence the link as drawn.

of 125

6.6.5 Primary Information Locations The following table defines the primary data stores for IHI related information.

Information Type Primary Location

Patient P&CMS, other PAS

HI Service

IHI HI Service

P&CMS, other PAS

User and access control information P&CMS, or other PAS

A separate Identity and Access Management (IdAM) solution, eg the Victorian CTI project

HI Service Messages HSIE

Other HI Service interface solution

HI Service message logs HSIE

Other HI Service interface solution

IHI Events, Exceptions and Resolutions P&CMS, or other PAS

Some in the HSIE

6.6.6 Data Flow Diagrams A number of data flow diagrams are included in the following pages. All are to be read from top left to bottom right.

Obtain the IHI from the HI Service

The first diagram (Figure 7 ) shows an IHI being retrieved from the HI Service follow a P&CMS user making an update to the patent record. Note the distribution of tasks, with the HSIE taking much of the load from the P&CMS platform and handling the complex messaging and queuing components.

This model is likely to apply in many situation where there is logical or physical separation of the PAS component from the messaging component.

Distribute the IHI to Downstream systems

The second diagram (Figure 8 ) shows the distribution of an IHI, previously obtained via the process in Figure 7 , to other systems within HealthSMART and the client health service. Note that, under NO circumstances, will HealthSMART distribute IHIs between health services, except as part of a valid e-health message. While only Pathology, Radiology and Pharmacy systems are shown, many other health services application may receive the patient update and IHI through this approach.

This represents the current HealthSMART operating model for distributing patient data to other systems.

Interim Solution – Add IHI to a Discharge Summary

This data flow diagram shows an interim solution, in which the PAS (P&CMS) is not the initiator of request for the IHI. Instead the request to the HI Service is triggered by a discharge summary being generated from the Clinical System.

This approach is available for rapid implementation, and may be used to support the Victorian Wave 1 project.

of 125

Figure 7 - Data Flow - Obtain IHI from the HI Service

of 125

Figure 8 – Data Flow - Distributing the IHI to Downstream Systems

of 125

Figure 9 - Interim Solution - Adding the IHI to a Discharge Summary

of 125

6.6.7 Information Standards Some of the key health information standards, including messaging standards, are listed below.

• AS5017-2006 Health care Client Identification

• National Health Data Dictionary, Version 13, 2006

• Medicare Australia HI Service Specifications

• HealthSMART iSOFT i.PM vendor documentation

• HealthSMART Unified HL7, 9/3/2011

• AS4700.1-2005 Implementation of Health Level Seven (HL7) Version 2.4 – Patient Administration

Note that some standards, such as AS5017, are not commonly implemented in health IT systems, and must be regarded as setting the future direction.

Healthcare Identifier Standards10

The IHI, HPI-I and HPI-O are persistent and unique 16 digit reference numbers that are designed to be machine and human readable and are intended for use on tokens, medical documents, patient wrist bands and other media as appropriate.

ISO 7812 3523.1 Number (HI number)

Issuer Identification Number

Assigned by ISO

Fixed Length 6 Digits

Individual Account Identification

Assigned by Identification Service

Variable Length Max. 12 Digits (ISO 7811-3)

9 digits for the healthcare identifier

Check Digit

N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16

Figure 10: Issuer Identification Number (IIN)11 as outlined in the Australian (AS 3523-1&2) and International Standards (ISO 7812 3523.1)

Each of the identifiers is made up of three components: issuer identification number, individual account identification number and the check digit.

• The issuer identification number is the first 6 digits of the identifier. This is a constant for each identifier as follows:

o For all identifiers, the first 5 digits will be ‘80036’8 o The 6th digit (N6) will be

‘0’ for an IHI ‘1’ for an HPI-I; or ‘2’ for an HPI-O

• The individual account identification number is the unique reference number.

• The check digit will be calculated using all components of the issuer and individual identification numbers. The check digit is computed using the Luhn formula modulus 10 “double-adddouble” check digit [ISO7812].

A healthcare identifier number format for computer displays and manual data entry should read in the following way:

• visually rendered as four groups of four digits, for example:

(8003 60) 12 0456 7891

10 Healthcare Identification HI Service Use of Issuer Identification Numbers Policy, Version 1.6 – 2010

11 International Standard ISO/IEC 7812-1 Identification cards – identification of issuers- Part 1 Numbering System

of 125

A healthcare identifier number will be used to link the patient to an object identifier (OID12) of particular importance when the patient undergoes medical procedures (e.g. implant of a prosthesis):

• an object identifier (OID) has the healthcare identifier embedded and is recorded in the following way:

‘1.2.36.1.2001.1003.0.8003.6012.456.7891’

6.6.8 Information Security Information security in a distributed environment is managed through a rigorous approach to securing message content. This is enabled through the use of the Transport Layer Security (TLS) security solution for all HI Service related messaging.

The behaviour, in terms of managing data security, of organisations consuming HI Service functions, and indeed the behaviour of the HI Service operator are somewhat beyond the scope of this architecture, however all health organisation must comply with relevant information security and privacy legislation.

The NEHTA Security and Access Framework (SAF), when released, may address other requirements for data security within healthcare organisations, possibly including a health service specific data security policy, acceptance by senior management, and the need for periodic audits. The precise nature of the SAF is not yet clear.

Within HealthSMART the current approach to ensuring information security will continue to be used. It is possible that some minor enhancement to current HealthSMART information security practices may be required upon release of the NEHTA Security and Access Framework,

12 Healthcare information interchange standards use OIDs for globally unique identifiers for both individual objects as well as references to code systems and data element dictionaries. An OID format is generally only required and used within an electronic message and should not be used in any human readable context

of 125

6.7 Reporting Architecture 6.7.1 Introduction The reporting requirements to support IHI Integration are primarily operational in nature with three main focus areas:

1. Enhancement to current health service data quality reports, incorporating IHI duplications and other data related exceptions.

2. A suite of new operational reports enabling reporting on IHI exceptions, specifically concerned with obtaining the IHI and managing it over time.

3. Reporting on the systems supporting IHI integration processes, such as the HSIE. This is system level reporting, which could be used to report on HI Service response times.

The reporting subsystems should be integrated with the respective platform or application, with a dedicated and specialised reporting environment not required.

In the course of the project the possibility of an IHI adoption measure was raised, with a possible link to health service funding. Adoption reporting is supported, without any temporal element, by both the View IHI Summary Report, and Patient IHI List Report use cases.

6.7.2 Reporting Overview The table below shows the business reports that are currently incorporated within the Victorian IHI Integration design. No dedicated reporting system, such as a data warehouse and business intelligence solution, is required to support the operational reporting requirements.

Technical reports on the functioning of the HI Service interface layer will be available through the standard HSIE reporting tools. For those implementing an HI Service interface without an EAI or ESB type tool, the recommended technical reports are defined in the Victorian IHI Integration Technical Design.

See the Functional Design and Technical Design deliverables for more information.

Use Case Title Description

Scan for Patient Anomalies

The System performs a scan to detect the following situations: 1. Multiple patients with the same IHI 2. Duplicate patients based on demographic data.

3. Patients with provisional IHIs View Patient IHI Report

This is an on screen report that allows the user to review a list of all IHI related transactions for one patient only.

View IHI Summary Report

1. Patient IHI Analysis (counts)

2. Multiple patient records that satisfy the same IHI Search criteria (for all 3 levels of IHI Search)

3. Exception Analysis

4. Patient records with open IHI Exceptions (can be excluded from further exception processing)

Patient IHI List Report

(See Technical Design for further details)

1. Patient IHI Reports

2. Multiple patient records that satisfy the same IHI Search criteria

3. Patient Scheduling Reports

4. Patient Attendance Reports

5. Patient Waiting List Reports

6. Incoming Service Request IHI Reporting

7. Outgoing Service Request IHI Reporting

Recommendations:

of 125

1. As the reports are all operational in their nature, they should be run against the operational database. Users may need to be prevented from running complex reports when the system is heavily loaded.

2. Alternatively, the system administrator may elect to schedule these reports for overnight execution, and then provide the output to authorised users.

of 125

6.8 Technology Architecture 6.8.1 Overview The technology architecture is constrained by HealthSMART infrastructure solutions, and by infrastructure used within Victorian HealthSMART health services. Based on the preferred solution architecture, the HealthSMART Integration Engine (HSIE) will implement all interfaces to the HI Service, and distribute IHI related data via i.PM to other HealthSMART and health service applications.

There is therefore little change required to the existing HealthSMART technology architecture.

The role of the technical architecture becomes one of ensuring that the HSIE, the Agency Integration Engines (AIE), the supporting networks, and downstream systems can be scaled to handle predicted future transaction volumes.

Note that any consideration of major enhancements to the HSIE, possibly including eIndex, is out of scope of this document.

6.8.2 Scope The systems that will be primarily impacted by IHI implementation will be the HSIE, iSOFT i.PM, and InterSystems TrakCare. The HSIE will implement all interfaces to the HI Service, and hence the load on the HSIE will be significantly greater than before. i.PM will be the primary repository of IHI related data in a HealthSMART health service. TrakCare will be the primary repository of IHI data for Community centres.

All health service systems that store and use patient information are likely to need to store the IHI at a point in the future, though consideration of these systems is limited to those within the HealthSMART application suite for the Victorian IHI Integration project. This objective can be addressed incrementally as third party vendors become aware of the IHI solution.

Another area of potential impact relates to the increased network traffic due to the HI Service request and response transactions. In the steady state scenario the network traffic within a health service should be incrementally higher, as patient’s IHIs are checked prior to generation of an external patient communiqué, such as a Discharge Summary, or a Pathology Result that will be sent outside the hospital. For internal systems patient updates are already broadcast and processed by these systems. Allowance has been made for the inclusion of the IHI in the HL7 PID segment, as the national health identifier.

There is little that this solution architecture can do to influence the other technology components upon which the IHI Integration is dependent, such as the National Authentication Service for Health, or even predict their possible impact on current systems, as their design and architecture are unknown.

Victoria has made a number of requests to NEHTA and Medicare Australia with respect to enhancements to the HI Service. These are unlikely to cause any potential increase in load.

6.8.3 Technology Solution Requirements The technology architecture must fully support the requirements, as outlined in the Vic IHI Business Requirements Specification deliverable. Further to this, the design must also respond to a number of technical requirements, which are described below.

Performance

The performance of a system usually refers to user perceivable response times, i.e. the time it takes for the system to respond to a user’s request. In the case of the IHI Integration solution, performance is largely concerned with message response from the local system (i.PM) to the HI Service and back, and efficient message processing in the various solution components.

The current design and architecture specify fully asynchronous operations, meaning that a user will never have to wait for an HI Service response before they can proceed to their next task. Some health services may wish to vary this, at which point end to end performance becomes important. This will need to be addressed on a case by case basis.

The HI Service operator has committed to a maximum response time SLA of 8 seconds13, averaged over a 15 minute period. The HSIE will include a mechanism to report on slow HI Service performance.

13 Note the NHCIOF proposed alteration of the average HI Service response time SLA from 8 seconds to 3 seconds.

of 125

Addendum for Solution Architecture Release 2. NEHTA and Medicare Australia have been asked to examine the feasibility of altering the 8 seconds SLA to 3 seconds. This represents a significant benefit to users, though does not alter the Victorian IHI Integration project’s architecture.

Performance of and load on the HSIE and networks will need to be monitored as HealthSMART health services adopt the IHI. Workload estimation and capacity planning activities should occur prior to any implementation of IHI related services.

Scalability

Scalability refers to the ability of a system to respond to temporary or permanent increases in the business workloads. The business perceivable outcome of this requirement is that at no time should the system be unable to process IHI requests because of insufficient capacity.

The IHI Integration solution must scale to support the expected growth in volumes of IHI request messages from the HealthSMART health services, initially through the implementation phase, as health services adopt the IHI, and later to cater for normal daily processing patterns. The steady state situation is expected to involve lower volumes of IHI requests and also simpler transactions, especially as GPs take up the IHI and include it on referrals.

The HSIE is implemented on a platform well suited to scaling to support increased workload, and recent changes within the technology architecture to Virtual Machines (based on VMWare ESX) further supports a highly scalable solution. The HealthSMART application infrastructure is also managed centrally and capacity can be managed appropriately.

The AIE and other downstream systems are under the management of the respective health services, and, while the impacts are expected to be minor, a more formal assessment of the likely load is recommended.

Manageability

The Victorian HealthSMART infrastructure already has strong systems management capabilities, including notifications and queue management capabilities, which can be used to support the IHI integration solution.

Availability

Availability describes the periods during which the system is expected to be fully operational. It is commonly expressed as a percentage of the total time window during which business services are to be available to the ultimate consumers of these services. Specific allowances outside the availability window are made for scheduled systems maintenance events.

Industry practice indicates that 100% availability, whilst desirable, is not a realistic or practical objective, due to the extreme costs, and technical / operational complexities involved in the attainment of this objective.

The availability window of all components of system supporting IHI use in health services is assumed to be 24 hours a day x 7 days per week.

It is expected that the heaviest use of IHI systems will occur during normal business hours, i.e. 9:00 am to 5:00 pm, Monday to Friday, with peaks likely late morning and late afternoon.

The systems should be highly available for normal and extended office hours, delivering 99.5% or better uptime. Scheduled system outages may be acceptable outside extended office hours, allowing for system maintenance, and other approved activities. The system will be assumed by default to be “always on” during periods outside these maintenance windows.

The Victorian IHI Integration architecture design supports fully asynchronous operation, including the ability to manage and recover from any periods of non-availability of any component of the IHI integration components.

It is beyond the scope of this architecture to recommend changes to any current availability SLAs for existing HealthSMART applications.

Data Recoverability

Recoverability refers to the ability of a system to be restored to proper working order, following a non-catastrophic failure, with system and data integrity maintained.

of 125

Data recoverability in the context of the IHI Integration solution applies to the handling of messages in transit, either from the local system to the HI Service or vice versa. A message failure must not result in data in either system being left in an inconsistent state. 14 The HSIE, based on Oracle Sun JCAPS, provides good support for message management.

Audit and log data must also be retained and protected in accordance with the Healthcare Identifiers Act 2010.

Disaster Recovery

HealthSMART systems are already covered by a comprehensive disaster recovery arrangement, though this may need to be extended to cover the local interfaces to the HI Service. This should be addressed as a change to the current DR requirements for the HSIE.

Security

Health information and personal data is protected by legislation, with which all parties must comply. Requests from HealthSMART systems to the HI Service and responses must occur over a TLS connection, using client certificates. This is described in more detail in the Security section. This will ensure that patient information passing over the Internet will be encrypted, and hence secured from interference.

The security implementation will require one or more TLS enabled interfaces, depending on the final technical design chosen, all of which will use the same TLS PKI certificate, Note that this messaging and security approach is different from NEHTA’s SMD specification (used for e-Referrals), and from the eTP specification.

HealthSMART already provides physical and network security for all systems and infrastructure. Health services are expected to also have implemented appropriate levels of physical security.

User access security is undefined by NEHTA, with this being left to the health service, or a body such as HealthSMART. This is covered within the Application Architecture section of this document.

Reporting

No requirement has been identified for a dedicated and separate reporting requirement to support the integration of the IHI into HealthSMART and other health service systems.

Provision of any dedicated reporting infrastructure is excluded from the IHI Integration project scope.

14 The behaviour of the HI Service when the message returned to the client system fails is currently unknown, ie is the whole transaction rolled back if the transaction isn’t passive (ie a read). This would apply to requests such as Update IHI, Request Unverified IHI, Request Provisional IHI, etc.

of 125

6.8.4 Technology Solution Architecture The Victorian IHI Integration solution will exist in the HealthSMART technical environment, and will be implemented on the HealthSMART Integration Engine platform (Oracle Sun JCAPS).

No change to the (internal) existing HealthSMART technology environment is required to support IHI integration, other than appropriate capacity uplifts as health services adopt the IHI.

The external network connectivity required to support IHI Integration is also established in a basic form (used to support Medicare Australia’s Eclipse service), though in this case the capacity uplift may be significantly greater and have cost implications (additional bandwidth).

Existing HealthSMART technical documentation may be referenced if more information on the technology architecture is required.

6.8.5 Transactional Load Estimation Load estimation is an essential element of the solution architecture, and a key input to the HealthSMART capacity uplift required as health services take up the IHI. The figures here remain estimates only, with a more formal transactional analysis recommended for each health service, as they approach IHI implementation.

There are two areas to consider:

1. Number of records to be submitted to the HI Service via offline batch, to support Initial Data Load (IDL) activities. This activity would be subject to health service policy, and a source of funding.

2. Daily transaction volumes.

Parameters

• A typical Victorian health service may have:

o A patient master file containing 800,000 records

o 90,000 inpatient separations per annum

o 90,000 inpatient bookings per annum

o 60,000 ED attendances per annum

o 300,000 outpatient visits per annum

o 280,000 outpatient bookings per annum

• In the future, outputs will be generated for every inpatient separation, including a discharge summary, and possibly on referrals, prescriptions, etc.

• To further minimise technical risk ensure that the initial deployment configuration has a significant “contingency” component. At a minimum it is recommended that sufficient capacity

Assumptions

• All patient records will be submitted to the HI Service for matching, as part of the initial data load.

• Every referral, outpatient visit and inpatient admission will be associated with at least one IHI search. A maximum of two IHI searches for the patient population would be supported.

• The IHI will be checked and confirmed once for each attendance. Approximately 33% of Inpatient and ED attendances will require an additional IHI check, following a stay of more than 1 day.

• This one IHI check will support all outputs generated as a result of an attendance.

• No allowance has been made for HI Service requests to support Unverified or Provisional IHIs.

• All patient records with IHIs will have the IHI checked at least once per annum.

• Most HI Service request will occur between 7:00 am and 7:00 pm, 100% assumed for the purposes of this estimation.

• No net (business) growth is factored in.

of 125

Overall number of HI Service requests occurring per annum equals:

• 640,000 number of patient records with an IHI match in IDL15

• 90,000 inpatient bookings

• 90,000 inpatient attendances

• 30,000 inpatient output documents (stay more than 1 day)

• 60,000 ED admissions

• 20,000 ED output documents (stay more than 1 day)

• 280,000 outpatient bookings

• 300,000 Outpatient attendances

• 1,510,000 HI Service requests per annum

Description Minimum Number

Maximum Number

HI Service Requests per annum 1,510,000 3,020,000

HI Service Requests per day (365 day year) 4137 8274

HI Service Requests per day (220 day year) 6864 13728

This suggests that the average number of HI Service requests per day, for an average health service, is likely to be between 4137 and 13728.

This equates to an average of between 345 and 1144 requests per hour, based on a 12 hour day, or between 6 and 19 requests per minute.

For HealthSMART, and given that HealthSMART may be called upon to support IHI Integration for 11 health services, the average transaction rate will be between 66 and 209 requests per minute.

While this does not seem high it should be recalled that each HI Service request must be retained in HSIE memory until the HI Service response is received.

6.8.6 Network Load Estimation NEHTA have recommended that the average message size to and from the HI Service is approximately 1 kbyte. Using the estimated load figures above allows us to calculate the likely network data load.

Description Volume (MB) Volume (MB)

HI Service Requests/Responses data per day (365 day year)

8,274 16,548

HI Service Requests/Responses data per day (220 day year)

13,728 27,456

This equates to an average per health service of between 12 MB and 38 MB of data transferred per minute, equally distributed between outgoing traffic and incoming traffic.

For HealthSMART, with 11 health services, the average data volumes transferred will be between 132 and 418 Mbytes per minute.

15 Based on 80% IHI match success achieved in other IHI matching investigations.

of 125

6.8.7 Batch Load Volumetrics Medicare Australia offer a service to assist with performing an initial data load of IHIs into a health service’s PAS as a pre-cursor to operational adoption of the IHI.

The recent IHI matching study demonstrated an average response time of approximately 1 second per record, for batch IHI matching requests. The figures below would double if batch processing can only occur after hours.

Description Min Time (1 search per record)

Max time (2 searches per record)

Submission of 800,000 patient records for IHI matching 555 days 1110 days

Submission of 640,000 patient records, assuming 20% are deceased

444 days 888 days

Submission of data from the 200,000 most recently seen patients

139 days 278 days

This table indicates that this process, as described, may not be feasible in a real world scenario..

If health services require a response from Medicare Australia within 1 week, for an average size patient master file, the following table shows the amount of parallel processing required. Assumption is 5 days of processing time, to cater for the one week turnaround.

Description Min Parallel processes required

Max parallel processes required

Submission of 800,000 patient records for IHI matching 111 threads 222 threads

Submission of 640,000 patient records, assuming 20% are deceased

56 threads 112 threads

Submission of data from the 200,000 most recently seen patients

28 threads 56 threads

Once again, if the batch processing may only occur after hours or on weekends, the number of threads suggested in the table would need to be doubled. Note that the addition of many more processing threads may simply move a processing bottleneck to the database platform, or to the network layer.

For Victoria, the project team has calculated that there may be in the order of 20 million patient records just in the HealthSMART health services.

6.8.8 Development and Testing Environment Provisioning The environments required to support IHI Integration development and testing activities will leverage existing HealthSMART platforms and processes, including the ability to use virtual servers.

The IHI Integration development environment will employ HealthSMART standard development tools and practices.

A view of the likely environment requirements to support the IHI Integration implementation project is shown in the diagram below.

of 125

The table below provides a brief description of the individual logical environments.

Environment Description

Development An environment supporting the development of JCAPS web services that implement the IHI integration solution. This environment is owned by HealthSMART.

System/Integration Testing The environment is used to validate the integration of technical components and support testing of the correct behaviour of functionality at the system level.

Ownership of this environment is likely to rest with HealthSMART, though as IHI take up progresses selected health service systems may be included. Environments supporting health service applications are owned by the respective health service.

User Acceptance Testing The environment is used to perform the end to end testing of business functionality.

Ownership to be determined, and may be shared.

Production Support The environment is primarily used to resolve high priority production incidents and to develop / test emergency fixes.

of 125

6.9 Security Architecture 6.9.1 Overview This section of the document describes the security elements of the IHI Integration solution. The level of detail may vary, with higher risk elements being described more fully.

The security architecture supports the business and application architectures, and is based upon an initial threat assessment. There is little that the Victorian Pre-Implementation project can do to influence the HI Service implementation, though Victoria must be aware of any potential threat and mitigate any risks.

NEHTA and Medicare Australia have adequately described the security requirements for the messaging layer, so that messages to the HI Service will be well protected. This relies on Transport Layer Security, with client certificates, which provides a greater level of security.

User level security for the HI Service B2B channel is effectively the domain of the client applications that will acquire, manage and use the IHI. The need for identification of any individual accessing the HI Service is embedded in the Healthcare Identifiers Act 2010, but there is little detail other than this. User level security for alternate channels including the HPOS and telephone is based upon the user having an HPI-I, and this is unlikely to provide adequate support for Victorian health services staff (those responsible for managing the IHI and patient data are not entitled to an IHI, and an alternative approach enabling them to access key H Service support services has not yet been defined).

It is important to recognise that there is only a very basic access control layer implemented in the HI Service B2B channel, which is based upon the organisational PKI certificate used for the TLS encryption of the message. The details of the user initiating the request must be included in every HI Service request, and NEHTA have advised that this user information in a request establishes authority for the user to access the HI Service. There is no access control layer implemented in the HI Service, so all liability for inappropriate access rests with the health service.

There is little visible to Victoria in terms of the tools implemented to protect the HI Service from intrusion or other attacks. Victoria assumes that comprehensive Internet security tools have been implemented, as would be consistent with world’s best practice. This particular applies to Intrusion Detection and Intrusion Prevention tools, as the HI Service seems a candidate for Denial of Service type attacks.

The security architecture depends primarily on the architecture of the HealthSMART IHI Integration solution, and this is founded upon the HSIE implementing the HI Service interfaces, with all other traffic being internal to HealthSMART, i.e. the transfers of IHI information between the HSIE and P&CMS.

Given the presence of client demographic information and unique identifiers in the message content, this architecture intentionally adopts a maximum security stance, which is largely aligned with the NEHTA approach.

Physical security is a feature of the HealthSMART implementation, as it is of the HI Service as implemented by Medicare Australia. Physical security will not be discussed further in this section.

The security architecture is fundamentally technical in its nature, and is very difficult to describe in terms familiar to business readers. This section is therefore primarily targeted at a technical audience. For additional details on XML signature and encryption standards, readers should become familiar with NEHTA’s XML Secured Payload Profile document, as well as the W3C standards.

6.9.2 Business Requirements The high level non-functional requirements for the IHI Integration solution (from the document Vic IHI Integration Business Requirements Specification v1.1) includes two components that explicitly relate to security:

NFR_05 Authorised Users The system will allow only authorised users to access/action patient and IHI details.

NFR_06 Systems must protect the integrity of patient information by providing a secure service.

All messages incorporating the IHI transmitted over the Internet are to be signed and encrypted.

See the HI Service specifications for additional detail.

There are a number of other requirements that have not been explicitly included in the business level requirements referred to above, but are assumed to be mandatory for a secure Internet-based distributed

of 125

system such as will support the IHI. The following requirements therefore should also be factored into the overall security architecture:

1. Access to services (e.g. HI Service and NASH) shall be provided to authorised parties only. 2. Malicious interference with application components, e.g. through Denial of Service attacks, shall be

prevented. 3. Messages may be sent many times without impacting the state or quality of the associated data

(load and performance is another matter). Therefore HI Service requests for IHI searching and checking have no requirement to be idempotent. HI Service requests for the creation or updating of IHI records may need to be idempotent.

6.9.3 Threat Assessment The Web Services Interoperability Organisation (WS-I) defines nine main areas of threat to the proper functioning of Web services, as described in the table below. This should not be regarded as a complete threat assessment for the IHI Integration solution, but rather deals with the messaging components only. Developing an end to end security risk assessment consistent with the DH framework is recommended.

Threat Description IHI Relevance Business Impacts (if Threat Materialises)

Message Alteration

An attacker inserts, removes or modifies information within a message to deceive the receiver

Critical

May result in a false IHI match received, and subsequent patient misidentification risk.

Public trust in DH would be diminished.

Loss of confidentiality

Information within a message is disclosed to an unauthorised individual

Critical

Client/patient and provider confidentiality is breached.

Breach of State and Commonwealth legislation

Information may be used for improper or malicious purposes.

Public trust in DH would be diminished.

Falsified messages

Fictitious messages that an attacker intends the receiver to believe are sent from a valid sender

Major

At a minimum would create additional workload for the receiver, and possibly impact other HI Service users.

Man in the middle

A third party sits between the sender and provider and forwards messages without knowledge of the two participants, allowing the attacker to view and potentially modify messages

Critical

Similar effect to first two items.

Principal spoofing

An attacker constructs and sends a message with credentials such that it appears to be from a different, authorised principal

Critical

At a minimum, would create additional work for the receiver.

Forged claims An attacker constructs a message with false credentials that appear valid to the receiver

Critical

At a minimum, would create additional work for the receiver.

Replay of message

An attacker resends a previously sent message

Moderate At a minimum, would create additional work for the receiver. Becomes more significant as part of

of 125

Threat Description IHI Relevance Business Impacts (if Threat Materialises)

a DoS style attack.

Replay of message parts

An attacker includes portions of one or more previously sent messages in a new message

Critical

Similar to forged claims above.

Denial of service An attacker causes the system to expend resources disproportionately such that valid requests cannot be met

Critical

DoS attacks on the HI Service would have a major effect on the sector, and must be prevented.

6.9.4 Web Services Security Standards Security is one of the more dynamic aspects of Web services, with multiple (sometimes competing) standards frameworks evolving in parallel. The diagram below shows the major standards that have been developed to support strong security for SOAP style web services.

The diagram is intended to convey the multi-dimensional and highly complex nature of security in the Web services world. Note that many of the items above are complementary and the adoption of some approaches (e.g. Secure Sockets Layer - SSL/Transport Layer Security - TLS) eliminates the need for others.

It also needs to be recognised that end to end implementation of the security solution will be reliant upon further external services such as public key access and management to support certificates for message signing and encryption (Certificate Authority and Registration Authority roles).

6.9.5 Security Solution Approach The security solution to support IHI integration is largely defined, and requires only implementation work by those wishing to connect to the HI Service.

The security solution will leverage the SSL/TLS component of the Web services standards frameworks described above. The following table shows the security components that contribute to addressing each of the major threat categories defined previously. The green row reflects the standard to support interfacing to the HI Service.

Security Management

WS-Trust

XKMS

Message Security

WS-SecureConversation

WS-Security

SOAP Foundation

XML Security

Transport Layer Security

Network Layer Security

XML SignatureXML Encryption

SSL/TLS

IPSec

Identity Management

Liberty AllianceWS - Federation

SAML

Reliable Messaging

WS-Reliable Messaging

WS-Reliability

Policy

WS-Policy

Access Control

XACML SAML

of 125

M

essa

ge

Alte

ratio

n

Loss

of

Con

fiden

tialit

y

Fal

sifie

d M

essa

ge

Man

in th

e M

iddl

e

Prin

cipa

l S

poof

ing

For

ged

Cla

ims

Rep

lay

of

Mes

sage

Rep

lay

of

Mes

sage

par

t

Den

ial o

f S

ervi

ce

XML Encryption X X X X X

XML Signature X X X X X X

WS-Security Tokens X X X

WS-Addressing X

SSL/TLS X X X* X X* X* X

SSL/TLS with client certificates

X X X X X X X

HTTP Authentication X X X

* Only protects messages from sender to receiver and not vice versa.

Note that SSL/TLS is not suited for use in a decoupled web services architecture, as would be used if a fully asynchronous web services model were to be employed for HI Service requests, as has been suggested by Victoria.

SSL/TLS also does not guard against all types of attacks, with the Denial of Service being the primary concern. Other security infrastructure components can detect and prevent DoS attacks, though these would be implemented to support the HI Service and are consequently out of scope for consideration in this document.

6.9.6 Security Solution The security changes required within the HealthSMART environment to support HI Service connectivity is limited, and includes the following:

1. Obtain authority for HealthSMART to act on behalf of the HealthSMART health services to interface to the HI Service.

2. Acquire a valid TLS organisational PKI digital certificate for use in encrypting outgoing HI Service requests.

3. Implement SSL / TLS capabilities within web services implemented in the HSIE.

4. Implement supporting TLS functionality to validate certificates used.

5. Ensure that the HealthSMART external firewall settings will support sending the encrypted request (should only be directed to one Internet address) and receiving the HI Service response (should only be received from one Internet address).

6.9.7 TLS Handshake Protocol Background The material below, referenced from Microsoft Developer Network website and other sources, is provided to demonstrate the complexity of negotiating a TLS connection between hosts, and the benefits that may be available through implementing more permanent connections between the HI Service and organisations likely to produce very high volumes of HI Service requests, such as HealthSMART.

The Transport Layer Security (TLS) Handshake Protocol is responsible for the authentication and key exchange necessary to establish or resume secure sessions. When establishing a secure session, the Handshake Protocol manages the following:

• Cipher suite negotiation

• Authentication of the server and optionally, the client

• Session key information exchange.

of 125

Cipher Suite Negotiation

The client and server make contact and choose the cipher suite that will be used throughout their message exchange.

Authentication

In TLS, a server proves its identity to the client. The client might also need to prove its identity to the server. PKI, the use of public/private key pairs, is the basis of this authentication. The exact method used for authentication is determined by the cipher suite negotiated.

Key Exchange

The client and server exchange random numbers and a special number called the Pre-Master Secret. These numbers are combined with additional data permitting client and server to create their shared secret, called the Master Secret. The Master Secret is used by client and server to generate the write MAC secret, which is the session key used for hashing, and the write key, which is the session key used for encryption.

Establishing a Secure Session by Using TLS

The TLS Handshake Protocol involves the following steps:

1. The client sends a "Client hello" message to the server, along with the client's random value and supported cipher suites.

2. The server responds by sending a "Server hello" message to the client, along with the server's random value.

3. The server sends its certificate to the client for authentication and may request a certificate from the client. The server sends the "Server hello done" message.

4. If the server has requested a certificate from the client, the client sends it.

5. The client creates a random Pre-Master Secret and encrypts it with the public keyfrom the server's certificate, sending the encrypted Pre-Master Secret to the server.

6. The server receives the Pre-Master Secret. The server and client each generate the Master Secret and session keys based on the Pre-Master Secret.

7. The client sends "Change cipher spec" notification to server to indicate that the client will start using the new session keys for hashing and encrypting messages. Client also sends "Client finished" message.

8. Server receives "Change cipher spec" and switches its record layer security state to symmetric encryption using the session keys. Server sends "Server finished" message to the client.

9. Client and server can now exchange application data over the secured channel they have established. All messages sent from client to server and from server to client are encrypted using session key.

of 125

Figure 11 - Ideal TLS Handshake with Client Certificate

Resuming a Secure Session by Using TLS

1. The client sends a "Client hello" message using the Session ID of the session to be resumed. 2. The server checks its session cache for a matching Session ID. If a match is found, and the server

is able to resume the session, it sends a "Server hello" message with the Session ID. i. If a session ID match is not found, the server generates a new session ID and the TLS client

and server perform a full handshake. 3. Client and server must exchange "Change cipher spec" messages and send "Client finished" and

"Server finished" messages. 4. Client and server can now resume application data exchange over the secure channel.

The actual TLS handshake seen most commonly in practice is more similar to the interaction below, in which a server initiated renegotiated occurs following the certificate exchange. This is represented by the black line across the diagram. The complexity of the process is readily visible, with 24 network transfers required, and this will introduce a response time delay to the first HI Service requests occurring after a period of inactivity.

of 125

Figure 12 - Typical TLS Handshake with Client Cert

Note that this diagram does not show any certificate validation steps, such as checking against a Certificate Revocation List (CRL).

TLS timeout settings are important to ensure that security is maintained, but also to ensure that needless network activity is avoided. TLS timeouts are typically controlled through system configuration parameters. There are two timeout values, one that controls activation of the resume session process above, and one that results in a full TLS handshake, as in the diagrams above.

Conclusion

While the use of TLS with client certificates provides a comprehensive security solution for the protection of patient data and the IHI, it also may not provide the most efficient solution for health services, or health IT service providers such as HeathSMART, with high volumes of HI Service requests.

See Section 6.3.11 for further information about discussions the project team had with NEHTA and Medicare Australia regarding this item, with agreement that this may be reviewed at some point in the future.

of 125

7. Glossary

Term Description

After Presentation A term used to describe when the patient is present in the health service, i.e. on or after presentation. This enables health staff to validate Medicare and demographic details directly with the patient.

AS Australian Standard

B2B Business to business, a term used to describe the web service based functions implemented in the HI Service.

BDM Birth, Deaths & Marriages

Before Presentation A term to describe the period prior to a patient presenting at the health service, in which a referral may be received, an entry created on a waiting list, and an appointment made, with the appropriate notifications. The patient is not readily available to confirm their Medicare number or demographic details, though this can be done via telephone, email, letter, etc.

CCA A NEHTA group responsible for Compliance, Conformance and Accreditation.

CMS Community Management System

CPU Central Processing Unit

CSV Comma Separated Value

DHHS Tasmanian Department of Health and Human Services.

DOB Date of Birth

DoH Victorian Department of Health

DoS Denial of Service, a common method of attacking a website, or web service.

DVA Commonwealth Department of Veterans’ Affairs

EAI Enterprise Application Integration, such as provided by a tool such as Oracle Sun JCAPS.

ED Emergency Department

EOI Evidence of Identity

Episode A single admission to a health service for a particular condition or conditions, or

A period of care for a particular condition, often covered by a single referral (supporting multiple admissions or attendances).

ESB Enterprise Services Bus, an EAI solution that employs the Service Oriented Architecture and web services. Oracle Sun JCAPS provides this functionality.

eTP Electronic Transfer of Prescription

FoI Freedom of Information

GNAF Geocoded National Address File

HI Healthcare Identifier

HIM Health Information Manager, a specialist in the management of health information, including patient records.

HIS Health Information Service, a department within a health service that provides information management services especially for patient records.

HL7 Health Level 7, a widely accepted standard to support exchange of medical information, both administrative and clinical.

HPI-I Healthcare Provider Identifier – Individual. A unique number to be assigned to

of 125

Term Description

every person involved in healthcare service delivery.

HPI-O Healthcare Provider Identifier – Organisation, a unique number that will be assigned to all organisations involved in healthcare service delivery

HPOS Health Professional Online Services, a portal provided by Medicare Australia.

HSD The Victorian Human Services Directory

HealthSMART The Victorian Department of Health HealthSMART program is responsible for managing processes to select, configure and implement applications to reflect state wide requirements (state wide footprint) into participating healthcare agencies. Additionally, the HealthSMART program is responsible for establishing and managing the shared ICT infrastructure that is required to support these applications and agencies use of them.

ICT Information and Communications Technology

ID Identity or identifier

Idempotent A transaction is idempotent if it can be sent many times but is actioned / processed only once. Duplicate transactions have no (additional) impact on the state of the data or service.

IDL Initial Data Load

IEC International Electrotechnical Commission, an international standards body which focuses on electrical, electronic and related technologies.

IHI The Individual Healthcare Identifier, which Medicare Australia allocated to every active Medicare and DVA enrolee, on the 1st July 2010.

IHI Record Status There are three record statuses of IHIs: • Verified • Unverified • Provisional

IHI Status There are five IHI Statuses of IHIs:

• Active • Deceased • Retired • Expired • Resolved

IIN Issuer Identification Number

IP Inpatient

Also Internet Protocol

IPSec Internet Protocol Security, a standard for security at the network / packet processing layer.

IRN Individual Reference Number, used on the Medicare card to identify each individual whose name appears on the card.

ISO International Standards Organisation

JCAPS Java Composite Application Platform Suite

MSO Medicare Service Operator

NASH The National Authentication Service for Health (NASH) project being delivered through NEHTA will deliver the first nationwide security service to enable healthcare organisations and individuals to exchange e-health information.

NEHTA National eHealth Transition Authority

NHCIOF National Health Chief Information Officer Forum, a key e-health governance body

of 125

Term Description

NOC Notice of Connection, Medicare Australia’s testing regime to support those wishing to connect to the HI Service

NOK Next of Kin

OID Object Identifier

OP Outpatient

OPD Outpatient Department

P&CMS Patient and Client Management System, also abbreviated to PCMS.

PAS Patient Administration System – a system used for the recording of patient and provider information to support management and coordination of service provision. Within HealthSMART this functionality is provided by either a consolidated Patient and Client Management System (P&CMS) through the iSOFT i.PM application, or Community Management System through the Trak application for stand-alone metropolitan community health centres.

PCEHR Personally Controlled Electronic Health Record.

PKI Public Key Infrastructure

QAS Generally used to refer to an address management solution, that matches a user entered address with one structured according to the Australia standard.

Also the name of a company that developed address management software.

Referral A referral is defined within the Australian standard as “the communication with the intention of initiating patient/client care transfer, from the provider making the referral (the originator) to the provider expected to act on the referral (the destination)."

In the context of this document a referral is used as a representative health service request or report, and the reader should consider Orders (pathology, diagnostic imaging, etc), discharge summaries, etc.

SLA Service Level Agreement, a contractual agreement that defines the required levels of services required from a vendor/supplier. For example, a common SLA may define that the system be available 98% of the time, and 100% of the time during working hours.

SSL Secure Sockets Layer, a means of securing TCP/IP traffic.

TDS Trusted Data Source, which refers to Medicare Australia and the Commonwealth Department of Veterans’ Affairs in the initial allocation of IHIs within the HI Service.

In the context of the IHI Pre-Implementation project, an organisation participating in e-health messaging, who has met the compliance/accreditation criteria, is also referred to as a trusted data source.

TLS Transport Layer Security, messaging security implemented at the transport layer rather than at the message layer.

UC Use case, part of the UML standard used to document tasks or business process steps.

UML Unified Modelling Language. An international standard for documenting the design of an application.

URN Unit Record Number, a patient identifier typically used in large health services. May also be referred to as the Medical Record Number.

VPHS Victorian Public Healthcare Sector

WSDL Web Services Description Language

of 125

8. Appendix 1 – Search Criteria All fields submitted as search criteria are mandatory unless otherwise noted.

Search Criteria (example) Returned Fields

(Search with TDS identifier)

• Medicare Number, or DVA File Number • Medicare Number IRN (Optional)16 • Family Name • Given Name 1 (Conditional)17 • Sex • Date of Birth • Health service reference identifier

• IHI Number • IHI Record Status • IHI Status • Medicare Number • IRN (only included when entered in the search

criteria) • Family Name • Given Name 1 (Only when first name is

recorded and entered as search criteria) • Sex • Date of Birth • Birth Date Accuracy Indicator • Health service reference identifier

(Search without TDS identifier)

• Family Name • Given Name 1 (Conditional) • Sex • Date of Birth • Address Fields: (Any of the following

fields) – Address18 – Locality – Postcode – State – International Address – International State/Province – International Postcode – Country

• Health service reference identifier

• IHI Number • IHI Record Status • IHI Status • Family Name • Given Name 1 (Only when first name is

recorded and entered as search criteria) • Sex • Date of Birth • Birth Date Accuracy Indicator • Health service reference identifier

(Check an IHI using IHI)

• IHI number • Family Name • Given Name 1 (Conditional) • Sex • Date of Birth • Health service reference identifier

• IHI Number • IHI Record Status • IHI Status • Given Name 1 (Only when first name is

recorded and entered as search criteria) • Family Name • Sex • Date of Birth • Date of Birth Accuracy Indicator • Health service reference identifier

(Check an IHI using TDS identifier)

• Medicare Number of DVA File Number • Family Name • Given Name 1 (Conditional) • Sex

• IHI Number • IHI Record Status • IHI Status • Given Name 1 (Only when first name is

recorded and entered as search criteria)

16 Note that the IRN field is not captured universally, and nor can all PAS type applications store the IRN. The IRN is most commonly entered into a system manually (it is not electronically scannable), and hence is susceptible to human errors.

17 The given name should be included where it is available, with the project team’s recommendation to use the given name in preference to the IRN. Note that the findings from the IHI Matching Investigation recommend submitting one given name only in an IHI search.

18 Street address may become optional if the requested change to the HI Service is approved and implemented.

of 125

Search Criteria (example) Returned Fields

• Date of Birth • Health service reference identifier

• Family Name • Sex • Date of Birth • Date of Birth Accuracy Indicator • Health service reference identifier

of 125

9. Appendix 2 – IHI Matching The Victorian IHI Integration project team contributed to the ACT IHI Matching Investigation project, conducted in 2010 by IBM/Initiate. The Victorian input to the project is included below, and is recommended as an IHI match confirmation test as Victorian health services begin to adopt the IHI.

The full suite of searches and analyses are recommended for use by at least one Victorian major public health service, and a number of GP practices.

9.1 Requirements The IHI Integration project team has identified a suite of requirements for a trial IHI matching exercise, and including tests applicable to a GP practice or practices. This is because GP practices, once they have adopted the IHI, will be a primary source of IHIs for a health service, through the inclusion of the IHI on referrals and similar.

Understanding the current state of IHI matching within the GP domain may be an important future consideration for health services.

9.1.1 Assumptions and Constraints The list of assumptions and constraints below is intended to be challenged and the item either confirmed or removed.

The IHI Integration project team has identified the following assumptions and constraints:

1. Depending on when the initial matching investigation is conducted, the HI Service database may contain records with various IHI Record Status (Provisional, Verified, Unverified) or IHI Status (Resolved, Deceased, etc). The assumption is that the vast majority of records will have an IHI Record Status of Verified, and an IHI Status of Active.

2. Initial data cleansing / review of data to be submitted to the HI Service is not mandated. Profiling would however be beneficial (see section 9.2.1).

3. Only data submitted to the HI Service will be returned, other than the IHI, the data of birth accuracy indicator, or error/informational messages (see Appendix 1). For example, if the first name of the patient is not included in the submitted data, the first name will not be included in the returned data.

4. Medicare recommends using the TDS identifier search where a Medicare number or DVA file number is available, and using minimal data elements. Victoria’s recommendations for data to be used in IHI searching are in section 6.6.2.

5. For the demographic search (no TDS identifier) a complete Australian address must be provided in the format specified by the Australian Standard (AS 4819), ie unit number, unit type, level, street number, lot number, street name, street type, street type suffix, suburb, state, postcode, country etc.

a. Victoria does not have data in this format, and would therefore not be able to use the address based searching facility

b. Parsing address data in an attempt to produce the required format is impractical and subject to error

c. Address line 1 and 2 are not supported for Australian addresses.

d. Suburb, postcode, state and country cannot currently be provided without the other address data.19

6. For the full demographic search the address fields will not be returned.

7. If a reference key is provided in a record submitted to Medicare, this key will be returned in its original state to the originating health service.

19 Note that there is a change request under consideration by Medicare Australia and NEHTA to relax the rules for the street address structure used for IHI searching, to enable use of locality, state and/or postcode instead of the complete address.

of 125

8. This exercise will be conducted on a replica of a PAS patient master file, rather than using live data. This eliminates the risk of change to the primary data source while the matching exercise is underway.

9. The HI Service supports two main IHI search types (TDS and demographic), with the basic data elements defined in Appendix 1.

10. The HI Service supports two main IHI check service contracts, with the basic data elements defined in Appendix 1 (one is equivalent to a new IHI search using a TDS identifier).

11. Based on Victoria’s understanding of a previous data analysis of the Medicare database, a unique record is returned given search criteria of family name, given name, date of birth, sex, and either one of suburb or postcode.

12. The HI Service will iterate through all recorded aliases. There is no guarantee that these will match any patient aliases recorded in the PAS.

13. To submit PAS stored patient aliases to the HI Service, the alias field data (family name, given name) must be placed in the family name and given name fields in the HI Service search request. Separate alias fields are not supported.

14. The HI Service will not inform the calling application or user that the match has been achieved against an alias.

15. Records of people either flagged as deceased, or likely to be deceased, shall be included in the data submitted to the HI Service, though there will be no useful data returned.

16. The health service reference number field shall be used to compare IHI matching results for individual patient records across the multiple test scenarios.

17. Inclusion of the Medicare IRN requires discussion. From a Victorian perspective iSOFT i.PM does not store the IRN, and for systems that do it is typically entered manually by the operator, so Victoria recommends excluding the IRN from the submitted search field list.

18. The HI Service does NOT accept a date of birth accuracy field as one of the search fields.

19. Victoria suggests excluding patient records of foreign nationals, as they should not have a record in the HI Service database.

20. There is no HI Service production like environment available for testing, so all IHI match testing must be conducted against the production system. This means that all IHI searches will be visible to the individual.

9.1.2 Data Requirements The core dataset to be extracted from a PAS, EMPI or equivalent is listed in section 0 below.

It is important that the data submitted to the HI Service as part of this investigation reflect a number of important requirements, including:

• Strong representation of ATSI people;

• Broad representation of people from Culturally and Linguistically Diverse (CALD) backgrounds, including cultures in which the name order is reversed (i.e. family name typically stated first);

o Should also include representation of cultures with single names only (e.g. some parts of Africa), and extremely long names (e.g. Thailand).

Core Data Set

The following data is required to be extracted from patient records in the PAS:

1. UR Number, or other identifier

2. Family name

3. First name

4. Date of birth

5. Medicare number

of 125

6. DVA file number

7. Street address (Residence)

a. unit number,

b. unit type,

c. address site name

d. level number,

e. level type

f. street number,

g. lot number,

h. street name,

i. street type code,

j. street suffix code,

k. suburb,

l. state,

m. postcode,

n. country

8. Record created date

9. Record last updated date

10. Last patient presentation date

Optional fields (to be considered)

11. Date of death (if applicable)

12. Deceased indicator (if applicable and available)

13. Culturally and Linguistically Diverse (CALD) status (if available)

14. Aboriginal and Torres Strait Islander (ATSI) status (if available)

Use of historical names and aliases, and alternate addresses for IHI searching was not recommended by IBM, following the ACT IHI Matching Investigation. The recommendation from the Victorian IHI Integration project team is to conduct at least one batch IHI matching exercise, eg for one Victorian health service, in which all permutations and combinations of patient data is submitted to the HI Service for IHI matching. The results should be analysed comprehensively, and results made available to stakeholders.

9.1.3 Primary Test Scenarios As an extension to each of the test scenarios below it is recommended that the original data be submitted to the HI Service at least twice and the results compared. This will give us a high degree of confidence in the results obtained.

IHI Match Using TDS Identifier

In this case the HI Service TDS search will be executed for matching and return of IHIs. This will process all records in the PAS with available Medicare numbers or DVA file numbers. This approach to locating an IHI is recommended by Medicare.

Submitted information shall include:

• Medicare number or DVA file number, where available

o Medicare number to be used when both are available (?)

of 125

• Family Name

• Given name

• Date of birth

• Sex

• Health Service reference number20

Measures:

• Report on match ratio achieved

• Report on variations, if any, between multiple submissions of the original data set

• Usefulness of error or informational messages returned

• Includes handling of data from deceased patients submitted

• Report on any duplicate IHI allocations (ie multiple submitted patient records, with the same IHI returned)

• Report on any inconsistencies in IHI allocation, ie multiple patient records, with the same IHI returned

• Turnaround time (source to Medicare and back to source – factoring in transport time)

• Processing time (time within the HI Service to complete the matching process)

• Measured ability to re-link returned IHIs with the original patient record (not against production system).

IHI Match with Demographic Search

This scenario will process all patient records, ie including those with Medicare Numbers and/or DVA File Numbers, using the full demographic search. This will only be possible for jurisdictions with patient address data in the required format.

The information submitted shall include:

• Name (family name and given name)

• Date of birth

• Sex

• Street address, as defined above, optional if the HI Service change has been implemented

• Suburb

• State

• Postcode

• Country

• Health Service reference number

A relatively straight forward analysis can be employed to deliver the match ratio on the first pass.

Measures:

• As for scenario 1 above

• Number of records matched for patient records without a Medicare Number or DVA File Number

• Number of records matched using a purely demographic search for patient records with a Medicare Number or DVA File Number

• Report on the intersection of matches and non-matches for patient records with Medicare Numbers or DVA File Numbers

• Exception report for any situations where a different IHI is allocated to the same patient record

20 There needs to be a simple mechanism to enable updating of the (correct) patient record in the PAS with the retrieved IHI. The health service reference number may be the PAS UR number or equivalent if permitted by privacy legislation, or a random reference number allocated by an intermediate process.

of 125

Iteration through Aliases in TDS Identifier Search

This scenario is similar to scenario 1, except that the data submitted to the HI Service will include all alias and address variations, though only for records with a TDS identifier. For example, for a patient record with 4 aliases and 3 address, 15 (5 x 3) separate records would be submitted to the HI Service. The same health service reference number would be used for all 15 records, ie this number reflects the actual record in the PAS.


• Medicare number or DVA file number, where available

o Medicare number to be used when both are available (?)


• Date of birth

• Sex


Measures:

• As for Scenario 1 above

• Report on match ratios obtained using aliases and/or alternate addresses

• Report on multiple IHIs returned for one patient record

• Report on duplicate IHIs returned for different patient records

• In this scenario the turnaround times may also be of particular importance, as they potentially reflect the real world HI Service search implementation.

Iteration through Aliases in Demographic Search

This scenario is similar to scenario 2, except that the data submitted to the HI Service will include all alias and address variations, for all records. For example, for a patient record with 4 aliases and 3 address, 15 (5 x 3) separate records would be submitted to the HI Service. The same health service reference number would be used for all 15 records, ie this number reflects the actual record in the PAS.



• Date of birth

• Sex

• Street address

• Suburb

• State

• Postcode

• Country


Measures:

• As for Scenario 1 above

• Report on match ratios obtained using aliases and/or alternate addresses

• Report on multiple IHIs returned for one patient record

• Report on duplicate IHIs returned for different patient records

• In this scenario the turnaround times may also be of particular importance, as they potentially reflect the real world HI Service search implementation.

Variations in Search Criteria

of 125

A range of other possible options may be worth investigating, if supported by the HI Service and by legislation, with the following being of interest:

• Excluding the street address line from the submitted data in a full demographic search (if some relaxation of the HI Service business rules is achieved)

• Excluding the patient’s given name from the submitted search fields, though one would expect that this would produce a high level of duplicates, and hence many “refine your search parameters” messages being returned

• Exclude either one of (suburb + State) or postcode, as they should be redundant

Submitted information depends on the type of search selected, based on data already provided above.

Measures:

• As above

• Compare IHI match successes and failures with results achieved above

o Exception reporting including different IHI allocations to the same patient record

IHI Checking Using Acquired IHI

In this scenario, we execute the HI Service IHI check routine and confirm that results match in accordance with our expectations.

For all records that have received an IHI, submit the following information to the HI Service to confirm that the IHI can be confirmed:

• IHI number

• Family Name

• Given Name 1 (Conditional)

• Sex

• Date of Birth


Measures:

• As for scenario 1 above (processing time is especially of interest given the lack of a publish – subscribe model in the HI Service, i.e. the PAS/EMPI will need to poll the HI Service to obtain any changes in IHI Record Status and Status)

• To report on all successful and unsuccessful matches from the above

o IHI Record Status and IHI Status variations to be reported upon

IHI Checking Using TDS Identifier

In this scenario, we execute the HI Service IHI check routine using the alternate data items and confirm that results match in accordance with our expectations.

For all records that have received an IHI, submit the following information to the HI Service to confirm that the IHI can be confirmed:

• Medicare Number or DVA File Number

• IRN (optional)

• Family Name

• Given Name 1 (Conditional)

• Sex

• Date of Birth


Measures:

of 125

• As for scenario 6 above

• Include comparison of results between the two data scenarios

9.1.4 GP Test Scenarios In this section Victoria proposes a group of test scenarios relevant to GP practices. The quality of GP stored patient data and their ability to reliably match their data with the HI Service to obtain IHIs will be an important measure for hospitals, affecting the hospital’s ability to trust information flowing to them from GPs.

Victoria expects that the IHI matching investigation on GP data will be conducted by NEHTA or their nominated representative, and will not impact the work to be undertaken on data from a State based EMPI or major hospital PAS.

Victoria suggest that a representative sample of GP practices could be selected to be involved in the investigation, including small, medium and large practices, all of whom will have to be IT enabled. Inclusion of a rural or remote practice would be beneficial.

The following test scenarios, described more fully above, are recommended for GP practices

• IHI Match Using TDS Identifier

• IHI Match with Demographic Search21

• IHI Checking Using Acquired IHI

• IHI Checking Using TDS Identifier

There will be no direct analysis or data level comparison of IHI matching results obtained by a health service (or EMPI) with those obtained by a GP practice (though the results would be extremely valuable).

Measures:

• Report on match ratio achieved

• Report on variations, if any, between multiple submissions of the original data set

• Usefulness of error or informational messages returned

• Includes handling of data from deceased patients submitted

• Report on any duplicate IHI allocations (ie multiple submitted patient records, with the same IHI returned)

• Report on any inconsistencies in IHI allocation, ie multiple patient records, with the same IHI returned

• Turnaround time (source to Medicare and back to source – factoring in transport time)

• Processing time (time within the HI Service to complete the matching process)

• Measured ability to re-link returned IHIs with the original patient record (not against production system).

21 Only applicable for GP practices with address data in the correct format, or when the HI Service search rules are relaxed to just allow locality, postcode, state and country fields to be included.

of 125

9.2 Analysis There would be value in having two levels of analysis, as described below.

9.2.1 Data Profiling (PAS or EMPI) The preliminary analysis, to occur prior to the IHI matching exercise, is conducted on the data from the PAS or EMPI that will be submitted in batch to the HI Service. This should include:

1. Broad based records analysis, including number of records, number of deceased records, etc.

2. Analysis of records by Medicare number field:

a. 10 digit numbers

b. 11 digit numbers

c. No number recorded

d. Another format number recorded

3. As above but for DVA number

4. Analysis of active vs inactive records, including records of deceased people

5. Analysis of records with one or more aliases and one or more recorded addresses.

a. Breakdown by number of aliases and number of addresses, to enable us to gauge the number of records that we would submit to the HI Service if we wanted to submit all potential data options.

6. Uniqueness investigation. Using parameters equivalent to each scenario above22, determine the likelihood of achieving a unique result within the PAS environment only, i.e. a single record only returned. For example, for the test including {Medicare #, name (family name and given name) DOB, sex} this should ideally return exactly the same number of rows as exist in the patient master database. Any duplication will result in problems allocating the IHI; ie which record do you allocate it against?

7. Provide a breakdown (or distribution) by number of records returned, e.g. for a query against a PAS with one million rows

a. Unique record returned: 990,00023

b. Two records returned: 9,000

c. Three records returned: 900

d. Four or more records returned: 100

8. We are not interested in the details of the actual records that produce duplicate results, but simply the fact of multiple rows being returned for the one query.

9. Provide an overall measure of the impact, eg using criteria x we achieved a 99.0% unique result (or 3.0% duplicates).

22 Note that the data returned from an HI Service full demographic search does NOT include the address details, so depending on the process to be used and the reliance to be placed upon the health service reference identifier, the PAS data analysis should include this returned set of data items.

23 Numbers chosen are purely fictitious.

of 125

9.2.2 IHI Matching The second analysis component examines the results of the IHI matching exercise, reporting on the measures mentioned above, as well as a comparison of the (different) results achieved using the different search parameters. As follows:

1. Report on match ratio achieved in all scenarios;

2. Report on variations, if any, between multiple submissions of the same data set to the HI Service;

3. Report on the errors and information returned, including a qualitative analysis of its potential usefulness within a health service context;

4. Report on processing and turnaround time achieved for all scenarios;

5. Report on the ability to re-link returned data to the original record, and any inconsistencies at a field level;

6. Report on ALL exceptions in the allocation of IHIs against records, but most especially:

7. Different IHIs allocated to the same “record” under differing search conditions;

8. Different patient records with the same IHI allocated;

9. Report (at the count level) on matches by record across all scenarios at the summary level, e.g.:

a. Number of records matched with same IHI across all scenarios;

b. Number of records matched using aliases and/or alternate addresses;

c. Breakdown (count) of partial matches by scenario, e.g. in a table;

d. Number of records matched with different IHIs (exception condition);

e. Number of single patient records matched with different/multiple IHIs (exception condition);

f. Number of different patient records with the same IHI allocated (exception condition);

g. Number of records unmatched against any scenario:

h. Breakdown of error and informational messages provided;

i. Provide breakdown by record currency, using one of the record last updated, record created, or date of last presentation fields:

j. May require some analysis to determine which field provides the most statistically relevant result;

k. Report on the results obtained from the Check IHI function, comparing the Check IHI with the original allocated, and also comparing the results for the two scenarios.

ihi pre-implementation project solution architecturedocs2.health.vic.gov.au/docs/doc...initiative....

Documents