Embed Size (px)
Citation preview
Joint HL7 and OMG Healthcare Services Specification Project
Interoperability at the Service LevelVia a
Standardized Healthcare Service Oriented Reference Architecture
(H-SOA-RA)And
Services Specification Framework (SDF)
REQUESTED ACTION: Send Suggestions for Improvement to [email protected] John Koisch, [email protected]
18 Aug 2007 version O
Contents
1. Management SOA Perspective
2. Technical SOA Perspective
3. Application SOA Perspective
4. Backup Slides
2
Goal: Healthcare SOA Reference Architecture
(H-SOA-RA)
NationalFederated
Healthcare Industry
VA/ DoD Interagency
DoD
TMA
Military Services
INTE
GR
ATIO
N
Identifying Opportunities to Leverage Technology and Alleviate Redundancy or Agency IT Overlap
Joining Forces to Improve Effectiveness, Efficiency, and Service delivery
CO
LLA
BO
RA
TIO
N
INTER-AGENCY
Key Business DriverPatient Centric Processes
3
Key Architectural ObjectiveStandardized Technical Solutions aligned with
Core Business Processes.
Healthcare SOA & Standards
Framework HL7 System Functions
Direct Care Supportive Information Infrastructure
Other
Business Process
Value Chains
FederatedServices Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas
Core BusinessServices
Functional Areas + Focal Classes
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
Ambulatory Care Systems,
In Patient Care Systems
Logistics SystemsFinancial SystemsDecision Support
Systems
Data MartsRepositories
Business Objects
Implementation
Profiles
Integrated Healthcare Enterprise (IHE)
Profiles
Analysis Profiles Communications Profiles/Stacks
Implementation Profiles
4
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
5
IT PLATFORM
SUPPORT
ANALYTIC
DATA MANAGEMENT
PERFORMANCE
DECISION SUPPORT
RECORDS MANAGEMENT
DOCUMENT
SUPPLY CHAIN: (ORDERS/CHARGES)
SCHEDULING
AUTHORIZATION
TERMINOLOGY
IDENTITY
RADIOLO
GY
LABORATORY
PHARMACY
CLI
NIC
AS
U
T
ES
T O
NLY
O
UT
PA
TIE
NT
OT
HE
R
INP
AT
IEN
T E
R
CARDIOLO
GY
PT/O
T/SPEECH
DIETARY
SPECIALTY CARE
Ancillary Systems
Co
re E
HR
Ser
vice
sINTEGRATED
REQUIREMENTSDESIGNS: Putting the H-SOA-RA
Pieces Together
RESPIRATORY
Fed
erat
ed B
usi
nes
sS
ervi
ces
Fed
erat
edS
ervi
ces
Federated Services, may be categorized by: -- Encounter Types -- CMS billing category -- Record type -- Care setting type -- etc.
Data sets are defined for each system functional-
capability-service module 6In
ter-
Age
ncy
Inte
r-S
ervi
ceA
cros
sP
rovi
ders
ENTERPRISEARCHITECTURE
ENTERPRISE ARCHITECTURE: THE INTEGRATION ROAD MAP
PLANNED, COLLABORATIVE, OPTIMIZED
s
SOA EA INTEGRATION
SYSTEM FUNCTIONS
SYSTEM INTERFACES
OPERATIONALNODE
INFORMATIONEXCHANGES
ACTIVITIES
DATA
BUSINESS RULES
BUSINESS PROCESS
BUSINESS PROCESS
eENTERPRISE
ARCHITECTUREOV-7
OV-5
SV-1
SV-4
OV-3
OV-2
OV-6a
OV-6c
s
PROCESS
SYSTEMS
DATA
APPLICATIONS
GOALS & STRATEGIESPOLICIES & GOVERNANCE
SECURITY
STAFF
Best PracticesPortfolio Management
Standards
Healthcare Enterprise Architecture
SOA BUSINESS INTEGRATION
STANDARDIZED
NON-DUPLICATIVE
RE-USED
INFORMED
INTEGRATED
SOA A
DVANTA
GE
RESPONSIVE
WORKING SMART
SafeEffective
Patient-centeredTimely
Efficient Necessary
Staff Efficiencies
Improved Patient/Staff Satisfaction
Improved Outcomes/ Reduced Risk
PATIENT-CENTERED
CARE
Revenue Improvement
Improved Information Accuracy/Availability
Reduced IT Expenditure/Maintenance Costs
Length of Stay Reduction
BENEFITS
Rapid Response
ADDRESSING REAL BUSINESS ISSUES THROUGH H-SOA-RA
Incomplete/Inaccurate Demographic Data
(Identity Service)
Incomplete/Inaccurate Insurance Information (Authorization Service)
Unauthorized Service (Authorization Service)
Diagnosis/Procedure Coding Errors (Terminology Service)
Service Delays (Scheduling Service)
Incomplete and Inefficient Charge Capture (Supply Chain Service)
Non-indicated or Contra-indicated Services (Decision Support/Authorization Services)Delays in EHR Document Production/ Provision (Document Service)
Billing Delays and Errors (Supply Chain/ Billing/ CollectionService)
Not fully coordinated Scheduling (Scheduling Service)
Lack of fully integrated Patient Assessment and Treatment Plan
(Document Service/ Decision Support Service)
Delayed or Lack of Medical Record Access (Record Service)
INTERAGENCY EA STANDARDIZATION IN SUPPORT OF THE WOUNDED WARRIOR
GOAL: Seamless Uninterrupted Care Across the Continuum of Care
Care Plan
Decision Support
Case Management
Records Management
Referral
Performance
Benefits Management
Trauma Registry
H-SOA-RA IT Services
VA DOD
Integrated Care Planning involving Key Players Upfront
Informed Decision Making with Timely Alerts
Consistent Care Oversight and Co-Ordination
Timely Complete Information
Streamlined Referral
Joint Performance Review, Learning, Improvement
Timely, Efficient Benefit Access
Improved Patient Monitoring/Epidemiological Analysis
12
Civilian
Warfighter
Combat Theater
DOD
Landstuhl
Walter Reed Purchased Care
Recuperative and Long Term Care
Acute and Recuperative Care
AcuteCare
SpecialtyCare
CriticalCare
StabilizationCare
Contents
1. Management SOA Perspective
2. Technical SOA Perspective
3. Application SOA Perspective
4. Backup Slides
13
Joint HL7 and OMG Healthcare Services Specification Project
Interoperability at the Service LevelVia a
Standardized Healthcare Service Oriented Reference Architecture
(H-SOA-RA)And
Services Specification Framework (SDF)
REQUESTED ACTION: Send Suggestions for Improvement to [email protected] John Koisch, [email protected]
18 Aug 2007 version O
BackgroundFederal Direction
15
‘2001 President’s E-Gov Initiative resulted in Consolidated Health Informatics (CHI) and Federal Health Architecture (FHA)
‘2004 Executive Order (EO) #13335 mandated “Incentives for the Use of Health IT and Establishing the Position of the National Health IT Coordinator.” It set a ‘2014 target for US EHR interoperability.
‘2006 Executive Order (EO) #13410 “Promoting Quality and Efficient healthcare in Federal Government Administered or Sponsored healthcare Programs,” starting in Jan ‘2007.
Health and Human Services (HHS) is the designated Executive Agency to implement the Executive Orders (EOs).
Healthcare Information Technology Standards Panel (HITSP) is chartered by HHS to define the Interoperability Specifications (IS) of standards to enable the sharing of health information in a secure environment to improve healthcare.
President’s Commission on Care for America’s Returning Wounded Warriors made six patient centric recommendations to fix the MHS-VA health systems.
Joint HL7-OMG Healthcare Services Specification Project
(HSSP)
GOAL: Faster-better-cheaper interoperable-healthcare-systems resulting from consistent enterprise architectures, system acquisitions, system developments, system tests and system certifications within and among organizations.
PROBLEM: Inconsistent semantics among healthcare system users, venders, contractors and acquisition processes.
APPROACH: Standardize Healthcare SOA Reference Architecture (H-SOA-RA) based on the HL7 EHR System Functional Model (EHR-S) and commercial SOA best practices.
BENEFIT: Integrated EHR-S requirements linked to H-SOA-RA system design specifications and CCHIT certification tests will result in consistent, traceable and interoperable requirements-design specifications for procurements, developments & tests.
16
17
Situation: HealthcareService Oriented Architecture
Problem: A healthcare Service Oriented Architecture (SOA) potentially has 300-400 services and as many standards. This creates an architectural, requirements-design and configuration management challenge.
Proposed Solution: H-SOA Reference Architecture (H-SOA-RA) Horizontal: EHR System (EHR-S) Function Model– Direct Care, Supportive, Information Infrastructure, Other
Vertical: Service Layer Categories – Core Business: Identity, Terminology, Authorization, Scheduling, supply
Chain, Documents, Records Mgmt., etc.– Composite Business value chains– Information/Data: Entity Services– Utility: Agnostic/Federated Services
18
Objectives
EHR Systems Interoperability at the Service level
HITSP Compliant National Healthcare Information Exchange (NHIE)– Allow simplified Harmonization with HITSP Specifications through Compatible Architectures– Simplified differentiation between services required to be HITSP compliant and others
Facilitate Analysis by Subject Matter Experts (SME)s– Functional, Technical (e.g., system engineering), Security and Privacy
Harmonize with Stable De-facto Models– HL7 EHR System Functional Model (e.g., system function categorization)– Commercial SOA layers (e.g., Oasis SOA); Federal Enterprise Architecture (FEA)
Support Vertical Implementation Profiles– Within business areas– Across business affinity domains
Service Traceability EHR-S, HITSP and CCHIT
19 19
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
20
SOA Service ModelsPotential Service Layers [Thomas Erl]
21
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. 21
Federated Services [1]
22
Federation is a state achieved by extending SOA into the realm of service-oriented integration. A number
of key WS-* extensions provide feature-sets that support the attainment of federation. Most notable
among these are the specifications that implement the concepts of orchestration and choreography.
Establishing SOA within an enterprise does not necessarily require that you replace what you already have.
One of the most attractive aspects of this architecture is its ability to introduce unity across previously
non-federated environments. While web-services enable federation, SOA promotes this cause by
establishing and standardizing the ability to encapsulate legacy and non-legacy application logic and
by exposing it via a common, open, and standardized communications framework.
• WSRP (Web Services for Remote Portals) is the cornerstone of federated services
• SAML (Security Assertions Markup Language) is commonly used
• ALSO: WS-Security, WS-Trust, WS-Policy, WS-Federation
Additional info at: https://www120.livemeeting.com/cc/bea/viewReg
[1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07
HL7 EHR System Functional Model (EHR-S)
(> 230 System Functions in 4 level categorization
(see attached spreadsheet for full enumeration)
23
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
24
Leveraging SOA Processing in the Enterprise
BusinessServices
Information Services
InfrastructureServices
ApplicationServices
Choreographies(Orchestration Services)
Legacy
Healthcare SOA & Standards
Framework HL7 System Functions
Direct Care Supportive Information Infrastructure
Other
Business Process
Value Chains
FederatedServices Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas
Core BusinessServices
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
Ambulatory Care Systems,In Patient Care Systems
Logistics SystemsFinancial Systems
Decision Support Systems
Data MartsRepositories
Business Objects
ImplementationProfiles
Integrated Healthcare Enterprise (IHE) Profiles
Analysis Profiles Communications Profiles/Stacks
Implementation Profiles
25
26
EHR DATA REUSE THROUGH H-SOA-RAACROSS EPISODES OF CARE
• Patient Demographics• Provider Demographics• Insurer Demographic
IDENTITY
Terminology
Document
• Chronic Diagnoses• Procedure History
• Patient History• Summary Lists - Medication List - Allergy/Adverse Reaction List - Immunization
Current EpisodeOf Care EHR
Previous EpisodeOf Care EHR
Reu
sabl
e S
ervi
ces
Data Must Be Verified And Updated
SUPPLY CHAIN (ORDER/CHARGE)
ANATOMY OF AN ANCILLARY SYSTEM
AUTHORIZATION
DOCUMENT
RECORDS MANAGEMENT
DECISION SUPPORT
PERFORMANCE
DATA MANAGEMENT
SCHEDULING
IDENTITY
TERMINOLOGY
LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH
s
CO
RE
B
US
INE
SS
S
ER
VIC
ES
27
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 28In
ter-
Age
ncy
Inte
r-S
ervi
ceA
cros
sP
rovi
ders
IT PLATFORM
SUPPORT
ANALYTIC
DATA MANAGEMENT
PERFORMANCE
DECISION SUPPORT
RECORDS MANAGEMENT
DOCUMENT
SUPPLY CHAIN:
(ORDER/CHARGE)
SCHEDULING
AUTHORIZATION
TERMINOLOGY
IDENTITY
RADIOLO
GY
LABORATORY
PHARMACY
CLI
NIC
AS
U
T
ES
T O
NLY
O
UT
PA
TIE
NT
OT
HE
R
INP
AT
IEN
T
ER
CARDIOLO
GY
PT/OT/H
SPEECH
DIETARY
SPECIALT
Y CARE
AncillaryApplications
Co
re E
HR
-S S
ervi
ces
RESPIRATORY
Patient Encounter Types
Fed
erat
ed
Ser
vice
s
Composite Services, which may be categorized by: -- CMS billing category -- Record type -- Care setting type -- etc.
Data sets are defined for each service – application – encounter type module
CASE MANAGEMENT
COORDINATION
AC
RO
SS
CA
RE
CO
NT
INU
UM
AC
RO
SS
SE
RV
ICE
S (
SO
As)
Case Management Coordination Across SOAs and the Continuum
ASSESSMENTCARE
PLANNING
ORDERS &
SCHEDULING
BENEFITMANAGEMENT
AUTHORIZATION &
UTILIZATION MGT.
COMMUNICATION(FACILITATION
ADVOCACY)
DISCHARGE/TRANSFERPLANNING
REFERRAL RECORD TRANSPORT
ROLE OF CASE MANAGER
AcuteInpatient
ChronicRehab.
OutpatientWartimeTheater
ER AcuteRehab.
SkilledLongTerm Care
CustodialLongTermCare
HomeHealth
Prevention/Wellness
Care Continuum
Coordination ACROSS SOAS
cCOORDINATION ` ACROSS LEVELS OF CARE, PROVIDERS and LOCATIONS
EDUCATION.
Potential Benefits from Process Improvement through H-SOA-RA
Elimination of Process Obstacles would result in:– Length of Stay Reduction– Improved Patient Outcomes / Reduced Risk– Revenue Improvement– Staff Efficiencies– Improved Patient and Staff Satisfaction– Reduced IT Expenditure/Maintenance Costs – Improved Information Accuracy and Availability
31
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)
32
Service Definition Framework (SDF)
33
Source: Department of Defense Global Information Grid Service Strategy
As we move to federated SOA services, it is important that services across the enterprise be described using a common set of information (metadata) so that services can be consistently discovered and understood by others in the enterprise. The Service Definition Framework (SDF) shown below identifies the necessary attributes for effective description of a service.
See www.SOA.OMG.org “UML Profile and Metamodel for Services (UPMS) "SOA“ for related information.
Service Description Model
http://wiki.oasis-open.org/soa-rm/TheArchitecture/ServiceView/ServiceDescription
34
Contents
1. Management SOA Perspective (Mary Terlep lead)
2. Technical SOA Perspective (Steve Hufnagel lead)
3. Application SOA Perspective (FHA/Laura Tillery lead)
4. Backup Slides
35
Standardized Healthcare Service Oriented Reference Architecture
(H-SOA-RA)
Goal: President’s Commission on Wounded Warriors
Serve, Support, Simplify
Goal: MHS & VAInteroperability at the Service Level
Goal: HITSPTo enable the sharing of health information in a
secure environment to improve healthcare.
MHS IM/ITProgram
Goal: Healthcare SOA Reference Architecture
(H-SOA-RA)
NationalFederated
Healthcare Industry
VA/ DoD Interagency
DoD
TMA
Military Service
INTE
GR
ATIO
N
Identifying Opportunities to Leverage Technology and Alleviate Redundancy or Agency IT Overlap
Joining Forces to Improve Effectiveness, Efficiency, and Service delivery
CO
LLA
BO
RA
TIO
N
INTER-AGENCY
Key Business DriverPatient Centric Processes (e.g., Wounded Warriors)
37
Key Architectural ObjectiveStandardized Technical Solutions aligned with
Core Business Processes.
Objectives: Joint MHS & VA Healthcare SOA Reference Architecture (H-SOA-RA)
EHR Executive Orders:1. MHS-VA Electronic Medical Record (EMR) Interoperability2. Purchased Care Interoperability3. HITSP Compliance
Care for America’s Returning Wounded Warriors Executive Order: “care provided to America’s returning Global War on Terror service men and women from the time they leave the battlefield through their return to civilian life.” …
President Commission’s Recommendations [www.pccww.gov/]:1. Implement comprehensive Recovery Plans2. Restructure disability and compensation systems3. Improve care for people with post-traumatic stress disorder (PTSD) and traumatic brain injury (TBI)4. Strengthen support for families5. Transfer patient information across systems6. Support Walter Reed until closure
38
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)
39
Roadmap for Healthcare Service and Standards
Categorization using H-SOA-RA
Roadmap to HITSP Compliant EA IRDSolution Set for Wounded Warriors (WW)
National Health Information Exchange (NHIE)
1. Define Healthcare SOA Reference Architecture (H-SOA-RA) candidate service blueprint, based on Electronic Healthcare Record System Functional Model (EHR-S) categoriesand Service Oriented Architecture (SOA) system layers.
2. Map & Gap AHLTA & VISTA clinical system functions to EHR-S service functions.3. Define and analyze wounded warrior (WW) use cases using AHIC & HITSP processes.4. Define HITSP compliant WW National Healthcare Information Exchange (NHIE) Gateway
–Define AHLTA & VISTA application and federated services–Define Integrated Requirements-Design (IRD) Solution Sets from H-SOA-RA
5. Build Strategic Enterprise Architecture (EA) Transition Plan– Include EHR-S system functions, H-SOA-RA and CCHIT Test Specifications in
• Investment Portfolio (e.g., POM processes)• Procurement Contracts and Acceptance Test & Evaluation Master Plans
– Use EHR-S & H-SOA-RA as the key to CM traceability• Functional proponents, Investment Portfolio, OMB & IG reviews, NHIE Gateway• Capabilities/requirements, designs, standards, and test
7. CCHIT Certification (e.g., 2006, 2009, 2012) 40
1. Construct Use Case Scenarios focused on President’s Commission's WW recommendations – Start with AHIC Emergency Responder use case– Emphasize recommendation #5 ” transfer information among systems” [See www.pccww.gov/] – Add benefits determination and shared MHS-VA benefits repository
2. Build UML Models for WW scenarios FY07Q4– AHIC-HITSP style Use Cases and Interaction diagrams– H-SOA-RA System Solution UML Deployment diagrams – HITSP Interoperability Specification Constructs
3. Pre-Coordinate with MHS CIO, VHA & FHA FY08Q14. FHA (WW Line of Action #4 proponent) request ONC to verify & validate scenarios & models5. FHA specify WW National Healthcare Information Exchange (NHIE) Gateway
– based on EHR-S– based on H-SOA-RA– based on HITSP Interoperability Specifications
6. Build MHS & VA Strategic Architecture Transition Plan– based on WW NHIE Gateway IRD vision
7. Implement Strategic Architecture Transition Plan in Investment Portfolios
Next StepsMHS-VA Joint H-SOA-RA
Integrated Requirements Design (IRD) Solution Set for Wounded Warriors (WW)
41
FY07Q4 FY08Q1 FY08Q2 FY08Q3 FY08Q4
Optimistic Internal TimelineJoint MHS-VA using H-SOA-RA
Integrated Requirements Design (IRD)Solution Set for Wounded Warriors (WW)
National Health Information (NHIE) Gateway
Schedule is dependent on available resources!
42
OV-6C Enterprise (Business Value Chains) Process Flows
OV-7 Enterprise Logical Data Model Data Sets
SV-1/SV-2 Enterprise System Interface / Communication Descriptions
SV-4 Enterprise System Functions Descriptions
SV-4 Enterprise System Data Flows
SV-5 Enterprise Activity (OV-5) to System Function (SV-4) Mapping
SV-3/SV-6 Enterprise System to System Interface / Data Exchange Matrix
SV-8/SV-9 Enterprise System Evolution / Technology Forecast
SV-10C Enterprise Systems Event Trace Descriptions (e.g., Wounded Warrior)
TV-1 Enterprise System Standards Categorization
TV-2 Enterprise System Standards Forecast
Wounded Warrior Scenarios
43
Source:www.pccww.gov/ )
Medical Surveillance
CARE OUTSIDE THEATER
TRAINDEPLOY
ENROUTE CARE
GARRISONGARRISON
HEALTHY & FITFORCE
THEATERHOSPITALIZATION
AHLTA(Wounded Warrior)
TRAC2ES
CASUALTY PREVENTION
THEATER
AHLTA(Medical Treatment Facilities)
FORWARD RESUSCITATIVE
SURGERY
BATTALION AID STATION
Theater Medical
Data Store
Wounded WarriorContinuum of Care
VHA CARE
DISCHARGE
AHLTAClinical
Data Repository
FORCE HEALTH
PROTECTION
Medical Situation Awareness
VISTAClinical
Data Repository
VISTA(Medical Treatment Facilities) 44
INTERAGENCY EA STANDARDIZATION IN SUPPORT OF THE WOUNDED WARRIOR
GOAL: Seamless Uninterrupted Care Across the Continuum of Care
Care Plan
Decision Support
Case Management
Records Management
Referral
Performance
Benefits Management
Trauma Registry
H-SOA-RA IT Services
VA DOD
Integrated Care Planning involving Key Players Upfront
Informed Decision Making with Timely Alerts
Consistent Care Oversight and Co-Ordination
Timely Complete Information
Streamlined Referral
Joint Performance Review, Learning, Improvement
Timely, Efficient Benefit Access
Patient Monitoring and Epidemiological Analysis.
45
Civilian
Warfighter
Combat Theater
DOD
Landstuhl
Walter Reed Purchased Care
Recuperative and Long Term Care
Acute and Recuperative Care
AcuteCare
SpecialtyCare
CriticalCare
StabilizationCare
•Develop user-friendly single web portal for service members and veterans
•Continue efforts for fully interoperable information system
WOUNDED WARRIOR RECOMMENDATIONS: SOA VIEW
ASSESSMENT CARE PLAN ORDERS SCHEDULING
COMMUNICATION BENEFIT MANAGEMENT AUTHORIZATION &UTILIZATION REVIEW DOCUMENT
REFERRAL DISCHARGE/TRANSFER PLANNING
IDENTITY TERMINOLOGY
EDUCATION TRANSPORTATION
DECISION SUPPORT HUMAN RESOURCE MANAGEMENT
•Develop Corp of Recovery Coordinators•Address the shortage in medical health professionals •Expand network of experts in PTSD and TBI•Recruit and Retain Clerical/Admin. Staff•Assure adequate resources •Address shortage of mental health professionals
• Develop integrated Care Teams -Create Recovery Plans
•Clarify Objectives of DoD/VA Disability Programs•Provide lifetime TRICARE benefits for combat-injured•Restructure VA disability payments•Determine appropriate length and amounts of transition payments•Update and keep current the disability rating & Education Program•Provide VA PTSD care for Iraq and Afghanistan veterans•Cover family members under the Family Medical Leave
• Expand training regarding PTSD and TBI• Expand Caregiver Training for families
RECORD
• Create a single, comprehensive medical exam
•Develop or disseminate clinical practice guidelines
• Make patient information available to all who need it in readable form
IT SERVICES
47
Backup Slides
Abbreviations
HA DASD Traceability to HL7 EHR-S Functional Model SOA Background Slides • SOA Framework, Inventory, Design • SOA Principle Interaction • SOA Service Models (e.g., potential layers) • Service Elicitation Process • Service Categorization • Entity Services, Task Services, Utility Services • Focal Classes • Alternative Healthcare SOA & Standards Framework Representation
Federal Enterprise Architecture (FEA)• Technical Reference Architecture (TRM) • Performance Reference Model (PRM) • Business Reference Model (BRM) • Service Component Reference Model (SCRM) • Data Reference Model (DRM)
Other Healthcare Frameworks• Open Health (formerly IBM) • Microsoft
Global Justice Reference Architecture (SOA-TRM integration)
ASU Ambulatory Surgery UnitCCHIT Certification Commission for Healthcare Information TechnologyEA Enterprise ArchitectureEHR Electronic Healthcare RecordEHR-S Electronic Health Record-System Functional ModelHIT Healthcare Information Technology HITSP Health IT Standards PanelHITSP Health IT Standards PanelHRA Healthcare Reference ArchitectureIHE Integrating the Healthcare Enterprise NHIE National Health Information ExchangePPBES Planning, Programming, Budgeting and Execution System (DoD) SOA Service Oriented ArchitectureVA Veterans Administration
48
Abbreviations
Resources UsedDetailed list of H-SOA-RA Services are listed, described and referenced in a separate Excel Spreadsheet . They
were developed using the following resources
• FEA CONSOLIDATED REFERENCE MODEL VERSION 2.1
– FEA Business Reference Model (BRM)
– FEA Service Reference Model (SRM)
– FEA Technical Reference Model (TRM)
• HL7 EHR-S Model
• MHS Enterprise Architecture
• Open Healthcare Framework (OHF) (Formerly IBM Health Framework
• Microsoft Connected Health Framework Architecture and Design Blueprint
• HITSP /HL7 SOA Task Force
• Other Resources considered included:– Joint Commission on Accreditation of Hospital Standards (JCAHO)
– First Consulting Group Yellow Brick Road Document
– AMEDD Activity Mappings
– UJTLS Activity Mappings
– OASIS SOA Reference Model http://wiki.oasis-open.org/soa-rm/TheArchitecture
49
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
50
Organizational StructureTRICARE Management Activity
Acting Chief MedicalOfficer
1Dr. Smith
Acting Chief FinancialOfficer
1Mr. Middleton
Acting Chief Information
OfficerMr. Foster
Chief Force Health
Protection and Readiness
1Ms. Embrey
General CounselMr. Seaman
Dr. S. Ward CasscellsDirector, TMASenior Enlisted Advisor (SEA)
OASD (Health Affairs) & TMA
CMSgt Manuel Sarmina, USAF
Chief Health PlanOperationsMs. Storck
Acting Chief of StaffMr. Gidwani
Director, Program IntegrationMs. Speight
DirectorDoD/VA Program
Coordination OfficeMr. Cox
Regional DirectorTRO North
1Mr. Koenig
Regional DirectorTRO South
1Mr. Gill
Regional DirectorTRO West
1RADM Lescavage
MG Elder Granger, MC, USADeputy Director, TMA
DirectorTAO Latin Am/Can
1COL Franco
DirectorTAO Pacific
Mr. Chan
DirectorTAO Europe
1CAPT Niemyer
Chief Pharmaceutical
Operations2RADM McGinnis
Executive Officer
LTC Wooldridge
Deputy Chief of Staff
Vacant
TRICARE Military Education/Executive Assistant to
SEA OASD (HA) & TMAVacant
1Non-TMA2Public Health Service
51
HL7 EHR System Functional ModelVs DoD HA Deputy Secretary of Defense (DASD) Proponents
52
Acting Chief MedicalOfficer
1Dr. Smith
Acting Chief FinancialOfficer
1Mr. Middleton
Acting Chief Information
OfficerMr. Foster
Chief Force Health Protection and
Readiness1Ms. Embrey
Chief Health PlanOperationsMs. Storck
Chief Pharmaceutical
OperationsRADM McGinnis
CITPO
TMIP
RITPO
EIDS
DMLSS
TIMPO
DASDs
Personnel & Readiness(P&R) e.g., Benefits
RITPO
See associated spreadsheet for 260 detailed EHR-S functions mapped to DASDs
Other O-1 Electronic Resource Planning (ERP)
O-2 Finances
O-3 Other
Benefits Service Oriented Architecture (SOA)
and Standards Categorization (SOA&SC)
Considering that EHR-S is already mapped to CCHIT certification, Adopting the SOA&SC Framework gives traceability across
– Proponents (e.g., HA DASDs)
– PPBES processes and products
– Capabilities and their requirements
– Systems and their functions
– Technical Standards Profiles
– Technical requirements and test results
– Commercial Healthcare EHR Functions
– Commercial Service Oriented Architecture (SOA) practices 53
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.
54
[1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07)
We are proposing the use of the HL7 System Functional Model for this purpose.
SOA Design [1]
The service-oriented design process uses a set of predefined service candidates from the service inventory blueprint as a starting point from which they are shaped into actual physical service contracts.
When carrying out service-oriented design, a clear distinction is made between service candidates and services. The former represents a conceptual service that has not been implemented, whereas the latter refers to a physical service.
As shown in the following figure, the traditional (non-standardized) means by which Web service contracts are generated results in services that continue to express the proprietary nature of what they encapsulate. Creating the Web service contract prior to development allows for standards to be applied so that the federated endpoints established by Web services are consistent and aligned.
55
[1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07)
SOA Principle Interactions[Thomas Erl]
56
• Service autonomy establishes an execution environment that facilitates reuse because the service achieves increased independence and self-governance. The less dependencies a service has, the broader its reuse applicability.
• Service statelessness supports reuse because it maximizes the availability of a service and typically promotes a generic service design that defers state management and activity-specific processing outside of the service boundary.
• Service abstraction fosters reuse because it establishes the black box concept. Proprietary processing details are hidden and potential consumers are only made aware of an access point represented by a generic public interface.
• Service discoverability promotes reuse as it allows those that build consumers to search for, discover and assess services offering reusable functionality. • Service loose coupling establishes an inherent independence that frees a service from immediate ties to others. This makes it a great deal easier to realize
reuse. • Service composability is primarily possible because of reuse. The ability for new automation requirements to be fulfilled through the composition of existing
services is feasible when those services being composed are built for reuse. (It is technically possible to build a service so that its sole purpose is to be composed by another, but reuse is generally emphasized.)
Service Elicitation Processes
57
The proposed Healthcare SOA framework, analogous to the "Zachman Framework™ for enterprise architecture“, isuseful in providing completeness and familiarity within a larger methodology. However, the elicitation activity reduces the scope to three questions ("What-Who-Why“ at the contextual and conceptual levels of the Zachman Framework™.
Service Categorization
58
When building various types of services, it becomes evident that they can be categorized depending on: - the type of logic they encapsulate - the extent of reuse potential this logic has - how this logic relates to existing domains within the enterprise
As a result, there are (3) common service classifications that represent the primary service models used in SOA projects: - Entity (e.g., Information) Services - Task (e.g., Business) Services - Utility (e.g., common) Services
Direct Care Supportive Information Infrastructure Other
Service Type Definitions
59
The term "service" or “candidate service” is used as follows:• A (candidate) service is a container that can encompass collections of functions or business processes. • A service does not refer to or imply any specific implementation technology.
The following types of services might be considered:• Entity Service (e.g., Information Service) - Functional business context associated with a business entity or a collection of related business entities. (Entity services are also known as "entity-centric business services" and "business entity services".)• Utility Service (e.g., Infrastructure Service) - Functional non-business context associated with a related set of processing capabilities. (Utility services are also known as "application services," "infrastructure services," and "technology services".)•Task Service (e.g., Business Service) - Functional business context associated with a specific business process. (Task services are also known as "task-centric business services" and "business process services".) A variation of the task service is the Orchestrated Task Service which exists within an orchestration platform that imposes specific service characteristics. (Orchestrated task services are also known as "process services," "business process services,“ and "orchestration services".)
Entity Services [1]
(Information Service)
60
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)
Task Services [1]
(Business Service)
61
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.
Utility Services [1]
(Agnostic Services)
62
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)
Focal Classes
63
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.
64* “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?
64
65
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.
66
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:
67
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.
68
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.
69
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
70
Open Healthcare Framework (OHF)
(Formerly, IBM Health Framework)
71
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.
72
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.
73
Microsoft Connected Health Framework Architecture & Design Blueprint
73
74
Microsoft Connected Health Framework
Reference Architecture
74
75
MicrosoftAlignment of Business &
Technical Architecture
75
Global Justice Reference Architecture
Why we need it.
What it is.
Who is working on it.
76
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.
77
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.
78
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
79
Capabilities and Services
Services Service Consumers
Real-World EffectsCapabilitiesproduce
provide access to
use
seek
providersystems im
plem
ent
consumersystems
implement
80
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
81
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
82
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
83
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
84
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
85
Edge vs. Common Capabilities
Capabilities
Edge Capabilities
are types of
Common Capabilities
Functional
Non-Functional
PreviousSlides
86
87 87
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.
88
