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

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