Enterprise Architecture

Integrated Clinical Information Program (ICIP) Architecture Review - Final Report Summary

August 2004

OVERVIEW .................................................3 OBJECTIVES AND APPROACH ...........................3 GOAL STATE DRIVERS, BUSINESS NEEDS ..............8
GUIDING PRINCIPLES ........................................ 8

ARCHITECTURE OPTIONS ................................9

ASSESSMENT CRITERIA ....................................... 9 EMR SOLUTION COMPARISON ................................. 10 FRAMEWORK FOR VENDOR COMPETITION .......................... 11 COMMUNITY HEALTH ....................................... 12 OTHER LEGACY AND SPECIALIST SYSTEMS .......................... 12 SUMMARY OF HIGH LEVEL ARCHITECTURE RECOMMENDATIONS ............ 14

GOAL STATE ARCHITECTURE ......................... 15

INTEGRATION PRIORITIES .................................... 17

ICIP ROADMAP .......................................... 21 IMPLEMENTATION STRATEGY ......................... 22

1. ICIP GOVERNANCE AND THE HEALTH PRIORITIES TASKFORCE ........... 23 2 A CORE / STATE-STANDARD BUILD STRATEGY .................... 23 3 TECHNICAL ARCHITECTURE AND EAI FOUNDATIONS .................. 24 4 DEPLOYMENT OF SYSTEMS FROM CLINICAL HUBS ................... 24 5 PROJECT MANAGEMENT OFFICE AND IMPLEMENTATION ASSISTANCE FROM INDUSTRY .................................................... 25 6 FLEXIBILITY TO AHS BOUNDARY CHANGES ........................ 26 7 ALIGNMENT WITH EXISTING FUNDING ........................... 27 SUMMARY OF IMPLEMENTATION STRATEGY RECOMMENDATIONS ............ 27

NEW ICIP INITIATIVES AND IMPACTS ON EXISTING INITIATIVES.............................................. 29

IMPACTS ON EXISTING INITIATIVES ............................... 29 NEW ICIP INITIATIVES ...................................... 30

RISK MANAGEMENT..................................... 32 RECOMMENDATION SUMMARY ........................ 34

ICIP Architecture Review Page 2

Overview
The ICIP architecture review was initiated to identify opportunities to accelerate the deployment of core clinical systems across NSW to address the major priorities being tackled by NSW Health in the clinical services reform program. These priorities include: Managing access block Occupancy rates and bed capacity Effective management of the patient at all stages of the patient journey, whether between sections of a hospital or across the continuum of care from acute to community based (public and private) services Improved patient safety and reduction in adverse events Reducing off stretcher times Improved patient satisfaction in their journey through health and in the interfaces between services. The IM&T program has to be implemented in a way that allows the key systems to be implemented to address the current problems and priorities, while providing the foundation for clinical functionality across all Areas to support the delivery of health services at all points of the patients journey across the system. This includes systems to support: access to critical patient information from across the public and private sector delivered to any service the patient accesses; effective referrals between services; smooth transition of patients from hospital to community based care, residential care or general practice; a single point of access to key results within an Area to prevent duplication of diagnostic tests; integrated care processes implemented by multiple clinical professionals working as part of a multidisciplinary team; making navigation through health easier for the patient; effective management of patient flow and the alignment of supply and demand improved safety and quality. The review identified the following ICIP strategies to be accelerated to address the major problem areas and reform priorities: implementation of a patient centric area wide repository in all Areas to support shared access to medical records to all clinicians in an Area; evaluation of alternative Clinical Information Systems to introduce choice and drive competition; extended roll out of CHIME to give wider access to community health information, with evaluation of alternative products to support the migration to a single patient repository; establishment of a Health Service Provider Directory to support referrals between services; development of a strong integration capability to manage the exchange of information between health services and simplify the management of the Electronic Health Record.

Objectives and Approach

NSW Health initiated the ICIP review in response to the report by the Independent Pricing and Regulatory Tribunal (IPART) in August 2003 and the October 2003 review of the IM&T Strategic Plan. The IPART report reinforced the strategic direction set in 2000 by the Health Council, and emphasized the need for IM&T to be implemented in a
ICIP Architecture Review Page 3

