Joint HL7 and OMG Healthcare Services Specification Project Business Software Architecture (BSA) Specified by Software Definition Framework (SDF) Supporting Integrated Requirements Design (IRD) Sets of Integrated Management Information Within Business Capabilities Lifecycle (BCL) Using H-SOA-RA Send updates to Stephen.Hufnagel.email@example.com, editor Last updated 23 Oct 07 Working Document; Not for Public Release
EXECUTIVE SUMMARY:The objective of the Software Definition Framework (SDF) is to specify software components and their services within an Enterprise Architecture (EA), also known as a Business Software Architecture (BSA). The objective of the Integrated Requirements and Design (IRD) process is to guide investment portfolio, acquisition managers and engineers with the appropriate Software Development Lifecycle (SDLC) documentation needed for the Business Capability Lifecycle (BCL) of a Business Transformation Architecture (BTA). The SDF defines a BSA that supports the SDLC by specifying IRD solution sets which become part of the BCL “Integrated Management Information” (e.g., within the center purple box of the following figure). This “Integrated Management Information” should contain a “future state” strategic architecture and a BTA transition plan composed of IRD solution sets. Both the “future state” enterprise architecture and BTA transition plan are composed of SDF views and related artifacts, as shown in the following slides. EXECUTIVE ORDER#13335 and #13410 mandate federal agencies to have interoperable Electronic Healthcare Records (EHR), as specified by the Health and Human Services (HHS) Healthcare Information Technology Standards Panel (HITSP). See the companion paper and brief, which discusses the MHS-VA standardized “Healthcare SOA Reference-Architecture (H-SOA-RA)” for categorizing, describing and constructing system functional components within a HITSP compliant Enterprise Service Oriented Architecture (SOA).
Contents • Management SOA Perspective • Technical SOA Perspective • Application SOA Perspective • Backup Slides
Goal: Healthcare SOA Reference Architecture (H-SOA-RA) Identifying Opportunities to Leverage Technology and Alleviate Redundancy or Agency IT Overlap Key Business Driver Patient Centric Processes Key Architectural Objective Standardized Technical Solutions aligned with Core Business Processes. INTEGRATION Healthcare Industry COLLABORATION VA/ DoD Interagency DoD TMA Military Services INTER-AGENCY Joining Forces to Improve Effectiveness, Efficiency, and Service delivery 4
ANATOMY OF AN ANCILLARY SYSTEM LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH IDENTITY TERMINOLOGY AUTHORIZATION SCHEDULING CORE BUSINESS SERVICES SUPPLY CHAIN (ORDER/CHARGE) DOCUMENT RECORDS MANAGEMENT s DECISION SUPPORT PERFORMANCE DATA MANAGEMENT 6
INTEGRATED REQUIREMENTS DESIGNS: Putting the H-SOA-RA Pieces Together Ancillary Systems PT/OT/SPEECH LABORATORY SPECIALTY CARE RESPIRATORY PHARMACY CARDIOLOGY RADIOLOGY DIETARY IDENTITY TERMINOLOGY Inter-Service TEST ONLY AUTHORIZATION INPATIENT SCHEDULING Federated Business Services SUPPLY CHAIN: (ORDERS/CHARGES) Core EHR Services Inter-Agency ER DOCUMENT RECORDS MANAGEMENT ASU Federated Services, may be categorized by: -- Encounter Types -- CMS billing category -- Record type -- Care setting type -- etc. DECISION SUPPORT PERFORMANCE CLINIC Across Providers OUTPATIENT OTHER DATA MANAGEMENT ANALYTIC Federated Services SUPPORT Data sets are defined for each system functional-capability-service module IT PLATFORM 7
ENTERPRISE ARCHITECTURE: THE INTEGRATION ROAD MAP s SOA EA INTEGRATION OV-6a ENTERPRISE ARCHITECTURE OV-6c SV-4 ENTERPRISE ARCHITECTURE OV-7 SV-1 OV-5 OV-2 OV-3 PLANNED, COLLABORATIVE, OPTIMIZED
s SOA BUSINESS INTEGRATION Healthcare Enterprise Architecture Best Practices Portfolio Management Standards S E C U R I T Y P R O C E S S S Y S T E M S D A T A A P P L I C A T I O N S S T A F F GOALS & STRATEGIES POLICIES & GOVERNANCE
INTEGRATED SOA ADVANTAGE RESPONSIVE INFORMED RE-USED NON-DUPLICATIVE STANDARDIZED WORKING SMART
BENEFITS Improved Information Accuracy/Availability Safe Effective Patient-centered Timely Efficient Necessary Revenue Improvement PATIENT-CENTERED CARE Rapid Response Length of Stay Reduction Reduced IT Expenditure/ Maintenance Costs
INTERAGENCY EA STANDARDIZATION IN SUPPORT OF THE WOUNDED WARRIOR GOAL: Seamless Uninterrupted Care Across the Continuum of Care H-SOA-RA IT Services DOD VA Civilian Specialty Care Acute and Recuperative Care Recuperative and Long Term Care DOD Purchased Care Walter Reed Integrated Care Planning involving Key Players Upfront Care Plan Acute Care Informed Decision Making with Timely Alerts Decision Support Consistent Care Oversight and Co-Ordination Case Management Landstuhl Timely Complete Information Records Management Critical Care Streamlined Referral Referral Combat Theater Joint Performance Review, Learning, Improvement Performance Warfighter Timely, Efficient Benefit Access Benefits Management Stabilization Care Improved Patient Monitoring/Epidemiological Analysis Trauma Registry 13
Performance Models Business Rules Business Software Architecture (BSA) MHS Strategic Vision Support the Core Mission Areas with high-quality, low-cost, aligned, interoperable and agile Healthcare Information Systems (HIS) Clinical Logistics & Readiness Financial & Budget Operations CIO Core Mission Areas Business Value Chain Segments Business Process Models Information Models Solution Architectures Service Oriented Architectures
KEY CONCEPT:Business Software Architecture (BSA)Components are Specified by theSoftware/Service Definition Framework (SDF)
Notional Time/Cost of IRD Process IRD 1.5 Define Quality Assessment Attributes Year of Execution Note: Coefficient “C” varies depending on submission size IRD 1.4 Refine Funded Solution IRD 1.3 Prioritize Solution Sets C*10 Hours C* 100 Hours C* 1000 Hours C*10,000 Hours C*100,000 Hours IRD 1.2 Conduct Enterprise Analysis of Requirements-Design Sets • COMPETING OBJECTIVES: • Minimize costs of IRD “overhead” phases 1.0, 1.1, 1.2 and 1.3 • Make changes and fix problems as early as possible • Avoid high cost changes in IRD phase 1.5 IRD 1.1 Process Submission IRD 1.0 Conduct Strategic Generation of IT Requirements IRD 1.0 IRD 1.1 IRD 1.2 IRD 1.3 IRD 1.4 IRD 1.5
Notional ROI of IRD Process Cost to make changes or fix problems C*1 C*10 C*100 C*1,000 C*10,000 10X 100X Cost of Sustainment • https://www.thedacs.com/databases/roi/display_all_facts.php?datasource=ROI&label=Cleanroom&improvement2=Cleanroom • Basili, V., McGarry, F., Page, G., Pajerski, R., Waligora, S., Zelkowitz, M., "Software Process Improvement in the NASA Software Engineering Laboratory", Technical Report CMU/SEI-94-TR-22, December 1994, Carnegie Mellon University, Pittsburgh, Pennsylvania: Software Engineering Institute. • Sherer, S. W., Kouchakdjian, A., Arnold, P. A., "Experience Using Cleanroom Software Engineering", IEEE Software, May 1996, pp. 69 - 76. IRD 1.0 IRD 1.1 I RD 1.2 IRD 1.3 I RD 1.4 IRD 1.5 Sustainment Note: Coefficient “C” varies depending on submission size Notional 5 to 10:1 ROI Six Sigma 1X 10X Cost of Software Engineering
IRD Creation of BCL “Integrated Management Information” SDF Artifacts
UML RelationshipsAmong Classes and Objects Association:a solid line represents an unspecified relationship between classes or objects; Optional open arrowheads indicate flow (e.g. messaging) Association - Composition: a solid line with an open arrowhead and a solid diamond at the tail end that represents a "has-a" relationship. The arrow points from the containing to the contained class. A composition models the notion of one object "owning" another and thus being responsible for the creation and destruction of another object. Association - Aggregation: a solid line with an open arrowhead and a hollow diamond at the tail end that represents a "has-a" relationship. The arrow points from the containing to the contained class. An aggregation models the notion that one object uses another object without "owning" it and thus is not responsible for its creation or destruction. Generalization - Inheritance: a solid line with a solid arrowhead that represents an “is-a” relationship. The arrow points from a sub-class to a super-class or from a sub-interface to its super-interface. Generalization - Implementation: a dotted line with a solid arrowhead that points from a class to the interface that it implement Generalization - Realize: a dotted line with a solid arrowhead shows that the source object implements or realizes the destination. Realize is used to express traceability in the model. Dependency: a dotted line with an open arrowhead that shows one entity depends on the behavior of another (e.g., Realization, Instantiation and Usage) client (tail) refines the source. Typical usages are to represent that one class instantiates another or uses the other as an input parameter. Message: a solid line with an open arrowhead that shows that one entity communicates with another.
Contents • Management SOA Perspective • Technical SOA Perspective • Application SOA Perspective • Backup Slides
Joint HL7 and OMG Healthcare Services Specification Project Interoperability at the Service Level Via a Standardized Healthcare Service Oriented Reference Architecture (H-SOA-RA) And Services Specification Framework (SDF) REQUESTED ACTION: Send Suggestions for Improvement to Stephen.Hufnagel.firstname.lastname@example.org John Koisch, email@example.com 18 Aug 2007 version O
BackgroundFederal Direction ‘2001 President’s E-Gov Initiativeresulted in Consolidated Health Informatics (CHI) and Federal Health Architecture (FHA) ‘2004 Executive Order (EO) #13335mandated “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.
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
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
orchestration service layer business service layer application service layer SOA LayersFocus on the Business Processes and Services [Thomas Erl] Business process layer Business Capabilities and Services Services interface layer System Components and Services Application layer Source: Service-Oriented Architecture, Thomas Erl .NET J2EE Legacy
Federated Services  • 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  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) Business Choreography Choreography Business Entity (Information) Service Types Business System Functions Infrastructure Entity (Information) Infrastructure Infrastructure Infrastructure Business Choreography NOTE: “Other” Category - The EHR-S model does NOT include Electronic Resource Planning (ERP) / Logistics and Financial components, which are needed for completeness of a military EHR.
Leveraging SOA Processing in the Enterprise Legacy SOA Business Services Application Services Information Services Infrastructure Services Choreographies (Orchestration Services)
EHR DATA REUSE THROUGH H-SOA-RAACROSS EPISODES OF CARE Previous Episode Of Care EHR Current Episode Of Care EHR IDENTITY Data Must Be Verified And Updated • Patient Demographics • Provider Demographics • Insurer Demographic Terminology • Chronic Diagnoses • Procedure History Reusable Services Document • Patient History • Summary Lists • - Medication List • - Allergy/Adverse Reaction List • - Immunization
ANATOMY OF AN ANCILLARY SYSTEM LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH IDENTITY TERMINOLOGY AUTHORIZATION SCHEDULING CORE BUSINESS SERVICES SUPPLY CHAIN (ORDER/CHARGE) DOCUMENT RECORDS MANAGEMENT s DECISION SUPPORT PERFORMANCE DATA MANAGEMENT