Business Software Architecture BSA - PowerPoint PPT Presentation

Loading...

PPT – Business Software Architecture BSA PowerPoint presentation | free to download - id: 21534f-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Business Software Architecture BSA

Description:

... from a sub-class to a super-class or from a sub-interface to its super-interface. ... Harmonize with Stable De-facto Models ... – PowerPoint PPT presentation

Number of Views:81
Avg rating:3.0/5.0
Slides: 112
Provided by: SWD874
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Business Software Architecture BSA


1
Joint HL7 and OMG Healthcare Services
Specification Project
  • 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-RA
  • Send updates to Stephen.Hufnagel.ctr_at_tma.osd.mil,
    editor
  • Last updated 23 Oct 07

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

3
Contents
  • Management SOA Perspective
  • Technical SOA Perspective
  • Application SOA Perspective
  • Backup Slides

4
Goal Healthcare SOA Reference Architecture
(H-SOA-RA)
Identifying Opportunities to Leverage Technology
and Alleviate Redundancy or Agency IT Overlap
Key Business Driver Patient Centric Processes
Key Architectural Objective Standardized
Technical Solutions aligned with Core Business
Processes.
INTEGRATION
Healthcare Industry
COLLABORATION
VA/ DoD Interagency
DoD
TMA
Military Services
INTER-AGENCY
Joining Forces to Improve Effectiveness,
Efficiency, and Service delivery
4
5
Healthcare SOA Standards Framework
5
6
ANATOMY OF AN ANCILLARY SYSTEM
LABORATORY
RADIOLOGY
PHARMACY
CARDIOLOGY
OT/PT/SPEECH
IDENTITY
TERMINOLOGY
AUTHORIZATION
SCHEDULING
CORE BUSINESS SERVICES
SUPPLY CHAIN (ORDER/CHARGE)
DOCUMENT
RECORDS MANAGEMENT
s
DECISION SUPPORT
PERFORMANCE
DATA MANAGEMENT
6
7
INTEGRATED REQUIREMENTS DESIGNS Putting the
H-SOA-RA Pieces Together
Ancillary Systems
PT/OT/SPEECH
LABORATORY
SPECIALTY CARE
RESPIRATORY
PHARMACY
CARDIOLOGY
RADIOLOGY
DIETARY
IDENTITY
TERMINOLOGY
Inter-Service
TEST ONLY
AUTHORIZATION
INPATIENT
SCHEDULING
Federated Business Services
SUPPLY CHAIN (ORDERS/CHARGES)
Core EHR Services
ER
DOCUMENT
RECORDS MANAGEMENT
ASU
Federated Services, may be categorized by --
Encounter Types -- CMS billing category --
Record type -- Care setting type -- etc.
DECISION SUPPORT
PERFORMANCE
CLINIC
OUTPATIENT OTHER
DATA MANAGEMENT
ANALYTIC
Federated Services
SUPPORT
Data sets are defined for each system
functional-capability-service module
IT PLATFORM
7
8
ENTERPRISE ARCHITECTURE THE INTEGRATION ROAD
MAP
s
SOA EA INTEGRATION
OV-6a
ENTERPRISE ARCHITECTURE
OV-6c
SV-4
ENTERPRISE ARCHITECTURE
OV-7
SV-1
OV-5
OV-2
OV-3
PLANNED, COLLABORATIVE, OPTIMIZED
9
s
SOA BUSINESS INTEGRATION
Healthcare Enterprise Architecture
Best Practices Portfolio Management Standards

S E C U R I T Y
P R O C E S S
S Y S T E M S
D A T A
A P P L I C A T I O N S

S T A F F
GOALS STRATEGIES POLICIES GOVERNANCE
10
WORKING SMART
11

BENEFITS
Improved Information Accuracy/Availability
Safe Effective Patient-centered Timely Efficient
Necessary
Revenue Improvement
PATIENT-CENTERED CARE
Rapid Response
Length of Stay Reduction
Reduced IT Expenditure/ Maintenance Costs
12
ADDRESSING REAL BUSINESS ISSUES THROUGH
H-SOA-RA
13
GOAL Seamless Uninterrupted Care Across the
Continuum of Care
INTERAGENCY EA STANDARDIZATION IN SUPPORT OF
THE WOUNDED WARRIOR
DOD
VA
Civilian
Recuperative and Long Term Care
Acute and Recuperative Care
Specialty Care
Purchased Care
Walter Reed
  • H-SOA-RA IT Services

