Presentation is loading. Please wait.

Presentation is loading. Please wait.

HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse.

Similar presentations


Presentation on theme: "HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse."— Presentation transcript:

1 HL7 Work Group Report September , Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse Event Reporting Nancy Orvis, HL7 Project Co-Chair Stephen Hufnagel PhD, HL7 Project Facilitator September 22, 2009-D

2 Contents EHR System Design Reference Model ( EHR-SD RM) Background –2008 Project Results –2009 HL7 EHR SD RM Project plan What Changed in 2009 –ARRA (American Reinvestment and Recovery Act) –HITSP Harmonization Framework for reuse –HITSP Capabilities Information Exchanges Interface Standards Specifications –HITSP Service Collaborations EHR SD RM Model –Jan 2009 baseline project –Sep 2009 Information Model (IM) additions –2010 EHR SD RM Model with HITSP Capabilities, IM & ARRA Vaccination and Adverse Event Reporting Prototype –AHIC Use Cases –EHR-S FM –HITSP Capabilities Next Steps 2

3 3 In 2004, Executive Orders set the objective for National Electronic Healthcare Record (EHR) Interoperability by 2014 In 2006, Executive Order mandated Federal agencies to begin transformation to Healthcare Information Technology Standards Panel (HITSP) conformant EHR interoperable systems by 2007 We present a standards-based strategic approach for interoperability at the service level to construct semantically consistent interoperable Enterprise Architectures (EAs) –It builds upon the functional foundation of the HL7 EHR System Functional Model (EHR-S) and the technical foundation of Thomas Erls Service Oriented Architecture (SOA) model to specify a standard Healthcare SOA Reference Architecture (H-SOA-RA) –Information Exchange Requirements (IERs) are used to identify services and as the key to traceability from requirements to implementation, test and certification Introduction

4 4 HL7 Project Intent Implement a step in HL7 roadmap –Identify gaps and overlaps in HL7s portfolio –Identify gaps in the EHR-S FM –Pilot HL7 ARB SAEAF methodology Create H-SOA-RA Version 2 Create Healthcare SOA EHR-SD Reference Model based on EHR System Functional Model (EHR-S FM) Create prototype architectural case study using HL7 HSSP Practical Guide for SOA in Healthcare sample health and service specifications, EHR-S FM, EHR-SD RM, AHIC Use Cases, HITSP Interoperability Specifications and NHIN services Demonstrate standards-based Model Driven Architecture (MDA) approach

