Goal : President’s Commission on Wounded Warriors Serve, Support, Simplify

1. Goal: HITSP To enable the sharing of health information in a secure environment to improve healthcare. Goal: President’s Commission on Wounded WarriorsServe, Support, Simplify Goal: Standardized Healthcare Service Oriented Reference Architecture (H-SOA-RA) To Specify HITSP Compliant Wounded Warriors National Healthcare Information Exchange (NHIE) Gateway Based on HL7 EHR System Functional Model & Thomas Erl SOA Layers In Conjunction with: Healthcare Services Specification Project (HSSP) of HL7 and OMG REQUESTED ACTION: Send Suggestions for Improvement to MHS: Stephen.Hufnagel.ctr@tma.osd.mil VA: John Koisch, john.koisch@va.gov 7 Aug 2007 version L

2. BackgroundFederal Direction ‘2001 President’s E-Gov Initiativeresulted in Consolidated Health Informatics (CHI) and Federal Health Architecture (FHA) ‘2004 Executive Order (EO)mandated “Incentives for the Use of Health IT and Establishing the Position of the National Health IT Coordinator.” It set a ‘2014 target for US EHR interoperability. ‘2006 Executive Order (EO) “Promoting Quality and Efficient healthcare in Federal Government Administered or Sponsored healthcare Programs,” starting in Jan ‘2007. Health and Human Services (HHS)is the designated Executive Agency to implement the Executive Orders (EOs). Healthcare Information Technology Standards Panel (HITSP)is chartered by HHS to define the Interoperability Specifications (IS) of standards to enable the sharing of health information in a secure environment to improve healthcare. President’s Commission on Care for America’s Returning Wounded Warriors made six patient centric recommendations to fix the MHS-VA health systems.

3. GoalsJoint MHS & VA Architecture EHR Executive Orders (EO): • MHS-VA Electronic Medical Record (EMR) Interoperability • Purchased Care Interoperability • HITSP Compliance Care for America’s Returning Wounded Warriors EO: “care provided to America’s returning Global War on Terror service men and women from the time they leave the battlefield through their return to civilian life.” … President Commission’s Recommendations[www.pccww.gov/]: • Implement comprehensive Recovery Plans • Restructure disability and compensation systems • Improve care for people with post-traumatic stress disorder (PTSD) and traumatic brain injury (TBI) • Strengthen support for families • Transfer patient information across systems • Support Walter Reed until closure

4. GoalJoint HL7-OMG Healthcare Services Specification Project (HSSP) GOAL: Faster-better-cheaper interoperable-healthcare-systems resulting from consistent enterprise architectures, system acquisitions, system developments, system tests and system certifications within and among organizations. PROBLEM: Inconsistent semantics among healthcare system users, venders, contractors and acquisition processes. APPROACH: Standardize Healthcare SOA Reference Architecture (H-SOA-RA) based on the HL7 EHR System Functional Model (EHR-S) and commercial SOA best practices. BENEFIT:Integrated EHR-S requirements linked to H-SOA-RA system design specifications and CCHIT certification tests will result in consistent, traceable and interoperable requirements-design specifications for procurements, developments & tests.

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

6. Executive SummaryRoadmap to HITSP Compliant EA IRDSolution Set for Wounded Warriors (WW)National Health Information Exchange (NHIE) • Define Healthcare SOA Reference Architecture (H-SOA-RA) candidate service blueprint, based on Electronic Healthcare Record System Functional Model (EHR-S) categories and Service Oriented Architecture (SOA) system layers. • Map & Gap AHLTA & VISTA clinical system functions to EHR-S service functions. • Define and analyze wounded warrior (WW) use cases using AHIC & HITSP processes. • Define HITSP compliant WW National Healthcare Information Exchange (NHIE) Gateway • Define AHLTA & VISTA application and federated services • Define Integrated Requirements-Design (IRD) Solution Sets from H-SOA-RA • Build Strategic Enterprise Architecture (EA) Transition Plan • Include EHR-S system functions, H-SOA-RA and CCHIT Test Specifications in • Investment Portfolio (e.g., POM processes) • Procurement Contracts and Acceptance Test & Evaluation Master Plans • Use EHR-S & H-SOA-RA as the key to CM traceability • Functional proponents, Investment Portfolio, OMB & IG reviews, NHIE Gateway • Capabilities/requirements, designs, standards, and test • CCHIT Certification (e.g., 2006, 2009, 2012)

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

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