Integrated Care Planning involving Key Players
Upfront
Care Plan
Acute Care
Informed Decision Making with Timely Alerts
Decision Support
Consistent Care Oversight and Co-Ordination
Case Management
Landstuhl
Timely Complete Information
Records Management
Critical Care
Streamlined Referral
Referral
Combat Theater
Joint Performance Review, Learning, Improvement
Performance
Warfighter
Timely, Efficient Benefit Access
Benefits Management
Stabilization Care
Improved Patient Monitoring/Epidemiological
Analysis
Trauma Registry
13
14
(No Transcript)
15
Business Software Architecture (BSA)
MHS Strategic Vision
Support the Core Mission Areas with high-quality,
low-cost, aligned, interoperable and agile
Healthcare Information Systems (HIS)
Core Mission Areas
Business Value Chain Segments
16
KEY CONCEPT Business Software Architecture
(BSA) Components are Specified by
the Software/Service Definition Framework (SDF)
17
Notional Time/Cost of IRD Process
IRD 1.5 Define Quality Assessment Attributes

Year of Execution ?
IRD 1.4 Refine Funded Solution
Note Coefficient C varies depending on
submission size
IRD 1.3 Prioritize Solution Sets
C10 Hours C 100 Hours C 1000 Hours
C10,000 Hours C100,000 Hours
IRD 1.2 Conduct Enterprise Analysis of
Requirements-Design Sets
  • 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

IRD 1.1 Process Submission
IRD 1.0 Conduct Strategic Generation of IT
Requirements
IRD 1.0 IRD 1.1 IRD
1.2 IRD 1.3 IRD 1.4
IRD 1.5
18
Notional ROI of IRD Process
Cost to make changes or fix problems
C1 C10 C100 C1,000 C10,000

10X 100X Cost of
Sustainment
  • https//www.thedacs.com/databases/roi/display_all_
    facts.php?datasourceROIlabelCleanroomimproveme
    nt2Cleanroom
  • 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.

IRD 1.0 IRD 1.1 I RD 1.2 IRD 1.3 I RD
1.4 IRD 1.5 Sustainment
Note Coefficient C varies depending on
submission size
Notional 5 to 101 ROI
? Six Sigma
1X 10X Cost of
Software Engineering
19
IRD Creation of BCL Integrated Management
Information SDF Artifacts
20
DODAF
SDF
21
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
  • The Business View supports concepts such as
    Capability which is further detailed by
    Processes, Subprocesses, Elementary Processes.
  • 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.
  • 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.
  •  
  •  
  •  
  •  
  •  

22
(No Transcript)
23
Minimum Essential Data Set for each IRD Phases
24
Minimum Essential Data Set for each IRD Phases
25
Minimum Essential Data Set for each IRD Phases
26
UML Relationships Among Classes and Objects
  • 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.

27
(No Transcript)
28
(No Transcript)
29
(No Transcript)
30
(No Transcript)
31
(No Transcript)
32
(No Transcript)
33
(No Transcript)
34
(No Transcript)
35
(No Transcript)
36
Contents
  • Management SOA Perspective
  • Technical SOA Perspective
  • Application SOA Perspective
  • Backup Slides

37
Joint HL7 and OMG Healthcare Services
Specification Project
  • Interoperability at the Service Level
  • Via a
  • Standardized Healthcare Service Oriented
    Reference Architecture (H-SOA-RA)
  • And
  • Services Specification Framework (SDF)
  • REQUESTED ACTION Send Suggestions for
    Improvement to
  • Stephen.Hufnagel.ctr_at_tma.osd.mil
  • John Koisch, john.koisch_at_va.gov
  • 18 Aug 2007 version O

38
Background Federal Direction
2001 Presidents 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. Presidents
Commission on Care for Americas Returning
Wounded Warriors made six patient centric
recommendations to fix the MHS-VA health systems.
39
Joint HL7-OMG Healthcare Services Specification
Project (HSSP)
  • GOAL Faster-better-cheaper interoperable-healthca
    re-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.

40
Situation Healthcare Service 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

