Guideline. Enterprise Architecture Guide. 1. Purpose. 2. Scope. 3. Related documents. 4. Enterprise Architecture Guide

Transcription

1 Guideline Policy # QH-GDL :2014 Guide 1. Purpose This Guideline provides an overview of the document structure of the Department of Health, an index to its contents and a consolidated definitions table. 2. Scope This Guideline applies to all employees, contractors and consultants within the Department of Health divisions, commercialised business units and agencies. 3. Related documents Authorising Policy and /s: Policy Framework Implementation Enterprise Business s Procedures, Guidelines and s: Sustainability Service Oriented Architecture Systems Integration Development Method Procedure Procedure 4. Guide 4.1 The Department of Health The Department of Health (DHEA) extends the Queensland Government to categorise specific Queensland Health Enterprise Architecture content. The Policy suite includes the documents that comprise the Department of Health as shown in the following diagram: The DHEA guides decision making by identifying applicable policies, positions and mandated standards aligned to five architecture domains (business, information, application, technology and information security). Effective From: 05/06/2014 Page 1 of 30

2 Department of Health: Guideline Common areas of multiple domains are noted within the relevant implementation standards. The policy and supporting documents apply to all employees, contractors and consultants within the Department of Health divisions, agencies and commercialised business units. 4.2 Benefits of the Strategically aligned Alignment with the Department of Health Policy will ensure that current and future ICT solutions and services: support the department s vision, strategic plans, and performance objectives are designed, implemented and managed according to the requirements of the Department of Health and the Queensland Government support accountable and contestable investments in technology with the adoption of an as-a-service approach by default. Patient centric Patient-focused information and data models underpinning ICT solutions and services will support the patient centric view of service delivery including rights of access, safety, respect, participation and privacy. Effective From: 05/06/2014 Page 2 of 30

3 Department of Health: Guideline Accessible services and integration between ICT solutions and services will enable secure exchange and access to accurate, timely and trustworthy sources of information across the continuum of care. Sustainable and effective solutions Quality ICT solutions and services will be developed to ensure efficient and effective use of information and to meet the growing demands and future needs of the Department of Health. s based An adaptable, scalable and evolvable architecture that includes recognised information, messaging and infrastructure standards specific to healthcare will lead to innovative and responsive ICT solutions and services, value for money and clearly articulated benefits. 4.3 Policy Artefacts Policy The Policy is a policy instrument that describes the position of the Department of Health regarding current and future business and technical architectures to support the department s vision, strategic plans, and performance objectives. The policy document includes the policy statement, principles, references and definitions that apply across the enterprise architecture. The policy is supported by a number of implementation standards, protocols, procedures and technical specifications. Development Method Procedure The Development Method describes the processes, inputs, outputs, guides and enablers that guide the development and maintenance of the Enterprise Architecture including the governing. Information Security Framework The Security Architecture elements have been included in the following Department of Health policy artefacts: Implementation for Information Security includes the ten domains of the Security Architecture for Information Security includes specific requirements for Information Exchange (Section 9.10 Department of Health Specific Requirements Information Exchange). Framework Implementation The Framework Implementation describes the minimum mandatory requirements to comply with the Department of Health. The standard includes the following sections: 5.1 Overview 5.2 Compliance and Dispensation 5.3 Domains 8.0 Responsibilities Table (included in all Implementation s) The describes the foundations for applying the Department of Health. Enterprise architecture foundations include principles, quality attributes and broad design goals. These foundational elements shape the and drive architectural requirements for implementations and procurements. They provide validation points for decision making by architects in both devising and governing solutions. The standard includes the following sections: Effective From: 05/06/2014 Page 3 of 30

4 Department of Health: Guideline 5.1 Principles, Rationale and Implications Align to Organisational Readiness Do No Harm Enterprise above Solution Manage Shared Assets as Queensland Health Assets Manage Technical Diversity Reuse, then Buy, then Build Separation of Concerns Authoritative Source Strategic and Tactical Unbiased Architecture 5.2 Quality Attribute Requirements Accessibility Adaptability Availability Maintainability Performance Scalability Usability 5.3 Broad Design Goals Best practices Integrated Systems Model Driven Patient Centricity Privacy Reuse Security Service Orientation s Based Unique Identification Web Enabled Enterprise Business The Enterprise Business describes the requirements for applying the Department of Health Enterprise Business Architecture. The Business Architecture describes how the Department of Health uses or manages its business services and processes in support of the organisation s strategic and operational imperatives. The standard includes the following sections: 5.1 Business Domain 5.2 Business Process Classification 5.3 Mandated Business Architecture Artefacts 5.4 Business Architecture s Business processes not having currently applicable positions Manage Information and Technology Resources [QP-BP-9] Appendix 1 Department of Health Process Classification Diagram Appendix 2 Business Products and Services Portfolio Classification (Department of Health) to Queensland Government Business Classification Alignment The describes the requirements for applying the Department of Health Architecture. The architecture describes how the Department of Health manages information throughout its lifecycle and defines the information flows between information systems. Information Effective From: 05/06/2014 Page 4 of 30

