Presentation is loading. Please wait.

Presentation is loading. Please wait.

Initial slides for Layered Service Architecture

Similar presentations

Presentation on theme: "Initial slides for Layered Service Architecture"— Presentation transcript:

1 Initial slides for Layered Service Architecture
From existing materials: Practical Guide to SOA in Healthcare Part II IHE SOA Whitepaper

2 Healthcare SOA Framework Based on HL7 EHR System Functional Model & Thomas Erl’s SOA Layers
HL7 System Functions  Direct Care Supportive Information Infrastructure Other Business Process Value Chains Composite Services Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas Core Business Functional Areas + Focal Classes Entity Information Management Reporting and Management Agnostic Services C r o s s T e c h n I c a l “Common S e r v I c e s” (e.g., Security, Privacy, Auditing, Logging…) Application Ambulatory Care Systems, In Patient Care Systems Logistics Systems Financial Systems Decision Support Systems Data Marts Repositories Business Objects Implementation Profiles Integrated Healthcare Enterprise (IHE) Profiles Analysis Profiles Communications Profiles/Stacks Implementation Profiles Re: Focal Classes:  The issue is less the idea of a focal class than a business focal class. The difference is that when you model the service, you are generally modeling a service that will express the state changes of a business. For example, via analysis, you would find the states of a business focal class (canceled, new, active, signed, finalized in lab orders for example) and the trigger events that would correspond to state changes ("a lab is ordered", "a lab is canceled", "a lab specimen is corrupted", and so on).  You could say that a "patient" is a focal class, but a patient ID service generally doesn't express operations to modify the state of that "object". Rather, a patientID service would generally encompass operations that would express information about the class (reconcileID or lookUpID, eg) rather than tying the service functional components to changes in the state of that class.  It is not a subtle distinction - most clinical domains are focused on a focal class (an order, an encounter, an appointment, a schedule, a lab). A business service is focused with exposing that class to the enterprise.  Infrastructure services (or the subset information services) are generally function calls or based on exposing sets of information. The functional profiles of the service are generally not focused on the state of the underlying information or in the trigger events that modify the state of that information. They tend to be focused along different lines - typically along the lines of an information profile (a RIM-based patient class, eg, or a CDA-based CCD). The focal class is explicit in a business service, generally implicit in other services. 2 2

