Enterprise Architecture Guide - Queensland Health · Enterprise Architecture Guide 4.1 The Department of Health Enterprise Architecture The Department of Health Enterprise Architecture

Effective From: 05/06/2014 Page 1 of 30

Guideline Standard # QH-GDL-402-6-3:2014

Enterprise Architecture Policy

Enterprise Architecture Guide

1. Purpose

This Guideline provides an overview of the document structure of the Department of Health Enterprise Architecture, 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 Standard/s:

• Enterprise Architecture Policy

• Enterprise Architecture Framework Implementation Standard

• Enterprise Architecture Foundations Implementation Standard

• Enterprise Business Architecture Implementation Standard

• Enterprise Information Architecture Implementation Standard

• Enterprise Applications Architecture Implementation Standard

• Enterprise Technology Architecture Implementation Standard

Procedures, Guidelines and Protocols:

• Information System Sustainability Protocol

• Interoperability Protocol

• Service Oriented Architecture Protocol

• Systems Integration Protocol

• Enterprise Architecture Development Method Procedure

• Integration Patterns Procedure

4. Enterprise Architecture Guide

4.1 The Department of Health Enterprise Architecture

The Department of Health Enterprise Architecture (DHEA) extends the Queensland Government Enterprise Architecture to categorise specific Queensland Health Enterprise Architecture content.

The Enterprise Architecture Policy suite includes the documents that comprise the Department of Health Enterprise Architecture 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).

Department of Health: Enterprise Architecture 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 Enterprise Architecture

• Strategically aligned – Alignment with the Department of Health Enterprise Architecture 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 Enterprise Architecture and the Queensland Government Enterprise Architecture

� 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.



• Accessible services – Interoperability 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.

• Standards 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 Enterprise Architecture Policy Artefacts


The Enterprise Architecture 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.

Enterprise Architecture Development Method Procedure

The Enterprise Architecture Development Method describes the processes, inputs, outputs, guides and enablers that guide the development and maintenance of the Enterprise Architecture including the governing Enterprise Architecture.

Information Security Framework

The Enterprise Information Security Architecture elements have been included in the following Department of Health policy artefacts:

• Implementation Standard for Information Security – includes the ten domains of the Enterprise Information Security Architecture

• Protocol for Information Security – includes specific requirements for Information Exchange (Section 9.10 Department of Health Specific Requirements – Information Exchange).

Enterprise Architecture Framework Implementation Standard

The Enterprise Architecture Framework Implementation Standard describes the minimum mandatory requirements to comply with the Department of Health Enterprise Architecture.

The standard includes the following sections:

5.1 Enterprise Architecture Overview 5.2 Enterprise Architecture Compliance and Dispensation 5.3 Enterprise Architecture Domains 8.0 Responsibilities Table (included in all Implementation Standards)

Enterprise Architecture Foundations Implementation Standard

The Enterprise Architecture Foundations Implementation Standard describes the foundations for applying the Department of Health Enterprise Architecture. Enterprise architecture foundations include principles, quality attributes and broad design goals. These foundational elements shape the Enterprise Architecture and drive architectural requirements for implementations and procurements. They provide validation points for decision making by architects in both devising and governing solutions.




5.1 Enterprise Architecture Principles, Rationale and Implications 5.1.1 Align to Organisational Readiness 5.1.2 Do No Harm 5.1.3 Enterprise above Solution 5.1.4 Manage Shared Assets as Queensland Health Assets 5.1.5 Manage Technical Diversity 5.1.6 Reuse, then Buy, then Build 5.1.7 Separation of Concerns 5.1.8 Authoritative Source 5.1.9 Strategic and Tactical 5.1.10 Unbiased Architecture

5.2 Enterprise Architecture Quality Attribute Requirements 5.2.1 Accessibility 5.2.2 Adaptability 5.2.3 Availability 5.2.4 Interoperability 5.2.5 Maintainability 5.2.6 Performance 5.2.7 Scalability 5.2.8 Usability

5.3 Enterprise Architecture Broad Design Goals 5.3.1 Best practices 5.3.2 Integrated Systems 5.3.3 Model Driven 5.3.4 Patient Centricity 5.3.5 Privacy 5.3.6 Reuse 5.3.7 Security 5.3.8 Service Orientation 5.3.9 Standards Based 5.3.10 Unique Identification 5.3.11 Web Enabled

Enterprise Business Architecture Implementation Standard

The Enterprise Business Architecture Implementation Standard 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.


5.1 Enterprise Architecture Business Domain 5.2 Enterprise Architecture Business Process Classification 5.3 Mandated Business Architecture Artefacts 5.4 Business Architecture Positions

