1 / 26

Please Send Suggestions for Improvement to Nancy.Orvis@tma.osd.mil, GovProjects;

EHR SD RM SAIF Alpha Project “EHR System-Design Reference-Model”. Constructing a Future State EHR Reference Architecture EHR Way Ahead Business Architecture From HL7, HITSP and ARRA Artifacts For presentation at HL7 Sydney Workgroup Meeting, 11 Jan 2011

delila
Télécharger la présentation

Please Send Suggestions for Improvement to Nancy.Orvis@tma.osd.mil, GovProjects;

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EHR SD RM SAIF Alpha Project “EHR System-Design Reference-Model” Constructing a Future State EHR Reference Architecture EHR Way Ahead Business Architecture From HL7, HITSP and ARRA Artifacts For presentation at HL7 Sydney Workgroup Meeting, 11 Jan 2011 Practical Guide:http://hssp.wikispaces.com/PracticalGuide EHR SD RM info: http://hssp.wikispaces.com/Reference+Architecture Please Send Suggestions for Improvement to Nancy.Orvis@tma.osd.mil, GovProjects; Stephen.Hufnagel.ctr@tma.osd.mil, EHR, SOA, ArB

  2. Objective of this Presentation is toDiscuss the Following Next Step Questions … • How should the EHR-SD RM be represented? • Hypothesis: XML DB, DITTA documentation • Use cases for EHR-SD RM use? • Ad Hoc Reporting needs • Web based tools needs • Profile needs (e.g., domain adaption vs. local use adaption) • How to ballot the EHR-SD RM? • Part of EHR-S FM R2.1 • Independent of EHR-S FM • Who will Participate? • Information Model sub-project • XML/XSL Technical expert • Subject Matter Experts (e.g., diabetes, Immunization, etc.)

  3. EHR SD RM Milestones 2008 2009 2010 2011 Healthcare SOA Reference Architecture (H-SOA-RA) EHR SD RM Immunization & Response Management (IRM) Prototype May HSSP Practical Guide for SOA in Healthcare Volume II: Immunization Case Study May EHR-S FM R2.0 With EHR SD RM Informative Reference Sep EHR SD RM Integrated into EHR-S FM R2.1 DSTU is Draft Standard for Trial Use (ANSI standards development) EHR-S CI-IM is EHR System Computationally Independent Information Model HF&EA is Harmonization Framework and Exchange Architecture

  4. 2008 Healthcare SOA FrameworkBased on HL7 EHR System Functional Model & Thomas Erl’s SOA Layers 3

  5. HL7 EHR System Functional Model (EHR-S)> 160 System Functions in 4 level categorization(separate spreadsheet available for full enumeration) EHR-S FM functions can be grouped into Service Components … aka Capabilities (e.g., Lab Order Capability, which does eligibility and authorization function as well as lab order function). System Functions 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 Health IT Enterprise.

  6. ANATOMY OF AN ANCILLARY SYSTEM Capabilities, which orchestrate Core Business Services 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 5

  7. HL7 EHR_S-Based Functional Architecture/Services Analysis Primary Care Critical/Emergency Care Laboratory Pharmacy Dental Non-Surgical Specialty Care Nursing Behavioral Health ETC. Population Health ETC Manage Business Rules Infrastructure Functions Interoperability • Infrastructure • Services • Security • Policy • Records Management • Audit • Terminology • Registry • Workflow • Business Rules • etc Terminology Unique ID, Registry, and Director Information and Records Management Security Lines of Business Record Management Manage Patient History • Core Clinical • Services • Entity Identification • Resource Location and • Updating Services • Decision Support • Orders Management • Scheduling • Image Management • Etc. Preferences, Directives, Consents, and Authorizations Summary Lists Management of Assessment Cross-Cutting Direct Care/ Support Functions Care Plans, Treatment Plans, Guidelines, and Protocols Orders and Referral Management Documentation of Care, Measurement, and Results Record Patient Specific Instructions Clinical Decision Support Clinical Workflow Tasking Support Clinical Communication Support Knowledge Access ETC 6

  8. EHR System Design Reference Model (EHR SD RM) Supporting Requirements/ Architecture Development Cycle PROCESS INPUTS -Required Capabilities -Environments -Constraints EHR System Design Reference Model Capabilities, Functions, Information and Information Exchanges Stakeholder Requirements Definition Functions – Dependencies Conformance Criteria Conformanceis a recognition of formal testing, that prove that a system provides 100% support for a given standard. Requirements Loop Interface Specifications Requirements Analysis Test Specifications Specifications Loop Architectural Specifications Verification & Validation Loop Test Loop PROCESS OUTPUTS -System Architecture, -Test Specifications -Configuration Management Baselines 7

  9. EHR SD RM Supporting Requirements/ Architecture Development Cycle Stakeholder Requirements Whatis the system supposed to do? Under what conditions will the products be used? Where will the products of the system be used? How often? How long? Who will use the products of the system? Requirements Analysis (“HOW?” using “Action Verbs”) Analyze functions and Services Decompose higher level functions to lower level functions Allocate performance requirements to the functions Architecture Design (Whichhardware/ software elements) Define the physical architecture Each part must perform at least one function Some parts may perform more than one function Test Specifications How Requirements-Specifications are validated Requirements Loop • Ensure all requirements are covered by at least one function • Ensure all functions are justified by a valid requirement (no unnecessary duplication) Design Loop • Ensure all functions are covered by at least one hardware or software element • Ensure all elements of physical architecture are justified by a valid functional requirement (no unnecessary duplication) Verification & Validation (V&V) Loop • Each requirement must be verifiable that the solution meets requirements and validated that it meets the user’s needs and expectations. • V&V can be accomplished by: Inspection, Analysis, Demonstration, Test Test Loop • Ensure all information is covered by test specifications • Ensure all interfaces are covered by test specifications 8

  10. 2010 SAIF Alpha ProjectThe Practical Guide For SOA in Healthcare Volume IIImmunization Management Case Study The Practical Guide for SOA in Healthcare Volume II presents a case study, which adds an Immunization Management Capability (IMC) to Volume I’s SampleHealth’s Service Oriented Architecture (SOA). We used the TOGAF Architecture Development Method (ADM) and HL7 Service Aware Interoperability Framework (SAIF) Enterprise Conformance and Compliance Framework (ECCF). Volume II demonstrates the use of HL7’s EHR System Design Reference Model (EHR-SD RM) linked artifacts (e.g., EHR System Functional Model, FHIM, HITSP, HITEC, HSSP, IHE, NIEM, etc) to provide an initial architectural baseline suitable for an EHR related SOA acquisition, development or certification project. We conclude with lessons learned. Healthcare Services Specification Project (HSSP) Practical Guide: • http://hssp.wikispaces.com/PracticalGuide

  11. SAIF ECCF examples

  12. Example of SAIF Traceability Using HL7 EHR-S FM Business Viewpoints Conceptual Independent Model Platform Independent Model Platform Specific Model Information Viewpoints Conceptual Independent Model Platform Independent Model Platform Specific Model FMIDs FMIDs Engineering/Technical Viewpoints Conceptual Independent Model Platform Independent Model Platform Specific Model Behavioral Viewpoints Conceptual Independent Model Platform Independent Model Platform Specific Model FMIDs FMIDs EHR-S FM FMIDs Investment Portfolio Line Items Planning budget for new, improved or sunset capabilities Product Line Inventory Inventory of systems and their capabilities and Functions FMIDs Key to Traceability Traceability is achieved by using Functional Model Identifiers (FMIDs) as attributes to all SAIF artifacts. This is analogous to a library system, which uses Dewey decimal numbers as book identifiers.

  13. Immunization Management ECCF Specification Stack 12

  14. Implement & Test Initiation SAIF ECCF - Services Aware Interoperability Architecture - Enterprise Compliance and Conformance Framework EHR-S FM & EHR-S CI-IM EHR System Function Model & EHR System Computationally-Independent Information-Model V&V Checkpoint Peer Review “Ballot” Analysis V&V Checkpoint V&V Checkpoint HL7 Development Framework (HDF) DSTU - Draft Standard for Trial Use “Prototype” Draft Working Document; Not for Public Distribution • Specifications for • Business Objects • Components • Capabilities • Applications • Systems DAM Domain Analysis Models CDA Clinical Document Architecture CMET Common Model Element Types D-MIM Domain Message Information Model Design • Interoperability Specifications for • Messages and/or • Documents and/or • Services V&V Checkpoint 14 V&V is Verification and Validation

  15. Interoperability Specification ECCF SAIF ECCF Viewpoints CIM PSM CIM is Computationally Independent Model PIM is Platform Independent Model PSM is Platform Specific Model Draft Working Document; Not for Public Distribution PIM 15

  16. EHR-S CI-IM (Started Jun 2010)EHR System Computationally-Independent Information-Model This project will produce a set of Constrained Information Models called EHR-S “data profiles”. Each EHR-S data profile corresponds directly with an EHR-S function profile and each EHR-S data profile will include one-or-more Reference Information Model classes. Pairs of EHR-S function profiles and data profiles can be used to define business objects, which can be composed into software components, capabilities, applications, systems and their message exchanges and/or document exchanges and/or services. The superset of EHR-S data profiles is called the EHR-S Computationally-Independent Information-Model, which supports the HL7 Development Process and Service Aware Interoperability Framework. The project will include the development and execution of a communication strategy to ensure that all affected stakeholders are engaged.

  17. HL7 RIM (Reference Information Model)Six Core Classes Defining a Semantic Framework whichMaintains Clinical Data Context ACT (aka ACTION) ENTITY ROLE Participation Role link Act relationship ACT – something that has happened or may happen Entity – a person, animal, organization, or thing Role – a responsibility of, or part played by, an Entity Participation – the involvement of a Role in an Act Act Relationship – a relationship between two Acts Role Link – a relationship between two Roles. The HL7 RIM expresses the data content needed in a specific clinical or administrative context and provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages. Language / communication The HL7 RIM supports EHR interoperability; an EHR may needs additional foundation classes (e.g., Responsibility)

  18. Federal Health Information Model (FHIM) Person Model (Harmonized with RIM, HIPAA & HITSP)

  19. HL7 EHR System Computationally-Independent Information-Model (EHR-S CI-IM) Project Draft Working Document; Not for Public Distribution EHR-S CI-IM RIM Classes Entity a.b.c EHR-S Data Modules EHR-S FM … Entity d.e.f 1:1 Relationship between Function Profiles and Data Profiles For each EHR-S Function, its Data Profile = Set of RIM Classes and their EHR-S Data Modules 1:N Relationship among Data Profiles and RIM Classes … Role a.b.c EHR-S Data Modules DC x.y.z EHR-S Function Profile Role d.e.f … … … Act a.b.c EHR-S Data Modules Act d.e.f SC x.y.z EHR-S Function Profile … … … Act Relationship a.b.c EHR-S Data Modules Act Relationship d.e.f … … IN x.y.z EHR-S Function Profile Role Link d.e.f Role Link a.b.c EHR-S Data Modules … … … Participation d.e.f DC is Direct Care SC is Supportive Care IN is Infrastructure Participation a.b.c EHR-S Data Modules … …

  20. EHR SD RM Status (Oct 2010) • Supporting EHR System Functional Model R2 • EHR SD RM foundation (linked XML version) Spring 2011 ballot • HITSP (2010 completion) • ARRA Meaningful Use Objectives/ Criteria (Jun 2010 Final Rule) • Sub Projects • EHR Computationally Independent Information Model • Harmonization Framework and Exchange Architecture • SAIF Executive Summary and Implementation Guide • http://hssp.wikispaces.com/PracticalGuide

  21. Prototype Demonstration of Browser-Version XML with XSL & XSLT  HTML Style Sheet • EHR-S FM R1.1 linked to • US Meaningful Use Objectives and Criteria • US Mandated Standards • Information Model (TBD)

  22. EHR SD RM Issue/Questions • 2011 Planned Representation (Better Options?) • Linked XML (most flexible for documentation, current preference) • EHR–S FM (R2) and it’s profiles (2011) • ISSUE: Managing Profiles • ISSUE: Tracking Changes / Comments • ISSUE: Managing HL7 Domain Analysis Models (DAMS)? and • ISSUE: Managing Detailed Clinical Models (DCMs)? • ISSUE: DITTA Publishing? (Resources needed) • ISSUE: Data Base / Web version? (Resources Needed) • EHR CI-IM - Computationally Independent Information Model • ISSUE: RIM/RIMBA expertise needed • US HITSP (2010)  Health & Human Services Selected Standards • US ARRA MU Meaningful Use Objectives & Criteria (2010)

  23. Call for Participation • XSL style sheet expert for • EHR-S FM R2 • EHR-S FM R2 with EHR SD RM additions • Profiles • Comment/Change tracking • EHR Computationally Independent Information Model • Decomposed by EHR-S FM • Traceable to RIM

  24. Contact Information Nancy Orvis Chief Integration Architect Information Management DoD Military Health System Email: nancy.orvis@tma.osd.mil Steve Hufnagel Enterprise Architect, TIAG contract support Information Management DoD Military Health System Email: steven.hufnagel.ctr@tma.osd.mil HOW TO PARTICIPATE: Coordinate with SHufnagel@tiag.net, 703-575-7912-cell. We have a weekly telecom each Friday 1230-1330 Eastern PHONE: +1 770-657-9270, CODE: 071582#WEB LINK: http://my.dimdim.com/hssp PROJECT WIKI: http://hssp.wikispaces.com/Reference+Architecture Backup Slides Available at Web Site 24

  25. Immunization Management Case StudyQuestions? Nancy.Orvis@tma.osd.mil Stephen.Hufnagel.ctr@tma.osd.mil Akirnak@swpartners.com JohnRitter1@verizon.net HOW TO PARTICIPATE: Coordinate with SHufnagel@tiag.net, 703-681-3929 or 703-575-7912-cell. We have a weekly telecom each Friday 1230-1330 Eastern PHONE: +1 770-657-9270, CODE: 071582#WEB LINK: http://my.dimdim.com/hssp PROJECT WIKI: http://hssp.wikispaces.com/Reference+Architecture

More Related