architecure .pdf

7/27/2019 Architecure .pdf

1/21

Enterprise Architecture

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

August 2004


2/21

ICIP Architecture ReviewPage 2

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. . . . . . . . . . . . . . . . . . . 245 PROJECT MANAGEMENT OFFICE AND IMPLEMENTATION ASSISTANCE FROMINDUSTRY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 EXISTINGINITIATIVES.............................................. 29

IMPACTS ON EXISTING INITIATIVES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

NEW ICIP INITIATIVES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

RISK MANAGEMENT..................................... 32

RECOMMENDATION SUMMARY ........................ 34


3/21


OverviewThe ICIP architecture review was initiated to identify opportunities to accelerate thedeployment of core clinical systems across NSW to address the major priorities beingtackled 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 fromacute 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 theinterfaces 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 thefoundation for clinical functionality across all Areas to support the delivery of healthservices at all points of the patients journey across the system. This includes systemsto support:

access to critical patient information from across the public and private sectordelivered 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 ofdiagnostic 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 anddemand

improved safety and quality.

The review identified the following ICIP strategies to be accelerated to address themajor problem areas and reform priorities:

implementation of a patient centric area wide repository in all Areas to supportshared access to medical records to all clinicians in an Area;

evaluation of alternative Clinical Information Systems to introduce choice anddrive competition;

extended roll out of CHIME to give wider access to community healthinformation, with evaluation of alternative products to support the migration toa single patient repository;

establishment of a Health Service Provider Directory to support referralsbetween services;

development of a strong integration capability to manage the exchange ofinformation between health services and simplify the management of theElectronic 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 ofthe IM&T Strategic Plan. The IPART report reinforced the strategic direction set in2000 by the Health Council, and emphasized the need for IM&T to be implemented in a


4/21


way that supported more integrated service delivery, better quality care and improvedpatient safety and more integrated performance management. The focus of the ICIPreview was to ensure that the IM&T program as it is currently defined could supportclinicians 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 torespond to the needs of NSW Health and adapt to evolving models of care. The reportrecommends strategies to accelerate the implementation of core functionality acrossthe state building on the existing investment. The report also recommends thatgreater value can be obtained by introducing more competition into the marketplace.

The objective of the ICIP Architecture Review Project is to define an overallarchitecture and set of strategic initiatives to guide NSW Healths development ofstate-wide clinical systems over the next 5-7 years.

A comprehensive approach has been taken across a 20 week project, reviewing currentDepartment 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 ofan ICIP architecture that can be applied at a practical levelto support the implementation of the Electronic Health Record and clinicalsystems at the point of care;

High level assessment of alternative implementation options for programswithin the ICIP environment across NSW Health;

Review and refinement of existing principles and standards to supportselection and delivery of new ICIP solutions, including guidelines forimplementation of strategic solutions to meet the patient safety and quality of

care objectives of NSW Health;


5/21


Identification of practical, achievable implementation plans and theappropriate functional focus to meet the business goals of Area Health Servicesand the Department and integrated existing initiatives with revised strategies;

Revised governance strategies for balancing business needs with architecturedesign requirements;

Systems Integration and delivery strategies guiding overall integrationinfrastructure and operating platforms

High level funding estimates for near term initiatives

Risk management strategies.


6/21


Current State Findings

A detailed Current State Assessment (CSA) of existing ICIP strategies has beenconducted across the Department and four AHSs, with further documentation reviewfor the remaining AHSs.

The CSA identified critical issues, shared priorities, relative maturity of clinical systemsand lessons learnt from previous implementations.

The key findings from the current state assessment were as follows:

1. No long-term clinical architecture currently exists for ICIPNSW Health recognises the importance of a long-term architecture that provides anintegrating framework for ICIP. The ICIP Review project was commissioned largely inrecognition of this need. Because no long-term architecture currently exists, differingarchitectures and approaches have evolved from various AHSs that have sought todefine their own direction. In addition, AHSs seeking direction from the Departmenthave become frustrated, as no commonly shared approach was available. Effort has

been duplicated in the resolution of similar problems and there is limited reuse oftechnology assets.