5 Department of Health: Guideline resources shall be planned and managed in accordance with the Information Architecture to ensure that information is trustworthy and appropriately available for use throughout the Department of Health. The standard includes the following sections: 5.1 Information Domain 5.2 Information Process Classification 5.3 Mandated Information Architecture Artefacts 5.4 Business Architecture Policy Considerations 5.5 Information Architecture s Controls [QH-I-1] Plans [QH-I-2] Responsibilities [QH-I-3] Cases [QH-I-4] Events [QH-I-5] Interactions [QH-I-6] Services [QH-I-7] Infrastructures [QH-I-8] Parties [QH-I-9] Places [QH-I-10] Products [QH-I-11] Resources [QH-I-12] 5.6 Mandated Information s Client Directory Number Clinical Data s Appendix 1 Department of Health Information Classifications Diagram Appendix 2 Department of Health Process Classification to Queensland Government Business Process Classification Alignment The describes the requirements for applying the Department of Health Architecture. The architecture describes the specific directions, constraints and requirements in the application domain and describes how applications can deliver business and information needs. The architecture will guide and constrain decisions to ensure that its application portfolio meets the needs of the enterprise and its stakeholders. The standard includes the following sections: 5.1 Application Domain 5.2 Application Portfolio Classification 5.3 Mandated Application Architecture Artefacts 5.4 Application Architecture s Generic Service Delivery [QH-A-1] Line of Business Service Delivery [QH-A-2] Client/Patient Relationship Management [QH-A-3] Research Management, Science and Engineering [QH-A-4] Supply Chain Management [QH-A-5] Enterprise Resource Planning [QH-A-6] Organisational Optimisation [QH-A-7] Health Service Delivery [QH-A-8] Enterprise Services [QH-ES] 5.5 Mandated Application s Sustainability Appendix 1 Department of Health Application Portfolio Classification Diagram Clinical Application Portfolio Classification Diagram (QH-A-8.2 expanded) Effective From: 05/06/2014 Page 5 of 30

6 Department of Health: Guideline Appendix 2 Common Service Classification Diagram Appendix 3 Department of Health Application Products and Services Portfolio Classification () to Queensland Government Application Classification Alignment The describes the requirements for applying the Department of Health Architecture. The architecture describes the specific directions, principles, constraints and requirements in the technology domain and describes how commodity technology can deliver business and information needs. The architecture will guide and constrain decisions to manage the diversity of particular classes of technology product or service across the Department of Health. The standard includes the following sections: 5.1 Technology Domain 5.2 Technology Portfolio Classification 5.3 Mandated Technology Architecture Artefacts 5.4 Technology Architecture s Desktop and Productivity [QH-T-1] s Application Environments [QH-T-2] System Software [QH-T-3] Physical and Virtual Devices [QH-T-4] Management and Control Software [QH-T-5] ICT Equipment Accommodation and Cabling [QH-T-6] 5.5 Mandated Technology s Enterprise single sign-on and context management Consistent Time Service ICT Cabling Appendix 1 Department of Health Technology Products and Services Portfolio Classification Diagram Appendix 2 Department of Health Technology Products and Services () Portfolio Classification to Queensland Government Technology Classification Alignment Sustainability This protocol describes the mandatory steps for establishing and maintaining sustainable information systems in the delivery of healthcare for the Department of Health. The primary focus is future-proofing information systems and enabling legacy systems to ensure that Queensland Health information systems meet ongoing business requirements within accepted cost, technology and quality constraints. The protocol includes the following sections: 5 Sustainability Approach 6 Application components 6.1 Reuse application functionality before buying or building 6.2 Acquire applications with interchangeable components 6.3 Consolidate common functionality into reusable services 6.4 Tailor through configuration in preference to customisation 6.5 Minimise customisation of COTS applications 6.6 Configure user interfaces to provide common look and feel across the Queensland Health system enterprise Effective From: 05/06/2014 Page 6 of 30

