Component 9 – Networking and Health Information Exchange

Component 9 – Networking and Health Information Exchange
This component, Networking and Health Information Exchange, is an in-depth analysis of data mobility including the hardware infrastructure (wires, wireless, and devices supporting them), the ISO stack, standards, Internet protocols, federations and grids, the NHIN and other nationwide approaches. Unit 8 covers “Enterprise Architecture Models” and consists of one lecture. This is Unit 8. Unit 8 Enterprise Architecture Models This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC

Health IT Workforce Curriculum Version 2.0/Spring 2011
Objectives Explain regional healthcare networks – policy and implementation strategies Explain the concept of a Nationwide Healthcare Information network Explain the significance of Service Oriented Architecture in networking and health information exchange networks Explain the value of an Enterprise Architecture in networking and health information exchange networks Describe key elements of various service oriented architecture platforms and infrastructure options The objectives for unit 8 are to Explain regional healthcare networks – policy and implementation strategies, Explain the concept of a Nationwide Healthcare Information network, Explain the significance of Service Oriented Architecture in networking and health information exchange networks, Explain the value of an Enterprise Architecture in networking and health information exchange networks, and Describe key elements of various service oriented architecture platforms and infrastructure options. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Who Needs Interoperability?
Two or more groups interested in collaborating and sharing healthcare / life sciences data / information using computer systems and electronic interchange No assumption of any scale Nations Enterprises Individuals No assumption of what is being exchanged, how it is exchanged, or why Who needs interoperability? Two or more groups interested in collaborating and sharing healthcare, life sciences data, information using computer systems, and electronic interchange. There can be no assumptions. The system can be of any scale; nations, enterprises or individuals. No assumption of what is being exchanged, how it is exchanged, or why. Image source: HL7 Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Service Oriented Architecture (SOA)
Is an automation of common services Ensures functional consistency across applications Minimizes duplication across applications Reuse Messages can be either payloads in or infrastructure beneath services Is an accepted industry best practice Is used in many key products But interfaces are not exposed Service Oriented Architecture (SOA) is an automation of common services shared across a community. In this case, we are focused on common services shared in the healthcare community. It ensures functional consistency across applications. It minimizes duplication across applications and is reusable. Service modules are created that can be used by anyone. Messages can be either payloads in, or infrastructure beneath, services that provide the interface and communication with modules. SOA is an accepted industry best practice and has been required by the Office of the National Coordinator (ONC) for recent grants. Many key products use SOA but do not expose interfaces. Users just have to understand the data format. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

What is SOA? Flexible set of design principles Used during the phases of system development and integration SOA based architecture provides a loosely-integrated suite of services that are reusable These services function similarly to subroutines in computer programs SOA becomes more important with the availability of web services SOA is a flexible set of design principles used during the phases of system development and integration. SOA based architecture provides a loosely-integrated suite of services that are reusable. These services function similarly to subroutines in computer programs. SOA becomes more important with the availability of web services. This means that you are able to put service modules anywhere and build them into systems. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Defining SOA SOA interface is defined in terms of protocols and functionality SOA separates functions into distinct services Accessible over a network Permits users to combine and reuse them in different applications Data is passed in a well-defined format SOA service is self-contained It makes no calls out of its service package SOA interface is defined in terms of protocols and functionality. SOA separates functions into distinct services using HL7 and EHR models to identify the services. They are accessible over a network in order to permit users to combine and reuse them in different applications. Data is passed in a well-defined format. SOA service is self-contained and makes no calls out of its service package to anything else. If changes occur outside a service then there is no impact on the service itself. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Understanding Services
Perform specific tasks Have a well-defined interface May use different implementation languages XML is commonly used for interfacing with SOA services SOA contrasts with API approach Provides flexibility Modules can be updated Or even exchanged simply Services perform specific tasks, have a well-defined interface, and may use different implementation languages. Extensible Markup Language (XML) is commonly used for interfacing with SOA services. The data input stream is defined by XML format tags that identify characteristics of data. SOA contrasts with the EHR software that is produced by API Healthcare. SOA provides flexibility; and modules can be updated or even exchanged simply. API doesn’t have flexibility or independence. In API, if you change something it impacts the rest of the API system. When you change something in SOA, functionality is preserved. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