5 5 This project will mature the April 2008 H-SOA-RA version 1.0 into H-SOA-RA Version 2.0 and integrate it into an EHR-SD RM using –HL7 (SAEAF, –HITSP MEANS, and –EHR System Functional Model (EHR-S FM) Emphasis will be placed on maintaining AHIC, HITSP, NHIN and CCHIT conformance by maintaining IERs and Data Requirements (DRs) traceability –Mapping and analysis of the HL7 product portfolio against the EHR-S FM will be used to integrate the reference architecture with HL7 product lines and initially mature the resulting model as a technical white papers, then an informative reference model and finally a standard reference model An HSSP based prototype case study architectural specification will be built to validate the effort using the AHIC-HITSP Immunization and Response Management and Public Health Case Reporting use cases HL7 Project Scope

6 6 HL7 Project Schedule Sep 2008 – Healthcare SOA Reference Architecture (H-SOA-RA) Jan 2009 – harmonize and catalogue priority IERs, DRs and candidate services Mar 2009 – map priority IERs, DRs and candidate services to EHR-S FM Jun Mappings of V2.5, V3 products to EHR-S FM Jun Present at HL7 SOA Conference (for peer feedback) Sep 2009 – Report on Vaccination and Adverse Event Prototype Oct 2009 – Healthcare SOA Reference Architecture (H-SOA-RA) version 2.0 Nov HSSP Practical Guide for SOA in Health Care, Part II: Case Study Jan EHR-SD RM white paper for HL7 committee comments, to socialize the project. Sep EHR-SD RM Balloted as informative document Sep EHR-SD RM Balloted as a standard

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

8 Health SOA Reference Model Glossary (example) MHS/VA PROPOSED SERVICES SOA SERVICE DEFINITIONS Access to Care Functions IDENTITYIdentify and/or lookup subjects-of-care, providers, payers, employers, material resources, and references to various parts of the EHR (hosted locally and/or remotely). PatientMaintain current directory of patient information in accordance with relevant privacy and other applicable laws, regulations, and conventions, including, when available, full name, address or physical location, alternate contact person, primary phone number, and relevant health status. Provide the patient's location information within a facility's premises. GuarantorCollect, record, and update a core set of information to ensure accurate beneficiary guarantor identification and health plan information. Provide information of Related by genealogy (blood relatives). Provide information of Related by insurance (domestic partner, spouse, guarantor). Provide information of Related by other means (e.g. epidemiologic exposure) ProviderMaintain a current directory of practitioners that, in addition to demographic information, contains data needed to determine levels of access required by the EHR security system. Maintain current directory of provider information in accordance with relevant laws, regulations, and conventions, including full name, address or physical location, and a 24x7 telecommunications address (e.g. phone or pager access number) for the purposes of the following: Provide provider location or contact information on a facility's premises. Provide provider location or contact information on a facility's premises. Provide provider location or contact information when on call. Provide locations or contact information at which the provider practices, in order to direct patients or queries. Next of KinCollect, record, and update a core set of information to ensure accurate next of kin identification and health plan information. SupplierCollect, record, and update a core set of information to ensure accurate Supplier Information. InsurerCollect, record, and update a core set of information to ensure accurate Insurer Information. FacilityCollect, record, and update a core set of information to ensure accurate Facility Information.

9 Healthcare SOA Framework Based on HL7 EHR System Functional Model & Thomas Erls SOA Layers 9 9 HL7 System Functions Direct CareSupportiveInformation Infrastructure Other Business Process Value Chains Composite Services (Svcs) Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas Core Bus Svcs Functional Areas + Focal Classes Entity Svcs IM Info Reporting/IM Agnostic Svcs 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…) App Svcs Amb Care Sys, In Pt Care Sys Log Sys, Fin Sys, Dec Support Sys Data Marts Repositories Business Objects Imp Profiles IHE ProfilesAnalysis ProfilesCommunications Profiles/Stacks Implementation Profiles

10 10 SUPPLY CHAIN (ORDER/CHARGE) Anatomy of Ancillary Systems AUTHORIZATION DOCUMENT RECORDS MANAGEMENT DECISION SUPPORT PERFORMANCE DATA MANAGEMENT SCHEDULING IDENTITY TERMINOLOGY LABORATORYRADIOLOGYPHARMACYCARDIOLOGYOT/PT/SPEECH s CORE BUSINESS SERVICES

11 Contents EHR System Design Reference Model ( EHR-SD RM) Background –2008 Project Results –2009 HL7 EHR SD RM Project plan What Changed in 2009 –ARRA (American Reinvestment and Recovery Act) –HITSP Harmonization Framework for reuse –HITSP Capabilities Information Exchanges Interface Standards Specifications –HITSP Service Collaborations EHR SD RM Model –Jan 2009 baseline project –Sep 2009 Information Model (IM) additions –2010 EHR SD RM Model with HITSP Capabilities, IM & ARRA Vaccination and Adverse Event Reporting Prototype –AHIC Use Cases –EHR-S FM –HITSP Capabilities Next Steps 11

12 12 Information Exchange Number Exchange Action Exchange Content What System initiates this exchange? What System (s) consume this exchange?Qualifier Send Blood Lab Report Laboratory Information System PHR System EHR System Public Health Information SystemTBD Send Specimen Lab Report Laboratory Information System PHR System EHR System Public Health Information SystemTBD HITSP 2009 Model for IERs Reusable Facets Lexical Consistency

13 A new 2009 concept HITSP Capability A HITSP capability is an implementable business service that specifies interoperable information exchanges using HITSP constructs. It is meant to supports stakeholder requirements and as part of its design, it includes workflow, information content, infrastructure, security and privacy. Capabilities include constraints and operate on specific network topologies (contexts) Capabilities have options: subsets of the data content can be sent or received as appropriate by a system implementing a capability.

