text:
Logical Architecture Introductory Document
- Anne Daniels
- 3 years ago
- Views:
1 Ontario Provincial EHR Logical Architecture Introductory Document Version: 1.0.3a
2 Copyright Notice Copyright 2012, ehealth Ontario All rights reserved No part of this document may be reproduced in any form, including photocopying or transmission electronically to any computer, without prior written consent of ehealth Ontario. The information contained in this document is proprietary to ehealth Ontario and may not be used or disclosed except as expressly authorized in writing by ehealth Ontario. Trademarks Other product names mentioned in this document may be trademarks or registered trademarks of their respective companies and are hereby acknowledged. Logical Architecture /Architecture Principles /Version #1.0.1 final draft ii
3 Table of Contents Introduction 1 Context for Logical Architecture 2 ehealth Logical Architecture Ontario Business Context & Rationale... 2 Objectives... 2 Project 4 Scope 4 Governance... 4 Tooling 6 Enterprise Architect... 6 Justification... 6 ehealth Enterprise Architecture Framework 8 ehealth Logical Architecture Generation ehealth Logical Architecture Deliverables... 9 Architecture Principles... 9 Architecture Decisions Transaction Patterns Service Components Definitions Future Iterations Uses of the ehealth Logical Architecture 25 For strategic planning For investment governance For Regional Hub IT Organizations and Development Teams For Point-Of-Service Organisations For solution project initiatives Appendix A Modelling Usage & Conventions 29 Model Structure Navigation Tips Browsing the Generated Documentation Modelling Conventions Appendix B Architecture Principle Topics 38 Logical Architecture /Architecture Principles /Version #1.0.1 final draft ii
4 Introduction This document provides an introductory overview of the ehealth Logical Architecture including the business context, rationale, objectives, purpose, scope and approach of the project as well as the key assumptions and the stakeholder engagement structure. This document also describes the rationale of selecting and using the Enterprise Architect TM (Sparx Systems) multi-user modelling tool for this project which supports current software development methodologies and notation architecture standards such as Business Process Modelling Notation (BPMN) and Unified Modelling Language (UML). The Enterprise Architecture Framework section describes the scope of the key ehealth Logical architecture deliverables as defined in the project charter for a first generation (G1) logical level architecture. These deliverables include Architecture Principles, Architecture Decisions, Transaction Patterns and Service Components Definitions. Each of these deliverables is expected to be enhanced, expanded and developed in future iterations of the logical architecture occurring in the context of the ongoing activities of the enterprise architecture function. A special focus has been attributed to the support of ehealth Ontario priorities such as the Medication Management System, the procurement of HIAL technologies and the leveraging of parallel development of ehealth services with regional hub organisations. Prospective descriptions of how the ehealth Logical Architecture may be used for strategic planning, investment governance, ehealth program/project management and solution delivery are also included. These are especially important for ehealth and regional hub application development projects which architecture guidance to ensure new applications align with Ontario s ehealth Blueprint. An appendix has been provided showing how to navigate the ehealth Logical Architecture within the Enterprise Architect tool as well as the modelling conventions used within the different diagrams. Logical Architecture /Architecture Principles /Version #1.0.1 final draft 1
5 Context for Logical Architecture ehealth Logical Architecture Ontario Business Context & Rationale In 2011, ehealth Ontario completed the Ontario s ehealth Blueprint which provided an update to the original Ontario ehealth Blueprint and Reference Architecture (2007). Ontario s ehealth Blueprint updated the conceptual enterprise architecture and established some fundamental evolutions from the preceding 2007 version which in summary include: The definition of a service oriented architecture predicated upon the use of a core set of common integration and registry services to support the development and implementation of all ehealth services in Ontario; The use of two tiers of ehealth services, with service provision at the provincial level and services provided by a limited number of regional hubs that together form a comprehensive integrated system infrastructure to deliver ehealth in Ontario; An enhanced definition of the HIAL (Health Information Access Layer) as a connected network of integration layers, each including an ESB (Enterprise Service Bus) and Common Services that together form a common integration fabric between systems that provide ehealth services and systems in health delivery organizations acting as consumers of such services; Defining the roles of ehealth Ontario and the regional hubs in delivering ehealth solutions by providing a platform for shared innovation and integration to ensure interoperability using standards as well as architecture principles, guidelines and rules of engagement to promote structured development and collaboration. The ehealth Logical Architecture project initiated in May 2011, is a continuation of Ontario s ehealth Blueprint Conceptual Architecture, and is a component of a larger Logical Architecture and Governance Framework of the Enterprise Architecture project which includes the following parallel streams: Logical Enterprise Architecture for ehealth Ontario Governance Strategy/ Framework for the EHR Blueprint, Roadmap and Agency Investment Decisions Communications Strategy and Materials. Objectives The overall objective of the ehealth Logical Architecture stream is to work in collaboration with ehealth Ontario enterprise architecture teams to develop a first comprehensive logical level architecture for these common integration and registry services to support ehealth Ontario line of business applications. This first version of the enterprise logical architecture is positioned to support what is being defined as the Generation 1 of ehealth capabilities in the Province, this includes all current ehealth strategic business priorities (drugs, CDMS, laboratory, diagnostic imaging, clinical documents) and a prospective outlook on business services of the future such as shared health record, encounters, ereferrals, personal health records, escheduling. This Logical Architecture project provides design level artefacts (models and documents) to express how developers of business or clinical application services can configure and adapt their applications to participate fully in the ehealth foundation in Ontario. Logical Architecture /Architecture Principles /Version #1.0.1 final draft 2
6 The specific objectives of the ehealth Logical Architecture stream are to: Use an enterprise architecture modelling platform as a tool to produce and establish consistent modelling and documentation artefacts to stand as the ehealth Ontario Logical Architecture for users and audiences. Define and document the enterprise level architecture principles to stand as the foundational rules and guidelines to support the development and delivery of all ehealth solutions. Define and document key architectural decisions expressing positions taken in regards to specific technical and functional capabilities required to build an interoperable platform for ehealth in Ontario. Model, define and design common transaction patterns in scope for the first generation (G1) of services capabilities delivered under the governance and funding of ehealth Ontario; Model, define and design service component definitions and models of the ehealth foundation Architecture in accordance with that same first generation scope. Purpose The purpose of the logical architecture is to provide architectural direction for ehealth Ontario to be able to measure compliance on the basis of a reference architecture that is applicable for developers of ehealth Services. The Transaction Patterns provide clarity for the functional behaviour expected of different parts of the ehealth system i.e. who does what and how does it work. The Architecture Principles and Architecture Decisions provide the rules to connect and use the ehealth foundation services and HIAL / ESB components. The Service Component definitions describe the responsibilities of each component and interfaces complete with references to the applicable interoperability standards and specifications. The primary audience for the ehealth Logical Architecture deliverables are ehealth system and business architects, IT analysts and system engineers. This audience also includes Point of Service application vendors developing, adapting and integrating PoS applications (e.g. EMR, HIS, PMS etc) to interoperate with ehealth services. HIAL / ESB and line of business application (e.g. Drug Information System, Registries, etc) solution developers and system integrators are also expected to use the Logical Architecture to adapt their products to work with ehealth compliant services. Logical Architecture /Architecture Principles /Version #1.0.1 final draft 3
7 Project Scope In line with the stated objectives, the following section summarizes the scope addressed by the ehealth Logical Architecture project: The Logical Architecture stream focus is the Systems perspective of the architecture. Define logical architecture principles in the form of a set of documented topics to establish structural definitions and precepts for overarching behaviours expected of the ehealth foundation System. Define and design common transaction patterns in the form of documented BPMN models that depict the sequence of services being called to describe the dynamic invocation patterns of internal ehealth services required to execute any given type of transaction. Model, define and design ehealth foundation Architecture service components in accordance with the layer of processing where each belongs (i.e. ESB, Common Services, Hub Application Services, and Provincial Application Services. Conduct workshops and analysis to create an SHR Discussion document to provide an overview of shared health record (SHR) concepts, functions, scope and potential implementation strategies. Out of scope The Business and Work Process Architecture is not a focus of the current Logical Architecture stream initiative. Modelling and defining business objectives, goals, roles, responsibilities, business networks and business/clinical processes or workflow is not in scope for the current Logical Architecture Stream initiative. The Information Architecture is not a focus of the current Logical Architecture stream initiative. Modelling and defining data entities, attributes and relationships are not in scope for the current Logical Architecture stream initiative. Governance In summary the following project governance guidelines are used to ensure the ehealth Logical Architecture deliverables are developed, reviewed and validated under the governance and authority of ehealth Ontario architecture management and processes. The Logical Architecture stream of work is sponsored by ehealth Ontario under the governance and authority of the Vice-President of Development & Delivery for ehealth Ontario. The overall direction and leadership for the Logical Architecture initiative was conducted by the Senior Director for Enterprise Architecture at ehealth Ontario. The outputs of the Logical Architecture project have been exposed and validated by the ehealth Ontario Architecture Core Team and solution project teams architects as the architecture was being crafted. Future evolutions and presentations of the architecture, now owned by ehealth Ontario are to involve the Business and Architecture Review Committee (BARC). Logical Architecture /Architecture Principles /Version #1.0.1 final draft 4
8 ehealth Ontario leadership for the logical architecture project have combined the input and management oversight of the ehealth Standards Group, the Application Architecture leadership and Architecture Program Management. Logical Architecture /Architecture Principles /Version #1.0.1 final draft 5
9 Tooling Enterprise Architect The ehealth Enterprise Architecture project approach includes the use of an enterprise architecture modelling platform as a tool to produce and establish consistent modelling and documentation artefacts as deliverables for the ehealth Ontario Logical Architecture. The project team has used this tool to model, define and design common transaction patterns in scope for the first generation of services capabilities for ehealth solutions as well as model, define and design service component models of the ehealth foundation Architecture. The team has established an overarching structure within this tool to support, not only the system architecture perspective which is the focus of this initiative, but also, the progressive growth of the logical architecture to address other perspectives such as the business architecture and the information architecture. Justification In the context of discussions held to refine and rationalise the scope for this project, a common understanding prevailed that a fully articulated logical architecture at the enterprise level would need to address many other dimensions that those listed above. Namely the information architecture, business architecture, business process architecture and technology architecture are all architectural perspectives that will need to be defined over time. However, given the available planned resources (financial, time, people) for this project, these perspectives or dimensions of the architecture were deemed out of scope for the current project. Given the scope of these activities both from the perspective of the different IT disciplines such as Business Architecture, Information Architecture, System Architecture as well as the number of diverse teams of experts from different organizations, it was determined that it was essential to purchase a well proven multi-user modelling tool to support this project. The decision to use Enterprise Architect (EA) by Sparx Systems was based on: the low cost of licenses per seat (less than $300 per seat, single desktop licence at $135) Support for a variety of configurations including central database, version control, floating licences and others support for Business Process Modelling Notation (BPMN) support for Unified Modelling Language (UML 2.3) support for data modelling (Entity Relationship Diagrams and Class Diagrams) support for The Open Group Architecture Framework (TOGAF) support for Service Orientated Architectures (SOA) support for XML based model imports and export (XMI 2.1) Logical Architecture /Architecture Principles /Version #1.0.1 final draft 6
10 flexible documentation options: HTML and Rich-Text (RTF) report writers the use of the EA tool by Infoway enterprise architecture teams and HL7 Development Framework (HDF) teams, etc support for multi-user version control check in and checkout of package subsets capability to support system development and code generation activities Logical Architecture /Architecture Principles /Version #1.0.1 final draft 7
11 ehealth Enterprise Architecture Framework The ehealth Enterprise Architecture provides a framework to support ehealth Ontario and the regional hubs in delivering coherent and interoperable ehealth solutions that together can form a true integrated ehealth System to deliver shared data and applications to healthcare participants. The Logical Architecture decomposes and further explains the concepts relayed in the conceptual architecture so that developers of ehealth solutions can apply them in delivering solutions, while maintaining a coherent reference to the target architecture. The diagram above is taken from the conceptual Blueprint and shows a layered representation of the services expected to materialise at the Provincial level (bottom part), the regional hub level (middle part) and the Point Of Service applications that all interoperate together to valid data and functions to endusers in different care settings. The Logical Architecture decomposes into further details the components that make up the Provincial and Regional Hub layers and provides definitions of transaction patterns. Transaction patterns define the processes and processing flow between components to make transactions work in this multi-layered ehealth system. The ehealth architecture identifies the different system capabilities required to make these services a reality: Provide registries, knowledge assets, clinical data and applications; Provide source-of-truth registry applications to normalize and improve fundamental identifiers required for sharing; Logical Architecture /Architecture Principles /Version #1.0.1 final draft 8
12 Compile ehealth data from stakeholders into repositories for sharing; Provide health system business functions through ehealth applications via portals, portlets and messaging to stakeholder application systems; Provide data to stakeholder application systems through messaging; Provide data to people through portals and portlets; Provide data transport capabilities between stakeholder organisation systems; Provide health information knowledge to people through portals, portlets and messaging to stakeholder application systems; ehealth Logical Architecture Generation 1 The focus of the ehealth Logical Architecture is a first-generation (G1) of these capabilities. It defines the common integration and registry services to support ehealth Ontario line of business application interactions with consumer clinical point of service applications and portlets. The ehealth Logical Architecture G1 includes transaction patterns and service component definitions as well as Common Services and ESB Services to support the following lines of business: Provincial Application Services CDMS OLIS Client Registry Provider Registry Location Registry Hub Application Services DI-r CDR The ehealth Logical Architecture design level models and specifications will provide guidance for developers of business and clinical application services to configure or adapt their applications to implement and support the above information technology capabilities and participate fully in Ontario`s ehealth foundation Services. Future generations and iterations of the ehealth Logical Architecture will address other dimensions as determined by ehealth Ontario`s business and clinical needs. ehealth Logical Architecture Deliverables Architecture Principles The ehealth Logical Architecture defines logical architecture principles in the form of an integrated document covering a set of 11 different topics to establish structural definitions and precepts for overarching behaviours expected of the ehealth foundation System. Purpose The architecture principle precepts act as guiding principles for the design and architecture choices made in the development of the logical architecture itself or for projects that develop and integrate any application that participates in the overall system (i.e. consumers or providers of services). Logical Architecture /Architecture Principles /Version #1.0.1 final draft 9
13 Structure The structure of each Architecture Principle (AP) uses the following format: ID Name Statement Rationale Implications AP-EXAMPLE-001 e.g. AP-DMI-006: Use of web services and web services protocol Represents an easily identifiable name that describes the essence of the Architecture Principle rule. Succinctly and unambiguously communicates the fundamental rule. Highlights the business benefits of adhering to the principle using business terminology. This section may also describe the similarity of information and technology principles to the principles governing business operations as well as relationship and precedence to other principles. Highlights the requirements, both for the business and IT, for carrying out the principle in terms of resources, costs, and activities/tasks (i.e."how does this affect me?"). The impact to the business and consequences of adopting a principle should be clearly stated especially if current systems, standards, or practices would be incongruent with the principle upon adoption. Topics The ehealth Logical Architecture includes a total of 95 Architecture Principles documented in the above format categorized under the following topics: Architecture Principle Category EHR SOA Principles External/Public Services Principles Internal Services Principles Data Messaging Interaction Principles EHR Data Principles EHR Document Principles Portlet Services Principles Privacy Principles EHR Service Level Objective Principles Time Synchronization Principles Security Principles ID Prefix AP-SOA AP-EPS AP-IS AP-DMI AP-EHR.Data AP-EHR.Doc AP-PTL AP-PRV AP-SLO AP-TS AP-SEC Logical Architecture /Architecture Principles /Version #1.0.1 final draft 10
14 Architecture Decisions Architecture Decisions documents represents key architecture decisions that apply to the ehealth Ontario Logical Architecture. Each decision represents a position on a specific topic recognized as having material impact on the design of systems and solutions that participate in the ehealth foundation. Key architecture decisions are set out clearly in a separate document so that they can be established and referenced as fundamental architecture directions for participants in ehealth in Ontario. Purpose In addition to the original scope of the project, these Architecture Decisions form an integral part of the ehealth Ontario Logical Architecture. They are created to provide the logical framework for the procurement and/or development of ehealth applications and services. It is assumed that the ehealth Ontario Governance Process, via its enterprise architecture function, will use and can provide for future enhancement to these Logical Architecture Decisions. It is understood that the development and evolution of solutions and the general evolution of technology over time may require updates and evolutions to these decisions.. However, unless a decision is amended in accordance with the ehealth Ontario Governance Process, ehealth applications or services that do not adhere to the Logical Architecture Decisions will be deemed to be non-compliant with Ontario s ehealth Blueprint Structure The ehealth Logical Architecture Decisions include the following topics: Architecture Decision Topic HIAL ESB General Scope Of Processing HIAL ESB Use Of Canonical Form HIAL ESB Transient Data Structure HIAL ESB LOB Service Separation Of Concerns Web Services Nomenclature Purpose To clarify the scope of responsibility of the HIAL- ESB and set some boundaries around the separation of concerns between the Line-Of-Business (LOB) systems and the HIAL-ESB layer. To clarify whether or not the HIAL-ESB is expected to rely on and use an internal canonical (standardized) representation of data when it is processing transactions. To clarify the nature of the data that the HIAL will be operating on in order to fulfil its mandate as the ESB and coordinator for the use of common services. This section presents a definition for the transient data used to control and process the communication, brokering and the application of common services at the enterprise service bus level for ehealth transactions. Provides a definition of scope and separation of concern between the business logic processing expected to happen within Line-Of-Business (LOB) applications and the business logic processing optionally handled within the common services layer tied to the ESB application component. Defines and promote a standard approach for naming services that will be exposed by the ESB. This promoted service nomenclature and taxonomy Logical Architecture /Architecture Principles /Version #1.0.1 final draft 11
15 Consent Service Separation Of Concerns applies primarily to Web Services exposed by the ESB to the external ehealth Ontario service consumers (i.e. Point of Service application). Consent Directives Management Service is responsible for the management and enforcement of privacy policies and rules when EHR data is queried. This architecture decision is concerned specifically with the Assess Consent methods that are included in this service. These methods (or service calls) apply and enforce the consent directives during the Get/List transaction orchestration. Electronic Signature and Encryption Terminology Service & Translation Separation Of Concern Communication Protocol Choices Describes how electronic signature and encryption should be used at the transport, message and business level within the context of the ehealth foundation Services. Describes communication protocol choices for ehealth foundation Services such as: exposed Big Web Services, leveraging XML, SOAPv1.1, and the WS-* and WS-I stacks available from the major software vendors (IBM, Microsoft, Oracle/Sun, etc). HL7V3 over SOAP over HTTP(S) for Synchronous Web Services etc EHR Index Pub/Sub Describes the separation of concerns of the ehealth Ontario EHR Index which provides services that allow for the maintenance and query of a logically unique index of EHR Data (including documents, data records and other EHR objects). Describes the architecture decisions for ehealth Ontario Publish and Subscribe (Pub/Sub) services implement a wide-used system integration pattern that allows information (e.g. messages) to flow between a source (i.e. the publisher) and one or more destinations (i.e. the subscriber). Logical Architecture /Architecture Principles /Version #1.0.1 final draft 12
16 Transaction Patterns The Logical Architecture model includes the definition and design of common transaction patterns in the form of documented BPMN models. Transaction Patterns depict the sequence of services being called to describe the dynamic invocation patterns of internal ehealth services required to execute any given type of transaction. The logical architecture for the use of ehealth services is built on the definition of three common patterns of interaction: data interactions publish/subscribe interactions and portlet interactions. The ability to rely on a limited number of patterns is an important factor in managing complexity and cost of ownership for the overall system. The transaction pattern architecture exposes and defines the different phases of processing for these three basic patterns and decomposes their functional behaviour from the high level down to applicable levels of details. The ehealth Logical Architecture categories of transaction patterns include: Point of Service (PoS) patterns describing the activities that point of service application systems are expected to conduct in order to interact with and use ehealth services. PoS Context Views /Domain patterns (e.g. CR, PR, MMS, Lab, etc), describing the applicability of the patterns to support the types of transactions expected under each line of business domains. ehealth foundation Service (ehfs) patterns (e.g. Clinical Data Interaction, Data Interaction, etc) defining the core patterns to express the detailed processing activities for the use of the HIAL and common services in supporting the delivery of ehealth services. Federated HIAL patterns (e.g. Regional Integration to ehealth Services, CDDR examples, etc) defining processing behaviour expected of different participants in a federated network of service providers including regional hub delivery organisations and provincially delivered services. class Start here - Map Point of Service applications ehealth Foundation Services (EHFS) PoS PoS ESB PROV LoB EHFS Patterns Clinical Data Interaction Data Interaction Security Session Management Pub/Sub PoS PoS PoS Patterns ESB HUB ESB LoB LoB LoB Portlet Interaction Error Management AuditLogging Deployment diagram Component diagram Architecture Principles PoS Context View CR PR MMS LAB SHR CDMS DI HUB LoB Federated HIAL Patterns Provincially supplied ehealth Services PoS Transaction Pattern Invoke clinical ehealth Foundation Service ESB HUB LoB Regional Integration to ehealth Services Regional-only Services Regionally Supplied ehealth Services Invoke non-clinical ehealth Foundation Service Clinical Document Repository Example Logical Architecture /Architecture Principles /Version #1.0.1 final draft 13
17 The diagram above shows a sample of the main navigation map provided as part of the logical architecture. This navigation map shows the point of service organisations and their applications on the left, and the ehealth foundation on the right that integrates Health Information Access Layer ESB capabilities at the provincial and hub level to deliver Line-Of-Business (LOB) services. Individual text links are positioned coherently on the diagram to provide for navigation to the different model diagrams and definitions and access all the artefacts available in the Logical Architecture. Purpose The transaction patterns provide a definition for the processing pathway of system interoperability within the ehealth Logical Architecture and set clear expectations of roles and responsibilities for the different layers of services and application roles expected of different service components. POS and Domain Patterns show the point-of-service context for calling ehealth services. EHFS patterns and Federated HIAL patterns are realized using public (external) service interfaces to line of business (LOB) service components supported by ESB and Common Services components. Modelling Approach Transaction patterns are delivered in the form of documented BPMN models that describe the sequence of services being called. This PoS Context View diagram is a Transaction Pattern sample BPMN model that shows an example of how a Pharmacy would use the ehealth foundation Services to get a list of patient medications and retrieve the medication details. Business Process GET/LIST MMS Data Name: Package: Version: Author: GET/LIST MMS Data eho - Medication Management Service 1.0 dpare Health Organization Care provider Pharmacy Start Perfom clinical service Get patient list of medications View patient list of medications Show patient list of medications Select a medication Get patient medication details View patient medication details Show Patient medication details End ehealth Services GetPatientMedicationSummary Service GetPatientMedicationDetails Service Each transaction pattern was analyzed in detail on a BPMN diagram to show: The start and end event to indicate where a particular process begins and ends The activities relating to particular entities within the model (such as the Care Provider, Pharmacy, ehealth Service) are placed within a containing swim lane to indicate their associations and responsibilities. How the point-of-service transaction patterns are used to establish clear expectations for external service consumers (i.e. applications in point-of-service organisations that call ehealth services) for the different types of transactions that the ehealth foundation will support. Logical Architecture /Architecture Principles /Version #1.0.1 final draft 14
18 How they are also used to establish clear expectations of the different internal services that get invoked in order to execute a transaction pattern. These internal services can belong to regional hubs or to the provincial level. This Transaction Pattern sample BPMN diagram shows a pathway between the ESB, Common Services and Application Services for internal services invocation: BPEL eho PUT Clinical Data Service Invoked ESB Service Invocation Request Triggered Establish Connection Receive Service Invocation Request Authenticate Service Invocation Sender Validate Service Authorization Accept Service Invocation Request Similar activities will be done at the ESB level for the response Return Response to Service Invocation Sender ehealth Internal Services Common Services Prepare Service Orchestration Create Service Canonical Representation Create Audit Log Entry for Service Request Perform Terminology Mapping Validate ehealth Client ID Validate eheath Provider ID(s) Orchestration Validate ehealth SDL ID(s) Confirm Consent? Perform Put Clinical Data Receive Clinical Data Response Create Audit Log Entry for Service Response Complete Orchestration Application Services Get Terminolgy Map Query Client Query Provider Query SDL Get Client Consent Directives Put Clinical Data Structure The types of transaction patterns in the ehealth Logical Architecture include: Context Views The ehealth Services Invocation Context View package contains models of activities and workflow that establish the context of the more detailed transaction patterns that may be found in Application Architecture / Integration Architecture. These patterns provide the context from a line of business perspective such as the registries, CDMS, Lab, MMS, etc. Service Invocation Patterns Invoke clinical ehealth Service Invoke non-clinical ehealth Service LOB Transaction Patterns ehealth Ontario - Chronic Disease Management Service ehealth Ontario - Diagnostic Imaging Service ehealth Ontario- Client Registry Service ehealth Ontario - Clinical Document Service ehealth Ontario - Lab Service ehealth Ontario - Medication Management Service ehealth Ontario - Provider Registry Service Federated HIAL Patterns PROV - Provincially supplied ehealth foundation Services HUB - Regional Integration to ehealth foundation Services HUB - Regional-only Services HUB - Regionally Supplied ehealth foundation Services Logical Architecture /Architecture Principles /Version #1.0.1 final draft 15
19 HUB - Clinical Document Repository Services o GET/LIST Clinical Document from CDDR o PUT Clinical Document to CDDR Security Session Management Patterns No session management Implicit session management Explicit session management ehealth foundation Patterns These transaction patterns are for data interactions and the processes describing the different activities related to Portlets as well as the Publish and Subscribe transaction pattern. Interaction Patterns Clinical Data Interaction Data Interaction Portlet Interaction Publish and Subscribe Specific patterns are also provided to address error management and audit logging. Logical Architecture /Architecture Principles /Version #1.0.1 final draft 16
20 Service Components Definitions A Service Component is a modular part of a system, whose behaviour is defined by its provided and required interfaces; the internal workings of the Component should be invisible and its usage environment independent. The ehealth Logical Architecture includes the following service component definitions and design models of the components including external (public) interfaces as well as native and internal interfaces. There are two key service component navigational maps provided in the Enterprise Architect model the ehealth foundation Component Diagram and the ehealth foundation Deployment Diagram. ehealth foundation Component Diagram cmp eho - ehealth Foundation - Component diagram Name: Package: Version: Author: eho - ehealth Foundation - Component diagram Component Architecture 1.0 dpare Provincial Application Services Knowledge Resources Registries Chronic Disease Management Laboratory (OLIS) Client Registry Prov ider Registry CDMS-DR Reference Information Location Registry Serv ice Drug Information System (DIS) Hub Application Services Diagnostic Imaging Repository Clinical Document Repository Common Services Security Priv acy EHR Index LOB Orchestration Authorization Access Control Digital Signature Consent Directiv es Management Terminology Serv ice LOB Realization Authentication User Registry Public Key Infrastructure Auditing Message Transformation Portlet Serv ices ESB Messaging Context Integration Management Encrypt/Decrypt Caching Interoperability Mapping Management Exception/Error Handling Session Parser Management Service Catalog Queuing Configuration Logging Protocol En/Decode Broker Alert/Notification Policy Management Application Protocol Serialization Network Protocol Routing Publish/Subscribe Logical Architecture /Architecture Principles /Version #1.0.1 final draft 17
21 This diagram represents the packages of service component for the different layers of the ehealth Logical architecture which are: Service Component Package Provincial Application Services Knowledge Resources Hub Application Services Common Services ESB Description This layer presents the Line-Of-Business applications that are established at the provincial level in the ehealth foundation. These applications are the individual information system components that make ehealth services available. The Knowledge Resources Repositories maintain common reference information recognized as valid for sharing and dissemination across a variety of settings in healthcare. These would be used for the development of enhanced portal services. Such information knowledge bases may also be used to support diverse applications. For example a repository of standardized clinical protocols for surgeries, could be used to support information dissemination to caregivers from an ehealth website portal, but it could also be used by an ereferral data transaction service to return this information as part of a referral transaction pathway for a surgery. The definition of the types of knowledge resources is not within the scope of the logical architecture project, nevertheless, the architecture does position a generic component to describe this capability as an integral part of the ehealth foundation Architecture. This layer presents the Line-Of-Business applications that are established at the regional hub level in the ehealth foundation. These applications are the individual information system components that make ehealth services available. This layer presents the first sub-layer of HIAL services. Common services address core functions and capabilities that are established as centrally available and reusable from a single implementation. Generally, common services are used by multiple transactions and they intervene and are invoked in the context of the orchestrated execution of transactions. The common services layer is a core component of the HIAL architecture. These services provide functional support for ehealth LOB Services. These services are responsible for the execution of the transaction patterns which may include the use of any components and services offered within the ehealth foundation. In a sense, the common services are considered as the central nervous system or the kernel for the execution of EHR data access transactions. All transactions aiming at accessing data in client s health records are expected to be processed by the common services layer, namely through the orchestration service. These services are the only components of the ehealth foundation that know about the transactions across the different systems. This layer presents the gateway middleware layer that creates the separation between the healthcare market of point of service applications and the environment of the ehealth foundation. It offers the basic capabilities expected of industry standard enterprise service bus systems. Logical Architecture /Architecture Principles /Version #1.0.1 final draft 18
22 ehealth foundation Deployment Diagram deployment eho - ehealth Foundation - Deployment diagram Name: Package: Version: Author: eho - ehealth Foundation - Deployment diagram Deployment Architecture 1.0 dpare Provincial (eho) Regional Hub (cgta) Regional Hub 2 (cswo) Regional Hub 3 (cneo) Laboratory (OLIS) Drug Information System (DIS) CDMS-DR c-gta CDR :Clinical Document Repository c-swo CDR : Clinical Document Repository Eastern Ontario CDR :Clinical Document Repository Location Registry Serv ice Client Registry Provider Registry HDIRS :Diagnostic Imaging Repository SWODIN :Diagnostic Imaging Repository NEODIN DI-r : Diagnostic Imaging Repository GTA West DI-r : Diagnostic Imaging Repository :Provincial HIAL :Hub HIAL :Hub HIAL :Hub HIAL HIAL The deployment diagram distinguishes instances of the Provincial Application services and Hub Application Services for each of the three regional hubs: c-gta, c-swo and c-neo. Purpose These two representations and definitions of the service components in the ehealth Logical Architecture align with the layers of components established in the ehealth Conceptual Architecture Blueprint. As described above, service components are defined for the following layers: LOB Services o Provincial Application Services o Hub Application Services HIAL - Common Services HIAL - ESB Services Each layer of the ehealth Logical Architecture provides distinct boundaries of component responsibilities within a service oriented architecture (SOA). This allows lines of business applications and components to be added or modified without impacting other components. The benefits of an SOA include but are not limited to: Architecting and designing well-defined business functionalities that are built as software components (discrete pieces of code and/or data structures). o Each service component comprises a self-contained unit of functionality available only via a formally defined interface. o Each service component can be reused by different participants that support different needs. o SOA helps create separation of concern between components of a system, which globally helps limit the complexity and chaos that can overcharge large systems. Logical Architecture /Architecture Principles /Version #1.0.1 final draft 19
23 Promotes the goal of separating consumer applications from the service implementations namely by relying on standards based messaging to enable communication between components. Services can therefore be run on various distributed platforms and be accessed across networks. Helping organizations respond more quickly and more cost-effectively to changing market conditions by relying on an architecture where individual components can more easily be changed and evolved without breaking the entire system. Structure Definitions for the services components in the Logical Architecture are built using UML component diagrams and include a service description and key functions supported as well as key dependencies between services. Each service component definition diagram includes: External (public) interfaces - which are consumed by PoS applications and may also be invoked by ehealth foundation components. External interfaces are realized by the HIAL ESB and typically use standard HL7 messaging specifications. Native interfaces - which are realized by the component application software and may use proprietary XML messages or even other means of inter-application communication (RPC, API, etc...). Internal interfaces (optional) are realized by the HIAL / ESB services and are needed in cases where services exposed by a component are only valid internally for ehealth foundation systems. The level of documentation includes Current & prospective Generation 1 G1 services components Current & prospective Generation 1 G1 public (external) interfaces Current known Native interfaces Note: Although the internal interfaces are not documented in the service definition models, a description template has been provided in the Notes to support future documentation. At this stage of the development of the services, many of the technology procurements and implementations have not been done, as software solutions get deployed to support the public service interfaces described, these native interfaces will have to be documented. Modelling Approach Each service component is analyzed to determine the ehealth definition of the component, the interfaces it must support. Any relevant background information such as relevant standards information or Infoway material is also included as well as document references. A target state section is included if this is relevant for this service component. The following Client Registry service component properties show an example of the service definition documentation format. Logical Architecture /Architecture Principles /Version #1.0.1 final draft 20
24 The service component interfaces are diagrammed in the model to show the Native interfaces realized by the component and the dependency with the HIAL / ESB as well as the External interfaces realized by the ESB which are available for point of service applications to consume. This example Client Registry service component diagram shows these Native and External interfaces as well as the dependencies on any key Common Services or ESB Services. For example the dependency on the Publish / Subscribe component is included to also describe how new patients are added to the Client Registry as well as how Client Identity Changes are communicated to other Provincial and Hub Application Services. Logical Architecture /Architecture Principles /Version #1.0.1 final draft 21
25 composite structure Client Registry - Legacy Name: Package: Version: Author: Client Registry - Legacy Registries 1.0 dpare Client Registry Publish Notification of Client Identity Changes Subscribe New Patient Information Bulk Uploads Integration:: Publish/Subscribe «interface» Client Registry::Get Client Summary - Nativ e «interface» Client Registry::Get Client Details - Native :Provincial HIAL «interface» Client Registry::Get Client Summary External «interface» Client Registry::Get Client Details External The vertical alignment of the realization arrow from the HIAL to the External interface with the dependency arrow from the HIAL to the Native interface with the same name indicates the external interface is expected to pass through its information to the internal interface. Future Iterations This section provides a prospective view of the evolution of the enterprise architecture not just at the logical level. The current logical architecture project has been focusing on the system view of the enterprise architecture with the system principles, the transaction patterns and the services and components definitions. In order to achieve a comprehensive enterprise architecture, a number of other dimensions should be addressed in the future which includes: Defining the Business Architecture: - Define strategy, objectives and goals - Identify Supporting Legislative Framework - Define business domains, business services - Define resources, organizations, people, geography - Actors, Parties, roles - Business networks - Business Process Model (domains, functions) Logical Architecture /Architecture Principles /Version #1.0.1 final draft 22
26 - Representative Business Processes - Representative Business Use Cases - ehealth Service Events Defining the Information Architecture: - Information Management Principles - Data Model: domains, facets, entities - Information Management Policies and Rules Integrating the existing System Architecture: - Linking Transaction Patterns to Data Model - Linking Service Interfaces to Data Model - Linking Domain Business Process Models to Transaction Patterns Defining the Technology Architecture: - Data Centers - Networks - Security Architecture - Client Technology Platforms - Protocols and Technology Choices Future iterations of the logical architecture should also address the evolution of the already provided System Architecture. As ehealth strategy and planning teams refine and determine the way forward for the development of ehealth services in Ontario, new iterative evolutions of the logical architecture will be required to maintain a valid enterprise architecture vision in support of the mission of ehealth Ontario. For the next transition states and future versions of the ehealth Logical architecture, the following items should be considered: - The current work is focused on the integration fabric (the health information access layer) that acts as the transaction processing engine and ties the use of common services (registries, consent, security, audit, logging, etc.) and an enterprise service bus for every ehealth service. Future iterations of the logical architecture also need to address the specifics of the line of business applications that participate in the ehealth foundation. Definitions for the inner components, data, behaviors and rules applied within the boundaries of each LOB applications should also be made a part of the enterprise logical architecture in the future. - The current work establishes definitions for a first target state called Generation 1 ehealth Services. (MMS / DIS, OLIS, DI, CDMS, CDDR, Registries, HIAL, Portlets) Logical Architecture /Architecture Principles /Version #1.0.1 final draft 23
27 - To achieve this first Generation 1 of services, one or two transition states will need to be considered when coupling the dependencies inherent to project delivery timelines and resourcing across the portfolio of initiatives at ehealth Ontario. - Each transition state should define which service components and service interfaces they will materialize, along with the subset of patterns that would be supported. - A prospective view of Generation 2 capabilities should start to be defined as soon as possible to address services such as ereferrals, Encounter History, Shared Health Record, Integrated Acute Care Records, Personal Health Records, Consumer Services, Portals, escheduling, etc. - These future capabilities should be established as long term targets to guide current investments and decisions and should first be defined from a business services perspective and then refined as system and information architecture within the Logical Architecture. Logical Architecture /Architecture Principles /Version #1.0.1 final draft 24
28 Uses of the ehealth Logical Architecture The ehealth Logical Architecture is a framework for ehealth enterprise architecture focused on the business needs and requirements of clinical information sharing initiatives in Ontario. The uses of the Logical Architecture include strategic planning, investment governance, health program and health project planning and management as well as solution project initiatives. For strategic planning Many stakeholders participate in the healthcare industry. The ehealth Logical Architecture describes what the ehealth foundation does from a system perspective and how and where interoperability would be created. The ehealth Logical Architecture is a key input into the strategic planning exercises for healthcare funders, providers, organizations and associations. Planners can use the logical architecture to understand the impact of a proposed change or evolution. They can also use it to understand the positioning and integration requirements associated with new line-of-business applications and services. The ehealth foundation is made up of many components and the strategic planning of an optimized path to the implementation within Ontario has many influencing factors that may include: Readiness Healthcare system priorities Results of early adopter pilot projects Pre-existing initiatives Change management capabilities Financial and human resources Capabilities of POS applications And others For investment governance The ehealth Logical Architecture consists of a set of a valuable strategic input documents and models that can guide and assist ehealth Ontario management in their decision-making related to the initial and ongoing funding and implementation of ehealth services initiatives and solution projects. The Logical architecture inputs into ehealth investment decisions include: The centralized management of well-defined requirements to facilitate appropriate technology procurement and vendor management o Provides a robust definition of the architecture dependencies of provincial and regional hub application services o Provides a cross reference and traceability of where each component is used within the enterprise architecture Facilitates concentration of required skill-sets (ESB experts, LOB experts, POS application experts,...) Defines how standards-based technology can be used optimally to support sharing of ehealth information Helps promote structural reuse of technology investments Enhances the opportunities for financial ROI from legacy applications Documented and clearer system development and migration strategies o Priorities, timelines, options and benefits o Focuses investment in the right areas at the right time Logical Architecture /Architecture Principles /Version #1.0.1 final draft 25
29 For Regional Hub IT Organizations and Development Teams Regional hub organizations such as the UHN IT group and regional ehealth development teams are expected to engage with the Logical Architecture for guidance and input as to how to develop their hub services or consumer applications to be ehealth Architecture compliant. The ehealth Logical Architecture deliverables, described in detail in the above sections, should be used by project architecture and design teams in the course of the system development requirements definition, architecture and design phases as well as architecture review checkpoint processes and solution testing activities. The following table depicts the key Logical Artefacts and a brief summary of their intended use in the context of solution projects. ehealth Logical Architecture Deliverable Architecture Principles Architecture Decisions Transaction Patterns (BPMN models) Project Use Provides the underlying and guiding principles for the design and architecture choices made in the development for solution projects that develop and integrate any application that participates in the overall system (i.e. consumers or providers of services). Provide fundamental architecture directions for design of ehealth Services. ehealth applications or services that do not adhere to the Logical Architecture Decisions will be deemed to be non-compliant with the Ontario s ehealth Blueprint. Provide architects and designers fundamental invocation patterns of interactions for ehealth services being developed. Provides POS perspective patterns and ehealth foundation patterns for: 1. Data interactions 2. Publish/subscribe interactions and 3. Portlet interactions It is expected that development of these types of transactions will use the Enterprise Architect BPMN models to refine and specialize and instantiate these transaction patterns to meet the requirements of specific project solutions. Service Definitions (UML Component models) Provide service component definitions and design models of all the Logical Architecture components including external (public) interfaces as well as native and internal interfaces. It is expected that developers of these types of component services and interfaces will use the Enterprise Architect Service Definition UML Logical Architecture /Architecture Principles /Version #1.0.1 final draft 26
30 models to refine, design and instantiate these components to implement the domain specific solutions. This may include developing new interfaces or evolving existing interfaces and service definitions to meet specific solution requirements. Such evolutions and changes would be done in collaboration and under the governance of the Enterprise Architecture Group at ehealth. For Point-Of-Service Organisations The Logical Architecture also contributes to ehealth solution planning processes ongoing in healthcare programs and health organizations, including hospitals, pharmacies, private clinics, regional health authorities, home care agencies, long term care and tertiary care facilities and agencies, etc. These organizations are at different stages in assessing or transforming their operations in regards to the use of ehealth services and capabilities. In that sense, the Logical Architecture can contribute to the planning activities of these organizations including: Identification of business and technical requirements to support procurement activities Planning the integration of their clinical and operational systems to support the use of ehealth services and the EHR. Planning and managing the change and adoption of these new capabilities by users, including physicians, nurses and allied health professionals Identifying opportunities to further benefit from the use of ehealth capabilities and services by: o Reengineering work processes o Upgrading systems and infrastructure o Creating new policies and guidelines o Enhancing the delivery of patient/client care For solution project initiatives The use of a common architectural model also establishes a consistent terminology that facilitates communications between stakeholder groups. Although those participating in these initiatives will have different perspectives and interests in relation to ehealth services, the ehealth Logical Architecture provides a common framework to better enable stakeholders and solution project initiatives to express their visions and requirements and to identify and resolve issues. The Logical Architecture puts forward several key architectural principles and decisions that should be taken into consideration with respect to how ehealth solution will be deployed. The Logical Architecture also demonstrates transaction patterns and service component interfaces for the use of pan-canadian and technical standards adopted by ehealth Ontario. This logical architecture constructs stand as a way to jump start projects and reduce the amount of re-analysis and re-design time on new projects implementing ehealth related initiatives in this complex environment. Planning phase In a project planning phase the ehealth Logical Architecture provides the high-level roadmap that vendors can leverage when defining their product development and marketing strategy. The deployment of standard-based, interoperable ehealth solutions in Ontario creates enormous opportunities for greater reusability of existing systems and, most importantly, for creating new, high value-add solutions. The ehealth Logical Architecture also serves to significantly reduce vendor development and implementation costs that are incurred in the non-standards based environment that would otherwise exist. By Logical Architecture /Architecture Principles /Version #1.0.1 final draft 27
31 incorporating the concepts and standards described in the Logical Architecture, vendors can plan to align and evolve their information systems solutions or services to capitalize on these models. Development phase The ehealth Logical Architecture provides the conceptual view of what needs to be deployed or developed. Thus, design architecture phases can be reduced in scope by using these deliverables and projects can more quickly complete the architecture and design phases to get to the development phases. The Logical Architecture, by way of providing a vetted shared logical level definition of components and software services, should stand as way to save 25% + of the effort normally spread across the Preliminary Analysis, Architecture and Design phases of any project that would operate without this level of definition. Test & Implementation phases The Logical Architecture should be used by system test analysts and quality assurance managers to build traceability matrices, test plans and validation grids for system testing. The logical architecture defines transaction patterns that can be established as test cases. It also provides definitions for service interfaces native and public expected of the different components of the ehealth foundation; those can also be used to build test cases. Logical Architecture /Architecture Principles /Version #1.0.1 final draft 28
32 Appendix A Modelling Usage & Conventions This section describes the Enterprise Architect usage and modelling conventions that have been established through the ehealth Ontario Logical Architecture. Model Structure The ehealth Logical Architecture model structure includes: Business Architecture This section includes a Business Architecture as a placeholder where ehealth Ontario is expected to build the Business Architecture deliverables in the future. Information Architecture This section is a placeholder for the related ehealth Information Architecture domain models which is currently being developed. This section also contains a preliminary data model material from Canada Health Infoway (Business Domain Model - Infoway reference). While this model is relevant to the ehealth space, it would need to be adapted to the specifics of the context in Ontario. Application Architecture Integration Architecture This package contains diagrams that describe the Context Views and Transaction Patterns that are core to the Logical Architecture. Logical Architecture /Architecture Principles /Version #1.0.1 final draft 29
33 Component Architecture Contains the component breakdown from the Conceptual Architecture work for Application Services, Common Services, ESB and Knowledge Resources Deployment Architecture Describes the nodes and components for Provincial and the three regional hubs c-gta, c-swo and c-neo Logical Architecture /Architecture Principles /Version #1.0.1 final draft 30
SOA in the pan-canadian EHR
SOA in the pan-canadian EHR Dennis Giokas Chief Technology Officer Solution Architecture Group Canada Health Infoway Inc. 1 Outline Infoway EHR Solution EHRS Blueprint Approach EHR Standards Oriented ArchitectureMore information
SOA in the pan-canadian EHR
SOA in the pan-canadian EHR Dennis Giokas Chief Technology Officer Solutions Products and Group Canada Health Infoway Inc. 1 Outline Infoway EHR Solution EHRS Blueprint Overview Oriented Architecture BusinessMore information
CONNECTING ONTARIO THROUGH THE CONNECTIVITY STRATEGY. Peter Bascom, Chief Architect Mike Krasnay, Director of Integration and Solution Architecture
CONNECTING ONTARIO THROUGH THE CONNECTIVITY STRATEGY Peter Bascom, Chief Architect Mike Krasnay, Director of Integration and Solution Architecture Advanced Preview! Published in the coming months ExtensiveMore information
Glossary. Audit Registry
Audit Registry Canada Health Infoway (CHI) Client Registry (CR) Clinical Data/Document Repository (CDDR) Consent Registry (CR) Continuum of Care Cross-enterprise Document Sharing for Imaging (XDS-I) ProfileMore information
Ontario s ehealth Blueprint
Ontario s ehealth Blueprint Narration The central themes of Ontario s ehealth Blueprint are connectivity, innovation and a commitment to improve patient care and care outcomes. Through these themes andMore information
Privacy and Security within an Interoperable EHR
1 Privacy and Security within an Interoperable EHR Stan Ratajczak Director Privacy and Security Solutions Architecture Group November 30, 2005 Electronic Health Information and Privacy Conference OttawaMore information
E-HEALTH PLATFORMS AND ARCHITECTURES E-Government Andreas Meier Nicolas Werro University of Fribourg Alfredo Santa Cruz 19.01.2007 Contents 1. Introduction 2. Existing Capabilities and Strategic ApproachMore information
SOA Standards Service Profile
SOA Standards Service Profile 1 Contents 1 Purpose... 1 2 Scope... 1 3 Service Attributes... 2 3.1 Business Facing Properties... 3 3.1.1 Business Service... 3 3.1.2 Service Level Definition... 5 3.2 TechnicalMore information
The EHR Agenda in Canada
The EHR Agenda in Canada IHE Workshop June 28, 2005 Dennis Giokas, Chief Technology Officer Agenda Background on Canadian Healthcare System About Canada Health Infoway Interoperable EHR Solution DefinitionsMore information
Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies
Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies 3-day seminar Give Your Business the Competitive Edge SOA has rapidly seized the momentum and center stage becauseMore information
SOA REFERENCE ARCHITECTURE: WEB TIER SOA Blueprint A structured blog by Yogish Pai Web Application Tier The primary requirement for this tier is that all the business systems and solutions be accessibleMore information
Ontario s Ehealth Blueprint. in-depth
Ontario s Ehealth Blueprint in-depth TERMS AND CONCEPTS ehealth Ontario supports the use of health informatics, health information management and information technology industry standard definitions forMore information
Industrial-Strength Interoperability Platform for Health (IOP-H)
Industrial-Strength Interoperability Platform for Health (IOP-H) Pierre Coderre To sustain the evolution toward pan-canadian electronic health records, Fujitsu was mandated to develop the InterOperabilityMore information
Developers Integration Lab (DIL) System Architecture, Version 1.0
Developers Integration Lab (DIL) System Architecture, Version 1.0 11/13/2012 Document Change History Version Date Items Changed Since Previous Version Changed By 0.1 10/01/2011 Outline Laura Edens 0.2More information
Government's Adoption of SOA and SOA Examples
Government's Adoption of SOA and SOA Examples Presented by : Ajay Budhraja, Chief of Enterprise Services ME (Engg), MS (Management), PMP, CICM, CSM, ECM (Master) AIIM, ITIL-F Copyright 2008 Ajay BudhrajaMore information
Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies
Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies 3-day seminar Give Your Business the Competitive Edge SOA has rapidly seized the momentum and center stage becauseMore information
For <Project> Version 1.0
Oklahoma Department of Human Services Data Services Division Service-Oriented Architecture (SOA) For Version 1.0 Table of Contents 1. Service Oriented Architecture (SOA) Scope...More information
SOA: The missing link between Enterprise Architecture and Solution Architecture
SOA: The missing link between Enterprise Architecture and Solution Architecture Jaidip Banerjee and Sohel Aziz Enterprise Architecture (EA) is increasingly being acknowledged as the way to maximize existingMore information
Logical Architecture Principles
Ontario Provincial EHR Logical Architecture Principles Version: 1.0 Copyright Notice Copyright 2012, ehealth Ontario All rights reserved No part of this document may be reproduced in any form, includingMore information
Singapore s National Electronic Health Record
Singapore s National Electronic Health Record The Roadmap to 2010 Dr Sarah Christine Muttitt Chief Information Officer Information Systems Division 17 th July, 2009 Taking the Next Step (MSM April 2008)More information
Portal and Web Application Connectivity
Portal and Web Application Connectivity Architecture and Standards Version: 1.0 Document Owner: ehealth Ontario Copyright Notice Copyright 2015, ehealth Ontario All rights reserved No part of this documentMore information
Table of Contents. 1 Executive Summary... 2 2. SOA Overview... 3 2.1 Technology... 4 2.2 Processes and Governance... 8
Table of Contents 1 Executive Summary... 2 2. SOA Overview... 3 2.1 Technology... 4 2.2 Processes and Governance... 8 3 SOA in Verizon The IT Workbench Platform... 10 3.1 Technology... 10 3.2 ProcessesMore information
Service Oriented Architecture 1 COMPILED BY BJ
Service Oriented Architecture 1 COMPILED BY BJ CHAPTER 9 Service Oriented architecture(soa) Defining SOA. Business value of SOA SOA characteristics. Concept of a service, Enterprise Service Bus (ESB) SOAMore information
SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) VERSION 2.1 SERVICE-ORIENTED SOFTWARE ARCHITECTURE MODEL LANGUAGE SPECIFICATIONS 1 TABLE OF CONTENTS INTRODUCTION... 3 About The Service-Oriented Modeling FrameworkMore information
SOA REFERENCE ARCHITECTURE: SERVICE TIER SOA Blueprint A structured blog by Yogish Pai Service Tier The service tier is the primary enabler of the SOA and includes the components described in this section.More information
NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0
NASCIO EA Development Tool-Kit Solution Architecture Version 3.0 October 2004 TABLE OF CONTENTS SOLUTION ARCHITECTURE...1 Introduction...1 Benefits...3 Link to Implementation Planning...4 Definitions...5More information
IBM Software. IBM Initiate: Delivering Accurate Patient and Provider Identification for Canadian Electronic Health Records
IBM Software IBM Initiate: Delivering Accurate Patient and Provider Identification for Canadian Electronic Health Records IBM Initiate: Delivering Accurate Patient and Provider Identification for CanadianMore information
Table of Contents. Preface... 1. 1 CPSA Position... 2. 1.1 How EMRs and Alberta Netcare are Changing Practice... 2. 2 Evolving Standards of Care...
March 2015 Table of Contents Preface... 1 1 CPSA Position... 2 1.1 How EMRs and Alberta Netcare are Changing Practice... 2 2 Evolving Standards of Care... 4 2.1 The Medical Record... 4 2.2 Shared MedicalMore information
Introduction to Service-Oriented Architecture for Business Analysts
Introduction to Service-Oriented Architecture for Business Analysts This course will provide each participant with a high-level comprehensive overview of the Service- Oriented Architecture (SOA), emphasizingMore information
March 31, 2006. Dear partners and collaborators:
March 31, 2006 Dear partners and collaborators: I am pleased to present the revised version of the Electronic Health Record Solution (EHRS) Blueprint, Canada Health s road map guiding the sustainable developmentMore information
Background: Business Value of Enterprise Architecture TOGAF Architectures and the Business Services Architecture
Business Business Services Services and Enterprise and Enterprise This Workshop Two parts Background: Business Value of Enterprise TOGAF s and the Business Services We will use the key steps, methods andMore information
National Integrated Services Framework The Foundation for Future e-health Connectivity. Peter Connolly HSE May 2013
National Integrated Framework The Foundation for Future e-health Connectivity Peter Connolly HSE May 2013 The Context Introduction A national approach to interoperability is essential for Ireland s E-HealthMore information
How service-oriented architecture (SOA) impacts your IT infrastructure
IBM Global Technology Services January 2008 How service-oriented architecture (SOA) impacts your IT infrastructure Satisfying the demands of dynamic business processes Page No.2 Contents 2 IntroductionMore information
Service Oriented Architecture (SOA) An Introduction
Oriented Architecture (SOA) An Introduction Application Evolution Time Oriented Applications Monolithic Applications Mainframe Client / Server Distributed Applications DCE/RPC CORBA DCOM EJB s MessagesMore information
Service-Oriented Architecture and Software Engineering
-Oriented Architecture and Software Engineering T-86.5165 Seminar on Enterprise Information Systems (2008) 1.4.2008 Characteristics of SOA The software resources in a SOA are represented as services basedMore information
Guideline. Enterprise Architecture Guide. 1. Purpose. 2. Scope. 3. Related documents. 4. Enterprise Architecture Guide
Guideline Policy # QH-GDL-402-6-3: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 definitionsMore information
Canada Health Infoway
Canada Health Infoway EHR s in the Canadian Context June 7, 2005 Mike Sheridan, COO Canada Health Infoway Healthcare Renewal In Canada National Healthcare Priorities A 10-year Plan to Strengthen HealthcareMore information
Service-Oriented Approach to Electronic Health Records Phase 3 November 23, 2010
Service-Oriented Approach to Electronic Health Records November 23, 2010 1 Table of Contents 1 Introduction... 4 1.1 Requirements... 5 1.2 Use Cases... 5 1.2.1 Use Case Description - Create EHR... 7 1.2.2More information
Independent Insight for Service Oriented Practice. An SOA Roadmap. John C. Butler Chief Architect. A CBDI Partner Company. www.cbdiforum.
Independent Insight for Oriented Practice An SOA Roadmap John C. Butler Chief Architect A CBDI Partner Company www.cbdiforum.com Agenda! SOA Vision and Opportunity! SOA Roadmap Concepts and Maturity Levels!More information
Service-Oriented Architecture and its Implications for Software Life Cycle Activities
Service-Oriented Architecture and its Implications for Software Life Cycle Activities Grace A. Lewis Software Engineering Institute Integration of Software-Intensive Systems (ISIS) Initiative Agenda SOA:More information
Emerging Technologies Shaping the Future of Data Warehouses & Business Intelligence
Emerging Technologies Shaping the Future of Data Warehouses & Business Intelligence Service Oriented Architecture SOA and Web Services John O Brien President and Executive Architect Zukeran TechnologiesMore information
Getting Started with Service- Oriented Architecture (SOA) Terminology
Getting Started with - Oriented Architecture (SOA) Terminology Grace Lewis September 2010 -Oriented Architecture (SOA) is a way of designing, developing, deploying, and managing systems it is neither aMore information
D. SERVICE ORIENTED ARCHITECTURE PRINCIPLES 1. Principles of serviceorientation 2. Service exchange lifecycle 3. Service composition 4. Evolution of SOA 212 D.1 Principles of service-orientation 213 HISTORICALMore information
Enterprise Service Bus Defined. Wikipedia says (07/19/06)
Enterprise Service Bus Defined CIS Department Professor Duane Truex III Wikipedia says (07/19/06) In computing, an enterprise service bus refers to a software architecture construct, implemented by technologiesMore information
SOA Planning Guide. 2015 The Value Enablement Group, LLC. All rights reserved.
SOA Planning Guide 1 Agenda q SOA Introduction q SOA Benefits q SOA Principles q SOA Framework q Governance q Measurement q Tools q Strategic (long term) View 2 Introduction to SOA q Service-oriented architectureMore information
An Overview Of Ontario s EHR Connectivity Strategy The Vision For 2015 And Beyond
An Overview Of Ontario s EHR Connectivity Strategy The Vision For 2015 And Beyond An Overview Of Ontario s EHR Connectivity Strategy The Vision For 2015 And Beyond 01 Contents Introduction 02 About TheMore information
Course Description. Course Audience. Course Outline. Course Page - Page 1 of 14
Course Page - Page 1 of 14 Solution Architecture Training: SA Practitioner's Guide (Extended) BSP-2325 Length: 4 days Price: $ 2,995.00 Course Description The course covers stakeholder identification,More information
Introduction to Service Oriented Architectures (SOA)
Introduction to Service Oriented Architectures (SOA) Responsible Institutions: ETHZ (Concept) ETHZ (Overall) ETHZ (Revision) http://www.eu-orchestra.org - Version from: 26.10.2007 1 Content 1. IntroductionMore information
BC ehealth Conceptual System Architecture
BC ehealth Conceptual System Architecture Copyright 2005, Province of British Columbia All rights reserved BC ehealth Conceptual System Architecture National Library of Canada Cataloguing in PublicationMore information
ONTARIO S EHR CONNECTIVITY STRATEGY IMPROVING PRIMARY TO SPECIALIST REFERRAL THROUGH INTEGRATION. Peter Bascom Chief Architect, ehealth Ontario
ONTARIO S EHR CONNECTIVITY STRATEGY IMPROVING PRIMARY TO SPECIALIST REFERRAL THROUGH INTEGRATION Peter Bascom Chief Architect, ehealth Ontario Cindy Hollister Director, Professional Practice, Canada HealthMore information
Service-Oriented Architecture: Analysis, the Keys to Success!
Service-Oriented Architecture: Analysis, the Keys to Success! Presented by: William F. Nazzaro CTO, Inc. email@example.com www.iconatg.com Introduction Service-Oriented Architecture is hot, but we seemMore information
Creating a national electronic health record: The Canada Health Infoway experience
Creating a national electronic health record: The Canada Health Infoway experience Presentation by Dennis Giokas Chief Technology Officer, Canada Health Infoway October 11, 2007 Overview The need for EHRMore information
Unifying IT Vision Through Enterprise Architecture
Unifying IT Vision Through Enterprise Architecture A model for Strategic Alignment Northeast Ohio Information Technology & Enterprise Architects (NEO-ITEA) Presentation To: Integrate 2010: Uniting theMore information
GOVERNANCE OPTIMIZATION Hire Wire EHR Governance Balancing Needs of Internal and External Stakeholders Peter Bascom, Chief Architect, ehealth Ontario Julia Peters, Director, ehealth Ontario. 1 Today sMore information
Realizing business flexibility through integrated SOA policy management.
SOA policy management White paper April 2009 Realizing business flexibility through integrated How integrated management supports business flexibility, consistency and accountability John Falkl, distinguishedMore information
Service-Oriented Architectures
Architectures Computing & 2009-11-06 Architectures Computing & SERVICE-ORIENTED COMPUTING (SOC) A new computing paradigm revolving around the concept of software as a service Assumes that entire systemsMore information
White Paper. An Introduction to Informatica s Approach to Enterprise Architecture and the Business Transformation Toolkit
White Paper An Introduction to Informatica s Approach to Enterprise Architecture and the Business Transformation Toolkit This document contains Confidential, Proprietary and Trade Secret Information (More information
The Way to SOA Concept, Architectural Components and Organization
The Way to SOA Concept, Architectural Components and Organization Eric Scholz Director Product Management Software AG Seite 1 Goals of business and IT Business Goals Increase business agility Support newMore information
Air Force SOA Enterprise Service Bus Study Using Business Process Management Workflow Orchestration for C4I Systems Integration
Air Force SOA Enterprise Service Bus Study Using Business Process Management Workflow Orchestration for C4I s Integration Dr. Timothy D. Kehoe, Irene Chang, Dave Czulada, Howard Kong, Dr. Dino KonstantopoulosMore information
SOA REFERENCE ARCHITECTURE August 15, 2007 Prepared by Robert Woolley, Chief Technologist and Strategic Planner INTRODUCTION This document is a derivative work of current documentation and presentationsMore information
An Oracle White Paper November 2009. Oracle Primavera P6 EPPM Integrations with Web Services and Events
An Oracle White Paper November 2009 Oracle Primavera P6 EPPM Integrations with Web Services and Events 1 INTRODUCTION Primavera Web Services is an integration technology that extends P6 functionality andMore information
Introduction to Financial Messaging Services Bus A White Paper by Microsoft and SAGA
Simplifying SWIFT Connectivity Introduction to Financial Messaging Services Bus A White Paper by Microsoft and SAGA Version 1.0 August 2009 Applies to: Financial Services Architecture BizTalk Server BizTalkMore information
SOA Blueprints Concepts
TECHNICAL SPECIFICATION Draft v0.5 (For Public Review) A move to drive industry standardization of SOA concepts and terminology http://www.middlewareresearch.com The Middleware Company Research Team SteveMore information
Enterprise Architecture at an Integrated Academic Medical Center
Enterprise Architecture at an Integrated Academic Medical Center April 15, 2015 Carlos A. Alegria, Ph.D., CPHiMS, PMP Director, Enterprise Architecture NYU Langone Medical Center @calegria001 #HIMSS15More information
Enterprise Application Integration (EAI) Architectures, Technologies, and Best Practices
Enterprise Application Integration (EAI) Architectures, Technologies, and Best Practices Give Your Business the Competitive Edge IT managers have been under increasing pressure to migrate a portfolio ofMore information
Five best practices for deploying a successful service-oriented architecture
IBM Global Services April 2008 Five best practices for deploying a successful service-oriented architecture Leveraging lessons learned from the IBM Academy of Technology Executive Summary Today s innovativeMore information
Enterprise SOA Strategy, Planning and Operations with Agile Techniques, Virtualization and Cloud Computing
Enterprise SOA Strategy, Planning and Operations with Agile Techniques, Virtualization and Cloud Computing Presented by : Ajay Budhraja, Chief, Enterprise Services ME (Engg), MS (Mgmt), PMP, CICM, CSM,More information
Standards and their role in Healthcare ICT Strategy. 10th Annual Public Sector IT Conference
Standards and their role in Healthcare ICT Strategy 10th Annual Public Sector IT Conference Peter Connolly Oct 2014 What is the Direction of Travel? 1 Understanding the Why- The Data Context 2 StakeholderMore information
Service Oriented Architectures
8 Service Oriented Architectures Gustavo Alonso Computer Science Department Swiss Federal Institute of Technology (ETHZ) email@example.com http://www.iks.inf.ethz.ch/ The context for SOA A bit of historyMore information
The Enterprise Service Bus: Making Service-Oriented Architecture Real
The Enterprise Service Bus: Making Service-Oriented Architecture Real M.T. Schmidt et al. Presented by: Mikael Fernandus Simalango SOA in Early Days Introduction Service Requester bind find Service RegistryMore information
A Step-by-Step Guide to Defining Your Cloud Services Catalog
A Step-by-Step Guide to Defining Your Cloud Services Catalog Table of Contents Introduction Chapter 1 Defining the Services Catalog Chapter 2 Building a Services Catalog Chapter 3 Choosing the Right SolutionMore information
Principles and Foundations of Web Services: An Holistic View (Technologies, Business Drivers, Models, Architectures and Standards)
Principles and Foundations of Web Services: An Holistic View (Technologies, Business Drivers, Models, Architectures and Standards) Michael P. Papazoglou (INFOLAB/CRISM, Tilburg University, The Netherlands)More information
Traventec. September 2004. Technology Feature. Roadmap for Adoption of Service Oriented Architecture
Traventec September 2004 Technology Feature Roadmap for Adoption of Service Oriented Architecture ROADMAP FOR ADOPTION OF SERVICE ORIENTED ARCHITECTURE... 2 1. INTRODUCTION...2 2. GET PEOPLE INVOLVED...2More information
Concept Proposal. A standards based SOA Framework for Interoperable Enterprise Content Management
Concept Proposal A standards based SOA Framework for Interoperable Enterprise Content Management Mike Connor firstname.lastname@example.com Paul Fontaine email@example.com What is it? IECM Framework Vision:More information
SOA and API Management
SOA and API Management Leveraging Your Investment in Service Orientation Version 1.0 December 2013 John Falkl General Manager, Technology, Strategy & Integration Haddon Hill Group, Inc. Contents Introduction...More information
1 What Are Web Services?
Oracle Fusion Middleware Introducing Web Services 11g Release 1 (11.1.1) E14294-04 January 2011 This document provides an overview of Web services in Oracle Fusion Middleware 11g. Sections include: WhatMore information
JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2008 Vol. 7, No. 8, November-December 2008 What s Your Information Agenda? Mahesh H. Dodani,More information
Platform Reusability to Support Multiple State Agencies, Systems and Programs
Platform Reusability to Support Multiple State Agencies, Systems and Programs Leveraging a Health Insurance Exchange (HIX) Platform to achieve inter-agency and intra-agency interoperability to meet agencyMore information
Business Process Management Tampereen Teknillinen Yliopisto
Business Process Management Tampereen Teknillinen Yliopisto 31.10.2007 Kimmo Kaskikallio IT Architect IBM Software Group IBM SOA 25.10.2007 Kimmo Kaskikallio IT Architect IBM Software Group Service OrientedMore information
A Quick Introduction to SOA
Software Engineering Competence Center TUTORIAL A Quick Introduction to SOA Mahmoud Mohamed AbdAllah Senior R&D Engineer-SECC email@example.com Waseim Hashem Mahjoub Senior R&D Engineer-SECC CopyrightMore information
Clinical Knowledge Manager. Product Description 2012 MAKING HEALTH COMPUTE
Clinical Knowledge Manager Product Description 2012 MAKING HEALTH COMPUTE Cofounder and major sponsor Member and official submitter for HL7/OMG HSSP RLUS, EIS 'openehr' is a registered trademark of theMore information
IBM Enterprise Service Bus for Healthcare
IBM Enterprise Service Bus for Enabling new levels of integration and interoperability for today s demanding hospitals and health plans Highlights Integrate data and applications from disparate sourcesMore information
Service Oriented Architecture
Service Oriented Architecture Charlie Abela Department of Artificial Intelligence firstname.lastname@example.com Last Lecture Web Ontology Language Problems? CSA 3210 Service Oriented Architecture 2 Lecture OutlineMore information
API Architecture. for the Data Interoperability at OSU initiative
API Architecture for the Data Interoperability at OSU initiative Introduction Principles and Standards OSU s current approach to data interoperability consists of low level access and custom data modelsMore information
Myths About Service-Oriented Architecture Demystifying SOA. producers can coexist, and still have no dependence on each other.
WSJ: SOA Myths About Service-Oriented Architecture Demystifying SOA Service-oriented architecture (SOA) refers to an architectural solution that creates an environment in which services, service consumers,More information
SOA for Healthcare: Promises and Pitfalls
SOA for Healthcare: Promises and Pitfalls Dennis B. Smith firstname.lastname@example.com SOA in Health Care Conference: Value in a Time of Change Chicago, IL USA June 3, 2009 Agenda Healthcare IT Challenges SOA: TheMore information
BEA AquaLogic Integrator Agile integration for the Enterprise Build, Connect, Re-use
Product Data Sheet BEA AquaLogic Integrator Agile integration for the Enterprise Build, Connect, Re-use BEA AquaLogic Integrator delivers the best way for IT to integrate, deploy, connect and manage process-drivenMore information
Guiding Principles for Technical Architecture
This document is a statement of the principles that will guide the technical development of the Kuali Student system. It will serve as a reference throughout the full lifecycle of the project. While theseMore information
EHR Business Process Models for Care Coordination and MU
EHR Business Process Models for Care Coordination and MU OSEHRA 2014 Conference Bethesda, MD Dr. Aneel Advani SVP Healthcare, everis Group Assoc. Prof (Adj.), Johns Hopkins 2012, everis Spain, S.L. SeptemberMore information
A standards-based approach to application integration
A standards-based approach to application integration An introduction to IBM s WebSphere ESB product Jim MacNair Senior Consulting IT Specialist firstname.lastname@example.com Copyright IBM Corporation 2005. All rightsMore information
Increasing Development Knowledge with EPFC
The Eclipse Process Framework Composer Increasing Development Knowledge with EPFC Are all your developers on the same page? Are they all using the best practices and the same best practices for agile,More information
GE Healthcare. ehealth: Solutions to Transform Care Delivery
GE Healthcare ehealth: Solutions to Transform Care Delivery This presentation does not constitute a representation or warranty or documentation regarding the product or service featured. All illustrationsMore information
Designing an Enterprise Application Framework for Service-Oriented Architecture 1
Designing an Enterprise Application Framework for Service-Oriented Architecture 1 Shyam Kumar Doddavula, Sandeep Karamongikar Abstract This article is an attempt to present an approach for transformingMore information
ISO 18308 INTERNATIONAL STANDARD. Health informatics Requirements for an electronic health record architecture
INTERNATIONAL STANDARD ISO 18308 First edition 2011-04-15 Health informatics Requirements for an electronic health record architecture Informatique de santé Exigences relatives à une architecture de l'enregistrementMore information
Provider Registries: Reduce Health System Costs, Increase Efficiencies, Improve Care
IBM Software Group, Information Management Healthcare Provider Registries: Reduce Health System Costs, Increase Efficiencies, Improve Care 2 Provider Registries: Reduce Health System Costs, Increase Efficiencies,More information
Central Ontario Electronic Health System
Central Ontario Electronic Health System Andrew Hussain Regional Chief Information Officer Central Ontario LHINs Marlene Ross Senior Project Manager, ehealth Lead Central East LHIN February 2013 TopicsMore information
POLAR IT SERVICES. Business Intelligence Project Methodology
POLAR IT SERVICES Business Intelligence Project Methodology Table of Contents 1. Overview... 2 2. Visualize... 3 3. Planning and Architecture... 4 3.1 Define Requirements... 4 3.1.1 Define Attributes...More information
Central Ontario Electronic Health System
Central Ontario Electronic Health System Andrew Hussain Regional Chief Information Officer Central Ontario LHINs May 2012 For the purpose of this overview it is important to keep in mind the specific definitionMore information
Title Draft Pan-Canadian Primary Health Care Electronic Medical Record Content Standard, Version 2.0 Data Extract Specifi cation Business View
pic Title Draft Pan-Canadian Primary Health Care Electronic Medical Record Content Standard, Version 2.0 Data Extract Specifi cation Business View Primary Health Care Who We Are Established in 1994, CIHIMore information


text:
Resistance to harm reduction initiatives, and to legalisation or decriminalisation of drug use, stems from many impulses. Here I will discuss just one: an expectation placed upon the addicted.
They are expected to live up to a conception of autonomy, perhaps liberation, the violation of which offends the sensibilities of persons with strong views on what people should be. If someone were to function properly with the aid of certain chemicals, many would prefer to see that person do it without such help - and even to jeopardise that individual's wellbeing, along with the wellbeing of those close to that person - in hopes of creating the "right" kind of person out of him.
Leaving aside that this is akin to taking away someone's wheelchair or hearing aid in the belief that there is only one acceptable way for humans to move or to listen, this column is about expectations that our civilisation has been thrusting upon people for some two hundred years. The efforts got really brutal in the early twentieth century when prohibition of alcohol and other drugs was invoked.
The issue could be framed this way: are addicts, and other citizens, duty bound to live up to the expectations of others? If so, when? I would say that it's a duty insofar as they are expected not to rob or assault their neighbours and to be productive if they are able. If such duties have been met, they should not feel duty bound to live up to someone's idea about what "truly free" people must "really" be like.
Often, it comes down to just that. Preachy questions - is this or that type of maintenance a real solution? - presume a lot. First, the meaning of real. Second, that life is about final solutions rather than manageable realities (which in fact are much more common).
It was in the late eighteenth and early nineteenth centuries that compulsive substance use of all kinds became a major target. An emerging culture of autonomy had a lot to do with it. People were not considered free if they could not control themselves. So their lack of freedom required scrutiny, leading to the ascendency of the notion of addiction still current today. Though much good certainly came out of these inquiries in the form of legitimate attention to real life issues, there was also a great deal of preachy interloping that caused far more harm than good. Alcohol prohibition in the early twentieth century is one example of social do-gooders running amuck. This was soon reversed. Only because fewer individuals used the other newly illicit drugs were the other (equally unsound) prohibitory statutes not so obviously flawed. It took a few decades to throw them into serious question, so by the 1960s strong challenges had begun to take shape.
Rather than go through all the history and politics, I will simply ask you to consider: When someone has a problem with yelling or verbal abuse and has improved considerably, we are unlikely to ask: how long have you been off yelling completely? Most people understand that gradual reduction of such behaviour is laudable, and that one unpleasant episode last week does not invalidate the person's efforts. Could we not apply the same grassroots wisdom to cocaine and heroin? Yelling is a nastier behaviour than getting high, yet we don't put the person in jail for it.
So what led us to incarcerate people, even for the simple possession of a drug? We live in a world where people are expected to live up to many ideals. Rousseau himself envisioned a time when all person's would be "forced to be free". No matter how silly that sounds, it is happening all over the West as I write these words.
Why not let each individual decide just how "free" he or she wishes to be? Many oppose harm reduction, long-term maintenance of any kind, and all types of drug use because they believe that all addicts can, and should, do better. Leaving aside the meaning of "better", many addicts themselves might not consider it their duty to live up the expectations of certain well-meaning (though annoying and preachy) souls.
Here is a paradox our civilisation must confront: we sincerely want our citizens to be free, and have become willing to lock them up to this end. No matter how laudable the original impulse, there is such as thing as going too far with a high ideal. Our dealings with addiction starting in the early twentieth century offer an excellent example.

subset: commoncrawl


text:
Great news for discerning holiday-makers in the Midlands! We are thrilled to hear that for a limited period from 1st August 2015, Emirates is adding a First Class service to flights out of Birmingham Airport. So what will this mean for your next luxury holiday?
At the Inspiring Travel Company we believe first class service should begin from the moment you leave home, so we love the complimentary Emirates chauffeur-drive service, which will collect you from your door and deliver you to the airport in style*.
Continuing the stress-free travel experience, you'll sail through check-in and immigration, leaving time to enjoy a bite to eat or grab a quick shower in the exclusive Emirates lounge. Sound like heaven so far? The luxury is only just beginning.
Emirates First Class cabins offer jaw-dropping levels of space and privacy, with each individual passenger enjoying the comfort of their own 'suite'. These personal compartments feature a decadently comfortable seat, which converts into a fully flat bed; a 23-inch TV screen, with over 2,000 channels of films, TV shows, games and albums to choose from; your own mini-bar; and even a sliding door for complete privacy!
Dining onboard is every inch the First Class experience, with a sumptuous à la carte menu served on bone China, whenever you want it. With the added indulgences of an Onboard Lounge serving drinks and canapés, and the sensational Shower Spa (complete with Bvlgari toiletries and signature Timeless Spa) it's easy to forget you're on a plane at all!
When you touch down in Dubai International Airport your chauffeur will escort you to your chosen luxury hotel or, if you're catching a connection to one of the many desirable destinations Emirates serves, you can wait in the flagship First Class lounge. Party at the Cigar Bar or snooze in a dedicated quiet room; the choice is yours.
Sold on the First Class experience? Well, let us tell you a little more about where this luxurious mode of travel can take you...
Dubai is undoubtedly a highly desirable destination in itself. Whether you crave the buzz of an ever-growing urban centre, the vast majesty of the deserts or the ultimate relaxation of 5-star beach resorts, this sparkling Emirate has it all. A stay at Burj Al Arab - a true icon of the Dubai skyline - offers the quintessential Dubai experience, with ultra-luxe accommodation and unique fine-dining experiences that range from being bathed in the blue light of a floor-to-ceiling aquarium to taking in the city views from 200-metres above sea-level.
Emirates offer one of the shortest flight times for First Class travel from Birmingham to Bangkok. Once there, why not start you luxury Thailand holiday in true style at The Peninsula? This exquisite hotel boasts incredible views out over the Chao Phraya River and the sprawling city, as well as an indulgent spa, many sumptuous dining options and even its own helipad! Moving onward, Inspiring Travel Company offers excellent options in everywhere from vibrant Phuket to lesser known destinations such as Koh Kood.
Perhaps you're planning the holiday of a lifetime to Australia? A First Class flight with Emirates is the perfect way to take the sting out of long-haul travel. Arrive in Sydney refreshed, and spend a few days in this exciting urban centre before heading off to explore the staggering beauty of this vast nation. Emirates One&Only Wolgan Valley is a spectacular eco-resort, nestled subtly in the glory of the Greater Blue Mountains, where sustainable luxury is the order of the day. Bliss.
First Class Emirates flights from Birmingham are only available until 31st December, so where will this world-leading airline whisk you off to?
Call our Travel Specialists now on 01244 355 600 to begin planning a bespoke luxury holiday to the destination of your choice, or start a webchat in the box below! We're waiting to create a unique holiday that is truly first class from start to finish!
*conditions apply - ask your Travel Specialist for further details.