SOA Supports Integration of diverse classes of information Distribution across a distributed heterogeneous research and care community Enables Coordination of functionality between inter-enterprise information systems Collaborative data processing and work flow execution Services Can be implemented standalone fashion Rapid creation of composite applications SOA supports integration of diverse classes of information and distribution across a distributed heterogeneous research and care community. Clinical trials can easily be done in SOA systems by creating a module to pull data out of an EHR system. SOA enables coordination of functionality between inter-enterprise information systems and collaborative data processing and work flow execution. SOA’s services can be implemented in a standalone fashion. It also allows for the rapid creation of composite applications. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Services XML is typically used to structure data that is wrapped in a nearly exhaustive description-container Web Services Description Language (WSDL) describes the services Simple Object Application Protocol (SOAP) describes the communication protocols XML is typically used to structure data that is wrapped in a nearly exhaustive description-container. You can include as much data as you want. You are not restricted to a certain number of data elements. Web Services Description Language (WSDL) describes the services. Simple Object Application Protocol (SOAP) describes the communication protocols. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Usage SOA permits developers to string together large chunks of functionality to build applications Building an application is like taking a set of blocks, each representing a service, and stringing them together to create the application SOA permits developers to string together large chunks of functionality to build applications. Ideally, applications will be built almost entirely from existing software services. Building an application is like taking a set of blocks, each representing a service, and stringing them together to create the application. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Value Component SOA relies on service-orientation as its fundamental design-principle Simple interface can abstract away the underlying complexity Users can access independent services without knowledge of the service’s platform implementation SOA relies on service-orientation as its fundamental design-principle. Its simple interface can abstract away the underlying complexity. Users can access independent services without knowledge of the service’s platform implementation. The complexity is hidden from the user. They just have to understand the data that is required for the package. They don’t have to worry about what happens inside the “black box.” Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

What SOA Buys Can use any Master Patient Index (MPI) without re-integrating Can painlessly integrate data from new clinical systems into a patient’s health summary Heterogeneous systems can be accessed consistently from an installed application base Standards support ability to redeploy or distribute hardware and software without breaking things You can use any Master Patient Index (MPI) without re-integrating. The data are independent. MPI is a database that maintains a unique index (or identifier) for every patient registered at a health care organization. You just link modules together. You can painlessly integrate data from new clinical systems into a patient’s health summary by having a module that pulls data from all sources to create the summary. Heterogeneous systems can be accessed consistently from your installed application base by simply meeting the requirements of the service functions. SOA standards support the ability to redeploy or distribute hardware and software without breaking things. In the old days, if we switched the hardware or software it affected the application, but an SOA application is not affected by changes. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Requirements to Use SOA
Interoperability between different systems as the basis for integration between applications on different platforms through a communication protocol. Messages are used across channels for communication and transfer of data. Create a federation of resources. Data flow is established and maintained in a federated database allowing new functionality developed to reference a common business format for each data element. In order to use SOA we must have interoperability between different systems as the basis for integration between applications on different platforms through a communication protocol like Transmission Control Protocol/Internet Protocol (TCP/IP). Messages are used across channels for communication and transfer of data. If we are going beyond a single organization, for example a regional health information system, then we can set up a common business format for each data element to orchestrate a system that will allow us to bring data together. If a hospital or clinic changes from application vendor A to application vendor B, and if vendor B is able to interface with the SOA then we are able to make changes without affecting the entire system. SOA lets us create a federation of resources. Data flow is established and maintained in a federated database allowing new functionality developed to reference a common business format for each data element. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