2. There is a disconnect between Healths business and technology strategyWhile models of care will continually evolve, NSW Health has a clear, high-level visionthat is not likely to change significantly over time. The key tenants of healthierpeople; providing quality care; creating equity of access and improving effectivenessand 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 visioninto practical objectives that guide the year-to-year operating priorities of the ICIPstrategy. As such, ICIP has been managed a series of projects, rather than oneintegrated program. While these projects generally hang together as a reasonable

overall strategy, they lack a focused and shared strategic rationale for clinical systemsinvestment. Perhaps because of this, funding of these projects has been inadequateover time and many initiatives have stalled, losing momentum due to lack of financialsupport at both a State and Area level.

At times, the governance model for ICIP programs has also varied from very AHS centricto very Department focused. The ongoing success of ICIP will depend heavily onconsistent and shared governance processes that balance front line business needs withshared standards and architecture.

3. Current technology is increasing fragmentation within the systemPatient flow blockages occurring within and across care settings (both public andprivate) are exacerbated by a lack of integration between patient management andclinical systems. From an acute perspective, the flow of data from the EmergencyDepartment to the inpatient setting and required specialties has not been achieved inmany hospitals. With some notable exceptions (e.g. the electronic Discharge ReferralSystem) adequate sharing of patient information between and within 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 beendeployed using different combinations of software hosted on different platforms.

The resolution of current information gaps and overlaps will also better enable theproactive management of inter and intra-area patient flows.

An accurate Health Service and Provider Directory (HSPD) and approach to commonpatient identification will also be critical to the success of ICIP. At present thesecapabilities vary in maturity and effectiveness across the AHSs.

Effort has beenplicated and there

is little reuse of

technology assets

ICIP has not beenmanaged as an

integrated programand the governancemodel has varied

over time

Adequate sharing ofpatient informationbetween and within

settings is rare


7/21


A handful of AHSs have relatively mature and robust technology deployed from theirmajor tertiary referral hospital, however from a state-wide perspective, the ICIPsystems are deployed using different combinations of software hosted on differentplatforms. In the majority of areas, the current infrastructure is immature comparedto industry standards, complex, not flexible and costly to operate.

4. The implementation of ICIP initiatives has been unevenAlthough pockets of excellence exist across the State, there is currently no sense of astate-wide foundation upon which clinical outcomes can be delivered and improved.Despite some successes, the overwhelming majority of AHSs are relatively immature inthe implementation of clinical systems. ICIP has had a mixed implementation recordwhich has led to a perception of the existence of the haves and have nots, ratherthan being a centrally coordinated program.

There is also a feeling amongst AHSs that there has been inequity in the response to thedifferent requirements of rural AHSs and Community Health services from a technologyperspective.

5. There is a degree of cynicism and frustration with the lack of progressThere 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 thatHealth has a mixed track record of executing major, state-wide strategic projects.

The current state assessment also identified inconsistent vendor management andlengthy program delays for many initiatives due largely to a lack of available funding.

The need for an increased emphasis on human performance and change managementwithin major implementation projects was also voiced by a number of AHSs.

There is no sense of astate-widefoundation uponwhich clinicaloutcomes can bedelivered and

evolved


8/21


Goal State Drivers, Business Needs

A major requirement for the Review was to more clearly articulate the businessobjectives that should drive the development priorities for ICIP.

In pursuing this requirement the team consolidated a range of priorities into four majorstrategic streams or imperatives, each with specific measures (KPIs), each supporting astack of clinical applications that should become core components of the goal statearchitecture.

The four streams were defined as follows:1. Making it easier for the patient2. Accelerating and improving clinical decision making and sharing of information

across settings3. Effectively managing patient flow and the alignment of supply and demand4. Supporting and driving management accountability (including safety and

quality)

These streams provide the conceptual framework for discussing the revised ICIPprogram and the inter-relationships between applications and projects.

Not only must ICIP support these strategies within the current context, it must also beflexible enough to allow for (and perhaps accelerate) structural changes across thesystem. For example, increased emphasis on aged and chronic care and the emergenceof new care models will require new approaches to information access and carecoordination.