3 Notional Set of HL7 Artifacts within a SAIF Enterprise Compliance and Conformance Framework (ECCF)
Enterprise Dimension “Why” - Policy Information Dimension “What” - Content Computational Dimension “Who/How” - Behavior Engineering Dimension “Where” - Implementation Technical Dimension “Where” - Deployments Conceptual Perspective Business Mission, Vision, Scope , Inventory of Contracts - PSSs Capabilities - RIM Policies Procedures Inventory of Reusable Entities Associations Information Information Models Data Models Inventory of Reusable Scenarios Business Activities System Functions Requirements Accountability, Roles Conformance Criteria Profiles, Behaviors Interactions and Info. Exchanges Inventory of SW Platforms, Layers SW Environments SW Components SW Services Technical Requirements Enterprise Service Bus Key Performance Parameters Inventory of HW Platforms HW Environments Network Devices Communication Devices Technical Requirements Logical Perspective Business Policies Governance Implementation Guides Design Constraints Organization Contracts Information Models Domain IM Detailed Clinical Terminologies Value Sets Content Specifications CCD RMIM Specifications Scenario Events Use Cases Workflow Use Cases Components Interfaces Collaboration Actors Collaboration Types Collaboration Roles Function Types Interface Types Service Contracts Models, Capabilities, Features and Versions for SW Environments SW Capabilities SW Libraries SW Services SW Transports Models, Capabilities, Features and Versions for HW Platforms HW Environments Network Devices Communication Devices HL7 Service Aware Interoperability Framework (SAIF) Enterprise Compliance and Conformance Framework (ECCF) The DoD and MHS EHRWF ECCF’s goal is to ensure Working Interoperability (WI) among various healthcare organizations; WI is also known as compatibility among healthcare systems. Working Interoperability is an instance of two “trading partners” –- human beings, organizations, or systems, successfully exchanging data or information, or coordinating behavior to accomplish a defined task, or both. The ECCF’s purpose is to manage the relationship between architectural artifacts and implementations of those artifacts. The objective of a fully qualified ECCF is to be a clear, complete, concise, correct, consistent and traceable interoperability specification, which is easy to use. An ECCF can be an assessment framework, which supports configuration management baselines and risk assessments throughout a business-capability lifecycle. The ECCF is used to specify information exchange interoperability and conformance statements for documents, messages and services. An ECCF Implementation Guide contains definitions of terms, such as conformance, compliance, consistency and traceability. An ECCF provides a template, called a Specification Stack (SS) that allows you to specify business objects, components, capabilities, applications and systems organized as a matrix of Dimension columns (Enterprise, Information, Computational, Engineering and Technical) and Perspective rows (Conceptual, Logical and Implementable)., as is shown in the slide. DoD and VA must define their common SAIF Implementation Guides, which define their architecture development methodologies and architecture artifacts. To foster consistency, VA has agreed to build a common DoD-VA EHRWF Implementation Guide, based on DoDAF, TOGAF and HL7 SAIF. This slide shows a notional Interoperability Specification template, using the HL7 SAIF ECCF SS. This is a super set of common architectural-artifacts. All the listed artifacts may NOT be required in the DoD-VA EHRWF Implementation Guide; other artifacts may be included. Within each cell You place or reference and discuss appropriate architectural artifacts and specifications. You define or reference conformance statements, which are testable-representations of assumptions that the specifications make. You manage traceability within columns and consistency across layers. An implementation of a Specification Stack (SS) asserts, as true or false, that one-or-more conformance assertions are met; certification asserts as true, that some set of conformance assertions are met. You identify and mitigate risks across the organization’s component development life cycles. Implementable Perspective Business Nodes Business Rules Business Procedures Business Workflows Technology Specific Standards Schemas for Databases Messages Documents Services Transformations Automation Units Technical Interfaces Technical Operations Orchestration Scripts SW Specifications for Applications GUIs Components SW Deployment Topologies HW Deployment Specifications HW Execution Context HW Application Bindings HW Deployment Topology HW Platform Bindings Responsibility: HL7 Organization | EHR-S FIM | HL7 WG Projects | Development Organization See notes page for ECCF description

4 Standards Overlap For Services
# Service Identification Retrieve, Locate and Update Decision Support 1 Standards Org HL7 2 Capability Identification Service Functional Mode Retrieve, Locate, Update SFM Decision Support SFM 3 OMG 4 Service Definition Identification Service Specification Retrieve, Locate, Update Spec Decision Support Service Spec 5 Profile Org IHE 6 Interoperability Layer PIX/PDQ Immunization Content (IC) Immunization Content Request for Clinical Guidance 7 AIRA/CDC 8 Draft: 2.5 Implemen- tation Guide 9 2.3.1 Implemen- tation Guide 10 11 Base Standard Version 2 Version 3 Patient Admin messaging Version 3 Immunization (POIZ) messaging Version 3 Care Record CDA Version 3 Care Record messaging

5 HL7 EHR_S-Based Functional Architecture/Services Analysis
ETC Infrastructure Functions Manage Business Rules Interoperability Infrastructure Services Security Policy Records Management Audit Terminology Registry Workflow Business Rules etc Terminology Unique ID, Registry, and Director Primary Care Critical/Emergency Care Dental Non-Surgical Specialty Care Laboratory Nursing Pharmacy Population Health Behavioral Health ETC. Information and Records Management Security Lines of Business Record Management Manage Patient History Preferences, Directives, Consents, and Authorizations Core Clinical Services Entity Identification Resource Location and Updating Services Decision Support Orders Management Scheduling Image Management Etc. Summary Lists Management of Assessment Cross-Cutting Direct Care/ Support Functions Care Plans, Treatment Plans, Guidelines, and Protocols Orders and Referral Management Documentation of Care, Measurement, and Results Record Patient Specific Instructions Clinical Decision Support Clinical Workflow Tasking Support Clinical Communication Support Knowledge Access ETC

6 Diagram of Service Definition source: IHE SOA Whitepaper

Download ppt "Initial slides for Layered Service Architecture"

Similar presentations

Ads by Google