5.4.2 Business processes not having currently applicable positions 5.4.3 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

Enterprise Information Architecture Implementation Standard

The Enterprise Information Architecture Implementation Standard describes the requirements for applying the Department of Health Enterprise Information Architecture. The architecture describes how the Department of Health manages information throughout its lifecycle and defines the information flows between information systems. Information



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.


5.1 Enterprise Architecture Information Domain 5.2 Enterprise Architecture Information Process Classification 5.3 Mandated Information Architecture Artefacts 5.4 Business Architecture Policy Considerations 5.5 Information Architecture Positions

5.5.2 Controls [QH-I-1] 5.5.3 Plans [QH-I-2] 5.5.4 Responsibilities [QH-I-3] 5.5.5 Cases [QH-I-4] 5.5.6 Events [QH-I-5] 5.5.7 Interactions [QH-I-6] 5.5.8 Services [QH-I-7] 5.5.9 Infrastructures [QH-I-8] 5.5.10 Parties [QH-I-9] 5.5.11 Places [QH-I-10] 5.5.12 Products [QH-I-11] 5.5.13 Resources [QH-I-12]

5.6 Mandated Information Architecture Requirements 5.6.1 Client Directory Number 5.6.2 Clinical Data Standards

Appendix 1 Department of Health Information Classifications Diagram Appendix 2 Department of Health Process Classification to Queensland Government

Business Process Classification Alignment

Enterprise Application Architecture Implementation Standard

The Enterprise Application Architecture Implementation Standard describes the requirements for applying the Department of Health Enterprise Application 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.


5.1 Enterprise Architecture Application Domain 5.2 Enterprise Architecture Application Portfolio Classification 5.3 Mandated Application Architecture Artefacts 5.4 Application Architecture Positions

5.4.2 Generic Service Delivery [QH-A-1] 5.4.3 Line of Business Service Delivery [QH-A-2] 5.4.4 Client/Patient Relationship Management [QH-A-3] 5.4.5 Research Management, Science and Engineering [QH-A-4] 5.4.6 Supply Chain Management [QH-A-5] 5.4.7 Enterprise Resource Planning [QH-A-6] 5.4.8 Organisational Optimisation [QH-A-7] 5.4.9 Health Service Delivery [QH-A-8] 5.4.10 Enterprise Services [QH-ES]

5.5 Mandated Application Architecture Requirements 5.5.1 Interoperability 5.5.2 Sustainability

Appendix 1 Department of Health Application Portfolio Classification Diagram Clinical Application Portfolio Classification Diagram (QH-A-8.2 expanded)



Appendix 2 Common Service Classification Diagram Appendix 3 Department of Health Application Products and Services Portfolio

Classification () to Queensland Government Application Classification Alignment

Enterprise Technology Architecture Implementation Standard

The Enterprise Technology Architecture Implementation Standard describes the requirements for applying the Department of Health Enterprise Technology 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.


5.1 Enterprise Architecture Technology Domain

5.2 Enterprise Architecture Technology Portfolio Classification

5.3 Mandated Technology Architecture Artefacts

5.4 Technology Architecture Positions

5.4.2 Desktop and Productivity [QH-T-1] Positions

5.4.3 Application Environments [QH-T-2]

5.4.4 System Software [QH-T-3]

5.4.5 Physical and Virtual Devices [QH-T-4]

5.4.6 Management and Control Software [QH-T-5]

5.4.7 ICT Equipment Accommodation and Cabling [QH-T-6]

5.5 Mandated Technology Architecture Requirements

5.5.1 Enterprise single sign-on and context management

5.5.2 Consistent Time Service

5.5.3 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

Information System Sustainability Protocol

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 Information System 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



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 Standards

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

Interoperability Protocol

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.


5 Interoperability 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 Interoperability 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



Integration Patterns Procedure

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 Protocol

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.


5 Service Oriented architecture approach

6 Service Oriented architecture

6.1 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



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 Protocol

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.


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 Protocol

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.




5 Process for ICT Cabling

5.1 ICT Cabling Application

5.2 ICT Cabling Compliance

4.4 Enterprise Architecture Index to Contents

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

Service architecture Service Oriented architecture protocol

7.6

Accessibility Enterprise Architecture Quality Attribute Requirement


5.2.1

Acquire applications with interchangeable components

Application components Information System Sustainability Protocol

6.2

Adaptability Enterprise Architecture Quality Attribute Requirement


5.2.2

Adopt endorsed Australian and national standards

Standards Information System Sustainability Protocol

9.1

Adopt national e-Health standards

Interoperability standards Interoperability Protocol 8.1

Align integration interfaces with approved integration patterns

Integration approach Systems integration protocol