14 The 2009 Refined HITSP Framework Business Requirements Identifies interoperability business needs Interoperability Specification Identifies what HITSP capabilities and constructs to use to meet Business Needs Defines Requirements, Context and Constraints for those capabilities and constructs Base Standard #1 Base Standard #n Base Standard #2 Base Standard #... Composite Standard #1 Composite Standard #... Composite Standard #m SDOs Component Transaction Transaction Package Available for Internal reuse or repurposing Component Transaction Constructs Transaction Transaction Package HITSP Constructs HITSP Capabilities Component Service Collaborations Service Collaboration Transaction Constructs Transaction Transaction Package 14

15 HITSP Reuse Framework GREEN Elements are reusable!

16 16 HITSP Model To Link Requirements to Design Design HITSP Constructs Transaction Transaction Packages Component Services

17 HITSP Requirements Analysis Framework GREEN Elements are reusable!

18 Design Specifications Framework GREEN Elements are reusable!

19 19 HITSP List of Priority Information Exchanges 1.Demographics 2.Problem List 3.Medications 4.Immunizations 5.Allergies 6.Progress Notes and Other Narrative Documents (History and Physical, Operative Notes, Discharge Summary) 7.Departmental Reports (Pathology/Cytology, GI, Pulmonary, Cardiology etc.) 8.Laboratory Results 9.Microbiology 10.Images 11.Administrative Transactions (Benefits/Eligibility, Referral/Authorization, Claims/Remittance) 12.Quality Measures 13.Privacy and Security

20 20 HITSP List of Priority Capabilities 1.HITSP/CAP117Communicate Ambulatory and Long Term Care Prescription 2.HITSP/CAP118Communicate Hospital Prescription 3.HITSP/CAP119Communicate Structured Document 4.HITSP/CAP120Communicate Unstructured Document 5.HITSP/CAP121Communicate Clinical Referral Request 6.HITSP/CAP122Retrieve Medical Knowledge 7.HITSP/CAP123Retrieve Existing Data 8.HITSP/CAP124Establish Secure Web Access 9.HITSP/CAP125Retrieve Genomic Decision Support 10.HITSP/CAP126Communicate Lab Results Message 11.HITSP/CAP127Communicate Lab Results Document 12.HITSP/CAP128Communicate Imaging Information 13.HITSP/CAP129Communicate Quality Measure Data 14.HITSP/CAP130Communicate Quality Measure Specification 15.HITSP/CAP131Update Immunization Registry 16.HITSP/CAP132Retrieve Immunization Registry Information 17.HITSP/CAP133Communicate Immunization Summary 18.HITSP/CAP135Retrieve and Populate Form 19.HITSP/CAP136Communicate Emergency Alert 20.HITSP/CAP137Communicate Encounter Information Message 21.HITSP/CAP138Retrieve Pseudonym 22.HITSP/CAP139Communicate Resource Utilization 23.HITSP/CAP140Communicate Benefits and Eligibility 24.HITSP/CAP141Communicate Referral Authorization 25.HITSP/CAP142Retrieve Communications Recipient 26.HITSP/CAP143Manage Consumer Preference and Consents

21 21 Service Traceability EHR-S, HITSP and CCHIT

22 Contents EHR System Design Reference Model ( EHR-SD RM) Background –2008 Project Results –2009 HL7 EHR SD RM Project plan What Changed in 2009 –ARRA (American Reinvestment and Recovery Act) –HITSP Harmonization Framework for reuse –HITSP Capabilities Information Exchanges Interface Standards Specifications –HITSP Service Collaborations EHR SD RM Model –Jan 2009 baseline project –Sep 2009 Information Model (IM) additions –2010 EHR SD RM Model with HITSP Capabilities, IM & ARRA Vaccination and Adverse Event Reporting Prototype –AHIC Use Cases –EHR-S FM –HITSP Capabilities Next Steps 22

23 23 Approach Service Oriented Architecture based on –Thomas Erls SOA layers (De Facto Standard) Business Process Value Chains, Composite Services Core Business Services, Entity Services Agnostic Services, Application Services, Implementation Profiles –HL7 EHR System Functional Model (EHR-S FM) 160+ Standardizes EHR system functions –Requirements and Test criteria standardized at National Level –Objective Strategic Planning and Investment Portfolio line costing. –HITSP Capabilities and Interoperability Specifications Federal Mandate for Design Interoperability Specifications Traceable to Enterprise Architecture –ARRA Meaningful Use Measures

