Joint HL7 and OMG Healthcare Services Specification Project

1. Joint HL7 and OMG Healthcare Services Specification Project Business Software Architecture (BSA) Specified by Software Definition Framework (SDF) Supporting Integrated Requirements Design (IRD) Sets of Integrated Management Information Within Business Capabilities Lifecycle (BCL) Using H-SOA-RA Send updates to Stephen.Hufnagel.ctr@tma.osd.mil, editor Last updated 23 Oct 07 Working Document; Not for Public Release

2. EXECUTIVE SUMMARY:The objective of the Software Definition Framework (SDF) is to specify software components and their services within an Enterprise Architecture (EA), also known as a Business Software Architecture (BSA). The objective of the Integrated Requirements and Design (IRD) process is to guide investment portfolio, acquisition managers and engineers with the appropriate Software Development Lifecycle (SDLC) documentation needed for the Business Capability Lifecycle (BCL) of a Business Transformation Architecture (BTA). The SDF defines a BSA that supports the SDLC by specifying IRD solution sets which become part of the BCL “Integrated Management Information” (e.g., within the center purple box of the following figure). This “Integrated Management Information” should contain a “future state” strategic architecture and a BTA transition plan composed of IRD solution sets. Both the “future state” enterprise architecture and BTA transition plan are composed of SDF views and related artifacts, as shown in the following slides. EXECUTIVE ORDER#13335 and #13410 mandate federal agencies to have interoperable Electronic Healthcare Records (EHR), as specified by the Health and Human Services (HHS) Healthcare Information Technology Standards Panel (HITSP). See the companion paper and brief, which discusses the MHS-VA standardized “Healthcare SOA Reference-Architecture (H-SOA-RA)” for categorizing, describing and constructing system functional components within a HITSP compliant Enterprise Service Oriented Architecture (SOA).

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

4. Goal: Healthcare SOA Reference Architecture (H-SOA-RA) Identifying Opportunities to Leverage Technology and Alleviate Redundancy or Agency IT Overlap Key Business Driver Patient Centric Processes Key Architectural Objective Standardized Technical Solutions aligned with Core Business Processes. INTEGRATION Healthcare Industry COLLABORATION VA/ DoD Interagency DoD TMA Military Services INTER-AGENCY Joining Forces to Improve Effectiveness, Efficiency, and Service delivery 4

5. Healthcare SOA & Standards Framework 5

6. ANATOMY OF AN ANCILLARY SYSTEM LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH IDENTITY TERMINOLOGY AUTHORIZATION SCHEDULING CORE BUSINESS SERVICES SUPPLY CHAIN (ORDER/CHARGE) DOCUMENT RECORDS MANAGEMENT s DECISION SUPPORT PERFORMANCE DATA MANAGEMENT 6

7. INTEGRATED REQUIREMENTS DESIGNS: Putting the H-SOA-RA Pieces Together Ancillary Systems PT/OT/SPEECH LABORATORY SPECIALTY CARE RESPIRATORY PHARMACY CARDIOLOGY RADIOLOGY DIETARY IDENTITY TERMINOLOGY Inter-Service TEST ONLY AUTHORIZATION INPATIENT SCHEDULING Federated Business Services SUPPLY CHAIN: (ORDERS/CHARGES) Core EHR Services 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

8. ENTERPRISE ARCHITECTURE: THE INTEGRATION ROAD MAP s SOA EA INTEGRATION OV-6a ENTERPRISE ARCHITECTURE OV-6c SV-4 ENTERPRISE ARCHITECTURE OV-7 SV-1 OV-5 OV-2 OV-3 PLANNED, COLLABORATIVE, OPTIMIZED

9. s SOA BUSINESS INTEGRATION Healthcare Enterprise Architecture Best Practices Portfolio Management Standards S E C U R I T Y P R O C E S S S Y S T E M S D A T A A P P L I C A T I O N S S T A F F GOALS & STRATEGIES POLICIES & GOVERNANCE

10. INTEGRATED SOA ADVANTAGE RESPONSIVE INFORMED RE-USED NON-DUPLICATIVE STANDARDIZED WORKING SMART

11. BENEFITS Improved Information Accuracy/Availability Safe Effective Patient-centered Timely Efficient Necessary Revenue Improvement PATIENT-CENTERED CARE Rapid Response Length of Stay Reduction Reduced IT Expenditure/ Maintenance Costs

12. ADDRESSING REAL BUSINESS ISSUES THROUGH H-SOA-RA

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

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

16. KEY CONCEPT:Business Software Architecture (BSA)Components are Specified by theSoftware/Service Definition Framework (SDF)

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

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

19. IRD Creation of BCL “Integrated Management Information” SDF Artifacts

20. SDF DODAF

