HealthSMART Design Authority. IHI Pre-Implementation Project. Solution Architecture. Department of Health

Transcription

1 HealthSMART Design Authority IHI Pre-Implementation Project Solution Architecture Department of Health

2 Authorised by the Victoria Government, Melbourne. To receive this publication in an accessible format Copyright, State of Victoria, Department of Health, 2011 Page 2 of 125

3 Table of Contents 1. Document Overview PURPOSE SCOPE ASSUMPTIONS CONSTRAINTS INTENDED AUDIENCE REFERENCES Introduction CONTEXT SOLUTION VISION IMPLEMENTATION CONSIDERATIONS Architecture Drivers ARCHITECTURAL PRINCIPLES ARCHITECTURAL CONSTRAINTS ARCHITECTURAL RISKS ARCHITECTURAL OPTIONS Current State Overview HEALTHSMART BUSINESS AND ORGANISATIONAL CONTEXT PATIENT IDENTIFIERS RELATED PROJECTS HI SERVICE SUMMARY IHI OVERVIEW Solution Overview SOLUTION OBJECTIVES SOLUTION DEPENDENCIES Solution Architecture Definition ARCHITECTURAL ASSUMPTIONS GENERAL ARCHITECTURE PRINCIPLES ARCHITECTURAL CONCERNS RAISED BUSINESS ARCHITECTURE APPLICATION ARCHITECTURE INFORMATION ARCHITECTURE REPORTING ARCHITECTURE TECHNOLOGY ARCHITECTURE SECURITY ARCHITECTURE Glossary Appendix 1 Search Criteria Appendix 2 IHI Matching REQUIREMENTS ANALYSIS Page 3 of 125

4 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 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 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. Page 4 of 125

5 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 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 v Any changes to the HI Service Specifications since release may not be fully reflected in the design and architecture. Page 5 of 125

6 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 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 Page 6 of 125

7 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 Page 7 of 125

8 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. Page 8 of 125

9 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. Page 9 of 125

10 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. Page 10 of 125

11 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. Page 11 of 125

12 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 o o o HI Service response times Transport and message preparation times Retries in the event of an error, and associated time delays 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 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. Page 12 of 125

13 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. Page 13 of 125

14 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) 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. Page 14 of 125

15 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 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. Page 15 of 125

16 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 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. IHI Functional Profile Reporting Exception Mgmt Systems Mgmt Security Common Application Behaviours Common User Behaviours Common Verified IHIs Inputs All IHI Record Statuses accepted Unverified IHIs Provisional IHIs Outputs including the IHI Search for an IHI Notify of Duplicate Update Unverified Create Unverified Create Provisional ereferrals Check IHI (Vic design) Notify of Replica Update Provisional Print Patient IHI Advice Admission & Discharge docs Receive all IHI types on Referrals, etc Update Verified IHI (Date of Death) Resolve Provisional Merge Letters Online Batch Search Resolve Provisional Create Unverified Orders Offline Batch Search Prescriptions Send Service Request (Vic design) PCEHR Legend Functions required for base systems Optional functions (for all systems) Not yet implemented In the HI Service Functions required to support Unverified IHIs Functions required to support Prov al IHIs Selected functions may be implemented 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 Page 16 of 125

17 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 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. Page 17 of 125

18 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 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. Page 18 of 125

19 Recommendations: This limits the number of TLS negotiations that must occur, and makes better use of an established connection. 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 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. Page 19 of 125

20 4. Current State Overview 4.1 HealthSMART Business and Organisational Context The information below is reproduced from the HealthSMART website at 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 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. Page 20 of 125