7 Department of Health: Guideline 7 Legacy transformation 7.1 Use legacy transformation to reuse legacy functionality 7.2 Integrate business workflows across information system silos 7.3 Selectively web-enable applications with non-contemporary interfaces 7.4 Enable clinical applications to use clinical context sharing 7.5 Selectively use specialised user interface components 8 Data 8.1 Synchronise cached data with an authoritative source 8.2 Hide internal data models and terminologies from external systems 8.3 Do not access data from transactional information systems directly 8.4 Separate transactional information repositories from authoritative sources 9 s 9.1 Adopt endorsed Australian and national standards 9.2 Implement interfaces that conform to established standards 10 Application management 10.1 Maintain currency of commercial applications 10.2 Minimise diversity of application components 10.3 Document applications This protocol describes the mandatory steps for achieving integration-based system interoperability in the delivery of healthcare for Queensland Health. This protocol will inform decision makers and provide direction that balances cost-effectiveness, sustainability and healthcare outcome benefits with the broad goal of achieving system interoperability across the whole of the Queensland Health s environment, and across organisational boundaries. The protocol includes the following sections: 5 approach 6 Information interoperability 6.1 Use Australian and International standards 6.2 Ensure terminology is compliant with the Department of Health terminology standards 6.3 Restrict data entry values to permissible value sets 6.4 Use extensions where standard interfaces need to be modified 6.5 Apply business rules consistently across systems 7 Technical interoperability 7.1 Use the enterprise integration platform to support interoperability 7.2 Do not expose proprietary internal data models and terminologies 7.3 Use web services to support loosely coupled interoperable systems 7.4 Use the E-health Web Services Profiles for interactions with external healthcare organisations. 7.5 Use the QGEA Web Services standard where no other standard is mandated 8 standards 8.1 Adopt national e-health standards and specifications 8.2 Use HL7 Version 2.x for sharing electronic health record information via HL7 8.3 Use HL7 Clinical Document Architecture to exchange structured documents 8.4 Use DICOM for transmitting and storing medical images 8.5 Enable clinical applications to use clinical context sharing Effective From: 05/06/2014 Page 7 of 30

8 Procedure Department of Health: Guideline This procedure guides decision making for designing an integration environment that allows information to be shared quickly and accurately throughout the organisation and across organisational boundaries, in a secure fashion that satisfies privacy and consent concerns in the delivery of healthcare for the Department of Health. The procedure includes the following sections: 5 Integration environment approach 6 Functional integration patterns 6.1 Point to Point (Direct Connection) 6.2 Broker 6.3 Mediated Request / Response 6.4 Content-based Router 6.5 Publish / Subscribe 6.6 Scatter-Gather 6.7 Process Manager 6.8 Orchestration Serial Process 6.9 Orchestration Parallel Process 6.10 Process Choreography 6.11 Complex Event 7 Composite Patterns - Functional & Data Integration 7.1 Database in - Message out 7.2 File in Message out 7.3 Message in Database out 7.4 Message in File out 8 Data integration 8.1 Shared Database 8.2 File Transfer 8.3 Maintain Data Copies 8.4 Population 8.5 Replication 8.6 Federation 8.7 Operational Data Store Service Oriented Architecture This protocol describes the mandatory steps for applying Service Oriented Architecture (SOA) principles and concepts in the design and delivery of common functionality within the Department of Health. Note Details of the contents of the protocol will be included here when the draft document is finalised. The protocol includes the following sections: 5 approach Deploy SOA services in an incremental fashion 6.2 Use third party services in preference to in-house services 7 Service architecture 7.1 Only acquire services when predefined criteria are satisfied 7.2 Use deployed services wherever the capability fits the requirement Effective From: 05/06/2014 Page 8 of 30

9 Department of Health: Guideline 7.3 Design services without being constrained by existing consuming applications 7.4 Support non service-enabled applications with data integration 7.5 Access service data via the provided service interfaces 7.6 Do not use services designed for transactional use in business intelligence applications 7.7 Use common security mechanisms 8 Operational infrastructure 8.1 Insulate service consumers from having to know service locations 9 ICT systems lifecycle 9.1 Manage enterprise services as shared assets 9.2 Publish services in a central design time directory 9.3 SOA-style services are centrally governed 9.4 Include service capability requirements in all procurement offers 9.5 Separate service provision from service consumption Systems Integration This protocol describes the mandatory steps for the use of integration technologies and standards to support decision making, ensuring trusted and accessible integration where and when needed, and using cost-effective and sustainable integration capabilities. The protocol includes the following sections: 5 Systems integration approach 6 Integration platform 6.1 Use the enterprise integration platform 6.2 Manage the enterprise integration platform centrally 6.3 Maintain quality of service to meet the most demanding integration needs 6.4 Use the External Gateway for all external application integration 7 Integration approach 7.1 Avoid using point-to-point interfaces 7.2 Use data integration for large scale data movement and data synchronisation 7.3 Separate integration logic from business logic 7.4 Limit the sending of unsolicited information 7.5 Align integration interfaces with approved integration patterns 7.6 Limit validation performed in the integration layer 7.7 Centralised translation logic 8 Commercial off the shelf packages 8.1 Limit use of application s own integration engine to within its own suite 9 ICT systems lifecycle 9.1 Document all interfaces in a central integration register ICT Cabling This protocol describes the mandatory steps for ICT Cabling undertaken on behalf of Department of Health to ensure cost effective design and construction of communication distribution infrastructure, built on low voltage cabling systems, at Department of Health owned and leased facilities. Compliance with this protocol will ensure that the ICT cabling infrastructure will support the Department of Health s complex and diverse ICT environments. Effective From: 05/06/2014 Page 9 of 30