42
Service Traceability EHR-S, HITSP and CCHIT
42
43
SOA Layers Focus on the Business Processes and
Services Thomas Erl
Business process layer
Business Capabilities and Services
Services interface layer
System Components and Services
Application layer
Source Service-Oriented Architecture, Thomas Erl
.NET
J2EE
Legacy
44
SOA Service Models Potential Service Layers
Thomas Erl
44
45
Federated Services 1
  •  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
46
HL7 EHR System Functional Model (EHR-S) (gt 230
System Functions in 4 level categorization (see
attached spreadsheet for full enumeration)
Business
Choreography
Choreography
Business
Entity (Information)
Service Types
Business
System Functions
Infrastructure
Entity (Information)
Infrastructure
Infrastructure
Infrastructure
Business
Choreography
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.
47
Leveraging SOA Processing in the Enterprise
SOA
48
Healthcare SOA Standards Framework
49
EHR DATA REUSE THROUGH H-SOA-RA ACROSS EPISODES
OF CARE
Current Episode Of Care EHR
Previous Episode Of Care EHR
IDENTITY
Data Must Be Verified And Updated
  • Patient Demographics
  • Provider Demographics
  • Insurer Demographic

Terminology
  • Chronic Diagnoses
  • Procedure History

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

50
ANATOMY OF AN ANCILLARY SYSTEM
LABORATORY
RADIOLOGY
PHARMACY
CARDIOLOGY
OT/PT/SPEECH
IDENTITY
TERMINOLOGY
AUTHORIZATION
SCHEDULING
CORE BUSINESS SERVICES
SUPPLY CHAIN (ORDER/CHARGE)
DOCUMENT
RECORDS MANAGEMENT
s
DECISION SUPPORT
PERFORMANCE
DATA MANAGEMENT
51
INTEGRATED REQUIREMENTS DESIGNS Putting the
H-SOA-RA Pieces Together
Ancillary Systems
PT/OT/SPEECH
LABORATORY
SPECIALTY CARE
RESPIRATORY
PHARMACY
CARDIOLOGY
RADIOLOGY
DIETARY
IDENTITY
TERMINOLOGY
Inter-Service
TEST ONLY
AUTHORIZATION
INPATIENT
SCHEDULING
Federated Business Services
SUPPLY CHAIN (ORDERS/CHARGES)
Core Business Services
ER
DOCUMENT
RECORDS MANAGEMENT
ASU
Federated Services, may be categorized by --
Encounter Types -- CMS billing category --
Record type -- Care setting type -- etc.
DECISION SUPPORT
PERFORMANCE
CLINIC
OUTPATIENT OTHER
DATA MANAGEMENT
ANALYTIC
Agnostic Services
SUPPORT
Data sets are defined for each system
functional-capability-service module
IT PLATFORM
52
CASE MANAGEMENT
ACROSS CARE CONTINUUM
ACROSS SERVICES (SOAs)
COORDINATION
53
Case Management Coordination Across SOAs and
the Continuum
c
COORDINATION ACROSS LEVELS OF CARE,
PROVIDERS and LOCATIONS
Skilled Long Term Care
Custodial Long Term Care
Prevention/ Wellness
Acute Inpatient
Chronic Rehab.
Wartime Theater
Acute Rehab.
Home Health
Outpatient
ER

Care Continuum
Coordination ACROSS SOAS
ORDERS SCHEDULING
AUTHORIZATION UTILIZATION MGT.
DISCHARGE/ TRANSFER PLANNING
COMMUNICATION (FACILITATION ADVOCACY)
BENEFIT MANAGEMENT
CARE PLANNING
ASSESSMENT
REFERRAL
TRANSPORT
EDUCATION.
RECORD
ROLE OF CASE MANAGER
54
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

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

56
Service Definition Framework (SDF)
  • 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.

Source Department of Defense Global Information
Grid Service Strategy
See www.SOA.OMG.org UML Profile and Metamodel
for Services (UPMS) "SOA for related information.
57
Service Description Model http//wiki.oasis-open.
org/soa-rm/TheArchitecture/ServiceView/ServiceDesc
ription
58
Contents
  • Management SOA Perspective (Mary Terlep lead)
  • Technical SOA Perspective (Steve Hufnagel lead)
  • Application SOA Perspective (FHA/Laura Tillery
    lead)
  • Backup Slides

59
Standardized Healthcare Service Oriented
Reference Architecture (H-SOA-RA)
Goal HITSP To enable the sharing of health
information in a secure environment to improve
healthcare.
  • Goal Presidents Commission on Wounded
    Warriors Serve, Support, Simplify
  • Goal MHS VA Interoperability at the Service
    Level

60
Goal Healthcare SOA Reference Architecture
(H-SOA-RA)
Identifying Opportunities to Leverage Technology
and Alleviate Redundancy or Agency IT Overlap
Key Business Driver Patient Centric Processes
(e.g., Wounded Warriors)
Key Architectural Objective Standardized
Technical Solutions aligned with Core Business
Processes.
INTEGRATION
Healthcare Industry
COLLABORATION
VA/ DoD Interagency
DoD
TMA
Military Service
INTER-AGENCY
Joining Forces to Improve Effectiveness,
Efficiency, and Service delivery
61
Objectives Joint MHS VA Healthcare SOA
Reference Architecture (H-SOA-RA)
  • EHR Executive Orders
  • MHS-VA Electronic Medical Record (EMR)
    Interoperability
  • Purchased Care Interoperability
  • HITSP Compliance
  • Care for Americas Returning Wounded Warriors
    Executive Order care provided to Americas
    returning Global War on Terror service men and
    women from the time they leave the battlefield
    through their return to civilian life. …
  • President Commissions Recommendations
    www.pccww.gov/
  • Implement comprehensive Recovery Plans
  • Restructure disability and compensation systems
  • Improve care for people with post-traumatic
    stress disorder (PTSD) and traumatic brain injury
    (TBI)
  • Strengthen support for families
  • Transfer patient information across systems
  • Support Walter Reed until closure

62
Roadmap for Healthcare Service and Standards
Categorization using H-SOA-RA
  • Recommended Roadmap (not in order concurrency is
    desirable)
  • Harmonize SOASC 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)
  • Validate with Open/IBM Microsoft Healthcare
    Frameworks (slides 43-48) done
  • Test the SOASC 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
  • Wounded Warrior (WW) Integrated
    Requirements-Design (IRD) for MHS-VA NHIE Gateway
  • Validate WW NHIE IRD with MHS VA Subject Matter
    Experts (SME)
  • Standardize H-SOA-RA as guideline through HL7 SOA
    SIG
  • Joint MHS-VA WW NHIE Gateway standardized as
    Federal Health Architecture (FHA)