24 24 January 2009 EHR SD RM Project EHR System Design Reference Model (EHR-SD RM)

25 Information Model Project Federal Health Information Model and Standards (FHIMS)

26 Project Integrated EHR-SD RM, FHIMS, HITSP Capabilities and ARRA Meaningful Use

27 27 Benefits 1.Faster, Better, Cheaper Integrated Requirements-Design Process 2.Strategic Plan based on International and National Standards 3.Objective Investment Portfolio Cost Estimation 4.Minimize the Chance of Year of Execution Unfunded Requirements (UFRs) 5.IM and IT aligned on Consistent Catalogue of Services 6.MHS EHR Interoperability alignment with National Agenda 1.Manage Care Support Contractor (MCSC) interoperability 2.VA interoperability 7.Consistent with Enterprise Architecture

28 28 Prototype Approach Build Integrated Requirements Design CONOPS package based on –Service Oriented Architecture categorized and populated by Candidate Services Derived from following Thomas Erls Service Oriented Design Principles HL7 EHR System Functional Model Requirements and HITSP Interoperability Specifications

29 Contents EHR System Design Reference Model (EHR-SD RM) Background –2008 Project Results –2009 HL7 EHR SD RM Project plan What Changed in 2009 –ARRA (American Reinvestment and Recovery Act) –HITSP Harmonization Framework for reuse –HITSP Capabilities Information Exchanges Interface Standards Specifications –HITSP Service Collaborations EHR SD RM Model –Jan 2009 baseline project –Sep 2009 Information Model (IM) additions –2010 EHR SD RM Model with HITSP Capabilities, IM & ARRA Vaccination and Adverse Event Reporting Prototype –AHIC Use Cases –EHR-S FM –HITSP Capabilities Next Steps 29

30 30 EHR-SD RM Prototype Requirements from 2008 AHIC Use Cases Use Case 1: Immunization and Response Management ( IRM ) and Use Case 2: Public Health Case Reporting (PHCR ) –The IRM AHIC Use Case and HITSP Interoperability Specification are intended to support current interoperability approaches between EHRs and Immunization Information Systems while allowing for a migration toward emerging interoperability implementations and document sharing environments where PHRs are able to be included in the information flow –The Interoperability Specification also allows for basic electronic information exchanges to enable requirement communications and alerting mechanisms and to lay the foundation for future clinical support capabilities –The Public Health Case Reporting AHIC Use Case and HITSP Interoperability Specification supports the bi-directional information exchanges of the Public Health Case Reporting process –The Public Health Case Reporting Use Case addresses numerous domains which have similar content and processes at a high level, but which also are dissimilar in report content details and case management processes when considering any specific report

31 31 EXAMPLE ARTIFACT : Vaccine and Drug Administration and Reporting Information Exchanges

32 32 EXAMPLE ARTIFACT Vaccine and Drug Administration and Reporting Use Case Full use case available at:

33 33 EHR-SD RM Prototype Information Exchange Requirements (IERs) Use Case 1: Immunization and Response Management (IRM) IER10 Identify patient IER13 Send/receive notification of document availability IER18 Send/receive clinical document IER26 Identify communication recipients IER27 Send non-patient notification message or alert IER40 Query for existing data IER42 Request/receive medical concept knowledge IER54 Query/response for clinical message data IER67 Send/receive clinical message IER78 Send/receive Vaccine Inventory Requirements IER79 Query/response for inventory usage data IER80 Send/receive Vaccine Inventory Data For details, see HITSP IS 10 Immunization and Response Management, available at Blue Italics indicates IERs, which are common to 1- IRM and 2- PHCR

34 34 DR08 Unstructured Data DR11 Immunization response data DR12 Adverse Event Report DR13 Drug/Vaccine Inventory Data DR14 Drug/Vaccine Inventory Usage Data DR15 Drug/Vaccine Inventory Availability Data DR16 Supply Chain Management Vaccine Recall DR17 Decision Support Data DR18 Vaccination Data DR19 Medication Administration data DR20 Aggregate Inventory of Available Vaccine DR21 Terminology Data DR22 Generic Alert Data DR23 Consumer Vaccination View 34 EHR-SD RM Prototype Data Requirements (DRs) Use Case 1: Immunization and Response Management (IRM) For details, see HITSP IS 10 Immunization and Response Management, available at Blue Italics indicates common across IRM and PHCR