7.7

Align service interfaces with the Department of Health system-wide information model


7.8

Align to Organisational Readiness

Enterprise Architecture Principle, Rationale and Implications


5.1.1

Application Architecture Positions


5.4


6

Application Environments [QH-T-2]

Technology Architecture Position


5.4.3

Application management Information System Sustainability Protocol 10

Apply business rules consistently across systems

Information interoperability


6.8

Apply user interface technologies where appropriate to support data entry



6.7




Authoritative Source Enterprise Architecture Principle, Rationale and Implications


5.1.8

Availability Enterprise Architecture Quality Attribute Requirement


5.2.3

Avoid using point-to-point interfaces

Integration approach Systems integration protocol 7.1

Best practices Enterprise Architecture Broad Design Goal


5.3.1

Broker Functional integration patterns

Integration patterns procedure 6.2

Business Architecture Policy Considerations


5.4

Business Architecture Positions


5.4

Business Products and Services Portfolio Classification (Department of Health) to Queensland Government Business Classification Alignment


Appx. 2

Cases [QH-I-4] Information Architecture Position


5.5.5

Centralised translation logic


Client Directory Number Mandated Information Architecture Requirement


5.6.1

Client/Patient Relationship Management [QH-A-3]

Mandated Information Architecture Requirement


5.4.4

Clinical Application Portfolio Classification Diagram (QH-A-8.2 expanded)


Appx. 1

Clinical Data Standards Mandated Information Architecture Requirement


5.6.2

Commercial off the shelf packages

Systems integration protocol 8

Common Service Classification Diagram


Appx. 2

Common Services [QH-CS]



5.4.10

Common Services are an authoritative source

Service architecture Service Oriented architecture protocol 7.5

Complex Event Functional integration patterns





Composite Patterns - Functional & Data Integration

Integration patterns procedure

7

Configure user interfaces to provide common look and feel across the Queensland Health system enterprise


6.6

Consider HSSP standards for common services interfaces

Interoperability standards Interoperability Protocol

8.5

Consider IHE profiles where there is a clearly defined benefit


8.7

Consistent Time Service Mandated Technology Architecture Requirement


5.5.2

Consolidate common functionality into reusable services


6.3

Content-based Router Functional integration patterns


Controls [QH-I-1] Information Architecture Position


5.5.2

Create reusable integration services from existing components


7.5

Data Information System Sustainability Protocol 8

Data integration Integration patterns procedure 8

Database in - Message out



7.1

Defer introduction of advanced integration capabilities

Integration platform Systems integration protocol

6.5

Deliver reusable components as services

Service Oriented architecture

Service Oriented architecture protocol 6.2

Department of Health Process Classification to Queensland Government Business Process Classification Alignment


Appx. 2

Department of Health Application Portfolio Classification Diagram


Appx. 1

Department of Health Application Products and Services Portfolio Classification to Queensland Government Application Classification Alignment


Appx. 3




Department of Health Information Classifications Diagram


Appx. 1

Department of Health Technology Products and Services Portfolio Classification to Queensland Government Technology Classification Alignment


Appx. 2

Department of Health Technology Products and Services Portfolio Classification Diagram


Appx. 1

Deploy SOA services in an incremental fashion


Service Oriented architecture protocol 6.1

Design services without being constrained by existing consuming applications


7.3

Desktop and Productivity [QH-T-1] Positions



5.4.2

Do No Harm Enterprise Architecture Principle, Rationale and Implications


5.1.2

Do not access data from transactional information systems directly

Data Information System Sustainability Protocol

8.3

Do not expose proprietary internal data models and terminologies

Technical interoperability Interoperability Protocol

7.2

Do not use services designed for transactional use in business intelligence applications


7.7

Document all interfaces in a central integration register

ICT systems lifecycle Systems integration protocol

9.1

Document applications Application management Information System Sustainability Protocol 10.3

Enable clinical applications to use clinical context sharing

Legacy transformation Information System Sustainability Protocol

7.4

Enable clinical context sharing for clinical applications


8.6

Ensure terminology is compliant with the Department of Health terminology standards



6.3

Enterprise above Solution Enterprise Architecture Principle, Rationale and Implications


5.1.3

Enterprise Architecture Overview Enterprise Architecture Framework Implementation

5.1




Standard

Enterprise Architecture Application Domain


5.1

Enterprise Architecture Application Portfolio Classification


5.2

Enterprise Architecture Broad Design Goals


5.3

Enterprise Architecture Business Domain


5.1

Enterprise Architecture Business Process Classification


5.2

Enterprise Architecture Compliance and Dispensation


5.2

Enterprise Architecture Domains


5.3