9. Service TraceabilityEHR-S, HITSP and CCHIT 9

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

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

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

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

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

15. Proposed MHS & VAHealthcare SOA & Standards Framework

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

17. INTEGRATED REQUIREMENTS DESIGNS: Putting the H-SOA-RA Pieces Together Ancillary Systems PT/OT/SPEECH LABORATORY SPECIALTY CARE RESPIRATORY PHARMACY CARDIOLOGY RADIOLOGY DIETARY IDENTITY TERMINOLOGY Inter-Service TEST ONLY AUTHORIZATION INPATIENT SCHEDULING Federated Business Services SUPPLY CHAIN: (ORDERS/CHARGES) Core Business Services 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 Agnostic Services SUPPORT Data sets are defined for each system functional-capability-service module IT PLATFORM

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

19. INTERAGENCY EA STANDARDIZATION IN SUPPORT OF THE WOUNDED WARRIORS DOD VA GOAL: Seamless Uninterrupted Care Across the Continuum of Care Integrated Care Planning involving Key Players Upfront Care Plan Informed Decision Making with Timely Alerts Decision Support Consistent Care Oversight and Co-Ordination Case Management Timely Complete Information Standardized H-SOA-RA Records Management Streamlined Referral Referral Joint Performance Review, Learning, Improvement Performance Timely, Efficient Benefit Access Benefits Management Patient Monitoring and Epidemiological Analysis. Trauma Registry

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

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

22. Recommended Next StepsMHS-VA Joint H-SOA-RAIntegrated Requirements Design (IRD) Solution Set for Wounded Warriors (WW) • Create Use Case Scenarios focused on President’s Commission's WW recommendations • (www.pccww.gov/ ) • Build UML Models for WW scenarios • AHIC-HITSP style Use Cases and Interaction diagrams • H-SOA-RA System Solution UML Deployment diagrams • HITSP Interoperability Specification Constructs • Pre-Coordinate with FHA & VA (e.g., Paul Tibbits) • Dr. Casscellis request AHIC & HITSP verify & validate scenarios & models • Specify WW National Healthcare Information Exchange (NHIE) Gateway • Which specifies WW IDR Solution Set • Traceable and consistent capabilities, requirements and design alternatives • Build MHS & VA Strategic Architecture Transition Plan • based on WW NHIE Gateway IRD vision • based on EHR-S • based on H-SOA-RA • based on HITSP Interoperability Specifications • Implement Strategic Architecture Transition Plan in Investment Portfolios Should this be the first or fourth step? First step will shift the resource burden to AHIC/HITSP & will be slower.

23. Integrated Requirements-Design Lexical & Semantic Consistency = EA Traceability resulting from EHR-S as H-SOA-RA Foundation Ancillary Applications LABORATORY PT/OT/HSPEECH RESPIRATORY RADIOLOGY CARDIOLOGY PHARMACY SPECIALTY CARE DIETARY IDENTITY TERMINOLOGY TEST ONLY • Strategic capabilities map to EHR-S system functions • EHR-S Functions map to Operational Activities (OV-5) • EHR-S Functions map to Functional Requirements • EHR-S Functions map to H-SOA-RA Services • Systems decompose into consistent & traceable sets of • -- EHR-S System Functional Capabilities • -- H-SOA-RA services AUTHORIZATION INPATIENT SCHEDULING ER Patient Encounter Types SUPPLY CHAIN: (ORDER/CHARGE) Core EHR-S Services ASU DOCUMENT Composite Services, which may be categorized by: -- CMS billing category -- Record type -- Care setting type -- etc. DODAF Enterprise Architecture View BASED ON OV-6C Enterprise (Business Value Chains) Process Flows EHR-S lexicon OV-7 Enterprise Logical Data Model Data Sets EHR-S SV-1/SV-2 Enterprise System Interface / Communication Descriptions H-SOA-RA & HITSP SV-4 Enterprise System Functions Descriptions EHR-S SV-4 Enterprise System Data Flows H-SOA-RA & OV-3 info flows SV-5 Enterprise Activity (OV-5) to System Function (SV-4) Mapping EHR-S & H-SOA-RA SV-3/SV-6 Enterprise System to System Interface / Data Exchange Matrix SV-1, SV-4, OV-7 & HITSP IS SV-8/SV-9 Enterprise System Evolution / Technology Forecast H-SOA-RA & CCHIT, EA Plan SV-10C Enterprise Systems Event Trace Descriptions (e.g., Wounded Warrior) OV-6C, SV-5 & SV-6 TV-1 Enterprise System Standards Categorization H-SOA-RA TV-2 Enterprise System Standards Forecast H-SOA-RA & EA Transition Plan RECORDS MANAGEMENT DECISION SUPPORT OUTPATIENT OTHER CLINIC PERFORMANCE DATA MANAGEMENT ANALYTIC Federated Services SUPPORT Data sets are defined for each service – application – encounter type module IT PLATFORM

