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