The diagram shows the connection between all the different elements in an SOA. In an SOA we have the application frontend, services, service repository, and service bus. Under the services category, we have contract, implementation, and interface. Finally, under implementation, we have business logic and data. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Guiding Principles Service encapsulation Service loose coupling Service contract Service abstraction Service usability Service composability Service autonomy Service optimization Service discoverability Service relevance The guiding principles of an SOA are Service encapsulation, Service loose coupling, Service contract, Service abstraction, Service usability, Service composability, Service autonomy, Service optimization, Service discoverability, and Service relevance. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Service Contract Header Name of service Version Owner Responsibility assignment Type (presentation, process, business, data, integration) The service contract includes the name of service, version, owner, responsibility assignment and type (i.e. presentation, process, business, data, integration). It defines the product you are building. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Service Contract Functional What the service accomplishes Service operations How to invoke service (SOAP, event triggers) It includes what the service accomplishes, service operations, and how to invoke the service (i.e. SOAP, event triggers). An example of an event trigger would be if you give the system a patient’s weight and height, the system would give you the Body Mass Index (BMI). Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Service Contract Non-Functional Security constraints Quality of service Translational Service level agreement Semantics Process The service contract also includes non-functional information like: security constraints, quality of service (for instance Is service guaranteed 24-7? Is it up percent of the time?), translational (including translation between different kinds of data and coding systems), service level agreement, semantics and process. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Service Contract At their simplest, contracts simply bind together technology to fulfill business processes. This diagram shows the HL7_BehavioralFramework_Contract. Image source: HL7 At their simplest, contracts simply bind together technology to fulfill business processes. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Behavioral Framework Differences Between Services, Documents, and Messages Specification Services Documents Messages Analysis (Blueprint Conformance) Application Role, Business Interactions, Trigger Events, Message Types are common to all Interoperability Paradigms Conceptual Design (Platform-Independent Conformance) Can support multiple systems playing multiple roles exhibiting multiple behaviors. Loose Coupling between Interaction Logic, Roles, and Participations Coarse operational behavior (previously implicit), Interfaces bound to Operational purpose of document (GetHandP ( ) ) Generally considered to be point to point or hub and spoke. One participant per role, very coarse explicit operational behavior (Send (), Do () ). Focus on message structure. Implementable Design (Platform-Specific Conformance) Requires scalable infrastructure (rules engines, orchestration engines, service advertising and discovery patterns, WS-*), message granularity varies to support operations. End points are information- focused, operations are atomic (few pre- and post-conditions to message events) Supported by many Messaging engines and platforms. Highly scalable implementation and deployment pattern. When we move to an enterprise architecture (EA), there are things we have to be aware of when understanding the SOA approach. This table shows the things we should take into consideration. If you will notice, at the analysis level, all of the things under services, documents and messages are based on HL7 standards. When we look at a conceptual design, SOA supports multiple platforms. We can change platforms without loosing functionality. Image source: HL7 Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Enterprise Architecture (EA)
The intersection of HL7, MDA, Distributed Systems Architecture, SOA, and CSI provide a goal, the artifacts, portions of a methodology, and the framework for defining robust, durable business-oriented constructs that provide extensibility, reuse, and governance. Computable Semantic Interoperability This slide shows the summary that HL7 has used for enterprise architecture (EA). The red dot in the middle is an SOA. The green square represents HL7. Built around an SOA is an EA that brings together all components. EA takes into consideration SOA along with computable semantic interoperability, meaning that interoperability between systems is mandatory. It uses a reference model for open distributed processing that defines communication protocol use. It also has a model-driven architecture that defines data elements and characteristics. Image source: HL7 Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

EA Specification Pattern from the 5 Viewpoints
In an EA how do I use all these pieces and how do they fit together? I need to look at an EA from 5 viewpoints: The enterprise view is the why. Why should we connect 16 hospitals and 5 clinics to each other? We want a flow of data and work. The information view is the what. What type of information needs to flow between the different entities? How is covered in the computational view. How do we share information? Do we share just part of the record or the entire record? The engineering view covers the where. Where is the physical information structure? This is where we look at scalability and sustainability. Lastly the technology view covers what is required to support the system. A new approach in the engineering and technology views is cloud computing. Cloud computing has a positive impact on SOA and EA because we don’t have to worry about where service modules are. They can be replicated and there are mechanisms in cloud computing that will allow the user to access the most efficient module at that given time. Image source: HL7 Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

The Specification Constraint Pattern
Enterprise / Business Viewpoint Information Viewpoint Computational Viewpoint Engineering Viewpoint Reference Reference Artifacts, Models, Patterns, and Templates from HL7 Analysis Conformance Assertions that are Computationally Independent, Conceptual, Business Oriented Conceptual Design Conformance Assertions that are Logically consistent, computable, verifiable Implementable Design Conformance Assertions that are directly implementable, often related directly to a platform or technology The table in this slide shows the matrix that is used to create an EA system. It includes four specifications; reference, analysis, conceptual design, and implementable design. The specifications should be viewed from four viewpoints: enterprise/business, information, computational and engineering. Image source: HL7 Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