Enterprise Architecture Information Domain


5.1

Enterprise Architecture Information Process Classification


5.2

Enterprise Architecture Principles (short form)


Enterprise Architecture Principles, Rationale and Implications


5.1

Enterprise Architecture Quality Attribute Requirements


5.2

Enterprise Architecture Technology Domain


5.1

Enterprise Architecture Technology Portfolio Classification


5.2

Enterprise Resource Planning [QH-A-6]



5.4.7

Enterprise single sign-on and context management

Mandated Technology Architecture Requirement


5.5.1

Establish central point of governance for SOA-style services

ICT systems lifecycle Service Oriented architecture protocol

9.3

Events [QH-I-5] Information Architecture Position


5.5.6

Expose common services via the enterprise

Integration platform Systems integration protocol 6.2




integration platform

Expose services via the Enterprise Service Bus

Operational infrastructure Service Oriented architecture protocol 8.1

Federation Data integration Integration patterns procedure 8.6

File in – Message out Composite Patterns - Functional & Data Integration


7.2

File Transfer Data integration Integration patterns procedure 8.2

Functional integration patterns

Integration patterns procedure 6

Generic Service Delivery [QH-A-1]



5.4.2

Health Service Delivery [QH-A-8]



5.4.9

Hide internal data models and terminologies from external systems


8.2

ICT Cabling Mandated Technology Architecture Requirement


5.5.3

ICT Equipment Accommodation and Cabling [QH-T-6]



5.4.7

ICT systems lifecycle Service Oriented architecture protocol 9

ICT systems lifecycle Systems integration protocol 9

Implement interfaces that conform to established standards

Standards Information System Sustainability Protocol

9.2

Include service capability requirements in all procurement offers


9.4

Incorporate interoperability standards in the Department of Health information model



6.1

Information Architecture Positions


5.5


Interoperability Protocol 6

Information System Sustainability Approach


5

Infrastructures [QH-I-8] Information Architecture Position


5.5.9

Insulate service consumers from having to know service locations

Operational infrastructure Service Oriented architecture protocol

8.2

Integrate business workflows across information system silos


7.2




Integrated Systems Enterprise Architecture Broad Design Goal


5.3.2

Integration approach Systems integration protocol 7

Integration environment approach

Integration patterns procedure 5

Integration platform Systems integration protocol 6

Intent of this policy Enterprise Architecture Policy

Interactions [QH-I-6] Information Architecture Position


5.5.7

Interoperability Mandated Application Architecture Requirement


5.5.1

Interoperability Enterprise Architecture Quality Attribute Requirement


5.2.4

Interoperability approach Interoperability Protocol 5

Interoperability standards Interoperability Protocol 8


7

Legislative or other Authority


Limit the sending of unsolicited information


Limit use of application’s own integration engine to within its own suite


Systems integration protocol

8.1

Limit validation performed in the integration layer


Line of Business Service Delivery [QH-A-2]



5.4.3

Maintain currency of commercial applications

Application management Information System Sustainability Protocol 10.1

Maintain Data Copies Data integration Integration patterns procedure 8.3

Maintain quality of service to meet the most demanding integration needs


6.4

Maintainability Enterprise Architecture Quality Attribute Requirement


5.2.5

Manage common services as shared assets

ICT systems lifecycle Service Oriented architecture protocol 9.1

Manage Information and Technology Resources [QP-BP-9]

Business Architecture Position


5.4.3

Manage Shared Assets as Queensland Health Assets



5.1.4

Manage Technical Diversity



5.1.5




Manage the enterprise integration platform centrally


6.3

Management and Control Software [QH-T-5]



5.4.6

Mandated Application Architecture Artefacts


5.3

Mandated Application Architecture Requirements


5.5

Mandated Business Architecture Artefacts


5.3

Mandated Information Architecture Artefacts


5.3

Mandated Information Architecture Requirements


5.6

Mandated Technology Architecture Artefacts


5.3

Mandated Technology Architecture Requirements


5.5

Mediated Request / Response



Message in – Database out



7.3

Message in – File out Composite Patterns - Functional & Data Integration


7.4

Minimise customisation of COTS applications


6.5

Minimise diversity of application components

Application management Information System Sustainability Protocol 10.2

Model Driven Enterprise Architecture Broad Design Goal


5.3.3

Only acquire services when predefined criteria are satisfied


7.1

Operational Data Store Data Integration Integration patterns procedure 8.7

Operational infrastructure Service Oriented architecture protocol 8

Orchestration – Parallel Process



Orchestration – Serial Process



Organisational Optimisation [QH-A-7]



5.4.8




Parties [QH-I-9] Information Architecture Position


5.5.10