way that supported more integrated service delivery, better quality care and improved patient safety and more integrated performance management. The focus of the ICIP review was to ensure that the IM&T program as it is currently defined could support clinicians in providing high quality and safe care at all stages of the patient journey. The IPART report highlighted the imperative to implement the core ICIP systems in a timely manner, and to reassess implementation and integration opportunities and risks. The review has focused on the opportunities to ensure ICIP is aligned and able to respond to the needs of NSW Health and adapt to evolving models of care. The report recommends strategies to accelerate the implementation of core functionality across the state building on the existing investment. The report also recommends that greater value can be obtained by introducing more competition into the marketplace. The objective of the ICIP Architecture Review Project is to define an overall architecture and set of strategic initiatives to guide NSW Healths development of state-wide clinical systems over the next 5-7 years. A comprehensive approach has been taken across a 20 week project, reviewing current Department and Area Health Service (AHS) performance in delivering the program, designing a future goal state architecture and defining implementation plans, required investments and models for shared governance moving forward.

Figure 1: High Level ICIP Architecture Review Approach The Key deliverables of the process were: A Current State Assessment reviewing current clinical technology performance across a range of areas including: business, process, information, human, application, technical and implementation; The definition of an ICIP architecture that can be applied at a practical level to support the implementation of the Electronic Health Record and clinical systems at the point of care; High level assessment of alternative implementation options for programs within the ICIP environment across NSW Health; Review and refinement of existing principles and standards to support selection and delivery of new ICIP solutions, including guidelines for implementation of strategic solutions to meet the patient safety and quality of care objectives of NSW Health;

ICIP Architecture Review Page 4

Identification of practical, achievable implementation plans and the appropriate functional focus to meet the business goals of Area Health Services and the Department and integrated existing initiatives with revised strategies; Revised governance strategies for balancing business needs with architecture design requirements; Systems Integration and delivery strategies guiding overall integration infrastructure and operating platforms High level funding estimates for near term initiatives Risk management strategies.

ICIP Architecture Review Page 5

Current State Findings

A detailed Current State Assessment (CSA) of existing ICIP strategies has been conducted across the Department and four AHSs, with further documentation review for the remaining AHSs. The CSA identified critical issues, shared priorities, relative maturity of clinical systems and lessons learnt from previous implementations. Effort has been duplicated and there is little reuse of technology assets The key findings from the current state assessment were as follows:

1. No long-term clinical architecture currently exists for ICIP

NSW Health recognises the importance of a long-term architecture that provides an integrating framework for ICIP. The ICIP Review project was commissioned largely in recognition of this need. Because no long-term architecture currently exists, differing architectures and approaches have evolved from various AHSs that have sought to define their own direction. In addition, AHSs seeking direction from the Department have become frustrated, as no commonly shared approach was available. Effort has been duplicated in the resolution of similar problems and there is limited reuse of technology assets.

2. There is a disconnect between Healths business and technology strategy

While models of care will continually evolve, NSW Health has a clear, high-level vision that is not likely to change significantly over time. The key tenants of healthier people; providing quality care; creating equity of access and improving effectiveness and efficiency were as relevant five or ten years ago as they will be in 2010. The challenge for NSW Health has been to effectively translate this high level vision into practical objectives that guide the year-to-year operating priorities of the ICIP strategy. As such, ICIP has been managed a series of projects, rather than one integrated program. While these projects generally hang together as a reasonable overall strategy, they lack a focused and shared strategic rationale for clinical systems investment. Perhaps because of this, funding of these projects has been inadequate over time and many initiatives have stalled, losing momentum due to lack of financial support at both a State and Area level. At times, the governance model for ICIP programs has also varied from very AHS centric to very Department focused. The ongoing success of ICIP will depend heavily on consistent and shared governance processes that balance front line business needs with shared standards and architecture. Patient flow blockages occurring within and across care settings (both public and private) are exacerbated by a lack of integration between patient management and clinical systems. From an acute perspective, the flow of data from the Emergency Adequate sharing of Department to the inpatient setting and required specialties has not been achieved in patient information many hospitals. With some notable exceptions (e.g. the electronic Discharge Referral between and within System) adequate sharing of patient information between and within settings is rare. settings is rare This situation has arisen as technology has been deployed to solve point problems, rather than support patient flow and a continuum of care. ICIP systems have also been deployed using different combinations of software hosted on different platforms. The resolution of current information gaps and overlaps will also better enable the proactive management of inter and intra-area patient flows. An accurate Health Service and Provider Directory (HSPD) and approach to common patient identification will also be critical to the success of ICIP. At present these capabilities vary in maturity and effectiveness across the AHSs.
ICIP Architecture Review Page 6

ICIP has not been managed as an integrated program and the governance model has varied over time

3. Current technology is increasing fragmentation within the system

