Business Software Architecture (BSA) Specified by Software Definition Framework (SDF) Supporting...

Business Software Architecture (BSA)

Specified by

Software Definition Framework (SDF)

Supporting

Integrated Requirements Design (IRD)

Sets of

Integrated Management Information

Within

Business Capabilities Lifecycle (BCL)

Using

H-SOA-RASend updates to [email protected], editor

Last updated 23 Oct 07

Working Document; Not for Public Release04/10/23 1

Joint HL7 and OMG Healthcare Services Specification Project

04/10/23 2

EXECUTIVE SUMMARY: The objective of the Software Definition Framework (SDF) is to specify software

components and their services within an Enterprise Architecture (EA), also known as a Business Software

Architecture (BSA). The objective of the Integrated Requirements and Design (IRD) process is to guide investment

portfolio, acquisition managers and engineers with the appropriate Software Development Lifecycle (SDLC)

documentation needed for the Business Capability Lifecycle (BCL) of a Business Transformation Architecture (BTA).

The SDF defines a BSA that supports the SDLC by specifying IRD solution sets which become part of the BCL

“Integrated Management Information” (e.g., within the center purple box of the following figure). This “Integrated

Management Information” should contain a “future state” strategic architecture and a BTA transition plan composed

of IRD solution sets. Both the “future state” enterprise architecture and BTA transition plan are composed of SDF

views and related artifacts, as shown in the following slides.

EXECUTIVE ORDER #13335 and #13410 mandate federal agencies to have interoperable Electronic Healthcare

Records (EHR), as specified by the Health and Human Services (HHS) Healthcare Information Technology

Standards Panel (HITSP). See the companion paper and brief, which discusses the MHS-VA standardized

“Healthcare SOA Reference-Architecture (H-SOA-RA)” for categorizing, describing and constructing system

functional components within a HITSP compliant Enterprise Service Oriented Architecture (SOA).

Contents

1. Management SOA Perspective

2. Technical SOA Perspective

3. Application SOA Perspective

4. Backup Slides

3

Goal: Healthcare SOA Reference Architecture

(H-SOA-RA)

NationalFederated

Healthcare Industry

VA/ DoD Interagency

DoD

TMA

Military Services

INTE

GR

ATIO

N

Identifying Opportunities to Leverage Technology and Alleviate Redundancy or Agency IT Overlap

Joining Forces to Improve Effectiveness, Efficiency, and Service delivery

CO

LLA

BO

RA

TIO

N

INTER-AGENCY

Key Business DriverPatient Centric Processes

4

Key Architectural ObjectiveStandardized Technical Solutions aligned with

Core Business Processes.

Healthcare SOA & Standards

Framework HL7 System Functions

Direct Care Supportive Information Infrastructure

Other

Business Process

Value Chains

FederatedServices Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas

Core BusinessServices

Functional Areas + Focal Classes




EntityServices

Information Management



Information 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…)

ApplicationServices

Ambulatory Care Systems,

In Patient Care Systems

Logistics SystemsFinancial SystemsDecision Support

Systems

Data MartsRepositories

Business Objects

Implementation

Profiles

Integrated Healthcare Enterprise (IHE)

Profiles

Analysis Profiles Communications Profiles/Stacks

Implementation Profiles

5

SUPPLY CHAIN (ORDER/CHARGE)

ANATOMY OF AN ANCILLARY SYSTEM

AUTHORIZATION

DOCUMENT

RECORDS MANAGEMENT

DECISION SUPPORT

PERFORMANCE

DATA MANAGEMENT

SCHEDULING

IDENTITY

TERMINOLOGY

LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH

s

CO

RE

B

US

INE

SS

S

ER

VIC

ES

6

IT PLATFORM

SUPPORT

ANALYTIC

DATA MANAGEMENT

PERFORMANCE

DECISION SUPPORT

RECORDS MANAGEMENT

DOCUMENT

SUPPLY CHAIN: (ORDERS/CHARGES)

SCHEDULING

AUTHORIZATION

TERMINOLOGY

IDENTITY

RADIOLO

GY

LABORATORY

PHARMACY

CLI

NIC

AS

U

T

ES

T O

NLY

O

UT

PA

TIE

NT

OT

HE

R

INP

AT

IEN

T E

R

CARDIOLO

GY

PT/O

T/SPEECH

DIETARY

SPECIALTY CARE

Ancillary Systems

Co

re E

HR

Ser

vice

sINTEGRATED

REQUIREMENTSDESIGNS: Putting the H-SOA-RA

Pieces Together

RESPIRATORY

Fed

erat

ed B

usi

nes

sS

ervi

ces

Fed

erat

edS

ervi

ces

Federated Services, may be categorized by: -- Encounter Types -- CMS billing category -- Record type -- Care setting type -- etc.

Data sets are defined for each system functional-

capability-service module 7In

ter-

Age

ncy

Inte

r-S

ervi

ceA

cros

sP

rovi

ders

ENTERPRISEARCHITECTURE

ENTERPRISE ARCHITECTURE: THE INTEGRATION ROAD MAP

PLANNED, COLLABORATIVE, OPTIMIZED

s

SOA EA INTEGRATION

SYSTEM FUNCTIONS

SYSTEM INTERFACES

OPERATIONALNODE

INFORMATIONEXCHANGES

ACTIVITIES

DATA

BUSINESS RULES

BUSINESS PROCESS

BUSINESS PROCESS

eENTERPRISE

ARCHITECTUREOV-7

OV-5

SV-1

SV-4

OV-3

OV-2

OV-6a

OV-6c

s

PROCESS

SYSTEMS

DATA

APPLICATIONS

GOALS & STRATEGIESPOLICIES & GOVERNANCE

SECURITY

STAFF

Best PracticesPortfolio Management

Standards

Healthcare Enterprise Architecture

SOA BUSINESS INTEGRATION

STANDARDIZED

NON-DUPLICATIVE

RE-USED

INFORMED

INTEGRATED

SOA A

DVANTA

GE

RESPONSIVE

WORKING SMART

SafeEffective

Patient-centeredTimely

Efficient Necessary

Staff Efficiencies

Improved Patient/Staff Satisfaction

Improved Outcomes/ Reduced Risk

PATIENT-CENTERED

CARE

Revenue Improvement

Improved Information Accuracy/Availability

Reduced IT Expenditure/Maintenance Costs

Length of Stay Reduction

BENEFITS

Rapid Response

ADDRESSING REAL BUSINESS ISSUES THROUGH H-SOA-RA

Incomplete/Inaccurate Demographic Data

(Identity Service)

Incomplete/Inaccurate Insurance Information (Authorization Service)

Unauthorized Service (Authorization Service)

Diagnosis/Procedure Coding Errors (Terminology Service)

Service Delays (Scheduling Service)

Incomplete and Inefficient Charge Capture (Supply Chain Service)

Non-indicated or Contra-indicated Services (Decision Support/Authorization Services)Delays in EHR Document Production/ Provision (Document Service)

Billing Delays and Errors (Supply Chain/ Billing/ CollectionService)

Not fully coordinated Scheduling (Scheduling Service)

Lack of fully integrated Patient Assessment and Treatment Plan

(Document Service/ Decision Support Service)

Delayed or Lack of Medical Record Access (Record Service)

INTERAGENCY EA STANDARDIZATION IN SUPPORT OF THE WOUNDED WARRIOR

GOAL: Seamless Uninterrupted Care Across the Continuum of Care

Care Plan

Decision Support

Case Management

Records Management

Referral

Performance

Benefits Management

Trauma Registry

H-SOA-RA IT Services

VA DOD

Integrated Care Planning involving Key Players Upfront

Informed Decision Making with Timely Alerts

Consistent Care Oversight and Co-Ordination

Timely Complete Information

Streamlined Referral

Joint Performance Review, Learning, Improvement

Timely, Efficient Benefit Access

Improved Patient Monitoring/Epidemiological Analysis

13

Civilian

Warfighter

Combat Theater

DOD

Landstuhl

Walter Reed Purchased Care

Recuperative and Long Term Care

Acute and Recuperative Care

AcuteCare

SpecialtyCare

CriticalCare

StabilizationCare

HEALTH AFFAIRS

TRICAREManagement

Activity

12

The Business Capability Lifecycle


Conduct Analysis(Process, Metrics

Views)Develop & Validate

Outcomes

Business Case Validation,

Assess Risk & Monitor Metrics

Conduct Solution Analysis*

IRB/ PSA & DBSMC Review & Approve Capabilities

*Solution Analysis consists of gap analysis, BCA, AoA, impact on operational outcomes

**Solution Package may consist of IRD system acquisition/divestiture, policy changes, process modification, organizational changes

Recommend Solution

Package**

Program Definition

IRB/ DBSMCAnnual review,

MS Reviews

Guidance, Assumptions

Priority

Gap, Problem,Strategic Question

IRB/ DBSMC Business Case Approval, MS A

Decision

ExecuteProgram

Validation(Pilot/ Prototype)

Execute Policy and Process

Changes

End

Continue to Execute

Program or END

LessonsLearned

Source: Business Capability Lifecycle Kickoff Stakeholder Meeting Brief, Business Transformation Agency Investment Management Directorate, May 31, 2007 04/10/23 14

Service Oriented Architectures

ClinicalLogistics &Readiness

Financial& Budget Operations CIO

MHSStrategic Vision

CoreMissionAreas

BusinessValue ChainSegments

Business Process Models

Information Models

Solution Architectures


04/10/23 15

Support the Core Mission Areas with high-quality, low-cost, aligned,

interoperable and agile Healthcare Information Systems (HIS)

MHS IM/ITProgram

Service Definition Framework (SDF)

34

Source: Department of Defense Global Information Grid Service Strategy

As we move to federated SOA services, it is important that services across the enterprise be described using a common set of information (metadata) so that services can be consistently discovered and understood by others in the enterprise. The Service Definition Framework (SDF) shown below identifies the necessary attributes for effective description of a service.

See www.SOA.OMG.org “UML Profile and Metamodel for Services (UPMS) "SOA“ for related information.

KEY CONCEPT: Business Software Architecture (BSA)

Components are Specified by theSoftware/Service Definition Framework (SDF)

04/10/23 16

Notional Time/Cost of IRD Process

04/10/23 17IRD 1.0 IRD 1.1 IRD 1.2 IRD 1.3 IRD 1.4 IRD 1.5

C*1

0 Ho

urs

C

* 100

Hou

rs

C

* 100

0 Ho

urs

C

*10,

000

Hou

rs

C*1

00,0

00 H

ours

IRD 1.1 Process Submission

IRD 1.2 Conduct Enterprise Analysis of Requirements-Design Sets