63
Roadmap to HITSP Compliant EA IRD Solution Set
for Wounded Warriors (WW) National Health
Information Exchange (NHIE)
  • Define Healthcare SOA Reference Architecture
    (H-SOA-RA) candidate service blueprint,
  • based on Electronic Healthcare Record System
    Functional Model (EHR-S) categories
  • and Service Oriented Architecture (SOA) system
    layers.
  • Map Gap AHLTA VISTA clinical system
    functions to EHR-S service functions.
  • Define and analyze wounded warrior (WW) use cases
    using AHIC HITSP processes.
  • 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
  • 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
  • CCHIT Certification (e.g., 2006, 2009, 2012)

64
Next Steps MHS-VA Joint H-SOA-RA Integrated
Requirements Design (IRD) Solution Set for
Wounded Warriors (WW)
  • Construct Use Case Scenarios focused on
    Presidents 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
  • 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
  • Pre-Coordinate with MHS CIO, VHA FHA FY08Q1
  • FHA (WW Line of Action 4 proponent) request ONC
    to verify validate scenarios models
  • FHA specify WW National Healthcare Information
    Exchange (NHIE) Gateway
  • based on EHR-S
  • based on H-SOA-RA
  • based on HITSP Interoperability Specifications
  • Build MHS VA Strategic Architecture Transition
    Plan
  • based on WW NHIE Gateway IRD vision
  • Implement Strategic Architecture Transition Plan
    in Investment Portfolios