The ICIP architecture will need to effectively balance the demands of local care teamsfor 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 andprovider information to be commonly identified and integrated.

Finally, in order to support Healths business the ICIP Architecture needs to allow forany further changes in AHS and NSW Health governance constructs and to emergingtrends in technology while remaining simple, scaleable and usable for health serviceproviders.

Guiding Principles

With these business needs in mind, the following guiding principles for theimplementation of the ICIP architecture have been developed:

1. In order to best support a continuum of care for patients, ICIP applications andtechnologies 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 clinicalpriorities and outcomes

3. The ICIP architecture will empower clinical decision making4. The ICIP architecture will support the continuum of care across settings and

AHS boundaries5. Application choice will be maintained within an agreed framework at the

AHS level to engender competition, meet differing needs across AHSs andreduce 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 allnecessary system functionality

ur strategic streamswere defined:

Making it easier forthe patient

2. Accelerating andimproving clinical

decision making andaring of information

across settings

Effectively managingpatient flow and thealignment of supply

and demand

4. Supporting anddriving management

accountabilityincluding safety and

quality)

Provide stakeholderswith a single, integrated

view of patientinformation


9/21


Architecture Options

The goal state architectures most important purpose is the construction, managementand sharing of patient information in a secure and accessible way.

In recommending a specific architecture to meet this requirement a number of optionswere considered, however, broadly, two architecture options were evaluated for theICIP goal state architecture:

1. a regional or area-based patient-centric data repository to store information,built over time, fed by other specialist systems, or

2. portal-based technologies which dynamically query and access patient data atthe time of need using new integration technologies

Both solutions assume that specialist systems still exist for acute point of caremanagement, community health, patient administration, diagnostic support and otherdaily clinical system requirements.

The key difference is whether a patients eMR is both stored in a consolidatedrepository and distributed throughout the specialist systems a consolidated eMR, orwhether the information only exists in the specialist systems with the patient centricview 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 andmaintenance of the required infrastructure, the risks associated with consolidatingmission critical information for the whole state, and the acceptance this level ofchange would require.

In addition to determining whether a repository or dynamic approach was preferred,other important decisions in recommending an integrated architecture for NSW Health

were:

1. The framework in which competition would operate2. How each of the major current systems would integrate with the architecture,

in particular for Community Health3. How systems governed by Local IT Initiatives (LITI), the Greater Metropolitan

Transition Taskforce (GMTT) and Toward a Safer Community (TASC) would beimpacted

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 andmanagement

Total solution cost

The goal statearchitectures mostimportant purpose isthe construction,management andsharing of patientinformation in asecure and accessible

way

There are broadlytwo options NSWHealth should

consider an area-based patient-centricdata repository, orportal-basedtechnologies whichdynamically queryand access patient

data


10/21


Flexibility to IMTB change, AHS boundary re-alignment, trends in technologyand 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 repositoryOption one progressively builds an electronic medical record (eMR) for select patient

information across a region, regardless of the setting in which interactions occur. Forexample, an area-wide patient repository could store detailed radiology and pathologyresults, admission-discharge-transfer records and discharge referral summaries frominteractions with acute settings and notes, assessments and referrals from community-based interactions.

This option best enables a single view of the patient regardless of setting, theadherence to clinical pathways and the facilitation of referral management. By usingthe 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 thanfacility/service-based slices of it. Because critical results and clinical documentationare stored in one place, acute discharge and community-based referrals are more easilyfacilitated

A clinical information system (CIS) is mission critical for Health. A repositoryapproach minimises the risk of information not being available to support clinicaldecisions. Rather than attempting to access information dynamically, an architecturebased on a clinical repository stores all this information in the one highly availableplace with both site-based and cross area redundancy built-in.

While trends in connectivity are evolving and web-services appears to be a clear futuredirection, the deployment of clinical systems using a patient repository as theunderlying foundation is a proven and mature solution in NSW (for example CentralSydney and Western Sydney AHS), Australia (South Australias state-wide OACIS

solution) and globally (particularly in large integrated delivery networks in the UnitedStates).