10 The protocol includes the following sections: 5 Process for ICT Cabling 5.1 ICT Cabling Application 5.2 ICT Cabling Compliance 4.4 Index to Contents Department of Health: Guideline The following table is an index to the contents of the policy and supporting documents. Contents of additional enterprise architecture artefacts are added as documents are finalised. The definitions are provided separately in the Definitions table in Section 7. Topic Context Document Section Access service data via the provided service interfaces Accessibility Acquire applications with interchangeable components Adaptability Adopt endorsed Australian and national standards Adopt national e-health standards Align integration interfaces with approved integration patterns Align service interfaces with the Department of Health system-wide information model Align to Organisational Readiness Application Architecture s Application components Application Environments [QH-T-2] Application management Apply business rules consistently across systems Apply user interface technologies where appropriate to support data entry Service architecture Quality Attribute Requirement Application components Quality Attribute Requirement s standards Integration approach Service architecture Principle, Rationale and Implications Technology Architecture Information interoperability Information interoperability protocol Sustainability Sustainability protocol Sustainability Sustainability Effective From: 05/06/2014 Page 10 of 30

11 Department of Health: Guideline Topic Context Document Section Authoritative Source Availability Avoid using point-to-point interfaces Best practices Broker Business Architecture Policy Considerations Business Architecture s Business Products and Services Portfolio Classification (Department of Health) to Queensland Government Business Classification Alignment Cases [QH-I-4] Centralised translation logic Client Directory Number Client/Patient Relationship Management [QH-A-3] Clinical Application Portfolio Classification Diagram (QH-A-8.2 expanded) Clinical Data s Commercial off the shelf packages Common Service Classification Diagram Common Services [QH- CS] Common Services are an authoritative source Complex Event Principle, Rationale and Implications Quality Attribute Requirement Integration approach Broad Design Goal Functional integration patterns Information Architecture Integration approach Mandated Information Mandated Information Mandated Information Mandated Information Service architecture Functional integration patterns Enterprise Business Architecture Implementation Enterprise Business Architecture Implementation Effective From: 05/06/2014 Page 11 of Appx Appx Appx protocol

12 Department of Health: Guideline Topic Context Document Section Composite Patterns - Functional & Data Integration Configure user interfaces to provide common look and feel across the Queensland Health system enterprise Consider HSSP standards for common services interfaces Consider IHE profiles where there is a clearly defined benefit Consistent Time Service Consolidate common functionality into reusable services Content-based Router Controls [QH-I-1] Application components standards standards Mandated Technology Application components Functional integration patterns Information Architecture Sustainability Sustainability Create reusable Integration approach integration services from existing components 7.5 Data Sustainability 8 Data integration 8 Database in - Message Composite Patterns - out Functional & Data Integration 7.1 Defer introduction of Integration platform advanced integration capabilities 6.5 Deliver reusable components as services Service Oriented architecture protocol 6.2 Department of Health Process Classification to Queensland Government Business Process Classification Alignment Department of Health Application Portfolio Classification Diagram Department of Health Application Products and Services Portfolio Classification to Queensland Government Application Classification Alignment Appx. 2 Appx. 1 Appx. 3 Effective From: 05/06/2014 Page 12 of 30

13 Department of Health: Guideline Topic Context Document Section Department of Health Information Classifications Diagram Department of Health Technology Products and Services Portfolio Classification to Queensland Government Technology Classification Alignment Department of Health Technology Products and Services Portfolio Classification Diagram Deploy SOA services in an incremental fashion Design services without being constrained by existing consuming applications Desktop and Productivity [QH-T-1] s Do No Harm Do not access data from transactional information systems directly Do not expose proprietary internal data models and terminologies Do not use services designed for transactional use in business intelligence applications Document all interfaces in a central integration register Service Oriented architecture Service architecture Technology Architecture Principle, Rationale and Implications Data Technical interoperability Service architecture ICT systems lifecycle Effective From: 05/06/2014 Page 13 of 30 Appx. 1 Appx. 2 Appx. 1 protocol 6.1 protocol Sustainability protocol Document applications Application management Sustainability 10.3 Enable clinical applications to use clinical Legacy transformation Sustainability context sharing 7.4 Enable clinical context sharing for clinical applications Ensure terminology is compliant with the Department of Health terminology standards Enterprise above Solution standards Information interoperability Principle, Rationale and Implications Overview Framework Implementation

14 Department of Health: Guideline Topic Context Document Section Application Domain 5.1 Application Portfolio Classification Broad Design Goals Business Domain Business Process Classification Compliance and Dispensation Domains Information Domain Information Process Classification Principles (short form) Principles, Rationale and Implications Quality Attribute Requirements Technology Domain Technology Portfolio Classification Enterprise Resource Planning [QH-A-6] Enterprise single sign-on and context management Establish central point of governance for SOA-style services Events [QH-I-5] Expose common services via the enterprise Mandated Information Mandated Technology ICT systems lifecycle Information Architecture Integration platform Enterprise Business Architecture Implementation Enterprise Business Architecture Implementation Framework Implementation Framework Implementation Policy protocol Effective From: 05/06/2014 Page 14 of