35 35 EHR-SD RM Prototype IRM Information Exchange Requirements (IERs) Use Case 2: Public Health Case Reporting (PHCR) IER10 Identify patient IER13 Send/receive notification of document availability IER18 Send/receive clinical document IER26 Identify communication recipients IER27 Send non-patient notification message or alert IER29 Send/receive electronic form for data capture IER40 Query for existing data IER42 Request/receive medical concept knowledge IER49 Report confirmation For details, see HITSP IS 10 Immunization and Response Management, available at Blue Italics indicates common across 1-IRM and 2-PHCR

36 36 EHR-SD RM Prototype Data Requirements (DRs) Use Case 2: Public Health Case Reporting (PHCR) DR08 Unstructured Data DR17 Decision Support Data DR21 Terminology Data DR24 Case Report Pre-populate Data DR22 Generic Alert Data DR23 Consumer Vaccination View DR24 Case Report Pre-populate Data DR25 Case Report Content DR26 Reporting Criteria Content DR59 Generic Alert Data For details, see HITSP IS 10 Immunization and Response Management, available at Blue Italics indicates common across IRM and PHCR

37 37 EHR-SD RM Prototype Information Exchange Requirements (IERs) HITSP Security and Privacy IER01 Provide authorization and consent IER02 Send data over secured communication channel IER03 Create audit log entry IER04 Synchronize system time IER05 Verify entity identity IER06 Provide proof of document integrity and origin IER55 Anonymize patient identifiable data IER56 Pseudonymize patient identifying information For details, see HITSP IS 10 Immunization and Response Management, available at Blue Italics indicates common across IRM and PHCR

38 38 EXAMPLE ARTIFACT HL7 Requirements and Certification Criteria and HITSP Design HL7 EHR System Functional Model HITSP Interoperability Specifications

39 39 EXAMPLE ARTIFACT EHR-S Requirements

40 40 EXAMPLE ARTIFACT EHR-S FM Dependencies

41 41 EXAMPLE ARTIFACT HITSP Interoperability Design Specifications