A handful of AHSs have relatively mature and robust technology deployed from their major tertiary referral hospital, however from a state-wide perspective, the ICIP systems are deployed using different combinations of software hosted on different platforms. In the majority of areas, the current infrastructure is immature compared to industry standards, complex, not flexible and costly to operate. Although pockets of excellence exist across the State, there is currently no sense of a There is no sense of a state-wide foundation upon which clinical outcomes can be delivered and improved. state-wide Despite some successes, the overwhelming majority of AHSs are relatively immature in foundation upon the implementation of clinical systems. ICIP has had a mixed implementation record which clinical which has led to a perception of the existence of the haves and have nots, rather outcomes can be delivered and than being a centrally coordinated program. evolved There is also a feeling amongst AHSs that there has been inequity in the response to the different requirements of rural AHSs and Community Health services from a technology perspective.

4. The implementation of ICIP initiatives has been uneven

5. There is a degree of cynicism and frustration with the lack of progress

There is a perception among some AHSs that ICIP applications, in their current form, are too complex and costly (despite their potential value) to implement and that Health has a mixed track record of executing major, state-wide strategic projects. The current state assessment also identified inconsistent vendor management and lengthy program delays for many initiatives due largely to a lack of available funding. The need for an increased emphasis on human performance and change management within major implementation projects was also voiced by a number of AHSs.

ICIP Architecture Review Page 7

Goal State Drivers, Business Needs

Four strategic streams were defined: 1. Making it easier for the patient 2. Accelerating and improving clinical decision making and sharing of information across settings 3. Effectively managing patient flow and the alignment of supply and demand 4. Supporting and driving management accountability (including safety and quality) A major requirement for the Review was to more clearly articulate the business objectives that should drive the development priorities for ICIP. In pursuing this requirement the team consolidated a range of priorities into four major strategic streams or imperatives, each with specific measures (KPIs), each supporting a stack of clinical applications that should become core components of the goal state architecture. The four streams were defined as follows: 1. Making it easier for the patient 2. Accelerating and improving clinical decision making and sharing of information across settings 3. Effectively managing patient flow and the alignment of supply and demand 4. Supporting and driving management accountability (including safety and quality) These streams provide the conceptual framework for discussing the revised ICIP program and the inter-relationships between applications and projects. Not only must ICIP support these strategies within the current context, it must also be flexible enough to allow for (and perhaps accelerate) structural changes across the system. For example, increased emphasis on aged and chronic care and the emergence of new care models will require new approaches to information access and care coordination. The ICIP architecture will need to effectively balance the demands of local care teams for full clinical systems with the demands of connectivity and summary records. It will need to provide the common referencing and access capabilities to allow patient and provider information to be commonly identified and integrated. Finally, in order to support Healths business the ICIP Architecture needs to allow for any further changes in AHS and NSW Health governance constructs and to emerging trends in technology while remaining simple, scaleable and usable for health service providers.

Guiding Principles
With these business needs in mind, the following guiding principles for the implementation of the ICIP architecture have been developed: Provide stakeholders with a single, integrated view of patient information 1. In order to best support a continuum of care for patients, ICIP applications and technologies need to be deployed to provide stakeholders with a single, integrated view of patient information 2. The architecture and proposed initiatives will be aligned with clinical priorities and outcomes 3. The ICIP architecture will empower clinical decision making 4. The ICIP architecture will support the continuum of care across settings and AHS boundaries 5. Application choice will be maintained within an agreed framework at the AHS level to engender competition, meet differing needs across AHSs and reduce risk of provider lock-in 6. The ICIP architecture is designed to minimise the complexity and variety of systems that an individual clinician is required to use while still providing all necessary system functionality

ICIP Architecture Review Page 8

Architecture Options
The goal state architectures most important purpose is the construction, management and sharing of patient information in a secure and accessible way. The goal state In recommending a specific architecture to meet this requirement a number of options architectures most were considered, however, broadly, two architecture options were evaluated for the important purpose is the construction, ICIP goal state architecture: management and 1. a regional or area-based patient-centric data repository to store information, sharing of patient information in a built over time, fed by other specialist systems, or 2. portal-based technologies which dynamically query and access patient data at secure and accessible way the time of need using new integration technologies Both solutions assume that specialist systems still exist for acute point of care management, community health, patient administration, diagnostic support and other daily clinical system requirements. The key difference is whether a patients eMR is both stored in a consolidated repository and distributed throughout the specialist systems a consolidated eMR, or whether the information only exists in the specialist systems with the patient centric view being dynamically built at time of need - a distributed eMR. The use of a single repository for the entire state was discounted due to the cost and maintenance of the required infrastructure, the risks associated with consolidating mission critical information for the whole state, and the acceptance this level of change would require. There are broadly In addition to determining whether a repository or dynamic approach was preferred, two options NSW other important decisions in recommending an integrated architecture for NSW Health Health should were: consider an areabased patient-centric 1. The framework in which competition would operate data repository, or 2. How each of the major current systems would integrate with the architecture, portal-based in particular for Community Health technologies which 3. How systems governed by Local IT Initiatives (LITI), the Greater Metropolitan dynamically query Transition Taskforce (GMTT) and Toward a Safer Community (TASC) would be and access patient impacted data