24. Optimistic TimelineJoint MHS-VA using H-SOA-RAIntegrated Requirements Design (IRD)Solution Set for Wounded Warriors (WW) National Health Information (NHIE) Gateway FY07Q4 FY08Q1 FY08Q2 FY08Q3 FY08Q4 OV-6C Enterprise (Business Value Chains) Process Flows OV-7 Enterprise Logical Data Model Data Sets SV-1/SV-2 Enterprise System Interface / Communication Descriptions SV-4 Enterprise System Functions Descriptions SV-4 Enterprise System Data Flows SV-5 Enterprise Activity (OV-5) to System Function (SV-4) Mapping SV-3/SV-6 Enterprise System to System Interface / Data Exchange Matrix SV-8/SV-9 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 Schedule is dependent on available resources!

25. HEALTHY & FIT FORCE Wounded WarriorContinuum of Care AHLTA (Medical Treatment Facilities) AHLTA (Wounded Warrior) CASUALTY PREVENTION DEPLOY TRAIN BATTALION AID STATION AHLTA Clinical Data Repository Theater Medical Data Store Medical Surveillance FORWARD RESUSCITATIVE SURGERY GARRISON THEATER FORCE HEALTH PROTECTION CARE OUTSIDE THEATER DISCHARGE Medical Situation Awareness THEATER HOSPITALIZATION VISTA Clinical Data Repository ENROUTE CARE VHA CARE TRAC2ES VISTA (Medical Treatment Facilities)

26. Wounded Warrior Scenarios Source: www.pccww.gov/ )

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

28. Backup Slides • Abbreviations • HA DASD Traceability to HL7 EHR-S Functional Model • SOA Background Slides • SOA Framework, Inventory, Design • SOA Principle Interaction • SOA Service Models (e.g., potential layers) • Service Elicitation Process • Service Categorization • Entity Services, Task Services, Utility Services • Focal Classes • Alternative Healthcare SOA & Standards Framework Representation • Federal Enterprise Architecture (FEA) • Technical Reference Architecture (TRM) • Performance Reference Model (PRM) • Business Reference Model (BRM) • Service Component Reference Model (SCRM) • Data Reference Model (DRM) • Other Healthcare Frameworks • Open Health (formerly IBM) • Microsoft • Global Justice Reference Architecture (SOA-TRM integration)

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

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