Further, a patient repository does not inhibit the adoption of these new technologies inthe future (in fact it enables them). However a key consideration for ICIP is the needfor practical, commercially proven solutions that can be implemented in the short termand flexible enough to adapt to future trends in technology.

Deployment of the architecture also allows Health to consider delivering applicationsthough clinical hubs. Because economies of scale can be achieved through thisarchitecture 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 arrangementalso serves as a progression point for the standardisation of clinical applications.

A single, region-widepatient repository

best enables a singleview of the patientacross settings, thetracking of clinicalpathways and the

facilitation of referral

management

The deployment ofclinical systems using

a patient repositoryas the underlying

foundation is aproven and mature

solution


11/21


The deployment of clinical applications based on a patient repository also createssignificant efficiencies in terms of integrating with state-wide solutions for anelectronic Health Record (eHR) and the master Health Service and Provider Directory(HSPD). Rather than having the state-wide eHR integrate directly with multiple sourcesystems 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 extract-transform-load capabilities for data warehousing and clinical reporting.

Finally, a repository achieves something everywhere for all Health settings. Byrolling out area or region-wide patient for personal information, results, notes,assessments and referrals, Health achieves a common base upon which to extend levelsof maturity and to build on and create momentum.

Option 2: Portal-based web services architectureOption 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 aclinician need to access pathology and pharmacy information for a particular episodethis information would be sourced from the three systems (Admissions, Pathology,Pharmacy) that store this information, any required patient matching would beperformed 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 totheir full potential and it avoids potential data integrity issues by going directly to thesource system. This solution is also aligned with what appear to be clear emergingtrends in technology.

The biggest risk for NSW Health in adopting this architecture however is that whileindividual hospitals have implemented scaled down versions of the solution, there arefew, if any examples of this architecture deployed on the scale of a NSW Health area ofregion across multiple settings. Accordingly, there is some question whether Portalarchitectures are stable and scale-able enough to support state-wide processing.

Because real-time messaging must be available 100% of the time to support portalarchitectures, an extremely robust and high performance integration solution would berequired. Even if this solution could be implemented for results reporting, it wouldthen need to be extended into order management, clinical documentation and decisionsupport. The increased amount of information and rules involved in these capabilitieswould 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 forICIP, the Architecture team did not find a portal-based solution able to completelyhandle the complex requirements of a tertiary referral hospital, nor do we believe thisarchitecture would represent a cheaper goal state architecture once the effort and costof 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 isoperating well in a number of AHSs. As such, we recommend NSW Health continue to

use the Cerner platform within the revised ICIP architecture.

There is somequestion whetherPortal architecturesare stable andscaleable enough tosupport state- wide

processing

A repositoryachievessomethingeverywhere for

all Health settings


12/21


However, we also recommend that NSW Health potentially open the market to anadditional CIS vendor, to be managed within an agreed strategic framework.

There are three main reasons for this approach. First, having a multi-vendorenvironment 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, implementationtimeframes and technical inter-operability. Finally, the added cost of integration witha second platform will be mitigated by a core build approach and can be furtheraddressed contractually with each successful vendor. We recommend a formal processto be conducted in year 1 of the strategy to determine whether a viable alternativeexists.

Although the introduction of an additional CIS vendor is recommended, ordermanagement and results reporting functionality need to be tightly coupled (i.e. samevendor). This recommendation ensures integration risks are minimised between thesehighly complex modules. Areas can then choose whether to bolt on tools from thesame or other vendors to handle decision support, referrals, scheduling and clinicaldocumentation.

Community Health

The goal state architecture for community health systems is driven by the sameprinciples as the systems needed to support acute settings, that is: support for a singleview of the patient, facilitation of clinical information sharing across settings and theability 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 InformationManagement Enterprise (CHIME).

In the main, CHIME is viewed positively by community health users across the state. Itis a custom designed solution which supports many of the core business functions withincommunity health, providing an eMR for community health and supporting anintegrated view of the client across community health services. Further, for mostcommunity services, it is the only practical solution available. On this basis, it isrecommended that the deployment of CHIME should continue and an agreeddevelopment plan for the State standard build should be established in collaborationwith Program areas to determine maintenance and development priorities for CHIME.