Assessment Criteria
The following criteria were used in the assessment of the two underlying solutions (referred to from this point onward as 1. Single region-wide patient repository and 2. Portal-based web services architecture): Key Business Criteria Support for a single view of the patient facilitation of clinical information sharing across settings Ability to accelerate clinical decision making (e.g. Decision Support) Ability to manage patient flow Patient and technology risk Facilitation of better access for patients, health service providers and management Total solution cost

ICIP Architecture Review Page 9

Flexibility to IMTB change, AHS boundary re-alignment, trends in technology and new models of care

Key Technology Criteria Performance and scalability Levels of required maintenance (application and integration) Solution readiness and maturity for NSW Healths scale of operation Ability to support for clinical intelligence (analysis not necessarily real-time at the point of care) Usability Consistency with the national HealthConnect architecture

eMR Solution Comparison

Option 1: Single region-wide patient repository
A single, region-wide patient repository best enables a single view of the patient across settings, the tracking of clinical pathways and the facilitation of referral management Option one progressively builds an electronic medical record (eMR) for select patient information across a region, regardless of the setting in which interactions occur. For example, an area-wide patient repository could store detailed radiology and pathology results, admission-discharge-transfer records and discharge referral summaries from interactions with acute settings and notes, assessments and referrals from communitybased interactions. This option best enables a single view of the patient regardless of setting, the adherence to clinical pathways and the facilitation of referral management. By using the repository as the basis for clinical information system across tertiary district, community and rural services, care providers from across the continuum have access (managed by appropriate security) to a patients complete eMR rather than facility/service-based slices of it. Because critical results and clinical documentation are stored in one place, acute discharge and community-based referrals are more easily facilitated A clinical information system (CIS) is mission critical for Health. A repository approach minimises the risk of information not being available to support clinical decisions. Rather than attempting to access information dynamically, an architecture based on a clinical repository stores all this information in the one highly available place with both site-based and cross area redundancy built-in. While trends in connectivity are evolving and web-services appears to be a clear future direction, the deployment of clinical systems using a patient repository as the underlying foundation is a proven and mature solution in NSW (for example Central Sydney and Western Sydney AHS), Australia (South Australias state-wide OACIS solution) and globally (particularly in large integrated delivery networks in the United States). The deployment of clinical systems using a patient repository as the underlying foundation is a proven and mature solution Further, a patient repository does not inhibit the adoption of these new technologies in the future (in fact it enables them). However a key consideration for ICIP is the need for practical, commercially proven solutions that can be implemented in the short term and flexible enough to adapt to future trends in technology. Deployment of the architecture also allows Health to consider delivering applications though clinical hubs. Because economies of scale can be achieved through this architecture approach, a more strategic investment in infrastructure can be targeted. Areas or regions that either do not wish to run their own clinical information systems, or do not have the capability to do so, can rely on the services of IT service providers, including other Areas, with more mature technology capabilities. This arrangement also serves as a progression point for the standardisation of clinical applications.

ICIP Architecture Review Page 10

The deployment of clinical applications based on a patient repository also creates significant efficiencies in terms of integrating with state-wide solutions for an electronic Health Record (eHR) and the master Health Service and Provider Directory (HSPD). Rather than having the state-wide eHR integrate directly with multiple source systems within an AHS, event summary interfaces will be greatly simplified through the use of a single repository. Another advantage of the clinical repository is the ability to facilitate extracttransform-load capabilities for data warehousing and clinical reporting. A repository achieves Finally, a repository achieves something everywhere for all Health settings. By something rolling out area or region-wide patient for personal information, results, notes, everywhere for assessments and referrals, Health achieves a common base upon which to extend levels all Health settings of maturity and to build on and create momentum.

Option 2: Portal-based web services architecture