15 Department of Health: Guideline Topic Context Document Section integration platform Expose services via the Enterprise Service Bus Operational infrastructure protocol 8.1 Federation Data integration 8.6 File in Message out Composite Patterns - Functional & Data Integration 7.2 File Transfer Data integration 8.2 Functional integration patterns 6 Generic Service Delivery [QH-A-1] Health Service Delivery [QH-A-8] Hide internal data models and terminologies from external systems ICT Cabling ICT Equipment Accommodation and Cabling [QH-T-6] ICT systems lifecycle Mandated Information Mandated Information Data Mandated Technology Technology Architecture Sustainability protocol 9 ICT systems lifecycle 9 Implement interfaces that conform to established standards Include service capability requirements in all procurement offers Incorporate interoperability standards in the Department of Health information model Information Architecture s Information interoperability Sustainability Approach Infrastructures [QH-I-8] Insulate service consumers from having to know service locations Integrate business workflows across information system silos s ICT systems lifecycle Information interoperability Information Architecture Operational infrastructure Legacy transformation Sustainability protocol Sustainability protocol Sustainability Effective From: 05/06/2014 Page 15 of 30

16 Integrated Systems Department of Health: Guideline Topic Context Document Section Broad Design Goal Integration approach 7 Integration environment approach 5 Integration platform 6 Intent of this policy Policy Interactions [QH-I-6] Information Architecture Mandated Application Quality Attribute Requirement approach 5 standards 8 Legacy transformation 7 Sustainability Legislative or other Policy Authority Limit the sending of Integration approach unsolicited information 7.6 Limit use of application s own integration engine to within its own suite Limit validation performed in the integration layer Line of Business Service Delivery [QH-A-2] Commercial off the shelf packages Integration approach Mandated Information Effective From: 05/06/2014 Page 16 of Maintain currency of Application management commercial applications Sustainability 10.1 Maintain Data Copies Data integration 8.3 Maintain quality of service to meet the most demanding integration needs Integration platform 6.4 Maintainability Quality Attribute Requirement Manage common services as shared assets Manage Information and Technology Resources [QP-BP-9] Manage Shared Assets as Queensland Health Assets Manage Technical Diversity ICT systems lifecycle Business Architecture Principle, Rationale and Implications Principle, Rationale and Implications protocol 9.1 Enterprise Business Architecture Implementation

17 Department of Health: Guideline Topic Context Document Section Manage the enterprise integration platform centrally Management and Control Software [QH-T-5] Mandated Application Architecture Artefacts Mandated Application Architecture Requirements Mandated Business Architecture Artefacts Mandated Information Architecture Artefacts Mandated Information Architecture Requirements Mandated Technology Architecture Artefacts Mandated Technology Architecture Requirements Mediated Request / Response Message in Database out Integration platform Technology Architecture Functional integration patterns Composite Patterns - Functional & Data Integration Message in File out Composite Patterns - Functional & Data Integration Minimise customisation of Application components COTS applications Minimise diversity of Application management application components Model Driven Broad Design Goal Only acquire services when predefined criteria are satisfied Service architecture Enterprise Business Architecture Implementation Sustainability Sustainability protocol 7.1 Operational Data Store Data Integration 8.7 Operational infrastructure protocol 8 Orchestration Parallel Process Functional integration patterns 6.9 Orchestration Serial Process Functional integration patterns 6.8 Organisational Optimisation [QH-A-7] Mandated Information Effective From: 05/06/2014 Page 17 of 30

18 Parties [QH-I-9] Patient Centricity Performance Physical and Virtual Devices [QH-T-4] Places [QH-I-10] Plans [QH-I-2] Department of Health: Guideline Topic Context Document Section Information Architecture Broad Design Goal Quality Attribute Requirement Technology Architecture Information Architecture Information Architecture Effective From: 05/06/2014 Page 18 of Point to Point (Direct Connection) Functional integration patterns 6.1 Policy statement Policy Population Data integration 8.4 Privacy Broad Design Goal Process Choreography Process Classification Diagram (Department of Health) Process Manager Procurement considerations Products [QH-I-11] Provide application to enterprise mediation Publish / Subscribe Publish services in a central design time directory Rationalisation and retirement Related policy or documents Functional integration patterns Functional integration patterns ICT systems lifecycle Information Architecture Commercial off the shelf packages Functional integration patterns ICT systems lifecycle ICT systems lifecycle Enterprise Business Architecture Implementation protocol Policy 6.10 Appx Replication Data integration 8.5 Research Management, Science and Engineering [QH-A-4] Mandated Information Resources [QH-I-12] Information Architecture