IRD 1.3 Prioritize Solution Sets

IRD 1.4 Refine Funded Solution

IRD 1.5 Define Quality Assessment Attributes

IRD 1.0 Conduct Strategic Generation of IT Requirements

COMPETING OBJECTIVES: • Minimize costs of IRD “overhead” phases 1.0, 1.1, 1.2 and 1.3 • Make changes and fix problems as early as possible • Avoid high cost changes in IRD phase 1.5

Year of Execution

Note: Coefficient “C” varies depending on submission size

Notional ROI of IRD Process

04/10/23 18

1X 10X Cost of Software Engineering

1

0X

100

X

C

ost o

f Sus

tain

men

t

Cost to m

ake changes or fix problems

IRD 1.0 IRD 1.1 I RD 1.2 IRD 1.3 I RD 1.4 IRD 1.5 Sustainment

C*1

C

*10

C

*100

C

*1,0

00

C*1

0,00

0

Note: Coefficient “C” varies depending on submission size

Six SigmaNotional 5 to 10:1

ROI

https://www.thedacs.com/databases/roi/display_all_facts.php?datasource=ROI&label=Cleanroom&improvement2=Cleanroom• Basili, V., McGarry, F., Page, G., Pajerski, R., Waligora, S., Zelkowitz, M., "Software Process Improvement in the NASA Software Engineering Laboratory", Technical Report CMU/SEI-94-TR-22, December 1994, Carnegie Mellon University, Pittsburgh, Pennsylvania: Software Engineering Institute.• Sherer, S. W., Kouchakdjian, A., Arnold, P. A., "Experience Using Cleanroom Software Engineering", IEEE Software, May 1996, pp. 69 - 76.

act IRD Process Phases / SDF Products

1.1 TriageSubmissionsfor Validity andAffordability

1.1 Process SubmissionSubmission

- Needs Statement- Benefit , if done- Detrement, if not done

1.0 Conduct StrategicGeneration of ITRequirements


Future State (FS) EA

- Submission

Verified Submission

- Need Statement- Benefit, if done- Detrement, if not done- IRD 1.3 cost estimate

1.2 Conduct EnterpriseAnalysis of Requirements

Design Sets

Alternative Solutions

- Business Model- Business Case- Solution Model- Software Specification

1.2: Analysis ofAlternatives(AOA)

Verified Submissions

- Need Statement- Benefits, if done- Detrement, if not done

1.3 Prioritize SolutionSets

Selected Solution

- AOA- Solution Model- Software Specifications

1.3 MakeInvestmentDecision

Investment Portfolio

- Solution Model- Software Specifications

1.4 Refine FundedSolution

Funded Solution

- AOA- Solution Model- Software Specifications

Specified Solution

- AOA- Solution Model- Detailed SW Specs- Security Specifications- Exception Specifications- Test Specifications

1.4 IssueAcquisitionContract

1.5 Define QualityAssessment Attributes

Contract Deliverables

- Plans- Implementation View- Deployment View- EA-Deviation Wavers- Systems Documentation- SSAA & Certifications

1.5 FieldSolution

1.0 CMVersion ofFS EA

Contracted Solution

- Solution Model- Detailed SW Specs.- Enterprise Architecture

Requirements

- Domain Functional Models- Domain Best Practices- Functional Requirements- Non-Functional Requirements- Enterprise Architecture

Artifacts

- BTA- IT-300- JCIDS- PPBS

Rejected

Rejected

Rejected

Rejected

Rejected

Rejected

Assumption: Phase 1.6 includes the contract execution phase ( e.g., from the time the contract is issues til l the time the IRD product is accepted.)

Rejected

SelectedSolution

FundedSolution

Rejected

VerifiedSubmission

ContractedSolution

Future State EnterpriseArchitecture

FieldedSolution

Rejected

Rejected

Rejected

04/10/23 19

IRD Creation of BCL

“Integrated Management Information”

SDF Artifacts

04/10/23 20

DODAFSDF

class IRD's SDF v s. DODAF Products

BCL Integrated Management Information


+ IRD Processes and Products

+ Business Modeling View

+ Solution Modeling View

+ Planning and Provisioning Policy View

+ Software Specification View

+ Security Specification View

+ Exception Specification View

+ Test Specification View

+ Detailed Software Specification View

+ Deployment View

+ Runtime View

+ Sustainment View

Requirements

- Domain Functional Models- Domain Best Practices- Functional Requirements- Non-Functional Requirements- Enterprise Architecture


- Submission

Specified Solution


Contract Deliv erables


IRD 1.5

IRD 1.0

ACRONYMSAOA - Analysis of Approaches and/or Analysis of AlternativesCM - Configuration ManagementFS EA - Future State (FS) Enterprise Architecture (EA)HL7-S - Health Level 7 (HL7) Electronic Healthcare Record (EHR) System Functional ModelIRD - Integrated Requirements and DesignSDF - Software/Service Definition FrameworkSOA - Service Oriented ArchitectureSSAA - System Security Authorization Agreement (SSAA)

Alternativ e Solutions


Inv estment Portfolio


IRD 1.1

IRD 1.2

IRD 1.3

IRD 1.4

Verified Submission



- Business Case- OV-6c- SV-1, 6 (macro), 10c


- OV-6c- SV-1, 6 (macro), 10c

Specified Solution

- AOA- OV-6c- SV-1, 4 SDF, 6 (micro),10c

Dependency Realize

Realize

Realize

Realize

Name:Package:Version:Author:

IRD's SDF vs. DODAF ProductsSustainment View1.0FSWG

High Level Overview of Future State Framework and its use within the IRD process

The future state architecture group has developed a first version of a Future State Framework (the “Framework” hereafter) to be followed and complemented by appropriate Future State architecture content and supporting artifacts. The Framework, while having a COTS version as a starting point, is being adapted to MHS needs. It includes a series of interrelated “views” which are defined in an UML model. The Framework supports the IRD process and the MHS Enterprise Architecture (EA).

Central to the Framework is the support for Requirements-Design Sets from the from the capability/change request inception, through acquisition and deployment. There are three views which are meant to be extensively used in the initial IRD phases: Business View, Solution View, Software Specification View. Each view should increasingly become more detailed as the IRD process advances towards acquisition and later on towards deployment:

1. The Business View supports concepts such as Capability which is further detailed by Processes, Subprocesses, Elementary Processes.

2. The Solution View is defined in terms of Use Cases involving Actors and Use Case Steps. Use cases may be composites of other use cases and a set of requirements quite often is described as a collection of use cases.

3. The Software Specification View relies on concepts which include Transaction. A transaction can further contain transactions at increasingly lower levels.

These three views may be linked at a higher level (Capabilities, Processes, Use case are supported by some software specifications) but they may be further linked at various lower levels by appropriate choices of transactions associated to use case steps or elementary processes. Thus in a Requirement-Design set one may choose to pair in a flexible manner elements from the requirement side with elements from the design side, maintaining visibility and understanding for all stakeholders involved. One can also control the cost of the IRD process by calibrating the level of details of the required views at various decision points during the IRD process starting with the Triage step and continuing through the investment decision phase and further through acquisition, deployment and other phases deemed necessary.

A completed IRD package for acquisition purposes will have also (partial and incomplete) Framework Implementation, Deployment and Runtime views covering constraints, compliance and other aspects (such as network and communications specifications). These views will be completed after the acquisition phase by contractors, vendors and other entities as they become involved during the software development and deployment lifecycle.

The Framework views aim to allow for the recording of information sufficient for deriving various compliance artifacts (such as DoDAF OVs and SVs). The Framework needs to be extended in several directions including the areas of: Security, Testing, Error Handling, Federation.

04/10/23 21

04/10/23 22

class Software Definition Framework (SDF)

Software Specification View

+ Application Specification

+ Architecture Layer

+ Architecture Layer Rules

+ Interface Type

+ Operation Specification

+ Service Domain

+ Service Specification

+ Software Specification

+ Specification Dependency

Implementation View


+ AU Dependency

+ Automation Unit

+ External Org

+ Internal Org

+ Organization

+ Provided Capabilities

+ Required Capability



Deployment View

+ AU Dependency

+ Automation Unit

+ Communication Path

+ Deployment

+ Enterprise Service Bus

+ Execution Environment

+ Node

+ Processor

Runtime View

+ Automation Unit

+ Deployment

+ Endpoint

+ Endpoint Operation

+ Internal Location

+ Internal Location

+ Node


+ Protocol

+ Service Instance

+ Technical Interface

+ Technical Operation

Detailed Software Specification View

+ Application Layer

+ Business Objective

+ Business Type

+ Compliance Item

+ Compliance Level

+ Compliance Level Deviation Item

+ Employee

+ EndPoint


+ Informal Operation

+ Interface

+ Mandatory Message Sequence

+ Message Specification


+ Organization

+ Pre Post Condition Pak

+ Protocol

+ Service Level Agreement


+ Software Classification

+ Software Classification Group

+ Software Definition Language File

+ Software Information Model

+ Software Owner


+ Software State

+ Transaction

Planning and Prov isioning Policy View


+ Architecture Layer Rule

+ Business Domain

+ Business Rules

+ Business Scope

+ Policy

+ Policy Subject

+ Policy Type


+ Software Domain


Solution Modeling View

+ Actor



+ Transaction

+ Use Case

+ Use Case Association

+ Use Case Step

Business Modeling View

+ Business Capability

+ Business Domain

+ Business Event

+ Business Model Element

+ Business Segment

+ Business Type

+ Core Business Area

+ Elementary Process

+ Process


+ Sub Process

+ Top Process

Exception Specification View

Test Specification View

Software/Service Description Framework (SDF) "Including concepts from: CBDI Forum Service Architecture & Engineering meta model for SOA". http://www.cbdiforum.com/public/meta_model_v2.php

Security Specification View

+ C19 Entity Identity Assertion

+ C26 Nonrepudiation

+ T15 Collect and Communicate Audit Trail

+ T16 Consistent Time

+ T17 Secured Communications Channel

+ TP13 Manage Sharing of Documents

+ TP20 Access Control

+ TP30 Manage Consent Directives

dependency


Software Definition Framework (SDF)Business Software Architecture (BSA)1.0FS WG

04/10/23 23

Minimum Essential Data Set for each IRD Phases

class SDF IRD 1.1 Conduct Strategic Generation of IT Requirements



+ Business Domain

+ Business Event


+ Business Segment

+ Business Type



+ Process


+ Sub Process

+ Top Process

Planning and Prov isioning Policy View


+ Architecture Layer Rule

+ Business Domain

+ Business Rules

+ Business Scope

+ Policy

+ Policy Subject

+ Policy Type


+ Software Domain