Patient Centricity Enterprise Architecture Broad Design Goal


5.3.4

Performance Enterprise Architecture Quality Attribute Requirement


5.2.6

Physical and Virtual Devices [QH-T-4]



5.4.5

Places [QH-I-10] Information Architecture Position


5.5.11

Plans [QH-I-2] Information Architecture Position


5.5.3

Point to Point (Direct Connection)



Policy statement Enterprise Architecture Policy

Population Data integration Integration patterns procedure 8.4

Privacy Enterprise Architecture Broad Design Goal


5.3.5

Process Choreography Functional integration patterns


Process Classification Diagram (Department of Health)


Appx. 1

Process Manager Functional integration patterns


Procurement considerations

ICT systems lifecycle 6.5.1

Products [QH-I-11] Information Architecture Position


5.5.12

Provide application to enterprise mediation


Systems integration protocol 8.2

Publish / Subscribe Functional integration patterns


Publish services in a central design time directory


9.2

Rationalisation and retirement

ICT systems lifecycle 6.5.2

Related policy or documents


Replication Data integration Integration patterns procedure 8.5

Research Management, Science and Engineering [QH-A-4]



5.4.5

Resources [QH-I-12] Information Architecture Position

Enterprise Information Architecture Implementation

5.5.13




Standard

Responsibilities [QH-I-3] Information Architecture Position


5.5.4

Responsibilities Table (included in all Implementation Standards)


8.0

Restrict data entry values to permissible value sets


Interoperability Protocol 6.5

Reuse Enterprise Architecture Broad Design Goal


5.3.6

Reuse application functionality before buying or building


6.1

Reuse, then Buy, then Build



5.1.6

Scalability Enterprise Architecture Quality Attribute Requirement


5.2.7

Scatter-Gather Functional integration patterns


Security Enterprise Architecture Broad Design Goal


5.3.7

Selectively use specialised user interface components


7.5

Selectively web-enable applications with non-contemporary interfaces


7.3

Separate integration logic from business logic


Separate service provision from service consumption


9.5

Separate transactional information repositories from authoritative sources


8.4

Separation of Concerns Enterprise Architecture Principle, Rationale and Implications


5.1.7

Service architecture Service Oriented architecture protocol 7

Service Orientation Enterprise Architecture Broad Design Goal


5.3.8


Service Oriented architecture protocol 6

Service Oriented architecture approach

Service Oriented architecture protocol 5

Services [QH-I-7] Information Architecture Position

Enterprise Information Architecture Implementation

5.5.8




Standard

Shared Database Data integration Integration patterns procedure 8.1

Standards Information System Sustainability Protocol 9

Standards Based Enterprise Architecture Broad Design Goal


5.3.9

Strategic and Tactical Enterprise Architecture Principle, Rationale and Implications


5.1.9

Supply Chain Management [QH-A-5]



5.4.6

Support non service-enabled applications with data integration


7.4

Supporting documents Enterprise Architecture Policy

Sustainability Mandated Application Architecture Requirement


5.5.2

Synchronise cached data with an authoritative source


8.1

System Software [QH-T-3]



5.4.4

Systems integration approach

Systems integration protocol 5

Tailor through configuration in preference to customisation


6.4

Technical interoperability Interoperability Protocol 7

Technology Architecture Positions


5.4

Unbiased Architecture Enterprise Architecture Principle, Rationale and Implications


5.1.10

Unique Identification Enterprise Architecture Broad Design Goal


5.3.10

Usability Enterprise Architecture Quality Attribute Requirement


5.2.8

Use a common structure and common language for all data exchanges



6.4

Use Australian and International standards


Interoperability Protocol 6.2

Use common security mechanisms

Service architecture Service Oriented architecture protocol 7.9

Use data integration for large scale data movement and data


7.3




synchronisation

Use deployed services wherever the capability fits the requirement


7.2

Use DICOM for transmitting and storing medical images


8.4

Use extensions where standard interfaces need to be modified



6.6

Use functional integration in preference to data integration and presentation integration


7.2

Use HL7 Clinical Document Architecture to exchange structured documents


8.3

Use HL7 Version 2.x for sharing electronic health record information via HL7


8.2

Use legacy transformation to reuse legacy functionality


7.1

Use mediation services to integrate with COTS/legacy systems


7.10

Use the E-health Web Services Profiles for interactions with external healthcare organisations.


7.4

Use the enterprise integration platform

Integration platform Systems integration protocol 6.1

Use the enterprise integration platform to support interoperability


7.1

Use the External Gateway for all external application integration


6.6

Use the QGEA Web Services standard where no other standard is mandated


7.5

Use the state-wide information model to define integration data structures