31. Organizational Structure TRICARE Management Activity Dr. S. Ward Casscells Director, TMA Senior Enlisted Advisor (SEA) OASD (Health Affairs) & TMA CMSgt Manuel Sarmina, USAF General Counsel Mr. Seaman MG Elder Granger, MC, USA Deputy Director, TMA Acting Chief of Staff Mr. Gidwani TRICARE Military Education/Executive Assistant to SEA OASD (HA) & TMA Vacant Deputy Chief of Staff Vacant Executive Officer LTC Wooldridge Chief Pharmaceutical Operations 2RADM McGinnis Chief Health Plan Operations Ms. Storck Acting Chief MedicalOfficer 1Dr. Smith Chief Force Health Protection and Readiness 1Ms. Embrey Acting Chief FinancialOfficer 1Mr. Middleton Acting Chief InformationOfficer Mr. Foster Director, Program Integration Ms. Speight Regional Director TRO South 1Mr. Gill Regional Director TRO North 1Mr. Koenig Regional Director TRO West 1RADM Lescavage DirectorDoD/VA Program Coordination Office Mr. Cox Director TAO Latin Am/Can 1COL Franco Director TAO Pacific Mr. Chan Director TAO Europe 1CAPT Niemyer 1Non-TMA 2Public Health Service

32. HL7 EHR System Functional ModelVs DoD HA Deputy Secretary of Defense (DASD) Proponents See associated spreadsheet for 260 detailed EHR-S functions mapped to DASDs DASDs Acting Chief MedicalOfficer 1Dr. Smith CITPO RITPO Chief Force Health Protection and Readiness 1Ms. Embrey TMIP DMLSS Acting Chief FinancialOfficer 1Mr. Middleton RITPO EIDS Acting Chief InformationOfficer Mr. Foster TIMPO Chief Health Plan Operations Ms. Storck Chief Pharmaceutical Operations RADM McGinnis Personnel & Readiness (P&R) e.g., Benefits

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

34. Service Definition Framework (SDF) As we move to federated SOA services, it is important that services across the enterprise be described using a common set of information (metadata) so that services can be consistently discovered and understood by others in the enterprise. The Service Definition Framework (SDF) shown below identifies the necessary attributes for effective description of a service. Source: Department of Defense Global Information Grid Service Strategy See www.SOA.OMG.org “UML Profile and Metamodel for Services (UPMS) "SOA“ for related information.

35. Candidate Service Inventory [1]“Service Inventory Blueprint” An ultimate goal of an SOA transition effort is to produce a collection of standardized services that comprise a service inventory. The inventory can be structured into layers according to the service models used, but it is the application of the service-orientation paradigm to all services that positions them as valuable IT assets in full alignment with the strategic goals associated with the SOA project. However, before any services are actually built, it is desirable to establish a conceptual blueprint of all the planned services for a given inventory. This perspective is documented in the service inventory blueprint. There are several common business and data models that, if they exist within an organization, can provide valuable input for this specification. Examples include business entity models, logical data models, canonical data and message models, ontologies, and other information architecture models. A service inventory blueprint is also known as a service enterprise model or a service inventory model. We are proposing the use of the HL7 System Functional Model for this purpose. [1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07)

36. SOA Design [1] The service-oriented design process uses a set of predefined service candidates from the service inventory blueprint as a starting point from which they are shaped into actual physical service contracts. When carrying out service-oriented design, a clear distinction is made between service candidates and services. The former represents a conceptual service that has not been implemented, whereas the latter refers to a physical service. As shown in the following figure, the traditional (non-standardized) means by which Web service contracts are generated results in services that continue to express the proprietary nature of what they encapsulate. Creating the Web service contract prior to development allows for standards to be applied so that the federated endpoints established by Web services are consistent and aligned. [1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07)

37. SOA Principle Interactions[Thomas Erl] • Service autonomy establishes an execution environment that facilitates reuse because the service achieves increased independence and self-governance. The less dependencies a service has, the broader its reuse applicability. • Service statelessness supports reuse because it maximizes the availability of a service and typically promotes a generic service design that defers state management and activity-specific processing outside of the service boundary. • Service abstraction fosters reuse because it establishes the black box concept. Proprietary processing details are hidden and potential consumers are only made aware of an access point represented by a generic public interface. • Service discoverability promotes reuse as it allows those that build consumers to search for, discover and assess services offering reusable functionality. • Service loose coupling establishes an inherent independence that frees a service from immediate ties to others. This makes it a great deal easier to realize reuse. • Service composability is primarily possible because of reuse. The ability for new automation requirements to be fulfilled through the composition of existing services is feasible when those services being composed are built for reuse. (It is technically possible to build a service so that its sole purpose is to be composed by another, but reuse is generally emphasized.)

