Embed Size (px)
Citation preview
MHS IM/ITProgram
Goal: President’s Commission on Wounded Warriors
Serve, Support, Simplify
Goal: Standardized Healthcare Service Oriented Reference Architecture (H-SOA-RA)
To Specify HITSP Compliant Wounded WarriorsNational Healthcare Information Exchange (NHIE) Gateway
Based on HL7 EHR System Functional Model & Thomas Erl SOA Layers In Conjunction with: Healthcare Services Specification Project (HSSP)
of HL7 and OMG
REQUESTED ACTION: Send Suggestions for Improvement to MHS: [email protected] VA: John Koisch, [email protected]
7 Aug 2007 version L
Goal: HITSPTo enable the sharing of health information in a
secure environment to improve healthcare.
MHS IM/ITProgram
Background
Federal Direction
2
‘2001 President’s E-Gov Initiative resulted in Consolidated Health Informatics (CHI) and Federal Health Architecture (FHA)
‘2004 Executive Order (EO) 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) “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.
MHS IM/ITProgram
GoalsJoint MHS & VA Architecture
EHR Executive Orders (EO):1. MHS-VA Electronic Medical Record (EMR) Interoperability2. Purchased Care Interoperability3. HITSP Compliance
Care for America’s Returning Wounded Warriors EO: “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
3
MHS IM/ITProgram
GoalJoint 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.
4
MHS IM/ITProgram
GoalHealthcare 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)
5
Key Architectural ObjectiveStandardized Technical Solutions aligned with
Core Business Processes.
MHS IM/ITProgram
Executive SummaryRoadmap to HITSP Compliant EA IRD
Solution 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) 6
MHS IM/ITProgram
7
SituationHealthcare
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
MHS IM/ITProgram
8
Objectives
MHS-VA 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., Thomas Erl); Federal Enterprise Architecture (FEA)
Support Vertical Implementation Profiles– Within business areas– Across affinity domains (e.g., VA, MHS, Payers, & commercial partners)
MHS IM/ITProgram
Service Traceability EHR-S, HITSP and CCHIT
9 9
MHS IM/ITProgram
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
10
MHS IM/ITProgram
SOA Service Models
Potential Service Layers [Thomas Erl]
11
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. 11
MHS IM/ITProgram
Federated Services [1]
12
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
MHS IM/ITProgram
HL7 EHR System Functional Model (EHR-S)
(> 230 System Functions in 4 level categorization
(see attached spreadsheet for full enumeration)
13
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
MHS IM/ITProgram
14
Leveraging SOA Processing in the Enterprise
BusinessServices
Information Services
InfrastructureServices
ApplicationServices
Choreographies(Orchestration Services)
Legacy
MHS IM/ITProgram
Proposed MHS & VAHealthcare 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
Functional Areas + Focal Classes
Functional Areas + Focal Classes
Functional Areas + Focal Classes
EntityServices
Information Management
Information Management
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
ALTHA, VISTA , etc. DMLSS Data MartsRepositories
Business Objects
ImplementationProfiles
Integrated Healthcare Enterprise (IHE) Profiles
Analysis Profiles Communications Profiles/Stacks
Implementation Profiles
15
MHS IM/ITProgram
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
16
MHS IM/ITProgram
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 17In
ter-
Age
ncy
Inte
r-S
ervi
ceA
cros
sP
rovi
ders
MHS IM/ITProgram
18
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
MHS IM/ITProgram
INTERAGENCY EA STANDARDIZATION IN SUPPORT OF THE WOUNDED WARRIORS
GOAL: Seamless Uninterrupted Care Across the Continuum of Care
Care Plan
Decision Support
Case Management
Records Management
Referral
Performance
Benefits Management
Trauma Registry
Standardized H-SOA-RA
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.
19
MHS IM/ITProgram
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
20
MHS IM/ITProgram
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)
21
MHS IM/ITProgram
1. Create Use Case Scenarios focused on President’s Commission's WW recommendations – (www.pccww.gov/ )
2. Build UML Models for WW scenarios– AHIC-HITSP style Use Cases and Interaction diagrams– H-SOA-RA System Solution UML Deployment diagrams – HITSP Interoperability Specification Constructs
3. Pre-Coordinate with FHA & VA (e.g., Paul Tibbits)4. Dr. Casscellis request AHIC & HITSP verify & validate scenarios & models5. Specify WW National Healthcare Information Exchange (NHIE) Gateway
– Which specifies WW IDR Solution Set• Traceable and consistent capabilities, requirements and design alternatives
6. Build MHS & VA Strategic Architecture Transition Plan– based on WW NHIE Gateway IRD vision
• based on EHR-S• based on H-SOA-RA• based on HITSP Interoperability Specifications
7. Implement Strategic Architecture Transition Plan in Investment Portfolios
Recommended Next StepsMHS-VA Joint H-SOA-RA
Integrated Requirements Design (IRD) Solution Set for Wounded Warriors (WW)
22
Should this be the first or fourth step? First step will shift the resource burden to AHIC/HITSP & will be slower.
MHS IM/ITProgram
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
23
MHS IM/ITProgram
FY07Q4 FY08Q1 FY08Q2 FY08Q3 FY08Q4
Optimistic 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!
24
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
MHS IM/ITProgram
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) 25
MHS IM/ITProgram
Wounded Warrior Scenarios
26
Source:www.pccww.gov/ )
MHS IM/ITProgram
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)
27
Roadmap for Healthcare Service and Standards
Categorization using H-SOA-RA
MHS IM/ITProgram
28
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)
MHS IM/ITProgram
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
29
Abbreviations
MHS IM/ITProgram
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 30
MHS IM/ITProgram
Organizational Structure
TRICARE 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
31
MHS IM/ITProgram
HL7 EHR System Functional ModelVs DoD HA Deputy Secretary of Defense (DASD) Proponents
32
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
MHS IM/ITProgram
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 33
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.
MHS IM/ITProgram
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.
35
[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.
MHS IM/ITProgram
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.
36
[1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07)
MHS IM/ITProgram
SOA Principle Interactions[Thomas Erl]
37
• 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.)
MHS IM/ITProgram
Service Elicitation Processes
38
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™.
MHS IM/ITProgram
Service Categorization
39
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
MHS IM/ITProgram
Service Type Definitions
40
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".)
MHS IM/ITProgram
Entity Services [1]
(Information Service)
41
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.
[1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07)
MHS IM/ITProgram
Task Services [1]
(Business Service)
42
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.
[1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07)
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.
MHS IM/ITProgram
Utility Services [1]
(Agnostic Services)
43
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)
MHS IM/ITProgram
Focal Classes
44
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.
MHS IM/ITProgram
45* “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?
45
MHS IM/ITProgram
46
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.
MHS IM/ITProgram
47
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:
MHS IM/ITProgram
48
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.
MHS IM/ITProgram
49
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.
MHS IM/ITProgram
50
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
MHS IM/ITProgram
51
Open Healthcare Framework (OHF)
(Formerly, IBM Health Framework)
MHS IM/ITProgram
52
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.
MHS IM/ITProgram
53
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.
MHS IM/ITProgram
54
Microsoft Connected Health Framework Architecture & Design Blueprint
54
MHS IM/ITProgram
55
Microsoft Connected Health Framework
Reference Architecture
55
MHS IM/ITProgram
56
MicrosoftAlignment of Business &
Technical Architecture
56
MHS IM/ITProgram
Global Justice Reference Architecture
Why we need it.
What it is.
Who is working on it.
57
MHS IM/ITProgram
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.
58
MHS IM/ITProgram
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.
59
MHS IM/ITProgram
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
60
MHS IM/ITProgram
Capabilities and Services
Services Service Consumers
Real-World EffectsCapabilitiesproduce
provide access to
use
seek
providersystems im
plem
ent
consumersystems
implement
61
MHS IM/ITProgram
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
62
MHS IM/ITProgram
Service Interaction Profiles
Service Interaction Profile Guidelines
Service Interaction Profiles
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
63
MHS IM/ITProgram
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
64
MHS IM/ITProgram
Execution Context
Service Interaction Profiles
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
65
MHS IM/ITProgram
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
66
MHS IM/ITProgram
Edge vs. Common Capabilities
Capabilities
Edge Capabilities
are types of
Common Capabilities
Functional
Non-Functional
PreviousSlides
67
MHS IM/ITProgram
68 68
MHS IM/ITProgram
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.
69