7.8

Use third party services in preference to in-house services


Service Oriented architecture protocol

6.3

Use web services to support loosely–coupled interoperable systems


7.3




Web Enabled Enterprise Architecture Broad Design Goal


5.3.11

5. 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 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.

Information System Sustainability Protocol, Integration Patterns Procedure

Application component

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.


Application Integration

Integration refers to the set of technologies and services that enable the exchange of information between systems and applications across the enterprise.

Integration Patterns Procedure, Integration Patterns Procedure

Applications A software system deployed by the agency which has part of an agency's business process embedded with it, for example, SAP.

Queensland Government Chief Information Office (QGCIO) Glossary

Artefact Artefacts are documents that are components of the Department of Health Enterprise Architecture including but not limited to the policy, standards, protocols, procedures and guidelines.

Adapted from QGCIO Glossary

Authoritative source

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.


Information System Sustainability Protocol, Interoperability Protocol, Service Oriented Architecture Protocol

Broad Design Goals

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




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 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

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.

Using Directories and Directory Technology Protocol

Business Logic The logic within an application that deals with the implementation of business policies, rules, practices and procedures for relevant business functions or processes.

Integration Patterns Procedure, Systems Integration Protocol

Business Process Execution Language (BPEL)

BPEL is a standard executable language for specifying actions within business processes. Processes in BPEL export and import information by using web service interfaces.


Canonical form The data standards, structures, definitions and terminologies that are used within the integration environment.

Interoperability Protocol, Systems Integration Protocol

Choreography 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.


Clinical Context Object Workgroup (CCOW)

The HL7 CCOW (Clinical Context Object Workgroup) Standard 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 (CDA)

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.


Coarse-grained authorisation

A mechanism for determining permissions for accessing a resource.

QGCIO Glossary

Commercial off-the-shelf (COTS)

Commercial off-the-shelf refers to products that are sold in the commercial marketplace.

Information System Sustainability Protocol, Service Oriented Architecture Protocol

Common Service An information system component that delivers core business functionality common to multiple applications including access to shared authoritative information.

Identity Management and Demographics Protocol

Common Service 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.

Information System Sustainability Protocol, Systems Integration Protocol, Integration Patterns Procedure

Common Service An information system component that delivers core business Service Oriented




functionality common to multiple applications including access to shared authoritative information.

Architecture Protocol

Confidentiality Ensuring that data or information is accessible only to those authorised and is protected from unauthorised disclosure or intelligible interception.

Queensland Government Chief Information Office (QGCIO) Glossary

Credential Management

A business function incorporating processes for managing the lifecycle of any entity’s credentials.

Adapted from QGCIO Glossary, Identity Management and Demographics Protocol

Data Integration 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.


Data Integration 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.


Queensland Health

The Department of Health and the Hospital and Health Services (HHSs), making up the public healthcare system, is known as Queensland Health

http://qheps.health.qld.gov.au/ohsa/html/roledoh.htm

Interoperability Protocol, Systems Integration Protocol

Digital Imaging and Communications in Medicine (DICOM)

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.

Systems Integration Protocol, Interoperability Protocol

Directories 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.

QGCIO Glossary

Directory Services Directory services are the defined methods or protocols by which entity information can be accessed, retrieved or updated from enterprise directory systems.


Directory Technologies

Directory technologies are technology products that provide a data store and access method for managing collections of information about entities.


Dispensation For the purpose of this policy, the term ‘dispensation’ means the endorsed exception from compliance with the enterprise architecture.


Domain The categories used as part of the Queensland Government and Department of Health Enterprise Architectures to provide a consistent and convenient method of logically grouping

Policy and standards




business processes, information assets, applications and technologies and ICT initiatives into meaningful and manageable areas for analysis.

Encapsulation 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.


Enterprise 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.

Enterprise Architecture Policy, Integration Patterns Procedure

Enterprise Application Integration (EAI)

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.


Enterprise Architecture

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.

QGCIO Glossary

Enterprise ICT Service

Enterprise ICT Services are described in the ICT Service Catalogue available on the QHEPS intranet.

Policy and Standards

Enterprise Service

Enterprise Services provide core business functionality that is common to multiple applications (e.g. Clinical Data Service, Provider Directory Service etc)

Policy and Standards

Enterprise Integration Platform

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.

Information System Sustainability Protocol, Systems Integration Protocol

Enterprise Service Bus (ESB)

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.

Integration Patterns Procedure, Interoperability Protocol, Service Oriented Architecture Protocol, Systems Integration Protocol

External Gateway 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.


External Rules Engine

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 (ETL)

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


Fine-grained authorisation

A mechanism for determining permissions for performing a specific action within a resource.