42 42 Sample of Standards used within HITSP Components within IS10 1.Standard:HITSP Construct 2.Accredited Standards Committee (ASC) X12 Standards Release HITSP/C80 - Clinical Document and Message Terminology 3.American Medical Association (AMA) Current Procedural Terminology (CPT®) Fourth Edition (CPT-4); CPT Evaluation and Management Codes HITSP/C80 - Clinical Document and Message Terminology 4.ASTM International Standard Guide for Electronic Authentication of Health Care Information: # E (2003) HITSP/C26 - Nonrepudiation of Origin 5.CDC Race and Ethnicity Code SetsHITSP/C80 - Clinical Document and Message Terminology 6.Center for Disease Control and Prevention Implementation Guide for Immunizations Data Transaction using Version of the Health Level Seven (HL7) Standard Protocol. Implementation Guide Version 2.2 June 2006 HITSP/C70 - Immunization Query and Response, HITSP/C72 - Immunization Message, HITSP/C80 - Clinical Document and Message Terminology 7.Digital Imaging and Communications in Medicine (DICOM) Part 3.12: Media Formats and Physical Media for Media Interchange HITSP/T33 - Transfer of Documents on Media 8.European Telecommunications Standards Institute (ETSI) Technical Specification TS : XML Advanced Electronic Signatures (XadES) HITSP/C26 - Nonrepudiation of Origin 9.Federal Information Processing Standards (FIPS) Codes for the Identification of the States, the District of Columbia and the Outlying Areas of the United States, and Associated Areas Publication # 5-2, May, 1987 HITSP/C80 - Clinical Document and Message Terminology 10.Food and Drug Administration (FDA) - Unique Ingredient Identifier (UNII) HITSP/C80 - Clinical Document and Message Terminology 11.Food and Drug Administration (FDA) - National Drug Code (NDC) HITSP/C80 - Clinical Document and Message Terminology 12.Health Care Provider Taxonomy HITSP/C80 - Clinical Document and Message Terminology 13.Health Level Seven (HL7) Clinical Document Architecture (CDA) Release 2.0 HITSP/C78 - Immunization Document, HITSPC83 - CDA Content Modules 14.Health Level Seven (HL7) Common Terminology Services (CTS) Release 1 HITSP/T66 - Retrieve Value Set 15.Health Level Seven (HL7) Implementation Guide for CDA Release 2: History and Physical (H&P) Notes HITSP/C83 - CDA Content Modules 16.Health Level Seven (HL7) Implementation Guide for CDA Release 2: Consultation Note HITSP/C83 - CDA Content Modules 17.Health Level Seven (HL7) Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD), April 01, 2007 HITSP/C83 - CDA Content Modules 18.Health Level Seven (HL7) Standard Code Set CVX - Vaccines Administered HITSP/C80 - Clinical Document and Message Terminology 19.Health Level Seven (HL7) Standard Code Set MVX - Manufacturers of Vaccines HITSP/C80 - Clinical Document and Message Terminology 20.Health Level Seven (HL7) V3 RBAC, R1-2008, HL7 Version 3 Standard: Role Based Access Control (RBAC) Healthcare Permissions Catalog, Release 1, February 2008, HITSP/TP20 - Access Control 21.Health Level Seven (HL7) Version HITSP/C70 - Immunization Query and Response 22.Health Level Seven (HL7) Version Chapter 2 – Control, Chapter 3 – Patient Administration HITSP/TP22 - Patient ID Cross-Referencing 23.Health Level Seven (HL7) Version 2.5, Chapter 2 – Control, Chapter 3 – Patient Administration, Chapter 5 – Query HITSP/TP22 - Patient ID Cross-Referencing 24.Health Level Seven (HL7) Version 2.5, Chapter 2 – Control, Chapter 3 – Patient Administration, Chapter 5 - Query HITSP/T23 - Patient Demographics Query 25.Health Level Seven (HL7) Version HITSP/C80 - Clinical Document and Message Terminology 26.Health Level Seven (HL7) Version Vocabularies and Value Sets HITSP/C80 - Clinical Document and Message Terminology 27.Health Level Seven (HL7) Version 3.0 Context-Aware Information Retrieval Specification: URL Implementation Guide HITSP/T81 - Retrieval of Medical Knowledge

43 43 Work Plans EHR-SD RM Next Steps 1.EHR SD RM Framework –Populate the framework with candidate healthcare Information Exchanges/ capabilities/ services, based on HL7 EHR-S Functional Model 2.Information Model –Loosely-coupled top-down Framework –Rigorously specified bottom up structure/ content 3.Publish HL7 HSSP Practical Guide for SOA in Healthcare Part 2: Case Study 4.Socialize EHR SD RM 5.Collaborate with others 6.Informative ballot in 2010

44 44 Questions?? What was omitted? Suggestions for improvement? How should the model be represented? What should be balloted in 2010?

45 45 Questions? Contact us: Project info available at:

46 46 Backup

47 47 Learning Objective Understand how to leverage SOA and Information Exchange Requirements (IER) in the System Design Reference Model –Audience: Developers and Managers –Analytic Process: How to integrate a healthcare system design or acquisition specification, with national standards HL7, HITSP and CCHIT standards –Benefits: Understand what is needed to create standards-based EHR interoperability at the Service level Management level understanding supports funding justification –Understanding of services as automating business functions –Consistent reqmts, design-specs and implementations –Better costing

48 48 Candidate Services Sources 2008 H-SOA-RA: Identity, Terminology, Authorization, Scheduling, Supply Chain (Order/charge), Document Records Management, Decision Support, Performance, Data Management DoD-VA Sharing Project: Pharmacy Data, Clinical Data (Theater), Allergy Data, Lab Results, Discharge Summaries, SADR, Radiology Reports, Assessments (Pre/Post), Inpatient Consults NHIN Services: Subject Discovery, Query for Documents, Retrieve Documents, Query Audit Log, Authorization Framework, Consumer Preference Profile, Messaging Platform, Pseudonymization, Health Information Event Messaging, NHIE Service Registry HITSP Constructs as Services: Document Sharing, Patient Indexing, Security, Content Definition, Healthcare Services, Health Coverage, Decision Support, Dynamic Data, Data Aggregation, General Communication