However, the current platform upon which CHIME is based does not enable the desiredinter-operability with an Area wide repository and would require redevelopment in anew technology. This is also true of all existing major clinical information systems, butthese applications are already in the process of being standardised on .Net and J2EE

architectures at their own cost. Accordingly, it is recommended that longer-termalternatives be investigated during phase 1, including extending the patient-centricarchitecture into the community, with a view to its migration to a single area widerepository during phase 2. It is important that this builds on the existing knowledge ofcommunity health requirements, relating to business processes, functionalrequirements and information and classification requirements.

Other legacy and Specialist Systems

There are essentially 3 tiers of clinical systems in NSW Health. Tier 1 covers majorinitiatives such as Results Reporting, PAS and Community Health, Tier 2 covers systemssupporting major diagnostic services such as radiology, pathology and pharmacy and

Tier 3 covers the systems supporting particular patients, for example the obstetrics andspinal specialty systems governed by Local IT Initiatives (LITI).

The CIS will betiered based on

the acuity ofsetting with tight

coupling oforders and results

functionality

We recommendthat NSW Healthpotentially openthe market to an

additional CISvendor, to be

managed within

an agreedstrategicframework

It isrecommendedthat an agreed

evelopment planis established for

CHIME andalternatives are

investigated

during phase 1


13/21


In all tiers, the Department (through the Clinical Investment Council and DesignAuthority) has responsibility for setting standards and ensuring compliance with thearchitecture. This change in governance is critical to the success of an integratedresults 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 ifsimilar levels of standardisation can be achieved for radiology and pathology,integration complexity is reduced and the results reporting capability is more easilyachieved. State-wide strategies for PACS and EDIS are also priorities that NSW Healthneeds to investigate.

Tier 3 clinical systems are currently governed within ICIP through Local IT Initiatives(LITI), Greater Metropolitan Transition Taskforce (GMTT) and Towards a SaferCommunity (TASC). These initiatives have established significant clinician buy-in andsuccess 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 inclusionor, based on a high degree of overlap with larger initiatives or an inability to integrateshould be sunsetted. LITI, GMTT and TASC match the governance model proposed inthe ICIP implementation strategy and they are valuable to Health as they encourageinnovation and ensure re-usability outside the larger program.

Initiatives should only be governed by LITI, GMTT and TASC if there is a clear anddefined migration path to the broader initiatives and the system is used across multipleAHSs. The clinical investment council (See Implementation Strategy page 22) shouldhave responsibility for the decision of whether initiatives are handled by LITI, GMTT orTASC.


14/21


Summary of High Level Architecture Recommendations

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 managementof a patients eMR

2. An additional CIS vendor is considered based on a formal evaluation processconducted 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 toolsfrom 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 forthe State standard build should be agreed with Program Areas, givingconsideration to inter-agency, inter-state and national obligations.

Investigation of alternative products should be undertaken in Phase 1 for themid to long-term migration to a single patient repository. This work shouldbuild on the existing knowledge of Community Health requirements.

5. The systems supporting major diagnostic services should be rationalised toreduce integration complexities and better enable the results reportingcapability.

6. The LITI, GMTT and TASC initiatives should continue under ICIP based on clearlydefined entry criteria. Other systems not included in these programs should beconsidered for inclusion or sunset where significant overlaps exist or integrationis not achievable.

A patient-centricregion or area-

wide repository is

an essentialfoundation of the

ICIP goal state

architecture


15/21


Goal State Architecture

The following diagram depicts the recommended components of NSW Healths ICIP goalstate 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, facilitateclinical information sharing across settings, accelerate clinical decision-making andmanage patient flow.

Each numbered component in the figure below is described in the following table.

Figure 2: ICIP Goal State Architecture


16/21


A key feature of NSW Healths IT Architecture is the distinct segmentationof the architecture into a thin, passive Event Summary (eHR layer) and arich Clinical Information System (CIS Layer) to build and manage a patientseMR and provide clinicians with a single view of a patient.