19 Department of Health: Guideline Topic Context Document Section Responsibilities [QH-I-3] Information Architecture Responsibilities Table (included in all Implementation s) Restrict data entry values to permissible value sets Reuse Reuse application functionality before buying or building Reuse, then Buy, then Build Scalability Scatter-Gather Security Selectively use specialised user interface components Selectively web-enable applications with noncontemporary interfaces Separate integration logic from business logic Separate service provision from service consumption Separate transactional information repositories from authoritative sources Separation of Concerns Service architecture Service Orientation Service Oriented architecture Service Oriented architecture approach Services [QH-I-7] Information interoperability Broad Design Goal Application components Principle, Rationale and Implications Quality Attribute Requirement Functional integration patterns Broad Design Goal Legacy transformation Legacy transformation Integration approach ICT systems lifecycle Data Principle, Rationale and Implications Broad Design Goal Information Architecture Framework Implementation Sustainability Sustainability Sustainability protocol Sustainability Effective From: 05/06/2014 Page 19 of protocol protocol 6 protocol

20 Department of Health: Guideline Topic Context Document Section Shared Database Data integration 8.1 s Sustainability 9 s Based Strategic and Tactical Supply Chain Management [QH-A-5] Support non serviceenabled applications with data integration Supporting documents Sustainability Synchronise cached data with an authoritative source System Software [QH-T- 3] Broad Design Goal Principle, Rationale and Implications Mandated Information Service architecture Mandated Application Data Technology Architecture protocol Policy Sustainability Systems integration approach 5 Tailor through Application components 6.4 configuration in Sustainability preference to customisation Technical interoperability 7 Technology Architecture 5.4 s Unbiased Architecture Unique Identification Usability Use a common structure and common language for all data exchanges Use Australian and International standards Use common security mechanisms Use data integration for large scale data movement and data Principle, Rationale and Implications Broad Design Goal Quality Attribute Requirement Information interoperability Information interoperability Service architecture Integration approach Effective From: 05/06/2014 Page 20 of protocol

21 Department of Health: Guideline Topic Context Document Section synchronisation Use deployed services wherever the capability fits the requirement Use DICOM for transmitting and storing medical images Use extensions where standard interfaces need to be modified Use functional integration in preference to data integration and presentation integration Use HL7 Clinical Document Architecture to exchange structured documents Use HL7 Version 2.x for sharing electronic health record information via HL7 Use legacy transformation to reuse legacy functionality Use mediation services to integrate with COTS/legacy systems Use the E-health Web Services Profiles for interactions with external healthcare organisations. Use the enterprise integration platform Use the enterprise integration platform to support interoperability Use the External Gateway for all external application integration Use the QGEA Web Services standard where no other standard is mandated Use the state-wide information model to define integration data structures Use third party services in preference to in-house services Use web services to support loosely coupled interoperable systems Service architecture standards Information interoperability Integration approach standards standards Legacy transformation Service architecture Technical interoperability Integration platform Technical interoperability Integration platform Technical interoperability Integration approach Service Oriented architecture Technical interoperability protocol Sustainability protocol protocol Effective From: 05/06/2014 Page 21 of 30

22 Web Enabled Department of Health: Guideline Topic Context Document Section Broad Design Goal Review This Guideline is due for review on: 05 June 2016 Date of Last Review: N/A Supersedes: New Guideline 6. Business Area Contact Director, Strategy and Architecture Office, Planning, Engagement and Performance Directorate, Health Services Information Agency (HSIA) 7. Definitions of terms used in the policy and supporting documents Term Definition / Explanation / Details Source Abstraction Application component Application Integration Applications Artefact Authoritative source Broad Design Goals In the context of this paper, abstraction refers to an integration approach where existing system interface is made available externally to the application via an abstraction layer using the integration platform. A generic term that applies to an entire business application or a modular, deployable, and replaceable part of a system that encapsulates its contents and exposes its functionality through a set of interfaces. Integration refers to the set of technologies and services that enable the exchange of information between systems and applications across the enterprise. A software system deployed by the agency which has part of an agency's business process embedded with it, for example, SAP. Artefacts are documents that are components of the Department of Health including but not limited to the policy, standards, protocols, procedures and guidelines. An authoritative source is the one data source from a set of competing data sources that is designated by the enterprise as the most trusted and complete and representative of the truth. Any emergent discrepancies between competing data sources will be resolved by reference to the authoritative source. The term source of truth is synonymous with the term authoritative source with the latter being the preferred term for the purposes of enterprise architecture. This topic is discussed further in the Department of Health ICT guideline - Master Data Management. Enterprise architecture contributes to the organisational strategy by describing how ICT solutions should be designed and delivered to satisfy business objectives. Broad design goals provide an overall description of how organisational strategies will be achieved. They are not solutions to strategic objectives in their own right, but provide patterns and Sustainability, Procedure Sustainability Procedure, Integration Patterns Procedure Queensland Government Chief Information Office (QGCIO) Glossary Adapted from QGCIO Glossary Adapted from QGCIO Glossary Sustainability,, Service Oriented Architecture Effective From: 05/06/2014 Page 22 of 30