49 49 Discussion Topics H-SOA Reference Architecture Project deliverables 2009 HITSP work on Information Exchanges (IEs) among Use Cases Building content of System Domain Reference Model (RM) –From HL7, HITSP, DOD components Use Case Public Health & Emergency Response (PHER) System Domain (SD) analysis on PHER

50 Tasks 2009 Work Through HITSP Prototype HITSP IER Model Candidate Services Next Steps / Work Plan

51 Results Healthcare SOA Reference Architecture H-SOA-RA H-SOA-RA: Overall Goal –Service Traceability –EHR System Functional Model (EHR-S) –Healthcare SOA Reference Architecture –Notional Functional Example

52 52 Exchange Content Number Exchange Content Name Definition of the Exchange ContentData Requirements Genomic Decision Support Data Information from genetic/genomic knowledge sources and/or decision support modules within EHRs (including Fx HX and Test Results) DR1 Demographic Data DR3 Clinical History DR4 Personal genetic/genomic data DR5 Family genetic/genomic information DR8 Unstructured Data HITSP Exchange Content Contain Data Requirements (DRs) CDA and ANSI X12 Data Modules Reusable DRs Lexical Consistency

53 53 HL7 EHR System Functional Model (EHR-S) > 230 System Functions in 4 level categorization (see separate spreadsheet for full enumeration) 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 Infrastructure Entity (Information) Service Types System Functions Choreography Business

54 54 Application layer Services interface layer Business process layer SOA Layers Focus on the Business Processes and Services [Thomas Erl].NETJ2EELegacy Source: Service-Oriented Architecture, Thomas Erl orchestration service layer business service layer application service layer System Components and Services Business Capabilities and Services

55 55 SOA Service Models Potential Service Layers [Thomas Erl] Service ModelDescription Application 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.

56 56 SOA Service Models Potential Service Layers [Thomas Erl] (cont) 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. Service ModelDescription

57 57 EHR Data Reuse Through H-SOA-RA Across 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 Episode Of Care EHR Previous Episode Of Care EHR Reusable Services Data Must Be Verified And Updated

58 58 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

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

60 60 IT PLATFORM SUPPORT ANALYTIC DATA MANAGEMENT PERFORMANCE DECISION SUPPORT RECORDS MANAGEMENT DOCUMENT SUPPLY CHAIN: (ORDERS/CHARGES) SCHEDULING AUTHORIZATION TERMINOLOGY IDENTITY RADIOLOGY LABORATORY PHARMACY CLINIC ASU TEST ONLY OUTPATIENT OTHER INPATIENT ER CARDIOLOGY PT/OT/SPEECH DIETARY SPECIALTY CARE Ancillary Systems Core Business Services INTEGRATED REQUIREMENTS DESIGNS: Putting the H-SOA-RA Pieces Together RESPIRATORY Federated Business Services Agnostic Services 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 Inter-Agency Inter-Service Across Providers

61 61 CASE MANAGEMENT COORDINATION ACROSS CARE CONTINUUM ACROSS SERVICES (SOAs)

62 62 Case Management Coordination Across SOAs and the Continuum ASSESSMENT CARE PLANNING ORDERS & SCHEDULING BENEFIT MANAGEMENT AUTHORIZATION & UTILIZATION MGT. COMMUNICATION (FACILITATION ADVOCACY) DISCHARGE/ TRANSFER PLANNING REFERRAL RECORD TRANSPORT ROLE OF CASE MANAGER Acute Inpatient Chronic Rehab. Outpatient Wartime Theater ER Acute Rehab. Skilled Long Term Care Custodial Long Term Care Home Health Prevention/ Wellness Care Continuum Coordination ACROSS SOAS c COORDINATION ` ACROSS LEVELS OF CARE, PROVIDERS and LOCATIONS EDUCATION.

63 63 Potential Benefits: 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

64 64 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

65 65 Addressing Real Business Issues Through H-SOA-RA 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)


Download ppt "HL7 Work Group Report September 20 - 25, 2009 - Atlanta, GA USA HL7 Project Prototype: EHR System Design Reference Model (EHR-SD RM) Immunization and Adverse."

Similar presentations


Ads by Google