21. High Level Overview of Future State Framework and its use within the IRD process The future state architecture group has developed a first version of a Future State Framework (the “Framework” hereafter) to be followed and complemented by appropriate Future State architecture content and supporting artifacts. The Framework, while having a COTS version as a starting point, is being adapted to MHS needs. It includes a series of interrelated “views” which are defined in an UML model. The Framework supports the IRD process and the MHS Enterprise Architecture (EA).   Central to the Framework is the support for Requirements-Design Sets from the from the capability/change request inception, through acquisition and deployment. There are three views which are meant to be extensively used in the initial IRD phases: Business View, Solution View, Software Specification View. Each view should increasingly become more detailed as the IRD process advances towards acquisition and later on towards deployment: • The Business View supports concepts such as Capability which is further detailed by Processes, Subprocesses, Elementary Processes. • The Solution View is defined in terms of Use Cases involving Actors and Use Case Steps. Use cases may be composites of other use cases and a set of requirements quite often is described as a collection of use cases. • The Software Specification View relies on concepts which include Transaction. A transaction can further contain transactions at increasingly lower levels.  These three views may be linked at a higher level (Capabilities, Processes, Use case are supported by some software specifications) but they may be further linked at various lower levels by appropriate choices of transactions associated to use case steps or elementary processes. Thus in a Requirement-Design set one may choose to pair in a flexible manner elements from the requirement side with elements from the design side, maintaining visibility and understanding for all stakeholders involved. One can also control the cost of the IRD process by calibrating the level of details of the required views at various decision points during the IRD process starting with the Triage step and continuing through the investment decision phase and further through acquisition, deployment and other phases deemed necessary.  A completed IRD package for acquisition purposes will have also (partial and incomplete) Framework Implementation, Deployment and Runtime views covering constraints, compliance and other aspects (such as network and communications specifications). These views will be completed after the acquisition phase by contractors, vendors and other entities as they become involved during the software development and deployment lifecycle.  The Framework views aim to allow for the recording of information sufficient for deriving various compliance artifacts (such as DoDAF OVs and SVs). The Framework needs to be extended in several directions including the areas of: Security, Testing, Error Handling, Federation.

23. Minimum Essential Data Set for each IRD Phases

24. Minimum Essential Data Set for each IRD Phases

25. Minimum Essential Data Set for each IRD Phases

26. UML 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.

36. Contents • Management SOA Perspective • Technical SOA Perspective • Application SOA Perspective • Backup Slides

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

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

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

40. Situation: HealthcareService Oriented Architecture Problem:A healthcare Service Oriented Architecture (SOA) potentially has 300-400 services and as many standards. This creates an architectural, requirements-design and configuration management challenge. Proposed Solution:H-SOA Reference Architecture (H-SOA-RA) Horizontal:EHR System (EHR-S) Function Model • Direct Care, Supportive, Information Infrastructure, Other Vertical:Service Layer Categories • Core Business: Identity, Terminology, Authorization, Scheduling, supply Chain, Documents, Records Mgmt., etc. • Composite Business value chains • Information/Data: Entity Services • Utility: Agnostic/Federated Services

41. Objectives EHR Systems Interoperability at the Service level HITSP Compliant National Healthcare Information Exchange (NHIE) • Allow simplified Harmonization with HITSP Specifications through Compatible Architectures • Simplified differentiation between services required to be HITSP compliant and others Facilitate Analysis by Subject Matter Experts (SME)s • Functional, Technical (e.g., system engineering), Security and Privacy Harmonize with Stable De-facto Models • HL7 EHR System Functional Model (e.g., system function categorization) • Commercial SOA layers (e.g., Oasis SOA); Federal Enterprise Architecture (FEA) Support Vertical Implementation Profiles • Within business areas • Across business affinity domains

42. Service TraceabilityEHR-S, HITSP and CCHIT 42

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

44. SOA Service ModelsPotential Service Layers [Thomas Erl] 44

45. Federated Services [1] • Federation is a state achieved by extending SOA into the realm of service-oriented integration. A number of key WS-* extensions provide feature-sets that support the attainment of federation. Most notable among these are the specifications that implement the concepts of orchestration and choreography. • Establishing SOA within an enterprise does not necessarily require that you replace what you already have. One of the most attractive aspects of this architecture is its ability to introduce unity across previously non-federated environments. While web-services enable federation, SOA promotes this cause by establishing and standardizing the ability to encapsulate legacy and non-legacy application logic and by exposing it via a common, open, and standardized communications framework. • WSRP (Web Services for Remote Portals) is the cornerstone of federated services • SAML (Security Assertions Markup Language) is commonly used • ALSO: WS-Security, WS-Trust, WS-Policy, WS-Federation • Additional info at: https://www120.livemeeting.com/cc/bea/viewReg [1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07

46. HL7 EHR System Functional Model (EHR-S)(> 230 System Functions in 4 level categorization(see attached spreadsheet for full enumeration) Business Choreography Choreography Business Entity (Information) Service Types Business System Functions Infrastructure Entity (Information) Infrastructure Infrastructure Infrastructure Business Choreography NOTE: “Other” Category - The EHR-S model does NOT include Electronic Resource Planning (ERP) / Logistics and Financial components, which are needed for completeness of a military EHR.

47. Leveraging SOA Processing in the Enterprise Legacy SOA Business Services Application Services Information Services Infrastructure Services Choreographies (Orchestration Services)

48. Healthcare SOA & Standards Framework

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

50. ANATOMY OF AN ANCILLARY SYSTEM LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH IDENTITY TERMINOLOGY AUTHORIZATION SCHEDULING CORE BUSINESS SERVICES SUPPLY CHAIN (ORDER/CHARGE) DOCUMENT RECORDS MANAGEMENT s DECISION SUPPORT PERFORMANCE DATA MANAGEMENT