1 / 49

Health eDecisions (HeD) All Hands Meeting

Health eDecisions (HeD) All Hands Meeting. April 4th, 2013. Meeting Etiquette. Remember: If you are not speaking, please keep your phone on mute Do not put your phone on hold. If you need to take a call, hang up and dial in again when finished with your other call

dewei
Download Presentation

Health eDecisions (HeD) All Hands Meeting

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. Health eDecisions (HeD)All Hands Meeting April 4th, 2013

  2. Meeting Etiquette • Remember: If you are not speaking, please keep your phone on mute • Do not put your phone on hold. If you need to take a call, hang up and dial in again when finished with your other call • Hold = Elevator Music = frustrated speakers and participants • This meeting is being recorded • Another reason to keep your phone on mute when not speaking • Use the “Chat” feature for questions, comments and items you would like the moderator or other participants to know. • Send comments to All Panelists so they can be addressed publically in the chat, or discussed in the meeting (as appropriate). From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute  All Panelists

  3. Agenda

  4. Announcements • Vocabulary and Terminologies sub work will be meeting this week • Friday 12:30-2:30 EDT • http://wiki.siframework.org/Health+eDecisions+Homepage • We will be presenting the work of HeD at an AMIA webinar • Date and Time TBD

  5. HL7 Update • We have completed a rough draft of the Implementation Guide • http://wiki.siframework.org/HeD+Pilot+Tools • HeD/QDM/vMR harmonization work is complete • Plans: • We are postponing our HeD/CDS meetings but will resume as needed during Pilots http://wiki.siframework.org/Health+eDecisions+Homepage )

  6. HeD Pilots Goal • Goal • The goal of this initiative is to produce, consume and where feasible, execute implementable CDS interventions. • Event Condition Action Rules (ECA Rules) • Order Sets • Documentation Templates • Pilot Scope • Health eDecisions will apply defined aspects of the Implementation Guide in a real-world setting. • Modify the Implementation Guide to ensure it is usable • The real-world pilots evaluate not only the technology, standards and model (VMR), but also provide a test bed to evaluate the interaction of technology, implementation support, and operational infrastructure required to meet Health eDecisions use case 1 objectives at the stakeholder or organization levels. • Demonstrate intent of artifact (specifically structures and semantics) are communicated either by direct execution or by translation to native format • Ensure completeness and consumability of artifact

  7. Timeline We are Here

  8. What We Covered • Bryn’s HeD XML Validation Tool is available in Google code repository (Bryn: Open Source?) • Implementation Guide has been completed and published • Mark Roche: Terminology Section of IG done • Ken is pursuing potential pilots with other EMRs • Applied Pathways Training Session by Paul Arnone • Exciting stuff, looking forward to next session!

  9. Vendor Partners

  10. Next Steps • Additional Applied Pathways Training Session at next week’s regular pilot meeting (Monday) • Pilot participants begin or continue pilot activities, including IG review, document gap identification, etc. • CDC may present on April 8, TBD

  11. HeD Use Case 2

  12. Use Case 2 Workstream Agenda • Review outstanding Consensus comments • Round Robin Voting • Next Steps • Standards SWG Update • Standards Development & Harmonization Overview

  13. Consensus Comments • Many small edits were made to improve the readability of the Use Case document • Some mistakes in the cardinality of the Clinical data elements were corrected, and duplicative data elements were removed • Outstanding comments • Need better clarification between Support Evidence & Supporting Reference (H. Strasberg) • Supporting Reference doesn’t make sense as described in Clinical Data Elements (#136). Is this patient data? clinical knowledge? (D. Shields) • Facility in Clinical Data Elements seems to be covered by elements in the Context section. Remove? (B. Minton) • Should the word “Interface” be replaced with “API”? Interface generally means a user interface(C. Nanjo)

  14. Round Robin

  15. Use Case Next Steps • The final updates will be made to the document and it will then be posted to the S&I Framework wiki as well as the S&I Framework Browser (official repository for final S&I artifacts) • This group will be essential in helping with the Use Case Standards Crosswalk, part of the Technical & Standards Design Document (TSDD)

  16. S&I FrameworkStandards Development & Harmonization Overview Last updated: March 2013

  17. Standards Development & Harmonization in the S&I Framework NwHIN Exchange Operations S&I Framework S&I Pilots ATCBs and Testing Infrastructure S&I Framework NWHIN Implementation & Pre-Certification Testing eHealth Exchange Use Cases Standards Development Harmonization Federal Responsibility Joint Efforts Private Sector

  18. The Importance of Standards Necessary for Interoperability Increases Rate of HIT Adoption Enables Health Information Exchange Drives Systems Integration Integral for Compliance

  19. SDO Balloting, RI & Pilots* Standards Development & HarmonizationProcess for S&I Framework Candidate Standards Technical Design Evaluation and Selection of Standards Use Case Requirements Standards & Technical Gap Analyses The Harmonization Process provides detailed analysis of candidate standards to determine “fitness for use” in support of Initiative functional requirements. The resulting technical design, gap analysis and harmonization activities lead to the evaluation and selection of draft standards. These standards are then used to develop the real world implementation guidance via an Implementation Guide or Technical Specification which are then validated through Reference Implementation (RI) and Pilots. The gap mitigation results and lessons learned from the RI and Pilot efforts are then incorporated into an SDO-balloted artifact to be proposed as implementation guidance for Recommendation. Draft Harmonized Standard Harmonized Standard for Recommendation Validation of Standard Implementation Guidance for Real-World Implementers *Depending on the initiative the SDO Balloting, RI & Pilot activities may occur prior to the recommending a harmonized standard

  20. Standardization Development & Harmonization: Targeted Activities Validate candidate standards list Analyze candidate standards per HITSC criteria to produce selected standards Map UCR to selected standards in documented crosswalk Perform technical feasibility of analysis Develop gap mitigation plan Review with community and achieve consensus Gap mitigation plan Develop solution diagram and plan Confirm data model approach Develop new standard(s) Modify/harmonize existing standard(s) to produce final standards Achieve community consensus or agreement Final standards Using final standards, develop Implementation Guide document Document IG Conformance Statements in RTM Develop Examples to inform implementers Validate examples Achieve community consensus or agreement Implementation Guidance Survey SDO or standards organization options Select balloting approach Align timeline with ballot cycles Submit PSS (HL7) Submit NIB (HL7) Submit Content (HL7) Conduct balloting cycle & reconciliation per SDO guidelines Balloted standards Outputs Requirements Traceability Matrix

  21. Standards Development Support “Building Blocks” Successfully implement developed standards Result Initiative Progress Extend, modify, or develop a standard and develop implementation guidance Align initiative with SDO balloting or development priorities Action Support standards analysis against requirements Confirm Gaps Work with WG and SDOs to create plan and recommendations to address gaps Contribution Implement Communication Plan for SDO engagement Scan the standards & implementation environment Develop a “Candidate Standards” list Foundation

  22. How standards flow through an S&I Initiative Candidate Standards Evaluate • Document Use Case and functional requirements • Conduct environmental scans of real-world implementations and capture information like the deployment/operational complexity, current market adoption and pilots or demonstrations • Evaluate Candidate Standards on HITSC-outlined criteria to produce Selected Standards to be considered Selected Standards Analyze • Analyze Selected Standards against detailed functional & data requirements from Use Case • Identify where gaps in Selected standards exist to achieve functional requirements of Use Case • Document Technical & Standards design approach, including how to resolve Standards gaps • Determine most implementer-friendly standards-based approach to implementation • Harmonize previous evaluation & analysis to complete standards updates for Recommended Standards • Work with SDOs to develop, extend or modify required standards artifacts and follow-up with appropriate balloting process alignment to finalize Recommended Standards Harmonize Recommended Standards Develop Guidance • Develop implementation guidance that meets functional and technical requirements using current standards • Feedback on the implementation guidance is received from pilots, RI, and SDO balloting, and is then incorporated to result in a standard suitable for inclusion in regulation Implementation Guidance

  23. Standards Development & Harmonization: Targeted Activities This list represents the artifacts & activities which can take an S&I initiative through the Standards Development & Harmonization Phase, but can be tailored for each initiative

  24. Technical & Standards Design:Technical Design Document • The purpose of the S&I Technical and Standards Design Document is to: • Provide granular-level of technical detail to the business & functional requirements outlined in the Use Case • Document an overall technical & standards design approach for the initiative • This document and its underlying standards evaluation documents are intended to act as an input to the development of detailed solution artifacts • (e.g. Implementation Guidance, updates to standards, etc.) The following slides provide an overview of the contents of the Technical & Standards Design Document, which guides the Standards & Harmonization process at the most detailed level

  25. Technical & Standards Design:Table of Contents

  26. Technical & Standards Design:Technical Feasibility Analysis 2.0 Technical Analysis of Use Case Functional & Data Requirements • This section is to show a detailed technical analysis of the Functional (Information Interchange & System Requirements) and Data Requirements outlined in the Use Case 2.1 In-Scope Requirements Analysis Section Description: Use this section to expand the in-scope Use Case requirements to include technical details. The IDs within this section are taken from the consensus approved Use Case. - 2.1.1 Information Interchange Functions - 2.1.2 System Functions - 2.1.3 Data Requirements 2.2 Out-of-Scope Requirements Analysis 2.3 Solution Diagram 2.4 Data Model/Content Approach

  27. Technical & Standards Design:Technical Feasibility Analysis 2.1.1 Information Interchange Functions Section Description: For the Use Case information interchange requirements include the following technical details: • Assign roles to technical actors (sender, receiver, and responder.) A system should be listed once per role (e.g. if a system acts as both a sender and receiver it should be listed twice in the table, once for each). • Define exchange type: push (with or without response), pull (query-response), publish, subscribe, etc. • Document the data requirements for exchange at the level similar to the “Data Objects”( column E) of the Common Actions within the Core Matrix. There should be a direct link between the requirements listed in this column to the requirements contained in Table 3: Data Requirements • Add supporting exchanges not listed in UC, e.g., check patient consent, if within scope • Additional Supporting Exchanges defined as a pre-requisite exchange which must be implemented to successfully implement the Use Case • Could also include error messages or acknowledgement if defined as a part of the Use Case • Technical Feasibility considerations: • Are there existing approaches that could be used that is widely accepted? • If not, what is the projected time & effort to make this happen?

  28. Technical & Standards Design: Technical Feasibility Analysis 2.1.2 System Functions Section Description: For the Use Case System Requirements, determine if each is necessary for the technical design and within scope of interoperability, e.g., necessary pre-condition. Please note, technical design may or may not include system requirements based on the scope of the initiative and if the system requirements are in support of interoperability functions. For this reason, the last column is included in this table.

  29. Technical & Standards Design:Technical Feasibility Analysis 2.2 Out-of-Scope Requirements Analysis Section Description: Use this section to cover the assumptions and conditions excluded from the primary exchange documented in the Use Case. Requirements in this section are at the boundary of the Use Case activity and may not be pertinent for the flows, but could have considerations for architecture or implementation. Include columns for: • Refer to the types in the Core Matrix: http://wiki.siframework.org/file/view/ONC-SI-Simplification-Core-Matrix-v2_3-20121211.xlsx/391565188/ONC-SI-Simplification-Core-Matrix-v2_3-20121211.xlsx. • Considerations for infrastructure requirements and architecture/implementation options For the requirements listed below, please assign an ID in the far-right column only when the requirement is required as part of the technical solution. The naming structure for these IDs should follow the ID structures used above and should be dependent on what type of requirement from above it aligns with: for example if an assumption requires an ID the ID would begin with A01, a pre- condition would be PRC and a post condition would be POC.

  30. Technical & Standards Design:Technical Feasibility Analysis 2.1.3 Data Requirements Section Description: For the Use Case data requirements, add data type if applicable to indicate vocabulary, terminology, value set and/or code set. • Alternative value and/or code sets can be identified and enumerated in the below table • The table’s content should be leveraged to develop the initiative’s data dictionary • Per initiative requirements, the below table can be duplicated for each transaction in a separate sub-section, 2.1.3.x • 2.4 Data Model/Content Approach • Section Description:Use this section to describe the proposed approach for leveraging or developing informing components of, or entire, data models or other content needed for the initiative transactions. This could be represented using UML diagrams as appropriate. The content in section 2.2.3 should be used to develop this section. • Due to the requirements of a particular initiative, this section can be optional for inclusion.

  31. Technical & Standards Design:Technical Feasibility Analysis 2.3 Solution Diagram Section Description:Use this section to depict the overall solution diagram which represents the solution. Leverage the overall initiative workflow & Use Case diagrams to map potential standards pictorially. The example at right is taken from the esMD initiative, and the components included may vary per initiative.

  32. Technical & Standards Design:Candidate Standards & Evaluation 3.0 Solution Analysis 3.1 Identify Existing Solutions or Modules for Re-Use Section Description: This section will reference, via link to wiki, to the Candidate Standards list that was developed during the Pre-Discovery & Use Case development phases. When working through this section with the community the candidate standards list should be reviewed to ensure there are no missing standards. This section can also be used to capture other initiative work efforts that should be evaluated and potentially leveraged when developing the solution. Suggested format: List any standards or other content identified in addition to the initial candidate standards

  33. Technical & Standards Design:Candidate Standards & Evaluation 3.2 Evaluate Candidate Standards Section Description: There are two major steps for completing this section: Using the candidate standards list as a starting point pull in all of the standards to the table below and document the design relevance. For those standards relevant to the design use the standards analysis matrix to evaluate each standard against the HITSC-recommended criteria for maturity, implement-ability, etc. (See Standards Analysis template) Please note a link to the completed Standards Analysis Matrix on the wiki for the initiative should be included within this section. Section Format: 1)Table of candidate standards and design relevance. 2) Standards Analysis template that has been populated, reviewed with community, uploaded to the wiki and linked within this section.

  34. Technical & Standards Design:Standards Crosswalk & Gap-Mitigation Plan 4.0 Solution Mapping 4.1 UCR-Standards Crosswalk & Gap Identification Section Description: Use this section to map the technically feasible requirements from section 2.0 to the standards in 3.2. With each requirement document the standards mapping and any known gaps. This table is the UCR-Standards Crosswalk. Please note the IDs captured in this table originate from the tables in sections 2.2 & 2.3.

  35. Technical & Standards Design:Solution Plan & Issues, Risks, Obstacles 4.2 Solution Plan Section Description: Use this section to capture recommendations around extension, modification, or creation of new or existing standards or profiles to close any gaps between selected standards and functional or technical requirements. This becomes the Gap Mitigation plan. A high level summary of the design to complete initiative implementation guide(s) and/or fill gaps through SDOs should also be included within this section. Suggested format: Table to document Recommendations 5.0 Technical Risks, Issues and Obstacles Section Description: The Risks, Issues and Obstacles section lists the concerns that might interfere with meeting the proposed Technical and Standards Design.

  36. Technical & Standards Design:Solution Plan & Issues, Risks, Obstacles 4.2.1 Summary of Potential Changes to External Artifacts and Corresponding Ballot or Approval Process Considerations Section Description: This section will be used to summarize what changes may be required to standards or documentation owned by external organizations. Populate the “Standard or External Guidance Artifact” with all standards relevant to accepted design solutions (4.2 Table with “Y” in “Incorporate into Final Design” column) and the “Summary of Required Changes” column with all applicable changes for that artifact as identified in table 4.1. Please note that each relevant standard should be listed once, and all required changes for that standard should be grouped into a single cell under “Summary of Required Changes”. Leveraging information in the candidate standards list, other informally documented information (e.g. SDO Engagement Plan that is typically developed by SDS team), and community expertise populate the remaining columns “Owning Organization”, “Organization’s Ballot Process, Timelines and other Considerations” and “Organization Contact”

  37. Technical & Standards Design:Solution Plan & Issues, Risks, Obstacles 4.2.2 Expected Artifacts to Support Solution Plan Section Description: List all relevant artifacts required to support the approach detailed in this design document within the Standards & Harmonization phases of the S&I Framework. This list will be refined with initiative-specific content, in addition to general S&I artifacts. Some examples:

  38. Technical & Standards Design:Appendices Appendices The content of this section varies depending on the needs brought forth by the Community. Some Design Documents may have appendices that are specific to their content and issues. The appendices listed below are suggested for inclusion. Appendix A: References Appendix B: Key Terms

  39. Technical & Standards Design:Requirements Traceability Matrix

  40. Standards Harmonization:Standard Development or Modification SDO engagement Initiative Community involvement Modify a standard Subject Matter Expertise contribution S&I Framework and SDO balloting alignment

  41. Implementation Guidance:Develop Implementation Guidance Template Table of Contents for Development • Introduction • Use Case Overview • Implementation Approach • Data Types • Messages • Code Systems and Value Sets • Development Resources • Appendices • A Suggested Enhancements • B Acronyms • C Definitions • D Working Examples • E Conformance Statement Review • F References • G Implementation Alignment to Requirements

  42. Implementation Guidance:Requirements Traceability Matrix

  43. Implementation Guidance:Balloting Considerations

  44. Flow of Standards & Harmonization Activities

  45. The final result...! • Updated, balloted standards • Implementation Guidance for end-users • Traceability to the UC & Functional Requirements • Setting the stage for pilots

  46. Next Steps • Work Stream 1 – HL7: • Next HL7 meeting TBD • (see HeD Homepage wiki for meeting details: http://wiki.siframework.org/Health+eDecisions+Homepage • Work Stream 2 – Pilots: • We are beginning the work of pilots • Next Pilots meeting: April 1st, 1-2:30 pm EDT see HeD home page wiki for meeting details: http://wiki.siframework.org/Health+eDecisions+Homepage • Review timelines and vendor/content supplier activities • Work Stream 3 – Use Case 2: • We will reviewing candidate standards and consensus on UC 2 • Next meeting April 4th, 11-12:30 EDT (see the HeD Homepage wiki for meeting details: http://wiki.siframework.org/Health+eDecisions+Homepage

  47. Questions?

  48. Contact Information • For questions, please contact your support leads • Coordinator: • Ken Kawamoto: kensaku.kawamoto@utah.edu • Co-Coordinators: • Aziz Boxwala: aziz.boxwala@meliorix.com • Bryn Rhodes: bryn@veracitysolutions.com • ONC Leadership: • Alicia Morton: alicia.morton@hhs.gov • Project Management: • Jamie Parker: jamie.parker@esacinc.com • Christina Arenas: christina.arenas@esacinc.com • Use Case 2: • Dave Shevlin: d.s.shevlin@accenturefederal.com • Virginia Rhiel: virginia.riehl@verizon.net • Harmonization: • Lynette Elliot: lynette.elliott@esacinc.com • Merideth Vida: merideth.c.vida@accenture.com • Anna Langhans: anna.langhans@accenture.com

  49. Useful Links • Wiki • http://wiki.siframework.org/Health+eDecisions+Homepage • Use Case 1& 2 • http://wiki.siframework.org/Health+eDecisions+Use+Case • UC 2: Use Case 2: http://wiki.siframework.org/UC+2+-+CDS+Guidance+Service • Pilots • http://wiki.siframework.org/Health+eDecisions+Pilots • HL7 Ballot Submission: • http://wiki.siframework.org/Health+eDecisions+Reference+Materials#Ballot • UC 1 Harmonization and IG: • http://wiki.siframework.org/Health+eDecisions+Harmonization+and+Standards+%28Implementation%29 • HeD Glossary • http://wiki.siframework.org/HeD+Glossary

More Related