23 Department of Health: Guideline Term Definition / Explanation / Details Source approaches that will ensure that conformant solutions help achieve the strategies. Broad design goals are intended to be applied to the design and development of solutions. Business Activity Monitoring (BAM) Business Directories Business Logic Business Process Execution Language (BPEL) Canonical form Choreography Clinical Context Object Workgroup (CCOW) Clinical Document Architecture (CDA) Coarse-grained authorisation Commercial offthe-shelf (COTS) Common Service Common Service Business Activity Monitoring refers to the real time monitoring, analysis, and presentation of SOA enabled business activities inside enterprises. Business activity monitoring software assists in monitoring these business activities. Business directories are common services that provide business related master data to be used directly in business transactions. The kinds of master data suitable for provision by business directories are Employees, Patients, Providers, Locations and Services. The logic within an application that deals with the implementation of business policies, rules, practices and procedures for relevant business functions or processes. BPEL is a standard executable language for specifying actions within business processes. Processes in BPEL export and import information by using web service interfaces. The data standards, structures, definitions and terminologies that are used within the integration environment. Choreography is concerned with asynchronous work flows usually involving interaction with external enterprises. Choreography defines the steps and conditions under which cooperating independent participants exchange messages in order to perform a task. Unlike orchestration, there is no central controlling service or conductor. The integration platform coordinates interaction with its immediate peers, but plays no part in coordinating interaction between other systems involved in the process. The HL7 CCOW (Clinical Context Object Workgroup) is a standard for providing a unified view on the information held in separate and disparate healthcare applications referring to the same patient, encounter or user using a technique known as context management. Clinical Document Architecture is an HL7 standard which provides an exchange model for clinical documents (such as discharge summaries and progress notes). It uses XML, the HL7 Reference Information Model (RIM) and coded vocabularies, to make documents both machine-readable and human-readable. A mechanism for determining permissions for accessing a resource. Commercial off-the-shelf refers to products that are sold in the commercial marketplace. An information system component that delivers core business functionality common to multiple applications including access to shared authoritative information. Common Services (also known as Common Business Services) provide core business functionality that is common to multiple applications (e.g. Clinical Data Service, Provider Directory Service, Terminology Service etc.). Common Services deliver cross-cutting or common functionality. Effective From: 05/06/2014 Page 23 of 30 Systems Integration Using Directories and Directory Technology Procedure, Systems Integration Procedure, Systems Integration Systems Integration QGCIO Glossary Sustainability, Service Oriented Architecture Identity Management and Demographics Sustainability, Systems Integration, Integration Patterns Procedure Common Service An information system component that delivers core business Service Oriented

24 Department of Health: Guideline Term Definition / Explanation / Details Source functionality common to multiple applications including access to Architecture shared authoritative information. Confidentiality Credential Management Data Integration Data Integration Queensland Health Digital Imaging and Communications in Medicine (DICOM) Directories Directory Services Directory Technologies Dispensation Domain Ensuring that data or information is accessible only to those authorised and is protected from unauthorised disclosure or intelligible interception. A business function incorporating processes for managing the lifecycle of any entity s credentials. Used when applications need to share data from files or databases, as opposed to integration via the business logic layer. This style of integration is widely applied in the Business Intelligence domain for population of analytical repositories such as Data Warehouses and Data Marts. There are also still many applications where File Transfer is used to move large volumes around. Data Integration is widely supported by vendors, non-invasive to the application, and can handle large volumes of data. Used when applications need to share data from files or databases, as opposed to integration via the business logic layer. This style of integration is widely applied in the Business Intelligence domain for population of Data Warehouses and Data Marts. There are also still many applications where File Transfer is used to move large volumes around. Data Integration is widely supported by vendors, non-invasive to the application, and can handle large volumes of data. The Department of Health and the Hospital and Health Services (HHSs), making up the public healthcare system, is known as Queensland Health Digital Imaging and Communications in Medicine is a standard for handling, storing, printing, and transmitting information in medical imaging. It includes a file format definition and a network communications protocol. A directory is a Common Service data store that provides authoritative data on key topics and includes the means of managing and accessing the data. A directory operates in much the same way as the White Pages (lookup) and Yellow Pages (search) phone books. Directory services are the defined methods or protocols by which entity information can be accessed, retrieved or updated from enterprise directory systems. Directory technologies are technology products that provide a data store and access method for managing collections of information about entities. For the purpose of this policy, the term dispensation means the endorsed exception from compliance with the enterprise architecture. The categories used as part of the Queensland Government and Department of Health s to provide a consistent and convenient method of logically grouping Queensland Government Chief Information Office (QGCIO) Glossary Adapted from QGCIO Glossary, Identity Management and Demographics Sustainability Procedure, Systems Integration, Systems Integration Systems Integration, QGCIO Glossary Using Directories and Directory Technology Using Directories and Directory Technology Adapted from QGCIO Glossary Policy and standards Effective From: 05/06/2014 Page 24 of 30