Option Two builds an electronic medical record (eMR) dynamically from the information stored in legacy and specialist systems at the time of need. For example, should a clinician need to access pathology and pharmacy information for a particular episode this information would be sourced from the three systems (Admissions, Pathology, Pharmacy) that store this information, any required patient matching would be performed and the results would be viewed through a common user interface or portal. The key benefits of the portal based approach are that existing assets are utilised to their full potential and it avoids potential data integrity issues by going directly to the source system. This solution is also aligned with what appear to be clear emerging trends in technology. The biggest risk for NSW Health in adopting this architecture however is that while individual hospitals have implemented scaled down versions of the solution, there are few, if any examples of this architecture deployed on the scale of a NSW Health area of region across multiple settings. Accordingly, there is some question whether Portal architectures are stable and scale-able enough to support state-wide processing.

There is some question whether Portal architectures are stable and scaleable enough to Because real-time messaging must be available 100% of the time to support portal support state- wide architectures, an extremely robust and high performance integration solution would be processing required. Even if this solution could be implemented for results reporting, it would then need to be extended into order management, clinical documentation and decision support. The increased amount of information and rules involved in these capabilities would place an enormous load on integration services. A perception exists that a portal-based architecture would be cheaper, providing the same functionality as a repository-based architecture. In investigating solutions for ICIP, the Architecture team did not find a portal-based solution able to completely handle the complex requirements of a tertiary referral hospital, nor do we believe this architecture would represent a cheaper goal state architecture once the effort and cost of integration have been factored into the total cost of the solution.

Framework for vendor competition

Cerner is currently the state-wide vendor for the Point of Care CIS. The solution is operating well in a number of AHSs. As such, we recommend NSW Health continue to use the Cerner platform within the revised ICIP architecture.

ICIP Architecture Review Page 11

We recommend that NSW Health potentially open the market to an additional CIS vendor, to be managed within an agreed strategic framework

However, we also recommend that NSW Health potentially open the market to an additional CIS vendor, to be managed within an agreed strategic framework. There are three main reasons for this approach. First, having a multi-vendor environment will reduce the risk and over reliance on one vendor to deliver. Second, by establishing a managed, but competitive environment, NSW Health can expect greater flexibility from the vendor community in terms of pricing, implementation timeframes and technical inter-operability. Finally, the added cost of integration with a second platform will be mitigated by a core build approach and can be further addressed contractually with each successful vendor. We recommend a formal process to be conducted in year 1 of the strategy to determine whether a viable alternative exists. Although the introduction of an additional CIS vendor is recommended, order management and results reporting functionality need to be tightly coupled (i.e. same vendor). This recommendation ensures integration risks are minimised between these highly complex modules. Areas can then choose whether to bolt on tools from the same or other vendors to handle decision support, referrals, scheduling and clinical documentation.

The CIS will be tiered based on the acuity of setting with tight coupling of orders and results functionality

Community Health
The goal state architecture for community health systems is driven by the same principles as the systems needed to support acute settings, that is: support for a single view of the patient, facilitation of clinical information sharing across settings and the ability to effectively manage patient flow. A key consideration for the goal state architecture in terms of community health was, therefore, the future deployment strategy for Community Health Information Management Enterprise (CHIME). In the main, CHIME is viewed positively by community health users across the state. It is a custom designed solution which supports many of the core business functions within community health, providing an eMR for community health and supporting an integrated view of the client across community health services. Further, for most community services, it is the only practical solution available. On this basis, it is recommended that the deployment of CHIME should continue and an agreed development plan for the State standard build should be established in collaboration with Program areas to determine maintenance and development priorities for CHIME. However, the current platform upon which CHIME is based does not enable the desired inter-operability with an Area wide repository and would require redevelopment in a new technology. This is also true of all existing major clinical information systems, but these applications are already in the process of being standardised on .Net and J2EE architectures at their own cost. Accordingly, it is recommended that longer-term alternatives be investigated during phase 1, including extending the patient-centric architecture into the community, with a view to its migration to a single area wide repository during phase 2. It is important that this builds on the existing knowledge of community health requirements, relating to business processes, functional requirements and information and classification requirements.

It is recommended that an agreed development plan is established for CHIME and alternatives are investigated during phase 1

Other legacy and Specialist Systems

There are essentially 3 tiers of clinical systems in NSW Health. Tier 1 covers major initiatives such as Results Reporting, PAS and Community Health, Tier 2 covers systems supporting major diagnostic services such as radiology, pathology and pharmacy and Tier 3 covers the systems supporting particular patients, for example the obstetrics and spinal specialty systems governed by Local IT Initiatives (LITI).