65
Optimistic Internal Timeline Joint MHS-VA using
H-SOA-RA Integrated Requirements Design
(IRD) Solution Set for Wounded Warriors
(WW) National Health Information (NHIE) Gateway
FY07Q4 FY08Q1 FY08Q2
FY08Q3 FY08Q4
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 Enterpr
ise System Evolution / Technology
Forecast SV-10C Enterprise Systems Event Trace
Descriptions (e.g., Wounded Warrior) TV-1 Enterpr
ise System Standards Categorization TV-2 Enterpri
se System Standards Forecast
Schedule is dependent on available resources!
66
Wounded Warrior Scenarios
Source www.pccww.gov/ )
67
Wounded Warrior Continuum of Care
AHLTA (Wounded Warrior)
AHLTA (Medical Treatment Facilities)
CASUALTY PREVENTION
DEPLOY
TRAIN
BATTALION AID STATION
Theater Medical Data Store
AHLTA Clinical Data Repository
Medical Surveillance
FORWARD RESUSCITATIVE SURGERY
GARRISON
THEATER
FORCE HEALTH PROTECTION
CARE OUTSIDE THEATER
DISCHARGE
Medical Situation Awareness
THEATER HOSPITALIZATION
VISTA Clinical Data Repository
ENROUTE CARE
VHA CARE
TRAC2ES
VISTA (Medical Treatment Facilities)
68
GOAL Seamless Uninterrupted Care Across the
Continuum of Care
INTERAGENCY EA STANDARDIZATION IN SUPPORT OF
THE WOUNDED WARRIOR
DOD
VA
Civilian
Recuperative and Long Term Care
Acute and Recuperative Care
Specialty Care
Walter Reed
Purchased Care
  • H-SOA-RA IT Services

Integrated Care Planning involving Key Players
Upfront
Care Plan
Acute Care
Informed Decision Making with Timely Alerts
Decision Support
Consistent Care Oversight and Co-Ordination
Case Management
Landstuhl
Timely Complete Information
Records Management
Critical Care
Streamlined Referral
Referral
Combat Theater
Joint Performance Review, Learning, Improvement
Performance
Warfighter
Timely, Efficient Benefit Access
Benefits Management
Stabilization Care
Patient Monitoring and Epidemiological Analysis.
Trauma Registry
69
WOUNDED WARRIOR RECOMMENDATIONS SOA VIEW
ASSESSMENT
CARE PLAN
ORDERS
SCHEDULING
  • Develop integrated Care Teams
  • -Create Recovery Plans



REFERRAL

DISCHARGE/TRANSFER PLANNING
TRANSPORTATION
EDUCATION
  • Expand training regarding PTSD and TBI
  • Expand Caregiver Training for families

COMMUNICATION
BENEFIT MANAGEMENT
AUTHORIZATION UTILIZATION REVIEW
DOCUMENT
  • 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
  • Create a single, comprehensive medical
  • exam

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





IDENTITY
TERMINOLOGY
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 or disseminate clinical practice
  • guidelines

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)

71
Abbreviations
  • ASU Ambulatory Surgery Unit
  • CCHIT Certification Commission for Healthcare
    Information Technology
  • EA Enterprise Architecture
  • EHR Electronic Healthcare Record
  • EHR-S Electronic Health Record-System Functional
    Model
  • HIT Healthcare Information Technology
  • HITSP Health IT Standards Panel
  • HITSP Health IT Standards Panel
  • HRA Healthcare Reference Architecture
  • IHE Integrating the Healthcare Enterprise
  • NHIE National Health Information Exchange
  • PPBES Planning, Programming, Budgeting and
    Execution System (DoD)
  • SOA Service Oriented Architecture
  • VA Veterans Administration

72
Resources Used Detailed 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-ope
    n.org/soa-rm/TheArchitecture