25 Department of Health: Guideline Term Definition / Explanation / Details Source business processes, information assets, applications and technologies and ICT initiatives into meaningful and manageable areas for analysis. Encapsulation Enterprise Enterprise Application Integration (EAI) Enterprise Architecture Enterprise ICT Service Enterprise Service Enterprise Integration Platform Enterprise Service Bus (ESB) External Gateway External Rules Engine Extract, transform and load (ETL) Fine-grained authorisation Encapsulation is an integration approach that enables existing system functionality to be exposed in a way where that functionality is ONLY able to be consumed as an integration service through the integration platform applications cannot bypass the integration layer to access the functionality directly. The Department of Health and the Hospital and Health Services (HHSs) make up the public healthcare system known as Queensland Health. The use of the word enterprise within this document indicates the public healthcare system as it is influenced by enterprise architecture. EAI is the sharing of information amongst applications or data sources connected to a central integration framework that facilitates exchange of data and messages. EAI technologies generally support a range of legacy integration capabilities. The practice of applying a comprehensive and rigorous method for describing a current and future structure and behaviour for an organisation's processes, information, applications, technology and human resources, so that they align with the organisation's strategic direction. Enterprise ICT Services are described in the ICT Service Catalogue available on the QHEPS intranet. Enterprise Services provide core business functionality that is common to multiple applications (e.g. Clinical Data Service, Provider Directory Service etc) The central integration capability (currently JCAPS and e*gate) managed by the HSIA Systems Integration Team. In future this will be the new ESB/EAI platform. ESB is an application infrastructure component that enables integration using common business services that are made available across the organisation to consuming applications or business processes. A software component that is used to control exchange of information (messages, documents, services) across the organisation boundary. It is used to apply appropriate security controls and transform between external and internal formats. It can be thought of as an extension to the ESB for external integration. A software engine used to record, track, manage and revise system business processes, without having to modify the software application itself. The Rules Engine externalises the rules for quick and easy modification Extract, transform and load is a process in database usage and especially in data warehousing that involves extracting data from data sources; transforming the data to fit target needs; and loading it into the end target A mechanism for determining permissions for performing a specific action within a resource. Sustainability, Procedure Policy, Integration Patterns Procedure Procedure, Systems Integration QGCIO Glossary Policy and s Policy and s Sustainability, Systems Integration Procedure,, Service Oriented Architecture, Systems Integration Procedure, Systems Integration Procedure Sustainability, Procedure Using Directories and Directory Technology Effective From: 05/06/2014 Page 25 of 30

26 Department of Health: Guideline Term Definition / Explanation / Details Source Fit for purpose Functional Integration Health Level Seven (HL7) Healthcare Services Specification Project (HSSP) Information Information Model Integrating the Healthcare Enterprise (IHE) Integration logic Integration Platform Interface Contract The extent to which the current functionality of the Information Asset/Application/ Technology meets the need of the particular business area (NB: not the entire business of the agency) in which it is used The integration of the functional flow of processing between applications. Used to integrate applications via the business logic layer by allowing the business functionality in one application to be accessed by other applications. Functional Integration can be done through a number of integration technologies such as Enterprise Service Bus (ESB) and Integration (EAI). Health Level Seven (HL7) is an American National s Institute (ANSI) accredited, not-for-profit standards-development organisation whose mission is to provide standards for the exchange, integration, sharing, and retrieval of electronic health information; support clinical practice; and support the management, delivery and evaluation of health services. The Healthcare Services Specification Project is a collaboration effort involving standards groups (Health Level Seven and Object Management Group are the charter organisations) collaborating to address interoperability challenges within the healthcare sector. For the purposes of this paper Information covers the non-technical aspects of interoperability. (The technical aspects are covered under the Technical section). The Department of Health Information Model refers to the collection of models, data set specifications (DSS) and standards that have been iteratively developed across the organisation. Key sources of data standards include the Queensland Health Data Dictionary and the Corporate Reference Data System. Within the department, the information model equates to an enterprise information model. IHE is an initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information. IHE promotes the coordinated use of established standards such as DICOM and HL7 to address specific clinical need in support of optimal patient care. Integration logic is the logic that deals with connectivity, transformation, translation and routing of data from one application to another. This logic is ideally contained within the system integration platform. The central integration capability currently the JCAPS / e*gate platform managed by the HSIA Systems Integration work unit. In future this will be the new ESB/EAI platform. An interface contract specifies how the functionality of an application component can be accessed by other application components. The interface contract typically includes parameters, protocols, pre and post conditions and data formats. The ability for a system to securely communicate and exchange data in an accurate, reliable, and meaningful way with another information system so that the clinical or operational purpose and meaning of the data are preserved and unaltered. QGCIO Glossary Procedure, Systems Integration, Service Oriented Architecture Sustainability,, Systems Integration, Systems Integration Procedure Systems Integration Sustainability, JCAPS Java Composite Application Platform Suite Effective From: 05/06/2014 Page 26 of 30