38. Service Elicitation Processes The proposed Healthcare SOA framework, analogous to the "Zachman Framework™ for enterprise architecture“, is useful in providing completeness and familiarity within a larger methodology. However, the elicitation activity reduces the scope to three questions ("What-Who-Why“ at the contextual and conceptual levels of the Zachman Framework™.

39. Service Categorization When building various types of services, it becomes evident that they can be categorized depending on: - the type of logic they encapsulate - the extent of reuse potential this logic has - how this logic relates to existing domains within the enterprise As a result, there are (3) common service classifications that represent the primary service models used in SOA projects: - Entity (e.g., Information) Services - Task (e.g., Business) Services - Utility (e.g., common) Services Information Infrastructure Direct Care Supportive Other

40. Service Type Definitions • The term "service" or “candidate service” is used as follows: • A (candidate) service is a container that can encompass collections of functions or business processes. • A service does not refer to or imply any specific implementation technology. • The following types of services might be considered: • Entity Service (e.g., Information Service) - Functional business context associated with a business entity or a collection of related business entities. (Entity services are also known as "entity-centric business services" and "business entity services".) • Utility Service (e.g., Infrastructure Service) - Functional non-business context associated with a related set of processing capabilities. (Utility services are also known as "application services," "infrastructure services," and "technology services".) • Task Service (e.g., Business Service) - Functional business context associated with a specific business process. (Task services are also known as "task-centric business services" and "business process services".) A variation of the task service is the Orchestrated Task Service which exists within an orchestration platform that imposes specific service characteristics. (Orchestrated task services are also known as "process services," "business process services,“ and "orchestration services".)

41. Entity Services [1](Information Service) 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)

42. Task Services [1](Business Service) A business service with a functional boundary directly associated with a specific parent business task or process is based on the task service model. This type of service tends to have less reuse potential and is generally positioned as the controller of a composition responsible for composing other, more process-agnostic services. When discussing task services, one point of clarification often required is in relation to entity service capabilities. Each capability essentially encapsulates business process logic in that it carries out a sequence of steps to complete a specific task. An entity Invoice service, for example, may have an Add capability that contains process logic associated with creating a new invoice record. How then is what a task service encapsulates different from what an entity 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. [1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07)

43. Utility Services [1](Agnostic Services) Each of the previously described service models has a very clear focus on representing business logic. However, within the realm of automation, there is not always a need to associate logic with a business model or process. In fact, it can be highly beneficial to deliberately establish a functional context that is non-business-centric. This essentially results in a distinct, technology-oriented service layer. The utility service model accomplishes this. It is dedicated to providing reusable, cross-cutting utility functionality, such as event logging, notification, and exception handling. It is ideally application agnostic in that it can consist of a series of capabilities that draw from multiple enterprise systems and resources, while making this functionality available within a very specific processing context. The example on the right shows a utility service providing a set of capabilities associated with proprietary data format transformation. Utility services are also known as application services, infrastructure services, or technology services. [1] SOA: Principles of Service Design, by Thomas Erl, Prentice Hall, July 07)

44. Focal Classes  The issue is less the idea of a focal class than a business focal class. The difference is that when you model the service, you are generally modeling a service that will express the state changes of a business. For example, via analysis, you would find the states of a business focal class (canceled, new, active, signed, finalized in lab orders for example) and the trigger events that would correspond to state changes ("a lab is ordered", "a lab is canceled", "a lab specimen is corrupted", and so on).  You could say that a "patient" is a focal class, but a patient ID service generally doesn't express operations to modify the state of that "object". Rather, a patientID service would generally encompass operations that would express information about the class (reconcileID or lookUpID, eg) rather than tying the service functional components to changes in the state of that class.  It is not a subtle distinction - most clinical domains are focused on a focal class (an order, an encounter, an appointment, a schedule, a lab). A business service is focused with exposing that class to the enterprise.  Infrastructure services (or the subset information services) are generally function calls or based on exposing sets of information. The functional profiles of the service are generally not focused on the state of the underlying information or in the trigger events that modify the state of that information. They tend to be focused along different lines - typically along the lines of an information profile (a RIM-based patient class, eg, or a CDA-based CCD). In summary, the focal class is explicit in a business service, generally implicit in other services.