ICIP Architecture Review Page 12

In all tiers, the Department (through the Clinical Investment Council and Design Authority) has responsibility for setting standards and ensuring compliance with the architecture. This change in governance is critical to the success of an integrated results reporting capability and to ICIP as a whole. As part of the design, build and rollout of integrated results reporting across the state, it is recommended that systems supporting major diagnostic services be rationalised. NSW Health has achieved an appropriate level of standardisation for pharmacy and if similar levels of standardisation can be achieved for radiology and pathology, integration complexity is reduced and the results reporting capability is more easily achieved. State-wide strategies for PACS and EDIS are also priorities that NSW Health needs to investigate. Tier 3 clinical systems are currently governed within ICIP through Local IT Initiatives (LITI), Greater Metropolitan Transition Taskforce (GMTT) and Towards a Safer Community (TASC). These initiatives have established significant clinician buy-in and success in managing the systems that support specialty areas. These initiatives should continue under ICIP, and an evaluation of other specialist IT initiatives should be conducted to determine whether they are appropriate for inclusion or, based on a high degree of overlap with larger initiatives or an inability to integrate should be sunsetted. LITI, GMTT and TASC match the governance model proposed in the ICIP implementation strategy and they are valuable to Health as they encourage innovation and ensure re-usability outside the larger program. Initiatives should only be governed by LITI, GMTT and TASC if there is a clear and defined migration path to the broader initiatives and the system is used across multiple AHSs. The clinical investment council (See Implementation Strategy page 22) should have responsibility for the decision of whether initiatives are handled by LITI, GMTT or TASC.

ICIP Architecture Review Page 13

Summary of High Level Architecture Recommendations

A patient-centric region or areawide repository is an essential foundation of the ICIP goal state architecture 1. A patient-centric repository (Option 1), constructed at a regional or area level, is deployed in all AHSs as the foundation for the construction and management of a patients eMR 2. An additional CIS vendor is considered based on a formal evaluation process conducted in Year 1 3. Order management and results reporting functionality should be tightly coupled (i.e. same vendor), however areas can then choose whether to bolt on tools from the same or other vendors to handle decision support, referrals, scheduling and clinical documentation 4. The statewide deployment of CHIME should continue. A development plan for the State standard build should be agreed with Program Areas, giving consideration to inter-agency, inter-state and national obligations. Investigation of alternative products should be undertaken in Phase 1 for the mid to long-term migration to a single patient repository. This work should build on the existing knowledge of Community Health requirements. 5. The systems supporting major diagnostic services should be rationalised to reduce integration complexities and better enable the results reporting capability. 6. The LITI, GMTT and TASC initiatives should continue under ICIP based on clearly defined entry criteria. Other systems not included in these programs should be considered for inclusion or sunset where significant overlaps exist or integration is not achievable.

ICIP Architecture Review Page 14

Goal State Architecture

The following diagram depicts the recommended components of NSW Healths ICIP goal state architecture. The key objective of the architecture is to enable NSW Healths business architecture. That is it needs to provide clinicians with a single view of the patient, facilitate clinical information sharing across settings, accelerate clinical decision-making and manage patient flow. Each numbered component in the figure below is described in the following table.

Figure 2: ICIP Goal State Architecture

ICIP Architecture Review Page 15

A key feature of NSW Healths IT Architecture is the distinct segmentation of the architecture into a thin, passive Event Summary (eHR layer) and a rich Clinical Information System (CIS Layer) to build and manage a patients eMR and provide clinicians with a single view of a patient. Distinct segmentation of the architecture into a thin, passive Event Summary and a rich CIS The Clinical Information Systems functionality will be tiered based on clinical acuity and requirements, represented here as Tertiary (Principal referral, Paediatric Specialist and Ungrouped Acute), District (Major Metropolitan, Major Non-Metropolitan and Community Acute) and Community (Community Non-Acute, Psychiatric, Multi-Purpose Services, Hospices, Rehabilitation and Mothercraft) requirements1 A single area-wide patient repository (see architecture options page 8) Tight coupling of order management and results reporting functionality (see architecture options page 8) The architecture also recommends a distributed Health Service and Provider Directory (HSPD) environment with replicas in each clinical hub from where applications are deployed. In the short term a HSPD will assist in making available services known to clinicians and the community and for facilitating the referral process. In the long term this capability could be developed to facilitate access management to clinical systems for Health service providers. It is also essential for interagency transfer of information; for example the Better Service Delivery Program. Patient Identification and transaction matching will be achieved through multiple options. At a state level, patient record matching needs to support the electronic Health record program (eHR). At an area level, these services will be performed either through matching software resident within the patient repository platform or through existing Health third party alternatives A strong integration layer and capability is required to manage inter and intra-AHS clinical information sharing (including the management of event summaries with the eHR), integration with directories, specialist and patient administration systems and a common user interface Remote Access will also be enabled via integration technologies and will give external stakeholders such as GPs access to Areas clinical systems and the patient repository (based on appropriate security). Ideally clinicians would access the clinical systems they require through a common user interface or portal. In this model clinicians would also have a single logon and their access would be managed via the HSPD. Diagnostic and specialty systems (both the large requirements for radiology, pathology, pharmacy and emergency departments and the smaller requirements of the systems governed by LITI, GMTT and TASC), should be rationalised and based on architecture standards to minimise integration risk and ensure maximum re-usability. ICIPs technical architecture foundations will also be deployed based on the different requirements of each tier.
1