Using Directories and Directory Technology




Protocol

Fit for purpose 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

QGCIO Glossary

Functional Integration

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 Enterprise Application Integration (EAI).


Health Level Seven (HL7)

Health Level Seven (HL7) is an American National Standards 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.


Healthcare Services Specification Project (HSSP)

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.

Interoperability Protocol, Service Oriented Architecture Protocol

Information Interoperability

For the purposes of this paper Information Interoperability covers the non-technical aspects of interoperability. (The technical aspects are covered under the Technical Interoperability section).


Information Model 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.

Information System Sustainability Protocol, Interoperability Protocol, Systems Integration Protocol,

Integrating the Healthcare Enterprise (IHE)

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 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.


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.


Interface Contract 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.


Interoperability 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.

Information System Sustainability Protocol, Interoperability Protocol

JCAPS Java Composite Application Platform Suite Information System




Sustainability Protocol, Systems Integration Protocol

Legacy application

An existing application that continues to be used, typically because it still meets the business needs, even though more modern technologies or approaches are now available. These applications may be mission critical applications in which the organisation continues to invest time and money. Legacy applications are not necessarily old.


Legacy transformation

A technique to rebuild legacy applications in a new technology or platform, with the same or enhanced functionality.


Local Services supporting activities that may be specific to a local area or that arise from local innovation.

Local is one of the three categories in the applications portfolio with Core and Common.

Queensland Health ICT Governance Framework

Mandated/ Mandated Options

If an applicable position states a mandated product/service, it must be used. If there are multiple products/services for an applicable position, one of products/services must be used. A dispensation is required to not use a mandated product/service.

Mediation Services

Mediation services use the integration brokering capabilities of the integration platform to make functionality from legacy or packaged applications available to other applications as services. Examples are the Order Management, Scheduling Management and Referral Management services defined in the eHealth System map.


National E-Health Transition Authority Limited (NEHTA)

National E-Health Transition Authority Limited was established by the Australian, State and Territory governments to develop better ways of electronically collecting and securely exchanging health information.


openEHR An open standard specification that describes the management and storage, retrieval and exchange of health data in electronic health records (EHRs).


Personal information

Information or an opinion (including information or an opinion forming part of a data base), whether true or not, and where recorded in a material form, about an individual whose identity is apparent, or can reasonably be ascertained, from the information or opinion.

QGCIO glossary of terms

Information Privacy Act 2009

Point to Point Point to Point Integration is where one application shares information with another directly, through having knowledge of the location of the other system and the system specific aspects of its interfaces. This integration can be one-way, two-way and can occur in real time or in batch mode.


Portability A characteristic attributed to an application if it can be used in a computer environment other than the one in which it was created without requiring major rework.


Presentation Integration

Includes older technologies such as screen scraping, web page links and newer technologies such as portal integration and presentation integration servers.

Information System Sustainability Protocol, Integration Patterns Procedure, Systems Integration Protocol

Principles Principles represent the Information and Communication Technology (ICT) interpretation and application of the organisation’s mission and philosophy. They are fundamental





and apply to all levels of ICT initiatives from EA to specific solution implementations. Adherence to the principles ensures alignment to organisational strategy and intent and results in a sustainable ICT environment.

Processes A series of logically related activities or tasks performed together to produce a defined set of results. Processes are defined in the Business Process Classification document.


Quality attributes Quality attributes, often referred to as system qualities, are quality characteristics that extend the requirements of any ICT initiative or architecture. Quality attributes are intended to be applied to both solutions and the enterprise architecture. Quality attributes ensure that solutions are not only functional, but also supportable by the organisation and traceable to organisational non-functional requirements. Quality attributes ensure that the enterprise architecture is designed and developed in a way that supports business strategies and drivers and provides direction and guidance to solutions.


Queensland Government Enterprise Architecture (QGEA)

Queensland Government Enterprise Architecture is a framework with a repository containing ICT guidance and decisions.


Queensland Health

The Department of Health and the Hospital and Health Services (HHSs), making up the public healthcare system, is known as Queensland Health

http://qheps.health.qld.gov.au/ohsa/html/roledoh.htm


REST (Representational State Transfer)

REST is an architectural style that uses the existing technology and protocols of the internet, including HTTP (Hypertext Transfer Protocol) and XML.


Screen scraping Screen scraping is a presentation integration approach that enables an application to access data and functions from another application via that application’s terminal screen interface. An Application Programming Interface is used to access the data presented on terminal screens, allowing a desktop program to mimic a user interacting with host application screens.


Secure Transfer Service (STS)

The Secure Transfer Service is a Department of Health application that is used for secure transfer of messages and documents with external parties.