The Clinical Information Systems functionality will be tiered based onclinical acuity and requirements, represented here as Tertiary (Principalreferral, Paediatric Specialist and Ungrouped Acute), District (MajorMetropolitan, Major Non-Metropolitan and Community Acute) andCommunity (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 (seearchitecture options page 8)

The architecture also recommends a distributed Health Service and ProviderDirectory (HSPD) environment with replicas in each clinical hub from whereapplications are deployed.

In the short term a HSPD will assist in making available services known toclinicians and the community and for facilitating the referral process. Inthe long term this capability could be developed to facilitate accessmanagement to clinical systems for Health service providers. It is alsoessential for interagency transfer of information; for example the BetterService Delivery Program.

Patient Identification and transaction matching will be achieved throughmultiple options. At a state level, patient record matching needs to support

the electronic Health record program (eHR). At an area level, theseservices will be performed either through matching software resident withinthe patient repository platform or through existing Health third partyalternatives

A strong integration layer and capability is required to manage inter andintra-AHS clinical information sharing (including the management of eventsummaries with the eHR), integration with directories, specialist andpatient administration systems and a common user interface

Remote Access will also be enabled via integration technologies and willgive external stakeholders such as GPs access to Areas clinical systems andthe patient repository (based on appropriate security).

Ideally clinicians would access the clinical systems they require through acommon user interface or portal. In this model clinicians would also have asingle 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 smallerrequirements of the systems governed by LITI, GMTT and TASC), should berationalised and based on architecture standards to minimise integrationrisk and ensure maximum re-usability.

ICIPs technical architecture foundations will also be deployed based on thedifferent requirements of each tier.

1 Based on the existing NSW Health Peer Groupings

Distinctsegmentation ofthe architecture

into a thin,passive Event

Summary and a

rich CIS

A strong

integration layerand capability is

required tomanage inter andintra-AHS clinical

information

sharing


17/21


Integration Priorities

The implementation of an integration architecture to facilitate information sharing forapplications and services is fundamental to the success of the program.

Current approaches to implementation have meant that limited sharing of technologyassets has been possible and that many areas have immature enterprise ApplicationIntegration (eAI) capabilities. It is therefore recommended that the design,implementation, rollout and support of the core components of eAI tools andtechnologies are handled by a dedicated group with representation from all AHSs andwith initial assistance from industry.

The guiding principles for the implementation of ICIPs integration priorities are:

1. There is a strong integration layer/capability to manage inter and intra AHSclinical 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 required3. 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 externalagencies

6. Agreed NSW Health standards must be used when defining, storing, andexchanging data

7. Integration components should be reusable across the state8. 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 andaccess controls

10. There is a preference for a single state-wide eAI vendor11. Implementation of the different eAI capabilities should be aligned with the

roadmap. Initially only application and technical connectivity (adaptors),transformation and formatting and communications middleware are required.Only when the maturity of Healths clinical information systems and theirintegration requirements increase should Business Process and Interactionmanagement tools be considered.

There are conceptually 2 integration layers an AHS integration layer and a Regionalintegration layer. These layers have different purposes and objectives, but stronginteraction, 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 clinicalsupport 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.

It isrecommendedthat the design,

implementation,rollout andsupport of thecore componentsof eAI tools andtechnologies arehandled by adedicated groupwithrepresentation

from all AHSs

There areconceptually 2integration layers an AHSintegration layerand a Regional

integration layer


18/21


The role of the regional (multi-Area) integration layer will be to:

direct the appropriate identification and matching of transactions betweensystems;

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 federalagencies 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 goalstate integration architecture.

Figure 3: High Level ICIP Integration Goal State Architecture


19/21


Benefits RealisationThe proposed goal state architecture brings different benefits to each of Healthsstakeholders, 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.

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 ArchitectureThe following tables illustrate how current state issues and NSW Health Business driversare resolved by the proposed goal state ICIP architecture.

Current State Issue or NSWHealth Business Driver

Goal State Architecture Principle

1 The currentinfrastructure isimmature compared toindustry standards,complex, not flexible andcostly to operate

There will be fewer deployment points for clinicalsystems based on the level of infrastructure maturity ofAHSs

Clinical systems will be in a high availabilityenvironment

the technical infrastructure is standardised on provenand mature technologies