A strong integration layer and capability is required to manage inter and intra-AHS clinical information sharing

Based on the existing NSW Health Peer Groupings ICIP Architecture Review Page 16

Integration Priorities
The implementation of an integration architecture to facilitate information sharing for applications and services is fundamental to the success of the program. Current approaches to implementation have meant that limited sharing of technology assets has been possible and that many areas have immature enterprise Application Integration (eAI) capabilities. It is therefore recommended that the design, implementation, rollout and support of the core components of eAI tools and technologies are handled by a dedicated group with representation from all AHSs and with initial assistance from industry. The guiding principles for the implementation of ICIPs integration priorities are: It is recommended that the design, implementation, rollout and support of the core components of eAI tools and technologies are handled by a dedicated group with representation from all AHSs

1. There is a strong integration layer/capability to manage inter and intra AHS clinical information sharing and a common user interface 2. Event summaries be should sent to the eHR layer from the patient repository, not from all the independent source systems, to minimise the number of interfaces required 3. Messages are pushed from AHSs integration layer to regional integration layer, rather than pulled 4. Mapping and translation for information that is transferred between settings, AHS and regions occurs at an AHS-level, wherever possible 5. Secure transactions occur between AHSs and between Health and external agencies 6. Agreed NSW Health standards must be used when defining, storing, and exchanging data 7. Integration components should be reusable across the state 8. The ICIP Integration Architecture must be flexible and applicable across a diverse range of settings. 9. Information must be accessible to those who need it regardless of organisational boundaries, but within appropriate privacy and security and access controls 10. There is a preference for a single state-wide eAI vendor 11. Implementation of the different eAI capabilities should be aligned with the roadmap. Initially only application and technical connectivity (adaptors), There are transformation and formatting and communications middleware are required. conceptually 2 Only when the maturity of Healths clinical information systems and their integration layers integration requirements increase should Business Process and Interaction an AHS management tools be considered. integration layer and a Regional There are conceptually 2 integration layers an AHS integration layer and a Regional integration layer integration layer. These layers have different purposes and objectives, but strong interaction, a common approach to implementation and follow the same guiding principles. The role of the AHS integration layer will be to: interface Admission, Discharge and Transfer (ADT) information to clinical support and diagnostic systems; interface results to the patient repository; submit orders to clinical support and diagnostic systems; synchronise provider and service information; pass event summaries and discharge referrals to the regional layer, and facilitate local clinical intelligence and KPIs through batch Extract, Translate and Load (ETL) processes.

ICIP Architecture Review Page 17

The role of the regional (multi-Area) integration layer will be to: direct the appropriate identification and matching of transactions between systems; transmit event summaries and discharge referrals from the AHS layer handle information sharing for external stakeholders, which includes the subscription of event summaries for GPs, communication with state or federal agencies such as the HIC and integration with business exchanges; enable a common user interface and access management for clinicians; enable legislative reporting requirements, and facilitate regional and state-wide clinical intelligence and KPIs through batch Extract, Translate and Load (ETL) processes.

The following diagram depicts the recommended components of NSW Healths goal state integration architecture.

Figure 3: High Level ICIP Integration Goal State Architecture

ICIP Architecture Review Page 18

Benefits Realisation
The proposed goal state architecture brings different benefits to each of Healths stakeholders, the ICIP Architecture: benefits patients by: increasing their access to the Health system; better sharing their information between caregivers; supporting the patient journey and emerging models of care, and providing their clinicians with tools to make the best possible decisions. The ICIP architecture benefits patients by increasing access, better sharing their information and supporting the patient journey and emerging models of care