The HL7 Specification Stack
Enterprise / Business Viewpoint Information Viewpoint Computational Viewpoint Engineering Viewpoint Conformance Level EHR-FM, Clinical Statements BRIDG, LS DAM, HL7 ADTs EHR-FM - Domain Business Context, Reference Context Project-oriented DIM Dynamic Blueprint, Functional Profile(s) N/A Blueprint Business Governance CIM, LIM Dynamic Model, Interface Specification Logical Transforms, Schema Orchestration, Interface Realization Execution Context, Specification Bindings, Deployment Model Platform The table in this slide shows where the HL 7 standards fall in the planning and implementation of an EA. Within each of the four viewpoints -- enterprise/business, information, computational and engineering -- there are four conformance levels: domain, blueprint, logical, and platform. Image source: HL7 Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Service Oriented Architecture
Appears in the design of loosely connected inter-organization HIT networks Desired way to interconnect widely distributed systems Particularly attractive when no one organization owns/controls all of the applications and platforms We are seeing SOA appear in the design of loosely connected inter-organization HIT networks as the desired way to interconnect widely distributed systems. SOA is particularly attractive when no one organization owns or controls all of the applications and platforms. With cloud computing, health information exchange (HIE) and nationwide health information network (NHIN) SOAs are attractive because we can use a service that is provided by a service provider to build our applications. We have interoperability between the different systems. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

SOA vs. Web Services SOA Web Services Is a technology platform No Yes Is a transport protocol Primary ownership is business line owned Affects workflow and business processes Enables business and IT transformation Is an industry standard Sometimes people mix up SOA and web services. Web services are an enabler for SOA. This chart shows the difference between SOA and web services. SOA is not a technology or transport platform or an industry standard. Web services are. SOA are primarily business owned and affect workflow and business processes. This is not true with web services. Both SOA and web services enable business and IT transformation. SOA is moving towards standardization. Image source: HL7 Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

How Is SOA Different From Messaging?
A common practice in healthcare, just not yet in healthcare IT Many key products use them but do not expose interfaces Ensures functional consistency across applications Accepted industry best practice Furthers authoritative sources of data Minimizes duplication across applications, provides reuse Messages can be either payloads in or infrastructure beneath services Service-oriented architecture provides the framework for automation of common services Still, SOA has to be done well. It is cheaper and easier than ever to create badly designed applications and spaghetti integration Fits well with Open Source How is SOA different from messaging? It is: A common practice in healthcare, just not yet in healthcare IT, Many key products use them but do not expose interfaces , Ensures functional consistency across applications, Accepted industry best practice, Furthers authoritative sources of data, Minimizes duplication across applications, provides reuse, Messages can be either payloads in or infrastructure beneath services and Service-oriented architecture provides the framework for automation of common services. Still, SOA has to be done well. It is cheaper and easier than ever to create badly designed applications and spaghetti integration. It fits well with Open Source. Messages are a tool used in SOA. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

HL7 Services-Aware Enterprise Architecture Framework (SAEAF)
Interoperability Framework for Enterprise Architecture Uses v3/RIM artifacts and expertise Supports measurable, testable conformance and compliance Provides directly implementable solutions Three years ago, HL7 created a framework for interoperability for EA called HL7 Services-Aware Enterprise Architecture Framework (SAEAF). It uses v3/RIM artifacts and expertise, supports measurable, testable conformance and compliance and provides directly implementable solutions. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

SAEAF Services: This is about “services enabling” HL7’s Standards Awareness: This is about making our standards “aware” of both services and an Enterprise Architecture Enterprise Architecture: When adopted and imbedded in our development methodologies, SAEAF becomes our Enterprise Architecture Framework: This is a “framework” in which we will “place” our standards so that we can see how they relate to each other and they relate to other standards and becomes part of our users’ Integration Architectures. SAEAF has four defined areas: services, awareness, EA, and framework. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

SAEAF Core Components Information Framework Behavioral Framework Enterprise Conformance and Compliance Framework Governance Framework Implementation Guide The core components are: Information Framework, Behavioral Framework, Enterprise Conformance and Compliance Framework, Governance Framework and an Implementation Guide. The guide provides examples of how you put things together. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