Process

Business Capability

+ name+ definition


- Submission


SDF IRD 1.1 Conduct Strategic Generation of IT RequirementsIRD Processes and Products1.0FSWG

class SDF IRD 1.2 Process Submission

Verified Submission



SDF IRD 1.2 Process SubmissionIRD Processes and Products1.0FSWG

04/10/23 24

class SDF IRD 1.4 Prioritize Solution Sets


+ Actor



+ Transaction

+ Use Case


+ Use Case Step





+ Interface Type


+ Service Domain







SDF IRD 1.4 Prioritize Solution SetsIRD Processes and Products1.0FSWG


class SDF IRD 1.3 Conduct Enterprise Analysis of Requirements Design Sets



+ Business Domain

+ Business Event


+ Business Segment

+ Business Type



+ Process


+ Sub Process

+ Top Process


+ Actor



+ Transaction

+ Use Case


+ Use Case Step





+ Interface Type


+ Service Domain







SDF IRD 1.3 Conduct Enterprise Analysis of Requirements Design SetsIRD Processes and Products1.0FSWG

04/10/23 25

class SDF IRD 1.5 Refine Funded Solution

Specified Solution



+ Actor



+ Transaction

+ Use Case


+ Use Case Step

Detailed Software Specification View

+ Application Layer

+ Business Objective

+ Business Type

+ Compliance Item

+ Compliance Level

+ Compliance Level Deviation Item

+ Employee

+ EndPoint


+ Informal Operation

+ Interface

+ Mandatory Message Sequence

+ Message Specification


+ Organization

+ Pre Post Condition Pak

+ Protocol

+ Service Level Agreement



+ Software Classification Group

+ Software Definition Language File

+ Software Information Model

+ Software Owner


+ Software State

+ Transaction

Security Specification View

+ C19 Entity Identity Assertion

+ C26 Nonrepudiation

+ T15 Collect and Communicate Audit Trail

+ T16 Consistent Time

+ T17 Secured Communications Channel

+ TP13 Manage Sharing of Documents

+ TP20 Access Control

+ TP30 Manage Consent Directives

Exception Specification View

Test Specification View


SDF IRD 1.5 Refine Funded SolutionIRD Processes and Products1.0FSWG

class SDF IRD 1.6 Define Quality Assessment Attributes

Contract Deliv erables



SDF IRD 1.6 Define Quality Assessment AttributesIRD Processes and Products1.0FSWG


Association: a solid line represents an unspecified relationship between classes or objects; Optional open arrowheads indicate flow (e.g. messaging)

Association - Composition: a solid line with an open arrowhead and a solid diamond at the tail end that represents a "has-a" relationship. The arrow points from the containing to the contained class. A composition models the notion of one object "owning" another and thus being responsible for the creation and destruction of another object.

Association - Aggregation: a solid line with an open arrowhead and a hollow diamond at the tail end that represents a "has-a" relationship. The arrow points from the containing to the contained class. An aggregation models the notion that one object uses another object without "owning" it and thus is not responsible for its creation or destruction.

Generalization - Inheritance: a solid line with a solid arrowhead that represents an “is-a” relationship. The arrow points from a sub-class to a super-class or from a sub-interface to its super-interface.

Generalization - Implementation: a dotted line with a solid arrowhead that points from a class to the interface that it implement

Generalization - Realize: a dotted line with a solid arrowhead shows that the source object implements or realizes the destination. Realize is used to express traceability in the model.

Dependency: a dotted line with an open arrowhead that shows one entity depends on the behavior of another (e.g., Realization, Instantiation and Usage) client (tail) refines the source. Typical usages are to represent that one class instantiates another or uses the other as an input parameter.

Message: a solid line with an open arrowhead that shows that one entity communicates with another.

UML RelationshipsAmong Classes and Objects

04/10/23 26

04/10/23 27

class Business Modeling View

Business Modeling

Core Business Area

+ definition: string

Software Specification

+ IsInfrastructureService: boolean

Business Ev ent

+ type: enum+ expression: string+ identified: string

Business Capability

+ name+ definition

Process

+ name

Business Model Element

Business Type

- name- definition

Business Segment

+ name

Sub Process

Elementary Process

Business Domain

+ name: string+ description: string

In this view, we are not attempting to provide a comprehensive model business modeling concepts. We include the business modeling concepts we recomment are connected to other parts of the SA&E model. Further subtypes of Business Modeling Elements are not meant to be limited by this view.

Corresponds to OV-5 leaf activities

Top Process 1

part of

*

*

designed to specify support

*

generalize

*

triggered by

1..*

*

decomposes into *generalize

*

supported by

*

0..1

part of

*

1

*

currently used with

*

*

expected use with

*

1..* 0

*

*

1..*1..*

0..*


Business Modeling ViewBusiness Modeling View1.0; last updated 25 Sep 07FS WG

class Solution Modeling View

Solution Modeling

Business Modeling

Business Model Element

Business Segment

+ name

Process

Elementary Process

Serv ice Specification


Transaction

This view does not attempt to define all aspects of modeling Software Solution Modeling objects which are useful associated with service specification concepts. Furthermore, Use Case, Association and Actor are modified in simplified manner. See UML for the rigorous model

Use Case Association

+ isIncludes: boolean+ isExtends: boolean

Use Case

+ name+ goal

Application Specification

Actor

+ name

Use Case Step

+ number+ description

25 Sep 07 (EV): May need to go beyond use-cases in solution modelingRationale:Allow for l inking (pairing of requirements with design artifacts at a better aggregation level)Allow for flexibil ity in expressing various aggregation levelsAllow for compatibil ity with HITSP/IHE profiles