benefits clinicians by: - providing access tools and technologies that assist in making the best possible clinical decision for the patient; - identifying their patients and relevant history; - improving the coordination of information sharing between services and settings, and - saving their time. benefits management by: allowing better forecasting and management of demand; enabling patient flow across the system; supporting front-line accountability, and enabling better planning and configuration of clinical services.

Mapping of Current State Issues to the Goal State Architecture

The following tables illustrate how current state issues and NSW Health Business drivers are resolved by the proposed goal state ICIP architecture.
Current State Issue or NSW Health Business Driver 1 The current infrastructure is immature compared to industry standards, complex, not flexible and costly to operate 2 Blockages in the patient journey within large complex care settings are impacting on patient access to clinical services The ICIP systems are deployed using different combinations of software hosted on different platforms Lack of visibility of patient information across and within settings Inter area process flows are significant and not proactively controlled A greater and emerging emphasis on supporting care in the community Goal State Architecture Principle There will be fewer deployment points for clinical systems based on the level of infrastructure maturity of AHSs Clinical systems will be in a high availability environment the technical infrastructure is standardised on proven and mature technologies Supports one view of the patient across all care settings Provides visibility and planning tools for all beds within acute settings Supports rostering and scheduling of clinical staff to better meet patient demand Will accommodate multiple providers and multiple technology platforms to deliver the same ICIP capabilities while at the same time promoting standardisation of processes and information flows across settings and AHSs Single area wide patient repository There will be mechanisms for sharing information across settings (eg eHR) There will be flow management tools available Improved access and single point of entry to clinical information for all clinicians (acute, community, GP) Standard deployments to reduce variability in clinical practice Supports clinical processes and transfers of clinical information across settings Provides visibility of the clinical pathways and the
ICIP Architecture Review Page 19

ICIP will accommodate multiple providers and technology platforms while at the same time promoting standardisation of processes and information flows across settings and AHSs

Adverse events occurring in medication administration and surgery Aged Care and Chronic Care are areas of increased demand due to longer life spans and improved treatment programs AHS mergers will dramatically change the current balance of ICIP systems and will combine incompatible systems and networks together Because of an inadequate focus and integration between technology and human performance, ICIP initiatives not providing clinicians with an optimum level of support

available service providers for consequential care Facilitates communication of clinically significant information (including care plans) across settings within an AHS, across AHSs and between GPs and NSW Health Provides for the unique identification of patients at the point of care, along with access to longitudinal clinical information and medical history Supports the implementation of standard protocols, decision support processes and data structures across the state Allows different settings to share a single view of a patient and to share a care plan, enabling improved treatment in the community (i.e. keep people out of hospital) Supports the deployment of standard processes and protocols for managing chronic diseases. Provides a long term strategy for aligning AHS networks and systems Has the flexibility to accommodate changes in AHS boundaries Enables strong link between people and technology to drive patient care Programs and projects have a defined goal to support clinical processes and decisions Human performance strategy managed by Program Management Office (PMO)

10

ICIP Architecture Review Page 20

ICIP Roadmap
The deployment of the ICIP architecture will occur through distinct phases that build a common level of capability across the state. Each phase is intended to take between 24 and 36 months. The investment in infrastructure will matched to phase Deployment through distinct phases with requirements, thereby reducing the risk of over investment. matching Benefits realisation needs to be tied to each successive step and measured with infrastructure and tangible clinical performance metrics if appropriate benefits are not realised there adequate funding should be no progression to a subsequent phase. As a rule-of-thumb, progression should occur when approximately two thirds of Areas have implemented the planned functionality so momentum is maintained and a foundation is established. Adequate funding is crucial to the success of any program. The ICIP review recommends that the majority of the ICIP program funding should focus on the current phase to ensure implementation momentum and broad uptake across the State. The success of ICIP will be measured At the same time, focused pioneering development will also be encouraged. against practical and Pioneering projects will build standards and demonstrate potential benefits for future clearly defined KPIs development. The pioneering projects targeted for phase one include pilots for the with benefits eHR and electronic prescribing decision support (ePDS) for AHSs that already have realisation tied to mature results and order management functionality. The balance of the Departments each successive step. budget should be reserved for existing commitments. No benefits no progression While each initiative includes an infrastructure component, a significant risk for ICIP is the commitment of the AHSs to invest in infrastructure foundations (desktops and networks) to support the proposed ICIP architecture.

Figure 4: ICIP Roadmap

ICIP Architecture Review Page 21