Semantic interoperability

The ability for two or more systems to communicate information with a shared and consistent understanding of the meaning of the data. This requires a shared understanding of information models and terminologies and the means to translate between these. Syntactical interoperability is also a requirement for semantic interoperability.


Service Orchestration

Service Orchestration is a technique of combining services into a new process service under the control of a controlling service or ‘conductor’. Service Orchestration is used within a Service Oriented Architecture context to orchestrate standards-based services, although it can also be used to orchestrate other reusable components into services.


Service Registry The service registry provides a well-known location for the registration of Services specifications, i.e. service endpoints and contracts. The registry supports service discovery and invocation.





Service Repository

A service repository manages a multitude of IT assets and artefacts throughout their life cycles (for example, analysis, architecture, design, development, deployment, operations and retirement). Important IT software assets and artefacts related to the ESB include Unified Modelling Language designs, Web Services Description Language files, Business Process Execution Language flows, components, services and applications.


Service Oriented Architecture (SOA)

Service Oriented Architecture is a design approach that enables application functionality to be delivered as single software services and reused within those applications that would otherwise redundantly provision that functionality. The functionality is typically deployed as a collection of interoperable services that can be used within multiple separate systems from one or more business domains. Services are abstracted away from the implementation of any consuming application using standards-based interfaces. SOA is independent of specific technologies.

Integration Patterns Procedure, Service Oriented Architecture Protocol, Systems Integration Protocol

Services Re-usable, software-based capabilities that can be accessed by other information systems. These services are not the same as those services listed in the Health Services Information Agency Service Catalogue, or the health services offered to the public by Hospital and Health Services, or those services provided by the Health Services Support Agency or as defined in Queensland Health’s Clinical Services Capability Framework.


Simple Object Access Protocol (SOAP)

An XML based standard for making function calls across the internet to another application.


Source of Truth See authoritative source. Interoperability Protocol, Service Oriented Architecture Protocol

Specialty Applications

Applications that support functions in specific areas of Queensland that are performed in a unique or specialised manner, that justify use of specialised solutions (e.g. Cardiology, Oncology, anaesthetics). These applications are provided by specialty application vendors, or may be custom solutions.


Sustainability The ability of an application to continue to meet business requirements within accepted cost and quality constraints


Syntactic interoperability

Both sender and receiver understand the syntax of the information exchanged allowing it to be parsed consistently. This can be done using simple message-based integration (or even file-based integration) with standard message exchange formats (e.g. HL7 version 2).


System-wide information model

The system-wide 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 Queensland Health system, the system-wide information model equates to an enterprise information model.

Information System Sustainability Protocol, Interoperability Protocol, Systems Integration Protocol

Technical Interoperability

Technical Interoperability is concerned with providing common middleware, open interfaces, and tools for integrating systems and services.


Technologies Support the application portfolio of the business, including software technologies, hardware, and network support.

QGCIO Glossary




Transactional Information System

An information system designed to store and record day-to-day business information, often structured around events, business processes or business activities. These systems are optimised for storing large volumes of data, but not for analysing that data.


Translation logic Translation logic is a subset of integration logic (refer to definition above) and deals specifically with the rules for mapping information presented using one set of terms to information using an alternative set of terms e.g. mapping ICD-10 (International Classification of Diseases) diagnosis terms to SNOMED-CT clinical terms.


W3C The World Wide Web Consortium (W3C) is an international community that develops web standards.


Web Service A Web service is a standardised way of integrating Web-based applications using open standards (such as Extensible Markup Language [XML], Simple Object Access Protocol [SOAP], Web Service Definition Language [WSDL]) over an Internet protocol backbone. Web services are commonly used to implement SOA services (although SOA services can be implemented without web services).

Service Oriented Architecture Protocol, Systems Integration Protocol

Web Services Description Language (WSDL)

Web Services Description Language (also known as Web Services Definition Language) specifies the operational characteristics of a Web service using an XML document. It describes the services, its location and how it can be invoked.


8. Approval and Implementation

Policy Custodian:

Senior Director Strategy Governance and Architecture, Planning, Engagement and Performance Directorate, Health Services Information Agency (HSIA)

Responsible Executive Team Member:

Chief Information Officer, HSIA

Approving Officer:

Ray Brown, Chief Information Officer, HSIA

Approval date: 05 June 2014

Effective from: 05 June 2014

Version History

Version Date Prepared by Comments

1.0 13/05/2014 ICT Policy Finalised for CIO approval

Documents

Enterprise Architecture Guide - Queensland Health · Enterprise Architecture Guide 4.1 The Department of Health Enterprise Architecture The Department of Health Enterprise Architecture