2 Blockages in the patientjourney within largecomplex care settings areimpacting on patientaccess to clinical services

Supports one view of the patient across all caresettings

Provides visibility and planning tools for all beds withinacute settings

Supports rostering and scheduling of clinical staff to

better meet patient demand3 The ICIP systems are

deployed using differentcombinations of softwarehosted on differentplatforms

Will accommodate multiple providers and multipletechnology platforms to deliver the same ICIPcapabilities while at the same time promotingstandardisation of processes and information flowsacross settings and AHSs

4 Lack of visibility ofpatient informationacross and within settings

Single area wide patient repository There will be mechanisms for sharing information

across settings (eg eHR) There will be flow management tools available

5 Inter area process flowsare significant and notproactively controlled

Improved access and single point of entry to clinicalinformation for all clinicians (acute, community, GP)

Standard deployments to reduce variability in clinicalpractice

6 A greater and emergingemphasis on supportingcare in the community

Supports clinical processes and transfers of clinicalinformation across settings

Provides visibility of the clinical pathways and the

ICIP willaccommodatemultiple providersand technologyplatforms while atthe same timepromotingstandardisation ofprocesses andinformation flowsacross settings and

AHSs

The ICIParchitecturebenefits patients

by increasingaccess, bettersharing theirinformation andsupporting thepatient journeyand emerging

models of care


20/21


available service providers for consequential care Facilitates communication of clinically significant

information (including care plans) across settings withinan AHS, across AHSs and between GPs and NSW Health

7 Adverse events occurringin medicationadministration and

surgery

Provides for the unique identification of patients at thepoint of care, along with access to longitudinal clinicalinformation and medical history

Supports the implementation of standard protocols,decision support processes and data structures acrossthe state

8 Aged Care and ChronicCare are areas ofincreased demand due tolonger life spans andimproved treatmentprograms

Allows different settings to share a single view of apatient and to share a care plan, enabling improvedtreatment in the community (i.e. keep people out ofhospital)

Supports the deployment of standard processes andprotocols for managing chronic diseases.

9 AHS mergers willdramatically change thecurrent balance of ICIPsystems and will combineincompatible systems and

networks together

Provides a long term strategy for aligning AHS networksand systems

Has the flexibility to accommodate changes in AHSboundaries

10 Because of an inadequatefocus and integrationbetween technology andhuman performance, ICIPinitiatives not providingclinicians with anoptimum level of support

Enables strong link between people and technology todrive patient care

Programs and projects have a defined goal to supportclinical processes and decisions

Human performance strategy managed by ProgramManagement Office (PMO)


21/21

ICIP A hit t R i

ICIP Roadmap

The deployment of the ICIP architecture will occur through distinct phases that build acommon level of capability across the state. Each phase is intended to take between

24 and 36 months. The investment in infrastructure will matched to phaserequirements, thereby reducing the risk of over investment.

Benefits realisation needs to be tied to each successive step and measured withtangible clinical performance metrics if appropriate benefits are not realised thereshould be no progression to a subsequent phase. As a rule-of-thumb, progressionshould occur when approximately two thirds of Areas have implemented the plannedfunctionality so momentum is maintained and a foundation is established.

Adequate funding is crucial to the success of any program. The ICIP reviewrecommends that the majority of the ICIP program funding should focus on the currentphase to ensure implementation momentum and broad uptake across the State.

At the same time, focused pioneering development will also be encouraged.Pioneering projects will build standards and demonstrate potential benefits for futuredevelopment. The pioneering projects targeted for phase one include pilots for theeHR and electronic prescribing decision support (ePDS) for AHSs that already havemature results and order management functionality. The balance of the Departmentsbudget should be reserved for existing commitments.

While each initiative includes an infrastructure component, a significant risk for ICIP isthe commitment of the AHSs to invest in infrastructure foundations (desktops andnetworks) to support the proposed ICIP architecture.

Figure 4: ICIP Roadmap

Deployment throughdistinct phases withmatchinginfrastructure and

adequate funding

The success of ICIPwill be measured

against practical andclearly defined KPIswith benefitsrealisation tied toeach successive step.No benefits noprogression

architecure .pdf

Documents