25 Sep 07 (EV): Background on "Transactions"Typically a "transaction" is a logical unit that happens once or not-at-all - It has boundaries (it "begins" and "ends”" - It can be nested (an outer transaction may include several inner transactions - and so on -) - In db world a transaction is associated with a "commitment" operation to a persistent state - For CBDI we need to extend/include situations when no "commitment" to persistent storage is required, yet the other transaction characteristics are present

Transactions in IHE/HITSP - IHE/HITSP Integration profiles are defined in terms of IHE Actors and transactions. - Actors are information systems or components of information systems that produce, manage, or act on information associated with clinical and operational activities in the enterprise. - Transactions are interactions between actors that communicate the required information through standards-based messages. - In each transaction description, the actors, the roles they play, and the transactions between them are presented within one or more use cases.

The generic IHE transaction description includes the following components: Scope: a brief description of the transaction. Use case roles: textual definitions of the actors and their roles, with a simple diagram relating them Referenced Standards: the standards (stating the specific parts, chapters or sections thereof) to be used for the transaction. Interaction Diagram: a graphical depiction of the actors and transactions It is not necessarily performing "write" (i.e.commit) operations (i.e. Retrieve info for display profile)

Operation Specification

- name: string

*

1

* involves

*1..* participates in

*

1..*

participates in

*

generalize* uses

1

*

1

*

*

*realized using functionality within

*

1

/offers

1..*

*

supported by

*

*

supported by

*


Solution Modeling ViewSolution Modeling View1.0; last updated 25 Sep 07FS WG

04/10/23 28

04/10/23 29

class Planning and Prov isioning Policy View.

Policy Type

- typeCode: string- typeName: string

Policy

+ definition: string+ definitionLanguage: enum+ strictness: enum+ enforcementMethod: string+ originator: string

Architecture Layer Rule

+ mayContain: enum+ mayHaveDataStore: enum+ mayCallLayerNr: int+ intraLayerRule: enum+ interDomainRule: enum

Policy Subject

+ name: string

Business Scope

+ description: string

Business Domain

Software Domain

+ description: string+ isInfrastructureDomain: boolean+ hasOwnPolicies: boolean+ hasSharedTypeModel: boolean


Software Classification

+ meaning: string+ code: string

Architecture Layer

+ levelNr: int

Policy Type Names (Examples): Standards Conformance, Quality Requirement, Commercial, Architectural, Service LifeCycle, Sourcing, Tactics, Project Management,

Business Rules* contains

1

* constrains

1

*

belongs to**

applies tocombination of

1..*

generalize

1categorizes

*


Planning and Provisioning Policy View. Planning and Provisioning Policy View1.0FS WG

04/10/23 30

class SW Spec. View

Architecture Layer Rules

+ mayContain: enum+ mayHaveDataStore: enum+ mayCalLayerNr: []int+ interLayerRule: enun+ interDomainRule: enum

Serv ice Domain

+ name: string+ description: string+ is InfrastructureString: string+ hasOwnPolicies: boolean+ hasSharedTypeModel: boolean

Architecture Layer

+ Name: string+ levelNr: int


+ name: string+ technicalName: string+ alias: string [*]+ versionNr: int+ revisionNr: int+ issueNr: int

Specification Dependency

+ stereotype: enum

Application Specification


+ IsInfrastructureService: boolean+ responsibil ities: string+ purpose: string+ commodityLevel: enum+ standardizationSupport: string+ customizationSupport: string+ targetCustomers: string+ visibil ity: enum+ stabil ity: string+ hasRunTimeInstances: boolean+ otherInfo: string

Interface Type

+ name


- name: string

Transaction

*

*

Generalize

*

*

*has earlier release

*

1

constrains

*

*

overridesUsualRulesFor

0..1

1

constrains

*

*

contains

0..1

1

has

*

1

enables

*

generalize

Generalize

1

defines

1..* 1

groups

1..*


SW Spec. ViewSoftware Specification View1.0FS WG

04/10/23 31

class SPTC Logical Construct Diagram

Dynamic Security and Privacy Access Controls

Consistent Time

- docID: T16- type: Transaction

Collect and Communicate Audit

Trail


Manage Sharing of Documents

- docID: TP13- type: Transaction Package

Nonrepudiation

- docID: C26- type: Component

Entity Identity Assertion

- docID: C19- type: Component

Secured Communication Channel


Prerequisites to satisfy use cases

Data at rest static controls

Access Control


Manage Consent Directives


Protected Data or Function

Note: This includes optional support for Document Integrity

assertion

consent

class Detailed SW Spec. View

Application Layer

+ name: string+ levelNr: int


+ name: string+ technicalName: string+ alias: string [*]+ versionNr: int+ revisionNr: int+ issueNr: int- style: enum- transmission: enum- inputMessage: string- outputMessage: string- coordinationBy: enum

Informal Operation

+ text: string+ name: string

Mandatory Message Sequence

+ sequenceDescription: string [0..1]+ standardPatternName: string [0..1]

Organization

+ name: string+ isLegalEntity: boolean

Business Objectiv e

+ definition: string


+ isInfrastructure: boolean+ responsibil ities: string+ purpose: string+ commodityLevel: enum+ standardizationSupport: string+ customizationSupport: string+ targetConsumers: string+ visibility: enum+ stability: string+ hasRunTimeInstance: boolean+ otherInfo: string

Software Information Model

Business Type

+ name+ definition

Message Specification

+ role+ encodingForm+ structure


+ name: string+ errorMessage: string+ isTransactional: boolean

Employee

+ name: string+ id: string

Software Owner

+ type: enum

Software Definition Language File

Serv ice Lev el Agreement

+ fileName

Software State

+ name: string

Software Classification

+ name: string+ meaning: string+ code: string

Software Classification Group

+ singleValueMembership: boolean+ mandatoryMembership: boolean+ name: string

Compliance Lev el

+ areaName: enum+ name: string

Compliance Item

+ identifier: string+ definition: string+ category: enum+ notes: string

Interface

+ name

Protocol

+ name: enum+ versionNr: enum

EndPoint

+ name: string+ networkAddress: string+ WSDL binding name: string

Pre Post Condition Pak

+ identifer: string+ precondition: string+ postcondition: string

Endpoint Operation

+ name: string

Compliance Lev el Dev iation Item

Note: Model does not support concurrent substates. Probably needs to.

Transaction

1

defines

*

1

constrains

*

has alternative

0..*

0..*

1 offers

1..*

1defines

1..*

1..*

currently exists in

1

*

belongs to

*

*

consists of

0..1

*supported by

* 1..*send to or from

1..**is providerto

*

1employees

*

*involves executing

1..*

1..*

requested to execute

1

*

offers

Generalize

*

has earlier release*

1

subject to

*

*

is consumerto

*

1 supports

1..*

1bound to

*

1

applies to

1..*

1..*

comprised of

1..*

1 overrideability

*

*

has alternative

*

maintains datadefined by

*

has nested

0..*

Generalize

* concerns this

1..*

0..*

contains 1..*

0..2

responsible for

1..*

1 acts as

*

1

behaviordefined by

*

1

subject to

*

*

bound to

1..*

*member of

1

GeneralizeName:Package:Version:Author:

Detailed SW Spec. ViewDetailed Software Specification View1.0; Last Updated 25 Sep 07FS WG

04/10/23 32

04/10/23 33

class Implementation View

Organization

- name: string- isLegalEntity: boolean

Automation Unit

+ name: string+ stereotype: enum+ hasOwnDataSource: boolean

AU Dependency

+ stereotype: enum

Internal Org

External Org

Architecture Layer

+ name: string+ levelNr: int Prov ided

Capabilities

Required Capability

+ requiredType: enum


+ name: string+ technicalName: string+ alias: string [*]+ versionNr: int+ revisionNr: int+ issueNr: int


- isInfrastructureService: boolean+ responsibil ities: string+ purpose: string+ commodityLevel: enum+ standardizationSupport: string+ customizationSupport: string+ targetCustomers: string+ visibil ity: enum+ stabil ity: string+ hasRunTimeInstance: boolean+ otherInfo: string

Deliverable from the layers of the specification(s) supported by Automation Unit

1

constrains

*

1..*

/constraints

*

1 enables

*

1 has

*

*

implements

11 depends on

*

*conforms to1

*

has earlier release

*

1

partitioned into

*

1 provider of

*

* consumer of

*

*conforms to

1


Implementation ViewImplementation View1.0FS WG

04/10/23 34

class Runtime View

Node

+ name: string+ type: string+ properties: [ ] string

Deployment

Serv ice Instance

+ identifier: string

Endpoint

+ networkAddress+ name+ WSDL binding name

Internal Location

+ networkAddress: string


Endpoint Operation

+ name: string

Automation Unit

+ name: string+ stereotype: enum+ hasOwnDataStore: boolean+ mediationCategory: enum (0..1)

Technical Interface

+ name: string

Technical Operation

+ name: string

Protocol

+ name: enum+ versionNr: enum

1 supports

1..*

* hosts executing

*1

hosts

*

*

installs

1

1 resides at

1..*

*

manages 1

residence for

*

*

bound to

1

1offers

1..*

*

accessible at

1

1

bound to

1..*

1

implemented by

*

1..*

handels messages of

1

1 provides

*

1

partitioned into

*

0..*

accessed through alternative

1


Runtime ViewRuntime View1.0FS WG

04/10/23 35

class Deployment View

Communication Path

+ protocol

Node

+ name: string+ type: string+ properties: string

Deployment

Processor

Execution Env ironment Automation Unit

+ name: string+ stereotype: enum+ hasOwnDataStore: boolean+ mediationCategory: enum [0..1]

AU Dependency

+ stereotype: enum

Enterprise Serv ice Bus

+ isCentralHub: boolean+ isFederatedESB: boolean+ isLightweightSpoke: boolean

* hosts execution

*

*

residence for

*

hosts

1 has

*

1 enables

*

1

installs

*

1partitioned into

*

2

connects

*


Deployment ViewDeployment View1.0FS WG

Contents

1. Management SOA Perspective

2. Technical SOA Perspective

3. Application SOA Perspective

4. Backup Slides

36

Joint HL7 and OMG Healthcare Services Specification Project

Interoperability at the Service LevelVia a

Standardized Healthcare Service Oriented Reference Architecture

(H-SOA-RA)And

Services Specification Framework (SDF)

REQUESTED ACTION: Send Suggestions for Improvement to [email protected] John Koisch, [email protected]

18 Aug 2007 version O

BackgroundFederal Direction

38

‘2001 President’s E-Gov Initiative resulted in Consolidated Health Informatics (CHI) and Federal Health Architecture (FHA)

‘2004 Executive Order (EO) #13335 mandated “Incentives for the Use of Health IT and Establishing the Position of the National Health IT Coordinator.” It set a ‘2014 target for US EHR interoperability.

‘2006 Executive Order (EO) #13410 “Promoting Quality and Efficient healthcare in Federal Government Administered or Sponsored healthcare Programs,” starting in Jan ‘2007.

Health and Human Services (HHS) is the designated Executive Agency to implement the Executive Orders (EOs).

Healthcare Information Technology Standards Panel (HITSP) is chartered by HHS to define the Interoperability Specifications (IS) of standards to enable the sharing of health information in a secure environment to improve healthcare.

President’s Commission on Care for America’s Returning Wounded Warriors made six patient centric recommendations to fix the MHS-VA health systems.

Joint HL7-OMG Healthcare Services Specification Project

(HSSP)

GOAL: Faster-better-cheaper interoperable-healthcare-systems resulting from consistent enterprise architectures, system acquisitions, system developments, system tests and system certifications within and among organizations.

PROBLEM: Inconsistent semantics among healthcare system users, venders, contractors and acquisition processes.

APPROACH: Standardize Healthcare SOA Reference Architecture (H-SOA-RA) based on the HL7 EHR System Functional Model (EHR-S) and commercial SOA best practices.

BENEFIT: Integrated EHR-S requirements linked to H-SOA-RA system design specifications and CCHIT certification tests will result in consistent, traceable and interoperable requirements-design specifications for procurements, developments & tests.

39

40

Situation: HealthcareService Oriented Architecture

Problem: A healthcare Service Oriented Architecture (SOA) potentially has 300-400 services and as many standards. This creates an architectural, requirements-design and configuration management challenge.

Proposed Solution: H-SOA Reference Architecture (H-SOA-RA) Horizontal: EHR System (EHR-S) Function Model– Direct Care, Supportive, Information Infrastructure, Other

Vertical: Service Layer Categories – Core Business: Identity, Terminology, Authorization, Scheduling, supply

Chain, Documents, Records Mgmt., etc.– Composite Business value chains– Information/Data: Entity Services– Utility: Agnostic/Federated Services

41

Objectives

EHR Systems Interoperability at the Service level

HITSP Compliant National Healthcare Information Exchange (NHIE)– Allow simplified Harmonization with HITSP Specifications through Compatible Architectures– Simplified differentiation between services required to be HITSP compliant and others

Facilitate Analysis by Subject Matter Experts (SME)s– Functional, Technical (e.g., system engineering), Security and Privacy

Harmonize with Stable De-facto Models– HL7 EHR System Functional Model (e.g., system function categorization)– Commercial SOA layers (e.g., Oasis SOA); Federal Enterprise Architecture (FEA)

Support Vertical Implementation Profiles– Within business areas– Across business affinity domains

Service Traceability EHR-S, HITSP and CCHIT

42 42

Ap

plic

atio

n la

yer

Se

rvic

es

inte

rfa

ce la

yer

Bu

sin

ess

p

roce

ss la

yer

SOA LayersFocus on the Business

Processes and Services [Thomas Erl]

.NET J2EE Legacy

Source: Service-Oriented Architecture, Thomas Erl

orchestration service layer

business service layer

application service layer

SystemComponentsand Services

Business Capabilities and Services

43

SOA Service ModelsPotential Service Layers [Thomas Erl]

44

Service Model DescriptionApplication Service

A generic category used to represent services that contain logic derived from a solution or technical platform. Services are generally distinguished as application services when creating abstraction layers.

Business Service

A generic category used to represent services that contain business logic. When establishing specialized service layers, services that fall into the business service layers are collectively referred to as business. However, individually these services are classified as entity-centric (e.g., information) or task-centric business services.

Controller Service

A Service that composes others. Variations of this model exist, depending on the position of the controller in the composition hierarchy. The patent controller service can be classified as the master controller and a service that composes a subset of a larger composition can be labeled as sub-controller.

Coordinator Services

Three service models are derived from the concept of coordination: the coordinator, the atomic transaction coordinator, and the business activity coordinator. All three models are specific to the WS-Coordination specification and related protocols.

Entity-centric Business Service

A business process-agnostic variation of the business service that represents one or more related business entities. This type of service is created when establishing a business service layer.

Hybrid Service

A service that contains both business and application logic. Most services created as part of traditional distributed solutions fall into this category. When organizing services into abstraction layers, hybrid services are considered part of the application service layer.

Integration Service

An application service that also acts as an endpoint to a solution for cross-referencing integration purposes.

Process Service

A service that represents a business process as implemented by an orchestration platform and described by a process definition. Process services reside in the orchestration service layer.

Task-Centric Business Service

A business process-specific variation of the business service that represents an atomic unit of process logic. Task-centric services are different from process services in that the process logic is provided by the underlying service logic, not by a separate process definition. 44

Federated Services [1]

45

Federation is a state achieved by extending SOA into the realm of service-oriented integration. A number

of key WS-* extensions provide feature-sets that support the attainment of federation. Most notable

among these are the specifications that implement the concepts of orchestration and choreography.

Establishing SOA within an enterprise does not necessarily require that you replace what you already have.

One of the most attractive aspects of this architecture is its ability to introduce unity across previously

non-federated environments. While web-services enable federation, SOA promotes this cause by

establishing and standardizing the ability to encapsulate legacy and non-legacy application logic and

by exposing it via a common, open, and standardized communications framework.

• WSRP (Web Services for Remote Portals) is the cornerstone of federated services

• SAML (Security Assertions Markup Language) is commonly used

• ALSO: WS-Security, WS-Trust, WS-Policy, WS-Federation

Additional info at: https://www120.livemeeting.com/cc/bea/viewReg

[1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07

HL7 EHR System Functional Model (EHR-S)

(> 230 System Functions in 4 level categorization

(see attached spreadsheet for full enumeration)

46

NOTE: “Other” Category - The EHR-S model does NOT include Electronic Resource Planning (ERP) / Logistics and Financial components, which are needed for completeness of a military EHR.

Other O-1 Electronic Resource Planning (ERP)

O-2 Finances

O-3 Other

Business

Entity(Information)

Choreography

Infrastructure

Choreography

Business

Business

Infrastructure

Infrastructure

Infrastructure

Entity(Information)

Ser

vice

Typ

es

Sys

tem

Fun

ctio

ns

Choreography

Business

47

Leveraging SOA Processing in the Enterprise

BusinessServices

Information Services

InfrastructureServices

ApplicationServices

Choreographies(Orchestration Services)

Legacy

Healthcare SOA & Standards

Framework HL7 System Functions

Direct Care Supportive Information Infrastructure

Other

Business Process

Value Chains

FederatedServices Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas

Core BusinessServices





EntityServices




Information 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…)

ApplicationServices

Ambulatory Care Systems,In Patient Care Systems

Logistics SystemsFinancial Systems

Decision Support Systems

Data MartsRepositories

Business Objects

ImplementationProfiles

Integrated Healthcare Enterprise (IHE) Profiles

Analysis Profiles Communications Profiles/Stacks

Implementation Profiles

48

49

EHR DATA REUSE THROUGH H-SOA-RAACROSS EPISODES OF CARE

• Patient Demographics• Provider Demographics• Insurer Demographic

IDENTITY

Terminology

Document

• Chronic Diagnoses• Procedure History

• Patient History• Summary Lists - Medication List - Allergy/Adverse Reaction List - Immunization

Current EpisodeOf Care EHR

Previous EpisodeOf Care EHR

Reu

sabl

e S

ervi

ces

Data Must Be Verified And Updated

SUPPLY CHAIN (ORDER/CHARGE)

ANATOMY OF AN ANCILLARY SYSTEM

AUTHORIZATION

DOCUMENT

RECORDS MANAGEMENT

DECISION SUPPORT

PERFORMANCE

DATA MANAGEMENT

SCHEDULING

IDENTITY

TERMINOLOGY

LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH

s

CO

RE

B

US

INE

SS

S

ER

VIC

ES

50

IT PLATFORM

SUPPORT

ANALYTIC

DATA MANAGEMENT

PERFORMANCE

DECISION SUPPORT

RECORDS MANAGEMENT

DOCUMENT

SUPPLY CHAIN: (ORDERS/CHARGES)

SCHEDULING

AUTHORIZATION

TERMINOLOGY

IDENTITY

RADIOLO

GY

LABORATORY

PHARMACY

CLI

NIC

AS

U

T

ES

T O

NLY

O

UT

PA

TIE

NT

OT

HE

R

INP

AT

IEN

T E

R

CARDIOLO

GY

PT/O

T/SPEECH

DIETARY

SPECIALTY CARE

Ancillary Systems

Co

re B

usi

nes

s S

ervi

ces

INTEGRATEDREQUIREMENTS

DESIGNS: Putting the H-SOA-RA

Pieces Together

RESPIRATORY

Fed

erat

ed B

usi

nes

sS

ervi

ces

Ag

no

stic

S

ervi

ces

Federated Services, may be categorized by: -- Encounter Types -- CMS billing category -- Record type -- Care setting type -- etc.

Data sets are defined for each system functional-

capability-service module 51In

ter-

Age

ncy

Inte

r-S

ervi

ceA

cros

sP

rovi

ders

IT PLATFORM

SUPPORT

ANALYTIC

DATA MANAGEMENT

PERFORMANCE

DECISION SUPPORT

RECORDS MANAGEMENT

DOCUMENT

SUPPLY CHAIN:

(ORDER/CHARGE)

SCHEDULING

AUTHORIZATION

TERMINOLOGY

IDENTITY

RADIOLO

GY

LABORATORY

PHARMACY

CLI

NIC

AS

U

T

ES

T O

NLY

O

UT

PA

TIE

NT

OT

HE

R

INP

AT

IEN

T

ER

CARDIOLO

GY

PT/OT/H

SPEECH

DIETARY

SPECIALT

Y CARE

AncillaryApplications

Co

re E

HR

-S S

ervi

ces

RESPIRATORY

Patient Encounter Types

Fed

erat

ed

Ser

vice

s

Composite Services, which may be categorized by: -- CMS billing category -- Record type -- Care setting type -- etc.

Data sets are defined for each service – application – encounter type module

CASE MANAGEMENT

COORDINATION

AC

RO

SS

CA

RE

CO

NT

INU

UM

AC

RO

SS

SE

RV

ICE

S (

SO

As)

Case Management Coordination Across SOAs and the Continuum

ASSESSMENTCARE

PLANNING

ORDERS &

SCHEDULING

BENEFITMANAGEMENT

AUTHORIZATION &

UTILIZATION MGT.

COMMUNICATION(FACILITATION

ADVOCACY)

DISCHARGE/TRANSFERPLANNING

REFERRAL RECORD TRANSPORT

ROLE OF CASE MANAGER

AcuteInpatient

ChronicRehab.

OutpatientWartimeTheater

ER AcuteRehab.

SkilledLongTerm Care

CustodialLongTermCare

HomeHealth

Prevention/Wellness

Care Continuum

Coordination ACROSS SOAS

cCOORDINATION ` ACROSS LEVELS OF CARE, PROVIDERS and LOCATIONS

EDUCATION.

Potential Benefits from Process Improvement through H-SOA-RA

Elimination of Process Obstacles would result in:– Length of Stay Reduction– Improved Patient Outcomes / Reduced Risk– Revenue Improvement– Staff Efficiencies– Improved Patient and Staff Satisfaction– Reduced IT Expenditure/Maintenance Costs – Improved Information Accuracy and Availability

54

ADDRESSING REAL BUSINESS ISSUES THROUGH H-SOA-RA

• Incomplete/Inaccurate Demographic Data (Identity Service)• Incomplete/Inaccurate Insurance Information (Authorization Service)• Unauthorized Service (Authorization Service)• Diagnosis/Procedure Coding Errors (Terminology Service)• Service Delays (Scheduling Service)• Incomplete and Inefficient Charge Capture (Supply Chain Service)• Non-indicated or Contra-indicated Services (Decision Support/

Authorization Services)• Delays in EHR Document Production and Provision (Document Service)• Billing Delays and Errors (Supply Chain/ Billing/ Collection Services)• Not fully coordinated Scheduling (Scheduling Service) • Lack of fully integrated Patient Assessment and Treatment Plan (Document Service/ Decision Support Service)• Delayed or Lack of Medical Record Access (Record Service)

55

Service Definition Framework (SDF)

56

Source: Department of Defense Global Information Grid Service Strategy

As we move to federated SOA services, it is important that services across the enterprise be described using a common set of information (metadata) so that services can be consistently discovered and understood by others in the enterprise. The Service Definition Framework (SDF) shown below identifies the necessary attributes for effective description of a service.

See www.SOA.OMG.org “UML Profile and Metamodel for Services (UPMS) "SOA“ for related information.

Service Description Model

http://wiki.oasis-open.org/soa-rm/TheArchitecture/ServiceView/ServiceDescription

57

Contents

1. Management SOA Perspective (Mary Terlep lead)

2. Technical SOA Perspective (Steve Hufnagel lead)

3. Application SOA Perspective (FHA/Laura Tillery lead)

4. Backup Slides

58

Standardized Healthcare Service Oriented Reference Architecture

(H-SOA-RA)

Goal: President’s Commission on Wounded Warriors

Serve, Support, Simplify

Goal: MHS & VAInteroperability at the Service Level

Goal: HITSPTo enable the sharing of health information in a

secure environment to improve healthcare.

MHS IM/ITProgram

Goal: Healthcare SOA Reference Architecture

(H-SOA-RA)

NationalFederated

Healthcare Industry

VA/ DoD Interagency

DoD

TMA

Military Service

INTE

GR

ATIO

N

Identifying Opportunities to Leverage Technology and Alleviate Redundancy or Agency IT Overlap

Joining Forces to Improve Effectiveness, Efficiency, and Service delivery

CO

LLA

BO

RA

TIO

N

INTER-AGENCY

Key Business DriverPatient Centric Processes (e.g., Wounded Warriors)

60

Key Architectural ObjectiveStandardized Technical Solutions aligned with

Core Business Processes.

Objectives: Joint MHS & VA Healthcare SOA Reference Architecture (H-SOA-RA)

EHR Executive Orders:1. MHS-VA Electronic Medical Record (EMR) Interoperability2. Purchased Care Interoperability3. HITSP Compliance

Care for America’s Returning Wounded Warriors Executive Order: “care provided to America’s returning Global War on Terror service men and women from the time they leave the battlefield through their return to civilian life.” …

President Commission’s Recommendations [www.pccww.gov/]:1. Implement comprehensive Recovery Plans2. Restructure disability and compensation systems3. Improve care for people with post-traumatic stress disorder (PTSD) and traumatic brain injury (TBI)4. Strengthen support for families5. Transfer patient information across systems6. Support Walter Reed until closure

61

Recommended Roadmap (not in order; concurrency is desirable)1. Harmonize SOA&SC with Federal Enterprise Architecture (FEA) done

– Service Component Reference Model (SCRM)Individual agencies should map their architectures to the other FEA views:

• Performance Reference Model (PRM)• Business Reference Model (BRM)• Data Reference Model (DRM)• Technical Reference Architecture (TRM)

2. Validate with Open/IBM & Microsoft Healthcare Frameworks (slides 43-48) done3. Test the SOA&SC framework done

– Map HL7/OMG HSSP services and standards to framework– Map HITSP implied services & standards & CHI standards to framework– Map IHE implied services & standards to framework– Map candidate MHS & VA services & standards to framework

4. Wounded Warrior (WW) Integrated Requirements-Design (IRD) for MHS-VA NHIE Gateway5. Validate WW NHIE IRD with MHS & VA Subject Matter Experts (SME)6. Standardize H-SOA-RA as guideline through HL7 SOA SIG 7. Joint MHS-VA WW NHIE Gateway standardized as Federal Health Architecture (FHA)

62

Roadmap for Healthcare Service and Standards

Categorization using H-SOA-RA

Roadmap to HITSP Compliant EA IRDSolution Set for Wounded Warriors (WW)

National Health Information Exchange (NHIE)

1. Define Healthcare SOA Reference Architecture (H-SOA-RA) candidate service blueprint, based on Electronic Healthcare Record System Functional Model (EHR-S) categoriesand Service Oriented Architecture (SOA) system layers.

2. Map & Gap AHLTA & VISTA clinical system functions to EHR-S service functions.3. Define and analyze wounded warrior (WW) use cases using AHIC & HITSP processes.4. Define HITSP compliant WW National Healthcare Information Exchange (NHIE) Gateway

–Define AHLTA & VISTA application and federated services–Define Integrated Requirements-Design (IRD) Solution Sets from H-SOA-RA

5. Build Strategic Enterprise Architecture (EA) Transition Plan– Include EHR-S system functions, H-SOA-RA and CCHIT Test Specifications in

• Investment Portfolio (e.g., POM processes)• Procurement Contracts and Acceptance Test & Evaluation Master Plans

– Use EHR-S & H-SOA-RA as the key to CM traceability• Functional proponents, Investment Portfolio, OMB & IG reviews, NHIE Gateway• Capabilities/requirements, designs, standards, and test

7. CCHIT Certification (e.g., 2006, 2009, 2012) 63

1. Construct Use Case Scenarios focused on President’s Commission's WW recommendations – Start with AHIC Emergency Responder use case– Emphasize recommendation #5 ” transfer information among systems” [See www.pccww.gov/] – Add benefits determination and shared MHS-VA benefits repository

2. Build UML Models for WW scenarios FY07Q4– AHIC-HITSP style Use Cases and Interaction diagrams– H-SOA-RA System Solution UML Deployment diagrams – HITSP Interoperability Specification Constructs

3. Pre-Coordinate with MHS CIO, VHA & FHA FY08Q14. FHA (WW Line of Action #4 proponent) request ONC to verify & validate scenarios & models5. FHA specify WW National Healthcare Information Exchange (NHIE) Gateway

– based on EHR-S– based on H-SOA-RA– based on HITSP Interoperability Specifications

6. Build MHS & VA Strategic Architecture Transition Plan– based on WW NHIE Gateway IRD vision

7. Implement Strategic Architecture Transition Plan in Investment Portfolios

Next StepsMHS-VA Joint H-SOA-RA

Integrated Requirements Design (IRD) Solution Set for Wounded Warriors (WW)

64

FY07Q4 FY08Q1 FY08Q2 FY08Q3 FY08Q4

Optimistic Internal TimelineJoint MHS-VA using H-SOA-RA

Integrated Requirements Design (IRD)Solution Set for Wounded Warriors (WW)

National Health Information (NHIE) Gateway

Schedule is dependent on available resources!

65

OV-6C Enterprise (Business Value Chains) Process Flows

OV-7 Enterprise Logical Data Model Data Sets

SV-1/SV-2 Enterprise System Interface / Communication Descriptions

SV-4 Enterprise System Functions Descriptions

SV-4 Enterprise System Data Flows

SV-5 Enterprise Activity (OV-5) to System Function (SV-4) Mapping

SV-3/SV-6 Enterprise System to System Interface / Data Exchange Matrix

SV-8/SV-9 Enterprise System Evolution / Technology Forecast

SV-10C Enterprise Systems Event Trace Descriptions (e.g., Wounded Warrior)

TV-1 Enterprise System Standards Categorization

TV-2 Enterprise System Standards Forecast

Wounded Warrior Scenarios

66

Source:www.pccww.gov/ )

Medical Surveillance

CARE OUTSIDE THEATER

TRAINDEPLOY

ENROUTE CARE

GARRISONGARRISON

HEALTHY & FITFORCE

THEATERHOSPITALIZATION

AHLTA(Wounded Warrior)

TRAC2ES

CASUALTY PREVENTION

THEATER

AHLTA(Medical Treatment Facilities)

FORWARD RESUSCITATIVE

SURGERY

BATTALION AID STATION

Theater Medical

Data Store

Wounded WarriorContinuum of Care

VHA CARE

DISCHARGE

AHLTAClinical

Data Repository

FORCE HEALTH

PROTECTION

Medical Situation Awareness

VISTAClinical

Data Repository

VISTA(Medical Treatment Facilities) 67

INTERAGENCY EA STANDARDIZATION IN SUPPORT OF THE WOUNDED WARRIOR

GOAL: Seamless Uninterrupted Care Across the Continuum of Care

Care Plan

Decision Support

Case Management

Records Management

Referral

Performance

Benefits Management

Trauma Registry

H-SOA-RA IT Services

VA DOD

Integrated Care Planning involving Key Players Upfront

Informed Decision Making with Timely Alerts

Consistent Care Oversight and Co-Ordination

Timely Complete Information

Streamlined Referral

Joint Performance Review, Learning, Improvement

Timely, Efficient Benefit Access

Patient Monitoring and Epidemiological Analysis.

68

Civilian

Warfighter

Combat Theater

DOD

Landstuhl

Walter Reed Purchased Care

Recuperative and Long Term Care

Acute and Recuperative Care

AcuteCare

SpecialtyCare

CriticalCare

StabilizationCare

•Develop user-friendly single web portal for service members and veterans

•Continue efforts for fully interoperable information system

WOUNDED WARRIOR RECOMMENDATIONS: SOA VIEW

ASSESSMENT CARE PLAN ORDERS SCHEDULING

COMMUNICATION BENEFIT MANAGEMENT AUTHORIZATION &UTILIZATION REVIEW DOCUMENT

REFERRAL DISCHARGE/TRANSFER PLANNING

IDENTITY TERMINOLOGY

EDUCATION TRANSPORTATION

DECISION SUPPORT HUMAN RESOURCE MANAGEMENT

•Develop Corp of Recovery Coordinators•Address the shortage in medical health professionals •Expand network of experts in PTSD and TBI•Recruit and Retain Clerical/Admin. Staff•Assure adequate resources •Address shortage of mental health professionals

• Develop integrated Care Teams -Create Recovery Plans

•Clarify Objectives of DoD/VA Disability Programs•Provide lifetime TRICARE benefits for combat-injured•Restructure VA disability payments•Determine appropriate length and amounts of transition payments•Update and keep current the disability rating & Education Program•Provide VA PTSD care for Iraq and Afghanistan veterans•Cover family members under the Family Medical Leave

• Expand training regarding PTSD and TBI• Expand Caregiver Training for families

RECORD

• Create a single, comprehensive medical exam

•Develop or disseminate clinical practice guidelines

• Make patient information available to all who need it in readable form

IT SERVICES

70

Backup Slides

Abbreviations

HA DASD Traceability to HL7 EHR-S Functional Model SOA Background Slides • SOA Framework, Inventory, Design • SOA Principle Interaction • SOA Service Models (e.g., potential layers) • Service Elicitation Process • Service Categorization • Entity Services, Task Services, Utility Services • Focal Classes • Alternative Healthcare SOA & Standards Framework Representation

Federal Enterprise Architecture (FEA)• Technical Reference Architecture (TRM) • Performance Reference Model (PRM) • Business Reference Model (BRM) • Service Component Reference Model (SCRM) • Data Reference Model (DRM)

Other Healthcare Frameworks• Open Health (formerly IBM) • Microsoft

Global Justice Reference Architecture (SOA-TRM integration)

ASU Ambulatory Surgery UnitCCHIT Certification Commission for Healthcare Information TechnologyEA Enterprise ArchitectureEHR Electronic Healthcare RecordEHR-S Electronic Health Record-System Functional ModelHIT Healthcare Information Technology HITSP Health IT Standards PanelHITSP Health IT Standards PanelHRA Healthcare Reference ArchitectureIHE Integrating the Healthcare Enterprise NHIE National Health Information ExchangePPBES Planning, Programming, Budgeting and Execution System (DoD) SOA Service Oriented ArchitectureVA Veterans Administration

71

Abbreviations

Resources UsedDetailed list of H-SOA-RA Services are listed, described and referenced in a separate Excel Spreadsheet . They

were developed using the following resources

• FEA CONSOLIDATED REFERENCE MODEL VERSION 2.1

– FEA Business Reference Model (BRM)

– FEA Service Reference Model (SRM)

– FEA Technical Reference Model (TRM)

• HL7 EHR-S Model

• MHS Enterprise Architecture

• Open Healthcare Framework (OHF) (Formerly IBM Health Framework

• Microsoft Connected Health Framework Architecture and Design Blueprint

• HITSP /HL7 SOA Task Force

• Other Resources considered included:– Joint Commission on Accreditation of Hospital Standards (JCAHO)

– First Consulting Group Yellow Brick Road Document

– AMEDD Activity Mappings

– UJTLS Activity Mappings

– OASIS SOA Reference Model http://wiki.oasis-open.org/soa-rm/TheArchitecture

72

IT PLATFORM

SUPPORT

ANALYTIC

DATA MANAGEMENT

PERFORMANCE

DECISION SUPPORT

RECORDS MANAGEMENT

DOCUMENT

SUPPLY CHAIN:

(ORDER/CHARGE)

SCHEDULING

AUTHORIZATION

TERMINOLOGY

IDENTITY

RADIOLO

GY

LABORATORY

PHARMACY

CLI

NIC

AS

U

T

ES

T O

NLY

O

UT

PA

TIE

NT

OT

HE

R

INP

AT

IEN

T

ER

CARDIOLO

GY

PT/OT/H

SPEECH

DIETARY

SPECIALT

Y CARE

AncillaryApplications

Co

re E

HR

-S S

ervi

ces

RESPIRATORY

Patient Encounter Types

Fed

erat

ed

Ser

vice

s

Composite Services, which may be categorized by: -- CMS billing category -- Record type -- Care setting type -- etc.

Data sets are defined for each service – application – encounter

type module

Integrated Requirements-DesignLexical & Semantic Consistency= EA Traceability resulting from EHR-S as H-SOA-RA Foundation

DODAF Enterprise Architecture View BASED ONOV-6C Enterprise (Business Value Chains) Process Flows EHR-S lexiconOV-7 Enterprise Logical Data Model Data Sets EHR-SSV-1/SV-2 Enterprise System Interface / Communication Descriptions H-SOA-RA & HITSPSV-4 Enterprise System Functions Descriptions EHR-SSV-4 Enterprise System Data Flows H-SOA-RA & OV-3 info flowsSV-5 Enterprise Activity (OV-5) to System Function (SV-4) Mapping EHR-S & H-SOA-RASV-3/SV-6 Enterprise System to System Interface / Data Exchange Matrix SV-1, SV-4, OV-7 & HITSP ISSV-8/SV-9 Enterprise System Evolution / Technology Forecast H-SOA-RA & CCHIT, EA PlanSV-10C Enterprise Systems Event Trace Descriptions (e.g., Wounded Warrior) OV-6C, SV-5 & SV-6TV-1 Enterprise System Standards Categorization H-SOA-RATV-2 Enterprise System Standards Forecast H-SOA-RA & EA Transition

Plan

Strategic capabilities map to EHR-S system functionsEHR-S Functions map to Operational Activities (OV-5)EHR-S Functions map to Functional RequirementsEHR-S Functions map to H-SOA-RA ServicesSystems decompose into consistent & traceable sets of

-- EHR-S System Functional Capabilities -- H-SOA-RA services

73

Organizational StructureTRICARE Management Activity

Acting Chief MedicalOfficer

1Dr. Smith

Acting Chief FinancialOfficer

1Mr. Middleton

Acting Chief Information

OfficerMr. Foster

Chief Force Health

Protection and Readiness

1Ms. Embrey

General CounselMr. Seaman

Dr. S. Ward CasscellsDirector, TMASenior Enlisted Advisor (SEA)

OASD (Health Affairs) & TMA

CMSgt Manuel Sarmina, USAF

Chief Health PlanOperationsMs. Storck

Acting Chief of StaffMr. Gidwani

Director, Program IntegrationMs. Speight

DirectorDoD/VA Program

Coordination OfficeMr. Cox

Regional DirectorTRO North

1Mr. Koenig

Regional DirectorTRO South

1Mr. Gill

Regional DirectorTRO West

1RADM Lescavage

MG Elder Granger, MC, USADeputy Director, TMA

DirectorTAO Latin Am/Can

1COL Franco

DirectorTAO Pacific

Mr. Chan

DirectorTAO Europe

1CAPT Niemyer

Chief Pharmaceutical

Operations2RADM McGinnis

Executive Officer

LTC Wooldridge

Deputy Chief of Staff

Vacant

TRICARE Military Education/Executive Assistant to

SEA OASD (HA) & TMAVacant

1Non-TMA2Public Health Service

74

HL7 EHR System Functional ModelVs DoD HA Deputy Secretary of Defense (DASD) Proponents

75

Acting Chief MedicalOfficer

1Dr. Smith

Acting Chief FinancialOfficer

1Mr. Middleton

Acting Chief Information

OfficerMr. Foster

Chief Force Health Protection and

Readiness1Ms. Embrey

Chief Health PlanOperationsMs. Storck

Chief Pharmaceutical

OperationsRADM McGinnis

CITPO

TMIP

RITPO

EIDS

DMLSS

TIMPO

DASDs

Personnel & Readiness(P&R) e.g., Benefits

RITPO

See associated spreadsheet for 260 detailed EHR-S functions mapped to DASDs

Other O-1 Electronic Resource Planning (ERP)

O-2 Finances

O-3 Other

Benefits Service Oriented Architecture (SOA)

and Standards Categorization (SOA&SC)

Considering that EHR-S is already mapped to CCHIT certification, Adopting the SOA&SC Framework gives traceability across

– Proponents (e.g., HA DASDs)

– PPBES processes and products

– Capabilities and their requirements

– Systems and their functions

– Technical Standards Profiles

– Technical requirements and test results

– Commercial Healthcare EHR Functions

– Commercial Service Oriented Architecture (SOA) practices 76

Candidate Service Inventory [1]“Service Inventory Blueprint”

An ultimate goal of an SOA transition effort is to produce a collection of standardized services that comprise a service inventory. The inventory can be structured into layers according to the service models used, but it is the application of the service-orientation paradigm to all services that positions them as valuable IT assets in full alignment with the strategic goals associated with the SOA project. However, before any services are actually built, it is desirable to establish a conceptual blueprint of all the planned services for a given inventory. This perspective is documented in the service inventory blueprint.

There are several common business and data models that, if they exist within an organization, can provide valuable input for this specification. Examples include business entity models, logical data models, canonical data and message models, ontologies, and other information architecture models. A service inventory blueprint is also known as a service enterprise model or a service inventory model.

77

[1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07)

We are proposing the use of the HL7 System Functional Model for this purpose.

SOA Design [1]

The service-oriented design process uses a set of predefined service candidates from the service inventory blueprint as a starting point from which they are shaped into actual physical service contracts.

When carrying out service-oriented design, a clear distinction is made between service candidates and services. The former represents a conceptual service that has not been implemented, whereas the latter refers to a physical service.

As shown in the following figure, the traditional (non-standardized) means by which Web service contracts are generated results in services that continue to express the proprietary nature of what they encapsulate. Creating the Web service contract prior to development allows for standards to be applied so that the federated endpoints established by Web services are consistent and aligned.

78


SOA Principle Interactions[Thomas Erl]

79

• Service autonomy establishes an execution environment that facilitates reuse because the service achieves increased independence and self-governance. The less dependencies a service has, the broader its reuse applicability.

• Service statelessness supports reuse because it maximizes the availability of a service and typically promotes a generic service design that defers state management and activity-specific processing outside of the service boundary.

• Service abstraction fosters reuse because it establishes the black box concept. Proprietary processing details are hidden and potential consumers are only made aware of an access point represented by a generic public interface.

• Service discoverability promotes reuse as it allows those that build consumers to search for, discover and assess services offering reusable functionality. • Service loose coupling establishes an inherent independence that frees a service from immediate ties to others. This makes it a great deal easier to realize

reuse. • Service composability is primarily possible because of reuse. The ability for new automation requirements to be fulfilled through the composition of existing

services is feasible when those services being composed are built for reuse. (It is technically possible to build a service so that its sole purpose is to be composed by another, but reuse is generally emphasized.)

Service Elicitation Processes

80

The proposed Healthcare SOA framework, analogous to the "Zachman Framework™ for enterprise architecture“, isuseful in providing completeness and familiarity within a larger methodology. However, the elicitation activity reduces the scope to three questions ("What-Who-Why“ at the contextual and conceptual levels of the Zachman Framework™.

Service Categorization

81

When building various types of services, it becomes evident that they can be categorized depending on: - the type of logic they encapsulate - the extent of reuse potential this logic has - how this logic relates to existing domains within the enterprise

As a result, there are (3) common service classifications that represent the primary service models used in SOA projects: - Entity (e.g., Information) Services - Task (e.g., Business) Services - Utility (e.g., common) Services

Direct Care Supportive Information Infrastructure Other

Service Type Definitions

82

The term "service" or “candidate service” is used as follows:• A (candidate) service is a container that can encompass collections of functions or business processes. • A service does not refer to or imply any specific implementation technology.

The following types of services might be considered:• Entity Service (e.g., Information Service) - Functional business context associated with a business entity or a collection of related business entities. (Entity services are also known as "entity-centric business services" and "business entity services".)• Utility Service (e.g., Infrastructure Service) - Functional non-business context associated with a related set of processing capabilities. (Utility services are also known as "application services," "infrastructure services," and "technology services".)•Task Service (e.g., Business Service) - Functional business context associated with a specific business process. (Task services are also known as "task-centric business services" and "business process services".) A variation of the task service is the Orchestrated Task Service which exists within an orchestration platform that imposes specific service characteristics. (Orchestrated task services are also known as "process services," "business process services,“ and "orchestration services".)

Entity Services [1]

(Information Service)

83

In just about every enterprise, there will be business model documents that define the organization’s relevant business entities. Examples of business entities include customer, employee, invoice, and claim.

The entity service model represents a business-centric service that bases its functional boundary and context on one or more related business entities. It is considered a highly reusable service because it is agnostic to most parent business processes. As a result, a single entity service can be leveraged to automate multiple parent business processes.

Entity services are also known as entity-centric business services or business entity services.

The figure on the right shows an example of an entity service. Several of its capabilities are reminiscent of traditional CRUD (create, read, update, delete) methods.


Task Services [1]

(Business Service)

84

A business service with a functional boundary directly associated with a specific parent business task or process is based on the task service model. This type of service tends to have less reuse potential and is generally positioned as the controller of a composition responsible for composing other, more process-agnostic services.

When discussing task services, one point of clarification often required is in relation to entity service capabilities. Each capability essentially encapsulates business process logic in that it carries out a sequence of steps to complete a specific task. An entity Invoice service, for example, may have an Add capability that contains process logic associated with creating a new invoice record.


How then is what a task service encapsulates different from what an entity service’s capabilities contain? The primary distinction has to do with the functional scope of the capability. The Invoice service’s Add capability is focused solely on the processing of an invoice document. To carry out this process may require that the capability logic interact with other services representing different business entities, but the functional scope of the capability is clearly associated with the functional context of the Invoice service.

If, however, we had a billing consolidation process that retrieved numerous invoice and PO records, performed various calculations, and further validated consolidation results against client history billing records, we would have process logic that spans multiple entity domains and does not fit cleanly within a functional context associated with a business entity. This would typically constitute a “parent” process in that it consists of processing logic that needs to coordinate the involvement of multiple services.

Services with a functional context defined by a parent business process or task can be developed as standalone Web services or components – or – they may represent a business process definition hosted within an orchestration platform. In the latter case, the design characteristics of the service are somewhat distinct due to the specific nature of the underlying technology. In this case, it may be preferable to qualify the service model label accordingly. This type of service is referred to as the orchestrated task service.

The example on the top right shows a task service with a sole exposed capability required to initiate its encapsulated parent business process.

Task services are also known as task-centric business services or business process services. Orchestrated task services are also known as process services, business process services, or orchestration services.

Utility Services [1]

(Agnostic Services)

85

Each of the previously described service models has a very clear focus on representing business logic. However, within the realm of automation, there is not always a need to associate logic with a business model or process. In fact, it can be highly beneficial to deliberately establish a functional context that is non-business-centric. This essentially results in a distinct, technology-oriented service layer.

The utility service model accomplishes this. It is dedicated to providing reusable, cross-cutting utility functionality, such as event logging, notification, and exception handling. It is ideally application agnostic in that it can consist of a series of capabilities that draw from multiple enterprise systems and resources, while making this functionality available within a very specific processing context.

The example on the right shows a utility service providing a set of capabilities associated with proprietary data format transformation. Utility services are also known as application services, infrastructure services, or technology services.


Focal Classes

86

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

In summary, the focal class is explicit in a business service, generally implicit in other services.

87* “Agnostic Services” are also-known-as “Common Services” or “Shared Services”

AlternativeHealthcare SOA & Standards Framework Representation

EHR-S Functions

S e r v I c e s

Orchestration BusinessServices

InformationServices

AgnosticServices

Applications TechnicalProfiles

Direct Care

Supportive

InformationInfrastructure

Other

Considering there are over 200 HL7 EHR System Functions, this may be a better layout for a spreadsheet or database. Thoughts?

87

88

Federal Technical Reference Model (TRM)

TECHNICAL REFERENCE MODEL (TRM) is a component-driven, technical framework used to categorize the standards, specifications, and technologies that support and enable the delivery of service components and capabilities.

– The Technical Reference Model (TRM) provides a foundation to categorize the standards, specifications, and technologies to support the construction, delivery, and exchange of business and application components (Service Components) that may be used and leveraged in a Component-Based or Service-Oriented Architecture. The TRM unifies existing Agency TRMs and E-Gov guidance by providing a foundation to advance the re-use of technology and component services from a government-wide perspective.

– Service Access and Delivery Refers to the collection standard and specifications to support external access, exchange, and delivery of Service Components or capabilities. This area also includes the Legislative and Regulator requirements governing the access and usage of the specific Service Component.

89

Federal Performance Reference Model (PRM)

PERFORMANCE REFERENCE MODEL (PRM) is a “reference model” or standardized framework to measure the performance of major IT investments and their contribution to program performance. The PRM has three main purposes:

– Help produce enhanced performance information to improve strategic and daily decision-making;

– Improve the alignment — and better articulate the contribution of — inputs to outputs and outcomes, thereby creating a clear “line of sight” to desired results; and

– Identify performance improvement opportunities that span traditional organizational structures and boundaries

The PRM attempts to leverage the best of existing approaches to performance measurement in the public and private sectors, including the Balanced Scorecard, Baldrige Criteria, Value Measurement Methodology, program logic models, the value chain, and the theory of constraints. In addition, the PRM was informed by what agencies are currently measuring through PART assessments, GPRA, Enterprise Architecture, and Capital Planning and Investment Control. Agencies’ use of the PRM will populate the model over time. The PRM is currently comprised of four measurement areas:

90

Federal Business Reference Model (BRM)

BUSINESS REFERENCE MODEL (BRM) is a function-driven framework for describing the business operations of the Federal Government independent of the agencies that perform them.”

The Business Reference Model provides an organized, hierarchical construct for describing the day-to-day business operations of the Federal government. While many models exist for describing organizations - org charts, location maps, etc. - this model presents the business using a functionally driven approach. The Lines of Business and Sub-functions that comprise the BRM represent a departure from previous models of the Federal government that use antiquated, stove piped, agency-oriented frameworks. The BRM is the first layer of the Federal Enterprise Architecture and it is the main viewpoint for the analysis of data, service components and technology.

91

Federal Service Component Reference Model (SRM)

SERVICE COMPONENT REFERENCE MODEL (SRM) is a business and performance-driven, functional framework that classifies Service Components with respect to how they support business and/or performance objectives.”

The SRM is intended for use to support the discovery of government-wide business and application Service Components in IT investments and assets. The SRM is structured across horizontal and vertical service domains that, independent of the business functions, can provide a leverage-able foundation to support the reuse of applications, application capabilities, components, and business services.

92

Federal Data Reference Model (DRM)

DATA REFERENCE MODEL (DRM) describes, at an aggregate level, the data and information supporting government program and business line operations. This model enables agencies to describe the types of interaction and exchanges occurring between the Federal government and citizens.

The DRM categorizes government information into greater levels of detail. It also establishes a classification for Federal data and identifies duplicative data resources. A common data model will streamline information exchange processes within the Federal government and between government and external stakeholders.

The DRM provides a standard means by which data may be described, categorized, and shared. These are reflected within each of the DRM’s three standardization areas:

– Data Description: Provides a means to uniformly describe data, thereby supporting its discovery and sharing

– Data Context: Facilitates discovery of data through an approach to the categorization of data according to taxonomies; additionally, enables the definition of authoritative data assets within a community of interest (COI)

– Data Sharing: Supports the access and exchange of data where access consists of ad-hoc requests (such as a query of a data asset), and exchange consists of fixed, re-occurring transactions between parties

93

Open Healthcare Framework (OHF)

(Formerly, IBM Health Framework)

94

OHF Glossary

OHF Framework Extensions: Similar to other projects that build on the RCP and the Eclipse Platform, we will implement extensions and additions to the RCP. UI frameworks tailored to our user community and security extensions to the OSGI runtime are examples. In addition, we see a requirement for a server plug-in framework but have not decided on an implementation.

Tools: A number of custom editors and other tools will be developed to support OHF applications. OHF is willing to collaborate with other organizations wishing to use Eclipse extensions for their own tooling.

Identity Management: Applications must keep track of users, providers, resources and patients. Since legislation now typically mandates that patients must have access to at least a subset of their medical records, patients and providers acquire both active ("user") and passive ("resource") roles at different times.

User / Context Management: The authentication of the user and cleanly maintaining the user's session throughout the application is the foundation of good security. The user's session is closely associated with the user's context, which refers to state that is maintained when users interact with healthcare applications at the point-of-use (e.g., a clinical desktop). OHF will define a context framework and interoperate with other applications using HL7's Clinical Context Management Specification (CCOW). Context management additionally includes user-centric session management required to facilitate user mobility, where session state is persisted and accessible as the user relocates.

Security and Privacy: The usual security concerns are present as well as some that are specific to healthcare, usually again driven by legislation. Support for privacy in OHF goes beyond the standard application of security methodologies to protect confidential healthcare data, it must be pervasive, e.g. procedural support for privacy and integrity (including audit facilities) should be part of the message and document processing chains. The OHF project hopes to actively collaborate with the Higgins Trust Framework Project in the Identity Management, User and Context Management, and Security and Privacy areas.

95

OHF Glossary

Health Records: The core function of most healthcare systems is to create, store, search, retrieve and present records of healthcare events. In recent years healthcare standards have increasingly focused on this area, and have enabled a common implementation of these important function points.

Interoperability: HL7 has released an updated version of the HL7 Standard, which is the primary general healthcare information standard. Both HL7 V2 - the currently implemented version - and the newly released V3 will be in use for some time, so we intend to support both in our first release. DICOM (Digital Imaging and Communications in Medicine) specifies the standards relevant to medical imaging. As the project proceeds we expect to take account of other relevant standards, such as HL7's CDA and ASTM's CCR document standards.

– A terminology service is a key component of any Healthcare system. Essentially, it is a semantic interoperability support service. There are many different terminologies in use in healthcare, both small and large (e.g. the core terminology of the SNOMED database, operated by the College of American Pathologists, contains over 357,000 healthcare concepts with unique meanings). The HL7 Common Terminology Services (CTS) defines an API for accessing terminological content. The primary initial focus of the OHF project will be to implement this infrastructure; we are hoping to work with vendors and other organizations with either expertise, IP, or both, to provide the content.

– Archetypes are static models of clinical knowledge that can be used to describe the health records; they have recently gained acceptance in the healthcare community as the "best practice" technology. OHF will work with CEN and other archetype implementers to integrate archetypes with health records services. Other forms of meta-data representation such as schema, and OWL (W3C Web Ontology Language) will also be supported.

96

Microsoft Connected Health Framework Architecture & Design Blueprint

96

97

Microsoft Connected Health Framework

Reference Architecture

97

98

MicrosoftAlignment of Business &

Technical Architecture

98

Global Justice Reference Architecture

Why we need it.

What it is.

Who is working on it.

99

System IntegrationPrinciples

– Minimize the dependencies between integrated information systems (“loose coupling”).

– Favor technologies that leverage open industry standards.– Promote the treatment of integration interfaces as sharable

enterprise assets.– Promote the one-time entry (or update) of information.

100

System IntegrationBusiness Drivers

– The enterprise will implement technology capabilities incrementally.

– Enterprise solutions will continue to exhibit a mix of commonly-provisioned and agency-unique capabilities.

– The enterprise will continue to rely on a diverse set of software platforms and development technologies.

101

Conceptual Reference Architecture

• A reference architecture establishes key concepts, relationships, and high-level components to support integration

• Identifies specific areas where we need more work, but demonstrates how everything fits together to satisfy requirements

102

Capabilities and Services

Services Service Consumers

Real-World EffectsCapabilitiesproduce

provide access to

use

seek

providersystems im

plem

ent

consumersystems

implement

103

Interfaces and Interaction

Service Interfaces

Services

Visibility

Interaction

prov

ide

acce

ss to

are the means of

depends on

is described by

are composed of

Repository

define semantics of

hosts

assis

ts

hosts

Service Models

Information Model

Behavior Model

PreviousSlide

104

Service Interaction Profiles

Service Interaction Profile Guidelines


Service Interaction Requirements

Message Exchange Patterns

Service Interfaces

Interface Description

Requirements

guid

e de

sign

and

desc

riptio

n of

Message Definition Mechanisms

govern content of

require support for

defin

e in

tero

pera

ble

impl

emen

tatio

ns o

f

PreviousSlide

105

Policies, Contracts, Agreements

Service Interfaces

Services

prov

ide

acce

ss to

Policies and Contracts

constrain use of orexpected result of using

can

be d

escr

ibed

by

Agreementscan be specified in

PreviousSlides

106

Execution Context


Service Interaction Requirements

Execution Context

Policies and Contracts

can be implemented by

can constrain

esta

blish

som

e re

quire

men

ts fo

r

PreviousSlides

107

Business Processes / Service-Capability Hierarchy

Services Service Consumers

Real-World EffectsCapabilities

Orchestration Mechanisms

TransformersRoutersOrchestrations

are types of

produce

provide access to

use

seek

com

pose

act as

iden

tify

com

mon

type

s of

standardizeimplementation

of

Business Process Models define

Enterprise Integration Patterns

PreviousSlides

108

Edge vs. Common Capabilities

Capabilities

Edge Capabilities

are types of

Common Capabilities

Functional

Non-Functional

PreviousSlides

109

110 110

Global Justice Reference Architecture Resources

• OASIS SOA Reference Model Technical Committee, www.oasis-open.org

• Scott Came, [email protected]• Tom Clarke, [email protected]• Scott Fairholm, [email protected]• Thomas Erl, Service-Oriented Architecture: concepts,

technology and design.

111

Business Software Architecture (BSA) Specified by Software Definition Framework (SDF) Supporting...

Documents

Transcript of Business Software Architecture (BSA) Specified by Software Definition Framework (SDF) Supporting...