Upload
dewei
View
17
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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 • 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
Agenda
Topic Time Allotted Announcements 5 minutesWork Stream 1 Update: HL7 Meeting Update 5 minutes
Work Stream 2 Update: Pilots 5 minutes
Work Stream 3: Use Case 2 65 minutes
Next Steps 5 minutes
Wrap up/Questions 5 minutes
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
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 )
HeD Pilots Goal Goal
The goal of this initiative is to produce, consume and where feasible, execute implementable CDS interventions.1. Event Condition Action Rules (ECA Rules)2. Order Sets3. Documentation Templates
Pilot Scope4. Health eDecisions will apply defined aspects of the Implementation Guide
in a real-world setting.5. Modify the Implementation Guide to ensure it is usable 6. 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.
7. Demonstrate intent of artifact (specifically structures and semantics) are communicated either by direct execution or by translation to native format
8. Ensure completeness and consumability of artifact
7
Timeline
10/11/2011
Goal & Activities Week Dates Deliverables
Kickoff /Establish Goals & Partnerships: - Review HeD Initiative Goals - Review Piloting Process & Resources - Define Value Statement - Define HeD Pilot Goals & Success Metrics - Establish & Approve Pilots - Develop Pilot Briefs
1-2(4wks)
1/07-2/25 (we missed 2 meetings in January pushing our Dates back)
-Wiki Capturing Pilot Deliverables-Established Partnerships-Documented Value Statements and Success Metrics-Documented Pilot Briefs
Pilot Configuration: - Establish Pilot Test Environment & Resources - Establish Pilot Implementation & Testing Process - Develop & Review Pilot Configuration
3-4(2 wks.)
2/25-3/25
-Use Case is Updated with HL7 Comments (3/4)-Approved Pilot Briefs -Committed Pilot Resources-Documented & Reviewed Pilot Configuration Guide-Weekly Feedback on Use-Cases & IG Alignment
Pilot Development : - Setup & Develop Pilot Prototypes - Review prototypes
6 wks. or less
depending on Pilot activity
TBD
-Use Case is Updated with HL7 Comments (3/4)-Weekly Pilot Development Status Updates-Weekly Feedback on Use-Cases & IG Alignment-Updates to Pilot Configuration Guides
Pilot Testing & Showcase : - Complete Testing - Prepare Solution Showcase
2wks TBD -Weekly Pilot Testing Updates & KPIs-Showcase-Prepare for HL7
Pilot Wrap-up : - Develop Lessons Learned an ONC Feedback - Review Initiative Goal Alignment - Establish Next-Steps
2 wks TBD, end of May
-Documented ONC Feedback- Next Steps Action PlanWe are Here
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!
10/11/2011 8
Vendor Partners
10/11/2011 9
EHR Area of Interest Potential or Actual Match
Design Clinicals Order Sets Zynx
AllScripts ECA Rules –NQMF Rule (for Ambulatory Setting)
NewMentor (have catalog for rules in ambulatory setting)
Practice Fusion Anything MU centered
CDC (also may need Artifact supplier to help) Wolters Kluwer NewMentor (MU rule as example)
Success EHS
Next Gen Considering other rules that are a better fit
CDC
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
10/11/2011 10
HeD Use Case 2
Use Case 2 Workstream Agenda• Review outstanding Consensus comments• Round Robin Voting• Next Steps• Standards SWG Update• Standards Development & Harmonization Overview
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)
Round Robin
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)
S&I FrameworkStandards Development & Harmonization Overview
Last updated: March 2013
Standards Development & Harmonization in the S&I Framework
17
Federal
Responsibility Private SectorJoint Efforts
NwHINExchange
OperationsS&I PilotsS&I
Framework
ATCBs and Testing
Infrastructure
NWHIN Implementation & Pre-Certification
TestingStandards DevelopmentUse Cases Harmonization
S&I Framework
eHealth Exchange
Necessary for Interoperability
Drives Systems
Integration
Enables Health
Information Exchange
Increases Rate of HIT Adoption
Integral for Compliance
The Importance of Standards
18
Implementation Guidance for Real-World Implementers
Standards Development & HarmonizationProcess for S&I Framework
19
Draft Harmonized Standard
Standards & Technical
Gap Analyses
Candidate Standards
Evaluation and Selection of Standards
Validation of Standard
Harmonized Standard for Recommendation
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.
SDO Balloting, RI & Pilots*
*Depending on the initiative the SDO Balloting, RI & Pilot activities may occur prior to the recommending a harmonized standard
Use Case Requirements
Technical Design
Standardization Development & Harmonization: Targeted Activities
Outputs
1. Validate candidate standards list
2. Analyze candidate standards per HITSC criteria to produce selected standards
3. Map UCR to selected standards in documented crosswalk
4. Perform technical feasibility of analysis
5. Develop gap mitigation plan
6. Review with community and achieve consensus
Gap mitigation plan
Requirements Traceability Matrix
1. Develop solution diagram and plan
2. Confirm data model approach
3. Develop new standard(s)
4. Modify/harmonize existing standard(s) to produce final standards
5. Achieve community consensus or agreement
Final standards
1. Using final standards, develop Implementation Guide document
2. Document IG Conformance Statements in RTM
3. Develop Examples to inform implementers
4. Validate examples5. Achieve community
consensus or agreement
Implementation Guidance
1. Survey SDO or standards organization options
2. Select balloting approach
3. Align timeline with ballot cycles
4. Submit PSS (HL7)5. Submit NIB (HL7)6. Submit Content
(HL7)7. Conduct balloting
cycle & reconciliation per SDO guidelines
Balloted standards
Evaluate Standards
Plan for Solution and Develop
standards
Develop Implementation
GuidanceSDO Balloting
Standards Development Support “Building Blocks”
21
Successfully implement developed standards
Extend, modify, or develop a standard
and develop implementation
guidance
Align initiative with SDO balloting or
development priorities
Implement Communication
Plan for SDO engagement
Scan the standards & implementation
environment
Develop a “Candidate
Standards” list
Support standards analysis against
requirementsConfirm Gaps
Work with WG and SDOs to create plan
and recommendations to
address gaps
Foun
datio
nCo
ntrib
ution
Actio
n
Resu
lt
Initi
ative
Pro
gres
s
Harmonize
Develop Guidance
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
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
• 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
Selected Standards
Recommended Standards
How standards flow through an S&I Initiative
22
Candidate Standards
Implementation Guidance
Technical & Standards DesignReview and achieve Candidate Standards consensusAnalyze standards against HITSC CriteriaKeep RTM updated with all necessary contentMap UCR to standards in documented crosswalkDevelop gap mitigation planDevelop solution plan Document risks, issues and obstaclesReview with community and achieve consensus
Standards HarmonizationDevelop new standard(s)Modify/harmonize existing standard(s)Achieve community consensus or agreement
Implementation GuidanceDevelop Implementation Guidance & ExamplesDocument IG Conformance Statements in RTMAchieve community consensus or agreement
SDO BallotingDevelop balloting artifacts
Standards Development & Harmonization: Targeted Activities
23
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
Technical & Standards Design:Technical Design Document• The purpose of the S&I Technical and Standards Design
Document is to:
1. Provide granular-level of technical detail to the business & functional requirements outlined in the Use Case
2. Document an overall technical & standards design approach for the initiative
3. 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
Technical & Standards Design:Table of Contents
Table of Contents
1.0 Introduction & Purpose..................................................................................................................................................... 1
2.0 Technical Analysis of Use Case Functional & Data Requirements .................................................................................... 1
2.1 In-Scope Requirements Analysis ................................................................................................................................... 1
2.1.1 Information Interchange Functions ........................................................................................................................... 1
2.1.2 System Functions ....................................................................................................................................................... 2
2.1.3 Data Requirements .................................................................................................................................................... 3
2.2 Out-of-Scope Requirements Analysis............................................................................................................................ 3
2.3 Solution Diagram ........................................................................................................................................................... 4
2.4 Data Model/Content Approach .................................................................................................................................... 4
3.0 Solution Analysis ............................................................................................................................................................... 4
3.1 Identify Existing Solutions or Modules for Re-Use ........................................................................................................ 4
3.2 Evaluate Candidate Standards ...................................................................................................................................... 4
4.0 Solution Mapping .............................................................................................................................................................. 5
4.1 UCR-Standards Crosswalk & Gap Identification ............................................................................................................ 5
4.2 Solution Plan ................................................................................................................................................................. 5
4.2.1 Summary of Potential Changes to External Artifacts and Corresponding Ballot or Approval Process Considerations .................................................................................................................................................................... 5
4.2.2 Expected Artifacts to Support Solution Plan .............................................................................................................. 6
5.0 Technical Risks, Issues and Obstacles ............................................................................................................................... 7
Appendices .............................................................................................................................................................................. 7
Appendix A: References ..................................................................................................................................................... 7
Appendix B: Key Terms ....................................................................................................................................................... 7
Technical & Standards Design:Technical Feasibility Analysis2.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 AnalysisSection 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 Analysis2.3 Solution Diagram 2.4 Data Model/Content Approach
Technical & Standards Design:Technical Feasibility Analysis2.1.1 Information Interchange FunctionsSection 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?
ID System Functional Role Technical Role
Information Interchange
Requirement Name
Exchange Type
Additional Supporting Exchanges
Technical Feasibility
Include in Technical Design
(Y/N)
II01 Electronic Health Record System
Order Placer Sender Laboratory Test Requisition
Push
II02 Laboratory Information System
Order Receiver Receiver Laboratory Test Requisition
Push
Technical & Standards Design: Technical Feasibility Analysis
2.1.2 System FunctionsSection 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.
ID System System Requirement Technical Feasibility Include in Technical Design (Y/N)
S01 Electronic Health Record System
Generate an Electronic Laboratory Requisition with Standardized Structured Data
S02 Laboratory Information System
Process Electronic Laboratory Requisition
S03 Laboratory Information System
Link Laboratory Requisition to Appropriate Laboratory Results
S04 Laboratory Information System
Generate and Send Laboratory Order Status
S05 Electronic Health Record System
Process Laboratory Order Status
Technical & Standards Design:Technical Feasibility Analysis
2.2 Out-of-Scope Requirements AnalysisSection 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 optionsFor 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.
Requirement Type Requirement Details Reason for
Excluding
Consider When Defining Infrastructure Requirements (Y/N)
Consider When Defining Implementation Options (Y/N)
Consider When Designing Technical Architecture (Y/N)
If requires inclusion in design: User-generated ID
Assumption Appropriate security and transport protocols; patient identification methodology; requisition (order) identification methodology; consent; privacy and security procedures; coding, vocabulary and normalization standards have been agreed to by all relevant participants.
Functionally Out of Scope
Y Y Y A01
Technical & Standards Design:Technical Feasibility Analysis2.1.3 Data RequirementsSection 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 ApproachSection 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.
IDData
Element Set/ Section
Data Element
Data Type Cardinality Optionality
Value and/or
Code Sets
List applicable Information
Interchange IDs
Technical Feasibility
D01 D02
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.
Technical & Standards Design:Technical Feasibility Analysis
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
Technical & Standards Design:Candidate Standards & Evaluation
Technical & Standards Design:Candidate Standards & Evaluation
3.2 Evaluate Candidate StandardsSection Description: There are two major steps for completing this section:1. Using the candidate standards list as a starting point pull in all of the standards to the table
below and document the design relevance. 2. 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.
Standard Relevant to Design? Description
Laboratory Results Interface Implementation Guide
Yes The LOI solution will need to take into account the solution for LRI as that documents the follow-on processes after LOI is executed.
HL7 2.5.1. Messaging Standard
Yes This is a messaging standard that should be considered in support of LOI requirements.
LOINC No LOINC will be part of the transaction, but does not need to be taken into consideration for solution design.
Technical & Standards Design:Standards Crosswalk & Gap-Mitigation Plan
4.0 Solution Mapping
4.1 UCR-Standards Crosswalk & Gap IdentificationSection 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.
ID Standard Standards Gap
II01 HL7 Messaging Standard Version 2.5.1
Technical & Standards Design:Solution Plan & Issues, Risks, Obstacles4.2 Solution PlanSection 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 ObstaclesSection Description: The Risks, Issues and Obstacles section lists the concerns that might interfere with meeting the proposed Technical and Standards Design.
ID Recommendation Summary of Design Solution Incorporate into Final Design (Y/N)
II01 Populate with: extension, modification, or creation of new or existing standards or profiles
Add additional details about how this would fit into an overall solution and what implementation guidance (e.g. constrain use of a data element to specific values) would be required to meet requirement
This determination should include whether or not the complexity of the recommendation and/or design solution is at an acceptable level.
4.2.1 Summary of Potential Changes to External Artifacts and Corresponding Ballot or Approval Process ConsiderationsSection 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”
Technical & Standards Design:Solution Plan & Issues, Risks, Obstacles
Standard or External
Guidance Artifact
Summary of Required Changes
Owning Organization (e.g. the SDO
name)
Organization’s Ballot Process, Timelines and other Considerations
Organization Contact
4.2.2 Expected Artifacts to Support Solution PlanSection 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:
Technical & Standards Design:Solution Plan & Issues, Risks, Obstacles
Artifact Name Description LocationStandards Analysis Matrix Facilitates the evaluation of standards according to the following: 1) Maturity of
Standards and Technology, and 2) Deployment/Operational Complexity and Market Adoption; the process includes evaluation of “broad” and “detailed” criteria. This is based on FACA recommendations on evaluation criteria developed by HITSC’s NwHIN WG.
Included above (see 3.2 Evaluate Candidate Standards)
Standards-UCR Crosswalk Used as a means to capture the applicability of candidate standards to the user scenarios, use cases and requirements documented in the Use Case.
Included above (see 4.1 UCR-Standards Crosswalk & Gap Identification)
Extension, modification, or creation of new or existing standards or profiles
Identifies standards or profiles that will need to be modified in order to support or align with the initiative’s solution. It also documents the owning organization and corresponding approval process for getting changes incorporated, which can be a factor in determining if standard is worth including within the solution.
Included above (see 4.2.1 Summary of Potential Changes to External Artifacts and Corresponding Ballot or Approval Process Considerations)
Initiative Data Dictionary (previously referred to as “High-Level Data Model”)
Captures data elements, data types, and cardinality that will be required to support the initiative’s solution.
Not yet created
Implementation Guidance Provides clear, unambiguous recommendations and guidance to the commercial vendor or open-source communities. The IG is intended to address the scope and needs of an Initiative.
Not yet created
Requirements Traceability Matrix (RTM)
The RTM document is created after the completion of the Use Case and updated throughout the lifecycle of the initiative. Completion of this document will not have any direct impact on the RTM, but the Implementation Guidance (IG), which is developed based on the analysis performed within this document, will inform the population of IG conformance statements within the RTM.
Add link to file on wiki, if applicable
AppendicesThe 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.
Technical & Standards Design:Appendices
Appendix A: References
Document Name Description Location<Document Name and Version Number>
<Document description> <URL or Network path where document is located>
Appendix B: Key Terms
Term Definition<Insert Term> <Provide definition of term and acronyms used in this document.>
Technical & Standards Design:Requirements Traceability Matrix
Use Case Requirements Technical Design
UCR ID Description UC Actor Requirement Type
Technical Feasibility
Included in Technical
Design (Y/N)
Standard or Value/Code Set
Selected to support exchange
Status of standards to support exchange
Ready for use
Modification required
Development required
UCR_1.00Example description 1 Provider
Information Interchange Feasible Yes CDA R2 x
UCR_1.01Example description 2 EHR System System Feasible Yes HL7 2.5.1 x
UCR_1.02Example description 3 EHR System System Not feasible No HQMF x
UCR_1.03Example description 4 End User
Information Interchange
Feasible with additional modifications Yes QRDA x
UCR_1.04Example description 5 EHR System Data
Feasible with existing code sets No LOINC x
UCR_1.05 UCR_1.06
UCR_1.07 UCR_1.08
Standards Harmonization:Standard Development or Modification
S&I Framework and SDO balloting
alignment
Subject Matter Expertise
contribution
SDO engagementInitiative
Community involvementModify
a standar
d
Implementation Guidance:Develop Implementation Guidance
Template Table of Contents for Development
1 Introduction2 Use Case Overview3 Implementation Approach4 Data Types5 Messages6 Code Systems and Value Sets7 Development Resources8 Appendices
– A Suggested Enhancements– B Acronyms– C Definitions– D Working Examples– E Conformance Statement Review– F References– G Implementation Alignment to Requirements
Implementation Guidance:Requirements Traceability Matrix
Implementation Guidance Conformance Statements Testing
IGCS ID IG Section Description Conformance
LevelMapped
UCRs
Mapped StandardsPull from
previous tab
Test Case ID
Test Scenarios Test Case Expected
Results
Pilot Status
Pilot Site #1
Pilot Site #2
IGCS_1.00 1.1Example description 1 Shall
UCR_1.00, UCR_X.XX CDA R2, LOINC TC_1.00
Example scenario 1
Example test case 1
Example results 1 Passed N/A
IGCS_1.01 2.1Example description 2 Should UCR_1.00 HL7 2.5.1 TC_1.01
Example scenario 2
Example test case 2
Example results 2 Failed N/A
IGCS_1.02 3.1Example description 3 May UCR_1.01 HQMF, QRDA TC_1.02
Example scenario 3
Example test case 3
Example results 3 Passed Passed
IGCS_1.03 4.1Example description 4 May UCR_1.02 HQMF TC_1.03
Example scenario 4
Example test case 4
Example results 4 Passed Passed
IGCS_1.04 IGCS_1.05 IGCS_1.06 IGCS_1.07 IGCS_1.08
Implementation Guidance:Balloting Considerations
Flow of Standards & Harmonization Activities
44
Activity Informing Artifacts Resulting Work Product
Pre-Discovery A. Charter ConsensusB. Candidate Standards
Use Case & Functional Requirements A. Charter Consensus
C. Use Case & Functional requirementsD. Data Requirements
Standards &
Harmonization
Standards Evaluation & Technical Design
B. Candidate StandardsC. Functional requirementsD. Data requirements
E. Standards Evaluation & UCR-Standards Crosswalk (Recommended Standards)F. Technical Design Document (Technical Requirements)
Standards Modificationor Development
E. Recommended StandardsF. Technical Requirements G. Updated or modified Standards
Implementation Specifications
F. Technical RequirementsG. Updated or modified Standards H. Implementation Specifications
BallotingG. Updated or modified StandardsH. Implementation SpecificationsI. Balloting artifacts
J. Balloted standards, Implementation Guides, and other artifacts
The final result...!
• Updated, balloted standards
• Implementation Guidance for end-users
• Traceability to the UC & Functional
Requirements
• Setting the stage for pilots
• 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
Next Steps
Questions?
Contact Information• For questions, please contact your support leads
– Coordinator: • Ken Kawamoto: [email protected]
– Co-Coordinators:• Aziz Boxwala: [email protected]• Bryn Rhodes: [email protected]
– ONC Leadership: • Alicia Morton: [email protected]
– Project Management:• Jamie Parker: [email protected] • Christina Arenas: [email protected]
– Use Case 2:• Dave Shevlin: [email protected] • Virginia Rhiel: [email protected]
– Harmonization: • Lynette Elliot: [email protected] • Merideth Vida: [email protected] • Anna Langhans: [email protected]
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