45. AlternativeHealthcare SOA & Standards Framework Representation Considering there are over 200 HL7 EHR System Functions, this may be a better layout for a spreadsheet or database. Thoughts? 45 * “Agnostic Services” are also-known-as “Common Services” or “Shared Services”

46. Federal Technical Reference Model (TRM) TECHNICAL REFERENCE MODEL (TRM) is a component-driven, technical framework used to categorize the standards, specifications, and technologies that support and enable the delivery of service components and capabilities. • The Technical Reference Model (TRM) provides a foundation to categorize the standards, specifications, and technologies to support the construction, delivery, and exchange of business and application components (Service Components) that may be used and leveraged in a Component-Based or Service-Oriented Architecture. The TRM unifies existing Agency TRMs and E-Gov guidance by providing a foundation to advance the re-use of technology and component services from a government-wide perspective. • Service Access and DeliveryRefers 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.

47. Federal Performance Reference Model (PRM) PERFORMANCE REFERENCE MODEL (PRM) is a “reference model” or standardized framework to measure the performance of major IT investments and their contribution to program performance. The PRM has three main purposes: • Help produce enhanced performance information to improve strategic and daily decision-making; • Improve the alignment — and better articulate the contribution of — inputs to outputs and outcomes, thereby creating a clear “line of sight” to desired results; and • Identify performance improvement opportunities that span traditional organizational structures and boundaries The PRM attempts to leverage the best of existing approaches to performance measurement in the public and private sectors, including the Balanced Scorecard, Baldrige Criteria, Value Measurement Methodology, program logic models, the value chain, and the theory of constraints. In addition, the PRM was informed by what agencies are currently measuring through PART assessments, GPRA, Enterprise Architecture, and Capital Planning and Investment Control. Agencies’ use of the PRM will populate the model over time. The PRM is currently comprised of four measurement areas:

48. Federal Business Reference Model (BRM) BUSINESS REFERENCE MODEL (BRM) is a function-driven framework for describing the business operations of the Federal Government independent of the agencies that perform them.” The Business Reference Model provides an organized, hierarchical construct for describing the day-to-day business operations of the Federal government. While many models exist for describing organizations - org charts, location maps, etc. - this model presents the business using a functionally driven approach. The Lines of Business and Sub-functions that comprise the BRM represent a departure from previous models of the Federal government that use antiquated, stove piped, agency-oriented frameworks. The BRM is the first layer of the Federal Enterprise Architecture and it is the main viewpoint for the analysis of data, service components and technology.

49. Federal Service Component Reference Model (SRM) SERVICE COMPONENT REFERENCE MODEL (SRM)is a business and performance-driven, functional framework that classifies Service Components with respect to how they support business and/or performance objectives.” The SRM is intended for use to support the discovery of government-wide business and application Service Components in IT investments and assets. The SRM is structured across horizontal and vertical service domains that, independent of the business functions, can provide a leverage-able foundation to support the reuse of applications, application capabilities, components, and business services.

50. Federal Data Reference Model (DRM) DATA REFERENCE MODEL (DRM) describes, at an aggregate level, the data and information supporting government program and business line operations. This model enables agencies to describe the types of interaction and exchanges occurring between the Federal government and citizens. The DRM categorizes government information into greater levels of detail. It also establishes a classification for Federal data and identifies duplicative data resources. A common data model will streamline information exchange processes within the Federal government and between government and external stakeholders. The DRM provides a standard means by which data may be described, categorized, and shared. These are reflected within each of the DRM’s three standardization areas: • Data Description: Provides a means to uniformly describe data, thereby supporting its discovery and sharing • Data Context: Facilitates discovery of data through an approach to the categorization of data according to taxonomies; additionally, enables the definition of authoritative data assets within a community of interest (COI) • Data Sharing: Supports the access and exchange of data where access consists of ad-hoc requests (such as a query of a data asset), and exchange consists of fixed, re-occurring transactions between parties