What Is Being Specified?
8/19/07 What Is Being Specified? Standards are being developed for: Entity Identification (to manage and maintain identities within and across domains, localities, or products) Record Location & Retrieval (to discover, retrieve, and update records in distributed environments) Decision Support Services (to support evaluation processes such as clinical decision support) Terminology Service (to retrieve, maintain, and navigate [clinical] terminologies and ontologies) HL7 standards are being developed for entity identification, records location and retrieval, decision support services and terminology service. Entity identification is used to manage and maintain identities within and across domains, localities, or products. Record location and retrieval is used to discover, retrieve, and update records in distributed environments. Decision support services supports evaluation processes such as clinical decision support. Terminology services are used to retrieve, maintain, and navigate [clinical] terminologies and ontologies. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011 Copyright 2007 e_hammond & HL7

Where Would Specifications Be Used?
8/19/07 Where Would Specifications Be Used? Inter-Enterprise (such as National Health Information Network, Regional Health Information Organizations) By functionally specifying behavior, roles between applications and products are clarified, and the technologies supporting them can be profiled and sharpened Intra-Enterprise Standardization on functionality allows for better integration of off-the-shelf and custom development environments, and promotes more of a “plug and play” environment Intra-Product Facilitates vendors ability to integrate third-party value-add components and speed design phase with higher confidence Custom-Implementation Affords organizations wishing to custom-develop the opportunity to later integrate off-the-shelf These specifications would be used in inter-enterprises like National Health Information Network and Regional Health Information Organizations to functionally specify behavior, to clarify roles between applications and products, and to profile and sharpen the technologies supporting them. In intra-enterprise, the standardization would allow better integration of off-the-shelf and custom development environments, and promotes more of a “plug and play” environment. With intra-product relationships, the specification would facilitate a vendor’s ability to integrate third-party value-add components and speed design phase with higher confidence. Lastly, within custom-implementations, it would provide the opportunity to later integrate off-the-shelf products with custom products. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011 Copyright 2007 e_hammond & HL7

Services In Particular Are
More coarsely granulated than messages are more readily traceable to business, clinical capabilities, and requirements Specifications for a service are of the form: Functional Profile (collection of operations offered by a service) + Semantic Profile (static semantics utilized by operations in FP) + Conformance Profile (testable (automated or human) conformance standards against which an implementation may make pair-wise conformance assertions) Combination of these two points above provides a foundation for both intra- and inter-enterprise durable services interfaces Services in particular are more coarsely granulated than messages, and are more readily traceable to business, clinical capabilities, and requirements. They are specifications for a service that are of the following form: Functional Profile (collection of operations offered by a service) + Semantic Profile (static semantics utilized by operations in FP) + Conformance Profile (testable (automated or human) conformance standards against which an implementation may make pair-wise conformance assertions). The combination of the two points above provides a foundation for both intra- and inter-enterprise durable services interfaces. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Healthcare Service Specification Project (HSSP)
Effort to create common “service interface specifications” trackable within Health IT Joint standards development project by HL7 and Object Management Group (OMG) Objectives: To create useful, useable healthcare standards that address functions, semantics and technologies To complement existing work and leverage existing standards To focus on practical needs and not perfection To capitalize on industry talent through community participation Healthcare Service Specification Project (HSSP) is an effort between HL7 and Object Management Group (OMG) to create common “service interface specifications”. The objectives of the project are To create useful, useable healthcare standards that address functions, semantics and technologies, To complement existing work and leverage existing standards, To focus on practical needs and not perfection, and To capitalize on industry talent through community participation. Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

SAIF S = Services A = Aware I = Interoperability F = Framework The US government has become involved in the development of standards for data exchange so SAEAF has had a name change. The new name is SAIF (Services Aware Interoperability Framework). This new name brings emphasis to the word interoperability. Interoperability is the key word as we look at the development of new SOA and EA systems to share health information data. In this unit we have discussed regional and national health care networks, SOA and EA. References used to develop this unit: Internet from Dec 28, 2010 Internet from Oct 17, 2010 Component 9/Unit 8 Health IT Workforce Curriculum Version 2.0/Spring 2011

Component 9 – Networking and Health Information Exchange

Similar presentations

Presentation on theme: "Component 9 – Networking and Health Information Exchange"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Component 9 – Networking and Health Information Exchange

Similar presentations

Presentation on theme: "Component 9 – Networking and Health Information Exchange"— Presentation transcript:

Similar presentations

About project

Feedback