73
Integrated Requirements-Design Lexical Semantic
Consistency EA Traceability resulting from
EHR-S as H-SOA-RA Foundation
Strategic capabilities map to EHR-S system
functions EHR-S Functions map to
Operational Activities (OV-5) EHR-S Functions
map to Functional Requirements EHR-S
Functions map to H-SOA-RA Services Systems
decompose into consistent traceable sets of --
EHR-S System Functional Capabilities -- H-SOA-RA
services
DODAF Enterprise Architecture View BASED
ON OV-6C Enterprise (Business Value Chains)
Process Flows EHR-S lexicon OV-7 Enterprise
Logical Data Model Data Sets EHR-S SV-1/SV-2 En
terprise System Interface / Communication
Descriptions H-SOA-RA HITSP SV-4 Enterprise
System Functions Descriptions EHR-S SV-4 Enterpr
ise System Data Flows H-SOA-RA OV-3 info
flows SV-5 Enterprise Activity (OV-5) to System
Function (SV-4) Mapping EHR-S
H-SOA-RA SV-3/SV-6 Enterprise System to System
Interface / Data Exchange Matrix SV-1, SV-4, OV-7
HITSP IS SV-8/SV-9 Enterprise System Evolution
/ Technology Forecast H-SOA-RA CCHIT, EA
Plan SV-10C Enterprise Systems Event Trace
Descriptions (e.g., Wounded Warrior) OV-6C, SV-5
SV-6 TV-1 Enterprise System Standards
Categorization H-SOA-RA TV-2 Enterprise System
Standards Forecast H-SOA-RA EA Transition
Plan
74
Organizational Structure TRICARE Management
Activity
Dr. S. Ward Casscells Director, TMA
Senior Enlisted Advisor (SEA) OASD (Health
Affairs) TMA CMSgt Manuel Sarmina, USAF
General Counsel Mr. Seaman
MG Elder Granger, MC, USA Deputy Director, TMA
Acting Chief of Staff Mr. Gidwani
TRICARE Military Education/Executive Assistant
to SEA OASD (HA) TMA Vacant
Deputy Chief of Staff Vacant
Executive Officer LTC Wooldridge
Chief Pharmaceutical Operations 2RADM
McGinnis
Chief Health Plan Operations Ms. Storck
Acting Chief Medical Officer 1Dr. Smith
Acting Chief Financial Officer 1Mr. Middleton
Acting Chief Information Officer Mr. Foster
Chief Force Health Protection and Readiness 1Ms.
Embrey
Director, Program Integration Ms. Speight
Director DoD/VA Program Coordination Office Mr.
Cox
Regional Director TRO North 1Mr. Koenig
Regional Director TRO South 1Mr. Gill
Regional Director TRO West 1RADM Lescavage
Director TAO Latin Am/Can 1COL Franco
Director TAO Pacific Mr. Chan
Director TAO Europe 1CAPT Niemyer
1Non-TMA 2Public Health Service
75
HL7 EHR System Functional Model Vs DoD HA Deputy
Secretary of Defense (DASD) Proponents
See associated spreadsheet for 260 detailed
EHR-S functions mapped to DASDs
DASDs
Acting Chief Medical Officer 1Dr. Smith
CITPO
RITPO
Chief Force Health Protection and Readiness 1Ms.
Embrey
TMIP
DMLSS
Acting Chief Financial Officer 1Mr. Middleton
RITPO
EIDS
Acting Chief Information Officer Mr. Foster
TIMPO
Chief Health Plan Operations Ms. Storck
Chief Pharmaceutical Operations RADM McGinnis
Personnel Readiness (PR) e.g., Benefits
76
Benefits Service Oriented Architecture (SOA) and
Standards Categorization (SOASC)
  • Considering that EHR-S is already mapped to CCHIT
    certification, Adopting the SOASC 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

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

We are proposing the use of the HL7 System
Functional Model for this purpose.
1 SOA Principles of Service Design, by Thomas
Erl, Prentice Hall, July 07)
78
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.

1 SOA Principles of Service Design, by Thomas
Erl, Prentice Hall, July 07)
79
SOA Principle Interactions Thomas Erl
  • 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.)

80
Service Elicitation Processes
The proposed Healthcare SOA framework, analogous
to the "Zachman Framework for enterprise
architecture, is useful 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.
81
Service Categorization
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
Information Infrastructure
Direct Care
Supportive
Other
82
Service Type Definitions
  • 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".)

83
Entity Services 1 (Information Service)
In just about every enterprise, there will be
business model documents that define the
organizations 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.
1 SOA Principles of Service Design, by Thomas
Erl, Prentice Hall, July 07)
84
Task Services 1 (Business Service)
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 services
capabilities contain? The primary distinction has
to do with the functional scope of the
capability. The Invoice services 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.
1 SOA Principles of Service Design, by Thomas
Erl, Prentice Hall, July 07)
85
Utility Services 1 (Agnostic Services)
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.
1 SOA Principles of Service Design, by Thomas
Erl, Prentice Hall, July 07)
86
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).   In summary, the focal class is
explicit in a business service, generally
implicit in other services.
87
Alternative Healthcare SOA Standards Framework
Representation
Considering there are over 200 HL7 EHR System
Functions, this may be a better layout for a
spreadsheet or database. Thoughts?
87
Agnostic Services are also-known-as Common
Services or Shared Services
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, applica
About PowerShow.com