Enterprise Architecture


Published on

Published in: Health & Medicine, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Enterprise Architecture

  1. 1. Enterprise Architecture Integrated Clinical Information Program (ICIP) Architecture Review - Final Report Summary August 2004
  2. 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’................... 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
  3. 3. 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
  4. 4. 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 Health’s 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
  5. 5. 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
  6. 6. 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 The key findings from the current state assessment were as follows: duplicated and there is little reuse of 1. No long-term clinical architecture currently exists for ICIP technology assets 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 Health’s 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 ICIP has not been into practical objectives that guide the year-to-year operating priorities of the ICIP managed as an strategy. As such, ICIP has been managed a series of projects, rather than one integrated program integrated program. While these projects generally ‘hang together’ as a reasonable and the governance overall strategy, they lack a focused and shared strategic rationale for clinical systems model has varied investment. Perhaps because of this, funding of these projects has been inadequate over time 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. 3. Current technology is increasing fragmentation within the system 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
  7. 7. 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. 4. The implementation of ICIP initiatives has been uneven 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 than being a centrally coordinated program. delivered and 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. 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
  8. 8. Goal State Drivers, Business Needs Four strategic streams A major requirement for the Review was to more clearly articulate the business were defined: objectives that should drive the development priorities for ICIP. 1. Making it easier for In pursuing this requirement the team consolidated a range of priorities into four major the patient 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 2. Accelerating and architecture. improving clinical decision making and The four streams were defined as follows: sharing of information 1. Making it easier for the patient across settings 2. Accelerating and improving clinical decision making and sharing of information across settings 3. Effectively managing 3. Effectively managing patient flow and the alignment of supply and demand patient flow and the 4. Supporting and driving management accountability (including safety and alignment of supply quality) and demand These streams provide the conceptual framework for discussing the revised ICIP 4. Supporting and program and the inter-relationships between applications and projects. driving management accountability Not only must ICIP support these strategies within the current context, it must also be (including safety and flexible enough to allow for (and perhaps accelerate) structural changes across the quality) 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 Health’s 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: 1. In order to best support a continuum of care for patients, ICIP applications and Provide stakeholders technologies need to be deployed to provide stakeholders with a single, with a single, integrated integrated view of patient information view of patient 2. The architecture and proposed initiatives will be aligned with clinical information 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
  9. 9. Architecture Options The goal state architecture’s 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 architecture’s most were considered, however, broadly, two architecture options were evaluated for the important purpose is ICIP goal state architecture: the construction, management and 1. a regional or area-based patient-centric data repository to store information, sharing of patient built over time, fed by other specialist systems, or information in a 2. portal-based technologies which dynamically query and access patient data at secure and accessible the time of need using new integration technologies way 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 patient’s 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 area- based 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
  10. 10. • 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 Health’s 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 Option one progressively builds an electronic medical record (eMR) for select patient A single, region-wide information across a region, regardless of the setting in which interactions occur. For patient repository example, an area-wide patient repository could store detailed radiology and pathology best enables a single results, admission-discharge-transfer records and discharge referral summaries from view of the patient interactions with acute settings and notes, assessments and referrals from community- across settings, the based interactions. tracking of clinical pathways and the This option best enables a single view of the patient regardless of setting, the facilitation of referral adherence to clinical pathways and the facilitation of referral management. By using management 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 patient’s 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 Australia’s state-wide OACIS solution) and globally (particularly in large integrated delivery networks in the United States). Further, a patient repository does not inhibit the adoption of these new technologies in The deployment of the future (in fact it enables them). However a key consideration for ICIP is the need clinical systems using for practical, commercially proven solutions that can be implemented in the short term a patient repository and flexible enough to adapt to future trends in technology. as the underlying foundation is a Deployment of the architecture also allows Health to consider delivering applications proven and mature though ‘clinical hubs’. Because economies of scale can be achieved through this solution 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
  11. 11. 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 extract- transform-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 There is some few, if any examples of this architecture deployed on the scale of a NSW Health area of question whether region across multiple settings. Accordingly, there is some question whether Portal Portal architectures architectures are stable and scale-able enough to support state-wide processing. 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
  12. 12. We recommend that NSW Health However, we also recommend that NSW Health potentially open the market to an potentially open additional CIS vendor, to be managed within an agreed strategic framework. the market to an additional CIS There are three main reasons for this approach. First, having a multi-vendor vendor, to be environment will reduce the risk and over reliance on one vendor to deliver. Second, managed within by establishing a managed, but competitive environment, NSW Health can expect an agreed greater flexibility from the vendor community in terms of pricing, implementation strategic timeframes and technical inter-operability. Finally, the added cost of integration with framework 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. The CIS will be Although the introduction of an additional CIS vendor is recommended, order tiered based on management and results reporting functionality need to be tightly coupled (i.e. same the acuity of vendor). This recommendation ensures integration risks are minimised between these setting with tight highly complex modules. Areas can then choose whether to ‘bolt on’ tools from the coupling of same or other vendors to handle decision support, referrals, scheduling and clinical orders and results documentation. 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 It is community services, it is the only practical solution available. On this basis, it is recommended recommended that the deployment of CHIME should continue and an agreed that an agreed development plan for the State standard build should be established in collaboration development plan with Program areas to determine maintenance and development priorities for CHIME. is established for CHIME and However, the current platform upon which CHIME is based does not enable the desired alternatives are inter-operability with an Area wide repository and would require redevelopment in a investigated new technology. This is also true of all existing major clinical information systems, but during phase 1 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. 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
  13. 13. 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
  14. 14. Summary of High Level Architecture Recommendations A patient-centric 1. A patient-centric repository (Option 1), constructed at a regional or area level, region or area- is deployed in all AHSs as the foundation for the construction and management wide repository is of a patient’s eMR an essential foundation of the 2. An additional CIS vendor is considered based on a formal evaluation process ICIP goal state conducted in Year 1 architecture 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
  15. 15. Goal State Architecture The following diagram depicts the recommended components of NSW Health’s ICIP goal state architecture. The key objective of the architecture is to enable NSW Health’s 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
  16. 16. A key feature of NSW Health’s 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 The Clinical Information Systems functionality will be tiered based on segmentation of clinical acuity and requirements, represented here as Tertiary (Principal the architecture referral, Paediatric Specialist and Ungrouped Acute), District (Major into a thin, Metropolitan, Major Non-Metropolitan and Community Acute) and passive Event Community (Community Non-Acute, Psychiatric, Multi-Purpose Services, Summary and a Hospices, Rehabilitation and Mothercraft) requirements1 rich CIS 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 A strong multiple options. At a state level, patient record matching needs to support integration layer the electronic Health record program (eHR). At an area level, these and capability is services will be performed either through matching software resident within required to the patient repository platform or through existing Health third party manage inter and alternatives intra-AHS clinical information A strong integration layer and capability is required to manage inter and sharing 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 Based on the existing NSW Health Peer Groupings ICIP Architecture Review Page 16
  17. 17. Integration Priorities The implementation of an integration architecture to facilitate information sharing for applications and services is fundamental to the success of the program. It is recommended Current approaches to implementation have meant that limited sharing of technology that the design, assets has been possible and that many areas have immature enterprise Application implementation, Integration (eAI) capabilities. It is therefore recommended that the design, rollout and implementation, rollout and support of the core components of eAI tools and support of the technologies are handled by a dedicated group with representation from all AHSs and core components with initial assistance from industry. of eAI tools and technologies are The guiding principles for the implementation of ICIPs integration priorities are: handled by a dedicated group 1. There is a strong integration layer/capability to manage inter and intra AHS with clinical information sharing and a common user interface representation 2. Event summaries be should sent to the eHR layer from the patient repository, from all AHSs 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 Health’s 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
  18. 18. 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 Health’s goal state integration architecture. Figure 3: High Level ICIP Integration Goal State Architecture ICIP Architecture Review Page 18
  19. 19. Benefits Realisation The proposed goal state architecture brings different benefits to each of Health’s stakeholders, the ICIP Architecture: The ICIP • benefits patients by: architecture benefits patients - increasing their access to the Health system; by increasing - better sharing their information between caregivers; access, better - supporting the patient journey and emerging models of care, and sharing their - providing their clinicians with tools to make the best possible decisions. information and supporting the • benefits clinicians by: patient journey - providing access tools and technologies that assist in making the best and emerging possible clinical decision for the patient; models of care - 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 Goal State Architecture Principle Health Business Driver 1 The current • There will be fewer deployment points for clinical infrastructure is systems based on the level of infrastructure maturity of immature compared to AHSs industry standards, • Clinical systems will be in a high availability complex, not flexible and environment costly to operate • the technical infrastructure is standardised on proven and mature technologies 2 Blockages in the patient • Supports one view of the patient across all care journey within large settings complex care settings are • Provides visibility and planning tools for all beds within ICIP will impacting on patient acute settings accommodate access to clinical services • Supports rostering and scheduling of clinical staff to better meet patient demand multiple providers 3 The ICIP systems are • Will accommodate multiple providers and multiple and technology deployed using different technology platforms to deliver the same ICIP platforms while at combinations of software capabilities while at the same time promoting the same time hosted on different standardisation of processes and information flows promoting platforms across settings and AHSs standardisation of 4 Lack of visibility of • Single area wide patient repository processes and patient information • There will be mechanisms for sharing information information flows across and within settings across settings (eg eHR) across settings and • There will be flow management tools available AHSs 5 Inter area process flows • Improved access and single point of entry to clinical are significant and not information for all clinicians (acute, community, GP) proactively controlled • Standard deployments to reduce variability in clinical practice 6 A greater and emerging • Supports clinical processes and transfers of clinical emphasis on supporting information across settings care in the community • Provides visibility of the clinical pathways and the ICIP Architecture Review Page 19
  20. 20. 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 7 Adverse events occurring • Provides for the unique identification of patients at the in medication point of care, along with access to longitudinal clinical administration and information and medical history surgery • Supports the implementation of standard protocols, decision support processes and data structures across the state 8 Aged Care and Chronic • Allows different settings to share a single view of a Care are areas of patient and to share a care plan, enabling improved increased demand due to treatment in the community (i.e. keep people out of longer life spans and hospital) improved treatment • Supports the deployment of standard processes and programs protocols for managing chronic diseases. 9 AHS mergers will • Provides a long term strategy for aligning AHS networks dramatically change the and systems current balance of ICIP • Has the flexibility to accommodate changes in AHS systems and will combine boundaries incompatible systems and networks together 10 Because of an inadequate • Enables strong link between people and technology to focus and integration drive patient care between technology and • Programs and projects have a defined goal to support human performance, ICIP clinical processes and decisions initiatives not providing • Human performance strategy managed by Program clinicians with an Management Office (PMO) optimum level of support ICIP Architecture Review Page 20
  21. 21. 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 requirements, thereby reducing the risk of over investment. distinct phases with 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