Health eDecisions (HeD) All Hands Meeting May 9th, 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 TopicTime Allotted Announcements5 minutes Work Stream 1 Update: HL7 Meeting Update 5 minutes Work Stream 2 Update: Pilots5 minutes Work Stream 3: Use Case 265 minutes Next Steps5 minutes Wrap up/Questions5 minutes

Announcements Vocabulary and Terminologies sub work will be meeting this week ????? –Friday 12:30-1:30 EDT – May HL7 Meeting May 5-10 th HeD will have no formal meetings There will be discussion on the vMR We are starting the preparation process for balloting UC 2 through HL7 in September –Stay tuned for updates and ways to participate

HL7 Update We have completed a rough draft of the Implementation Guide – The Vocabulary and Terminology IG is also complete and will be incorporated into our IG. –To view and comment on the work of the Vocab and Terminology team please see the pilots tool page: We met this week and approved the pending issues as discovered during the Pilot process with CDC: –Next week: we will determine after HL7 meeting if we need to meet next week ) We are beginning the process of preparing UC 2 for HL7 balloting –We will resume these meetings in the near future for UC 2 disscussions

HeD Pilots Update We met this week Pilots Update –CDC and Practice Fusion –ECA Rule Aziz is working on the transformation from HQMF to HeD (90% complete) –There will be 2 rules – one of the Laboratory and one for the clinic –NewMentor and AllScripts – ECA Rule (98% complete) The team has transformed the NQF 0068 (Million Hearts) into HeD and then into the Allscripts native format (CREF) The initial pass was completed and we have successfully loaded the rule into the AllScripts test environment –Still need tweaks –Zynx and DesignClinicals - Order Set (60% complete) Working on simple and complex order sets –VA and Wolters Kluwer - Documentation Template (75% complete) UTI Documentation Template was transformed into HeD schema Wolters Kluwer is checking the rule to ensure it captures what is needed Ken, Robert Lario and Dave Sheilds are working with the VA to prepare for the final rule to be implemented into their system.

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 Sets 3.Documentation Templates Pilot Scope 1.Health eDecisions will apply defined aspects of the Implementation Guide in a real-world setting. 2.Modify the Implementation Guide to ensure it is usable 3.Submission of explicit feedback to sub workgroups such as vMR and Vocabulary and Terminology work group to close gaps 4.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. 5.Demonstrate intent of artifact (specifically structures and semantics) are communicated either by direct execution or by translation to native format 6.Ensure completeness and consumability of artifact New

Timeline 10/11/20118 We are Here Goal & Activities EST. Time DatesDeliverables 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 4 wks. (reality 5 weeks) 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 2 wks. (reality- 4 weeks) 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 3/25 – 5/6 -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 2wks5/6 -5/20-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.5/20 – 6/3-Documented ONC Feedback - Next Steps Action Plan

Vendor Partners 10/11/20119 EHRArea of InterestPotential or Actual Match Design ClinicalsOrder SetsZynx AllScriptsECA Rules –NQMF Rule (for Ambulatory Setting) – Million Hearts NewMentor (have catalog for rules in ambulatory setting) Practice FusionAnything MU centered CDC (also may need Artifact supplier to help) Wolters Kluwer NewMentor (MU rule as example) VADocumentation Template Wolters Kluwer

HeD Use Case 2

Ongoing/Planned Activities for Week of 5/6 FINAL feedback of the Selected Standards due by COB on Tuesday, 5/7 Gap Mitigation and Solution plan will be reviewed with the SWG on 5/8 and All Hands WG on 5/9. Initial feedback will be due COB 5/14 Will hold working sessions at the SWG and All Hands WG meetings Populating Data Requirements Table Internally. Formatting the IG template for HeD UC2 Determining which sections will be populated internally, which sections will be community homework, and which sections can be pulled from prior documents (UC2, TSDD, etc..) FINAL feedback of the Selected Standards due by COB on Tuesday, 5/7 Gap Mitigation and Solution plan will be reviewed with the SWG on 5/8 and All Hands WG on 5/9. Initial feedback will be due COB 5/14 Will hold working sessions at the SWG and All Hands WG meetings Populating Data Requirements Table Internally. Formatting the IG template for HeD UC2 Determining which sections will be populated internally, which sections will be community homework, and which sections can be pulled from prior documents (UC2, TSDD, etc..)

Use Case 2 – CDS Guidance Service Transactions CDS Guidance Requestor 2. CDS Response (Clinical Data, Supporting Evidence, Supporting Reference, Actions, Attribute-Value List, Response Metadata & Exceptions) CDS Guidance Supplier 1. CDS Request (Clinical Data & Context) INSERT SELECTED STANDARDS HERE

Transport and Security Transactional Layers 13 Transport and Security Response Service: e.g., DSS Response Element Response Items Organizer/Container: e.g., HeD Action Groups Element Response Item Payload: e.g., VMR Proposal Request Service: e.g., DSS Request Element Request Items Organizer/Container: e.g: VMR or CCDA Request Item Payload: e.g., VMR Clinical Statement

Transactional Layers Discussion –The diagram shows Payload being subdivided into “wrapper” and “detail”, which I don’t think matches the way DSS is designed to work, or the real content structure that we want. –My understanding is that DSS has a data payload, period. This applies to both request and response. That payload is either vMR or it is something else, but it is a single defined payload. –The vMR is not designed to be separated into individual Clinical Statements as “payload details” to be attached to another set of elements, because various details inherit from the root of the model. –When the vMR was first developed, a wrapper class was also developed in the model to provide context (i.e., non-patient data relevant to the task), and that model needs to be extended to include additional elements identified by the work group. –It seems to me that the functionality defined in the HeD UC1 artifacts for “Action Groups” as outputs more properly belong in the wrapper class “cdsOutput” as part of the vMR. This seems to me to be a much more consistent approach, because the response is a static object (a single Payload) as far as the DSS transaction is concerned, even if it contains structures requiring the recipient to make a “choice” between multiple sets. –cdsOutput class currently does not provides functionality like the ability to group actions/clinical statements and to annotate them with behaviors 14

Transactional Layers Discussion –CdsOutput was created as a placeholder for structuring output, which could have the advantage of keeping the input and output payloads for the DSS wrapped in a single standard specification, which could then provide for additional standards contributing for some or all of the content, as required. cdsInput (carrying context and supporting metadata) vMR or CCDA cdsOutput (carrying output metadata / action groups / whatever else needed to wrap the output) vMR or CCDA or HeD Order Set or Hed Documentation Template or ? depending on the requirements of the KM invoked 15

Use Case 2: CDS Guidance Service Transactions - Standards per Transaction #TransactionServiceOrganizer/ContainerItem Payloads Reference Information Model 1 CDS Request (patient data and potentially context) Decision Support Service (DSS) Context Aware Retrieval Application (Infobutton) CDS Knowledge Artifact Implementation Guide (HeD UC1 IG) Consolidated CDA Virtual Medical Record (vMR) Context Aware Retrieval Application (Infobutton) Virtual Medical Record (vMR) Consolidated CDA (hL7 Clinical Statements) HL7 Version 3 Standard: Order Set Publication, Release 1 Federal Health Information Model (FHIM) HL7 v2.x HL7 v3 2 CDS Response (guidance and/or other response elements) Decision Support Service (DSS) Context Aware Retrieval Application (Infobutton) CDS Knowledge Artifact Implementation Guide (HeD UC1 IG) HL7 Version 3 Standard: Order Set Publication, Release 1 Consolidated CDA Virtual Medical Record (vMR) Context Aware Retrieval Application (Infobutton) Virtual Medical Record (vMR) Consolidated CDA (HL7 Clinical Statements) HL7 Version 3 Standard: Order Set Publication, Release 1 Federal Health Information Model (FHIM) HL7 v2.x HL7 v3

Use Case 2: CDS Guidance Service Transactions - Standards per Transaction #TransactionTransport Authentication/ Authorization EncryptionVocab & Code Set 1 CDS Request (patient data and potentially context) SOAP REST SAML TLS LOINC SNOMED CT CVX Manufacturers of Vaccines (MVX) OID RxNorm ICD-9-CM and ICD-10-CM HCPCS C80 - Clinical Document and Message Terminology Component NQF Value Sets ICD-10-PCS UCUM CPT C154 NDC FDA Route Administration HL7 Vocabulary Diagnostic and Statistical Manual of Mental Disorders, Fourth Edition (DSM-IV) 2 CDS Response (guidance and/or other response elements) SOAP REST SAML TLS LOINC SNOMED CT CVX Manufacturers of Vaccines (MVX) OID RxNorm ICD-9-CM and ICD-10-CM HCPCS C80 - Clinical Document and Message Terminology Component NQF Value Sets ICD-10-PCS UCUM CPT C154 NDC FDA Route Administration HL7 Vocabulary Diagnostic and Statistical Manual of Mental Disorders, Fourth Edition (DSM-IV)

CDS Guidance Request Transaction: Service Standards Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale Decision Support Service (DSS) HITSC Rating:* M: A: 88.6 SI: T: (Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions (P) Partially Fits: Response Metadata; (N) Does not Fit: Yes One significant gap is DSS will tie to SOAP. There is significant industry movement towards REST. DSS has 2 levels, one is model of the service which is implementation agnostic. Could support standard with implementation based on REST, but it would have to be developed. DSS is designed to be able to support patient data, unlike Infobutton. Has broader scope than Infobutton * M: Maturity A: Adoptability SI: S&I Specific T: Total Context Aware Retrieval Application (Infobutton) HITSC Rating* M: A: SI: T: (Y) Fits: Context; Supporting Evidence; Supporting Resource (P) Partially Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response (N) Does not Fit: Clinical; Actions; Attribute Value List; Response Meta Data No Can send some patient data, but not designed to support rich patient data payload like DSS

CDS Guidance Response Transaction: Service Standards Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale Decision Support Service (DSS) HITSC Rating:* M: A: 88.6 SI: T: (Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions (P) Partially Fits: Response Metadata; (N) Does not Fit: Yes One significant gap is DSS will tie to SOAP. There is significant industry movement towards REST. DSS has 2 levels, one is model of the service which is implementation agnostic. Could support standard with implementation based on REST, but it would have to be developed. DSS is designed to be able to support patient data, unlike Infobutton. Has broader scope than Infobutton * M: Maturity A: Adoptability SI: S&I Specific T: Total Context Aware Retrieval Application (Infobutton) HITSC Rating:* M: A: SI: T: (Y) Fits: Context; Supporting Evidence; Supporting Resource (P) Partially Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response (N) Does not Fit: Clinical; Actions; Attribute Value List; Response Meta Data No Can send some patient data, but no designed to support rich patient data payload like DSS

CDS Guidance Request Transaction: Organizer/Container Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale CDS Knowledge Artifact Implementation Guide (HeD UC1 IG) HITSC Rating:* M: A: SI: T: (Y) Fits: (Sender) CDS Response; (Receiver) CDS Response; Clinical; Supporting Evidence; Supporting Resource; Actions; Attribute Value List; (P) Partially Fits: Context; Response Metadata (N) Does not Fit: Exceptions No UC1 is not designed to carry patient data If CCDA is chosen, would probably have to use related HL7 Clinical statements for the Item Payload bucket. If vMR is chosen, would probably have to use the vMR Clinical Statements for the Item Payload bucket External options may exist for transforming CCDA request into a vMR component Develop options for both CCDA and vMR * M: Maturity A: Adoptability SI: S&I Specific T: Total Consolidated CDA HITSC Rating:* M: A: SI: T: (Y) Fits: Clinical; (P) Partially Fits: (N) Does not Fit: Context, Supporting Evidence; Supporting Resource; Actions; Attribute Value List; Response Metadata; Exceptions Yes Can transform CCDA request into a vMR component from the execution system Not everything from CCDA goes easily into vMR, but vMR is designed to easily accept CCDA components

CDS Guidance Request Transaction: Organizer/Container Rationale (continued…) Standard Summary of Findings from UCR Crosswalk Keep?Rationale Virtual Medical Record (vMR) HITSC Rating:* M: A: SI: T: (Y) Fits: Clinical; Attribute Value List (P) Partially Fits: CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Context; Supporting Evidence; Supporting Resource; Actions; (N) Does not Fit: Response Metadata; Exceptions Yes Lighter weight than the other options Developed specifically for clinical decision support computability Intended to be used for this initiative, and has recently been enhanced in this respect * M: Maturity A: Adoptability SI: S&I Specific T: Total

CDS Guidance Response Transaction: Organizer/Container Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale CDS Knowledge Artifact Implementation Guide (HeD UC1 IG) HITSC Rating:* M: A: SI: T: (Y) Fits: (Sender) CDS Response; (Receiver) CDS Response; Clinical; Supporting Evidence; Supporting Resource; Actions; Attribute Value List; (P) Partially Fits: Context; Response Metadata (N) Does not Fit: Exceptions Yes Fits Clinical; Supporting Evidence; Supporting Resource; Actions data requirements Attribute value list is not supported in UC1 schema, however the schema does allow extensions using XSD Would use subset of HeD UC1 schema that may require further modifications * M: Maturity A: Adoptability SI: S&I Specific T: Total Consolidated CDA HITSC Rating:* M: A: SI: T: (Y) Fits: Clinical; (P) Partially Fits: (N) Does not Fit: Context, Supporting Evidence; Supporting Resource; Actions; Attribute Value List; Response Metadata; Exceptions Probably No There is a profile in IHE that uses DSS and returns IHE as an output. But hasn’t been finalized within IHE Lacks the ability to group and organize things the way that UC1 does Do not anticipate using, unless modification or subset of UC1 approach does not work

CDS Guidance Response Transaction: Organizer/Container Rationale (continued…) Standard Summary of Findings from UCR Crosswalk Keep?Rationale Virtual Medical Record (vMR) HITSC Rating:* M: A: SI: T: (Y) Fits: Clinical; Attribute Value List (P) Partially Fits: CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Context; Supporting Evidence; Supporting Resource; Actions; (N) Does not Fit: Response Metadata; Exceptions No (Probably) Does fit this situation, however CDS Knowledge artifact may be the better option UC1 action would need to be modified to represent payload for UC2 regarding vMR May need a model agnostic response Do not anticipate using, unless modification or subset of UC1 approach does not work * M: Maturity A: Adoptability SI: S&I Specific T: Total HL7 Version 3 Standard: Order Set Publication, Release 1 HITSC Rating:* M: A: SI: T: (Y) Fits: Supporting Evidence; Supporting Resource; Response Metadata (P) Partially Fits: Clinical; Context; Actions (N) Does not Fit: Attribute Value List; Exceptions No (Probably) Some vendors may want to support this as an option, however CDS Knowledge Artifact is the better option Adoption of this standard is low, so there is not a driving reason to extend support to it

CDS Guidance Request Transaction: Item Payloads Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale Context Aware Retrieval Application (Infobutton) HITSC Rating M: A: SI: T: (Y) Fits: Context; Supporting Evidence; Supporting Resource (P) Partially Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response (N) Does not Fit: Clinical; Actions; Attribute Value List; Response Meta Data No The information that is contained in infobutton is already represented in vMR, or if not can be Can use infobutton as a reference to modify vMR or CCDA * M: Maturity A: Adoptability SI: S&I Specific T: Total Virtual Medical Record (vMR) HITSC Rating:* M: A: SI: T: (Y) Fits: Clinical; Attribute Value List (P) Partially Fits: CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Context; Supporting Evidence; Supporting Resource; Actions; (N) Does not Fit: Response Metadata; Exceptions Yes The vMR has relevant information in a reasonable format The contents and scope of the vMR are aligned with the requirements of the Use Case Maintained by CDS WG As a reference model, part of its purpose is to provide exchangeable representation clinical information

CDS Guidance Request Transaction: Item Payloads Rationale (Continued…) Standard Summary of Findings from UCR Crosswalk Keep?Rationale Consolidated CDA HITSC Rating:* M: A: SI: T: (Y) Fits: Clinical; (P) Partially Fits: (N) Does not Fit: Context, Supporting Evidence; Supporting Resource; Actions; Attribute Value List; Response Metadata; Exceptions Yes Several stake holders have a business need to have this supported A methodology is needed to be able to reflect changes, which currently does not exist * M: Maturity A: Adoptability SI: S&I Specific T: Total HL7 Version 3 Standard: Order Set Publication, Release 1 HITSC Rating:* M: A: SI: T: (Y) Fits: Supporting Evidence; Supporting Resource; Response Metadata (P) Partially Fits: Clinical; Context; Actions (N) Does not Fit: Attribute Value List; Exceptions No Order Set does not hold patient data, not suitable for request transaction

CDS Guidance Response Transaction: Item Payloads Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale Context Aware Retrieval Application (Infobutton) HITSC Rating:* M: A: SI: T: (Y) Fits: Context; Supporting Evidence; Supporting Resource (P) Partially Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response (N) Does not Fit: Clinical; Actions; Attribute Value List; Response Meta Data No The information that is contained in infobutton is already represented in vMR, or if not can be Can use infobutton as a reference to modify vMR or CCDA * M: Maturity A: Adoptability SI: S&I Specific T: Total Virtual Medical Record (vMR) HITSC Rating:* M: A: SI: T: (Y) Fits: Clinical; Attribute Value List (P) Partially Fits: CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Context; Supporting Evidence; Supporting Resource; Actions; (N) Does not Fit: Response Metadata; Exceptions Yes The vMR has relevant information in a reasonable format The contents and scope of the vMR are aligned with the requirements of the Use Case Maintained by CDS WG As a reference model, part of its purpose is to provide exchangeable representation clinical information

CDS Guidance Response Transaction: Item Payloads Rationale (Continued…) Standard Summary of Findings from UCR Crosswalk Keep?Rationale Consolidated CDA HITSC Rating:* M: A: SI: T: (Y) Fits: Clinical; (P) Partially Fits: (N) Does not Fit: Context, Supporting Evidence; Supporting Resource; Actions; Attribute Value List; Response Metadata; Exceptions Yes Several stake holders have a business need to have this supported A methodology is needed to be able to reflect changes, which currently does not exist * M: Maturity A: Adoptability SI: S&I Specific T: Total HL7 Version 3 Standard: Order Set Publication, Release 1 HITSC Rating:* M: A: SI: T: (Y) Fits: Supporting Evidence; Supporting Resource; Response Metadata (P) Partially Fits: Clinical; Context; Actions (N) Does not Fit: Attribute Value List; Exceptions Yes Order set model contains recommendations for clinical actions, which is applicable to the types of outputs relevant in the Use Case

CDS Guidance Request Transaction: Transport Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale SOAP HITSC Rating:* M: A: SI: T: (Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions (P) Partially Fits: (N) Does not Fit: Yes There is currently implementation guidance on DSS to be used with SOAP, not REST Has the capabilities and functions needed for this initiative * M: Maturity A: Adoptability SI: S&I Specific T: Total REST HITSC Rating:* M: A: SI: T: (Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions (P) Partially Fits: (N) Does not Fit: Yes Industry is moving towards using REST Guidance could be written for DSS to work with REST

CDS Guidance Response Transaction: Transport Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale SOAP HITSC Rating:* M: A: SI: T: (Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions (P) Partially Fits: (N) Does not Fit: Yes There is currently implementation guidance on DSS to be used with SOAP, not REST Has the capabilities and functions needed for this initiative * M: Maturity A: Adoptability SI: S&I Specific T: Total REST HITSC Rating: M: A: SI: T: (Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions (P) Partially Fits: (N) Does not Fit: Yes Industry is moving towards using REST Guidance could be written for DSS to work with REST

CDS Guidance Request Transaction: Authentication/Authorization Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale SAML HITSC Rating:* M: A: SI: T: (Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions (P) Partially Fits: (N) Does not Fit: * M: Maturity A: Adoptability SI: S&I Specific T: Total

CDS Guidance Response Transaction: Authentication/Authorization Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale SAML HITSC Rating:* M: A: SI: T: (Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions (P) Partially Fits: (N) Does not Fit: * M: Maturity A: Adoptability SI: S&I Specific T: Total

CDS Guidance Request Transaction: Encryption Standard Summary of Findings from UCR Crosswalk Keep?Rationale TLS HITSC Rating:* M: A: SI: T: (Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions (P) Partially Fits: (N) Does not Fit: * M: Maturity A: Adoptability SI: S&I Specific T: Total

CDS Guidance Response Transaction: Encryption Standard Summary of Findings from UCR Crosswalk Keep?Rationale TLS HITSC Rating:* M: A: SI: T: (Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions (P) Partially Fits: (N) Does not Fit: * M: Maturity A: Adoptability SI: S&I Specific T: Total

Solution Plan View the different combination of standards, across the different buckets, and determine the viability of each implementation option Decide which implementation option(s), and therefore combination of standards, is the best approach Document reasons why certain implementation options were chosen or not chosen View the different combination of standards, across the different buckets, and determine the viability of each implementation option Decide which implementation option(s), and therefore combination of standards, is the best approach Document reasons why certain implementation options were chosen or not chosen

Solution Plan Next Steps Decide which implementation option(s), and therefore combination of standards, will be used as the approach in the IG and incorporated into the final design

Gap Mitigation Plan Identify any gaps for all standards under consideration Determine if the gap is for the request or response transaction, or both Document recommendations on how to close the gap (i.e. modification to existing standard) Identify any gaps for all standards under consideration Determine if the gap is for the request or response transaction, or both Document recommendations on how to close the gap (i.e. modification to existing standard)

Gap Mitigation Plan Next Steps: Pull out the standards which have gaps requiring modifications and document in the IG Contact the SDO to initiate modification needed Gaps that are related to a standard being utilized in a manner which it has not previously been designed for will be addressed and written into the IG Pull out the standards which have gaps requiring modifications and document in the IG Contact the SDO to initiate modification needed Gaps that are related to a standard being utilized in a manner which it has not previously been designed for will be addressed and written into the IG

Work Stream 1 – HL7: –Next HL7 meeting TBD –(see HeD Homepage wiki for meeting details: Work Stream 2 – Pilots: –We continue our Pilot activities –Next Pilots meeting: May 13th, 1-2:30 pm EDT see HeD home page wiki for meeting details: –Updates on Pilot Activities, Review of Timelines Work Stream 3 – Use Case 2: –Data Elements and Standards Sub Work Group Next Meeting: May 15 th, 2013 Homepage wiki for meetings: All Hands Community Meeting –We will reviewing candidate standards –Next meeting May 16 th, 2013(see the HeD Homepage wiki for meeting details: Next Steps

Questions?

Contact Information For questions, please contact your support leads –Coordinator: Ken Kawamoto: –Co-Coordinators: Aziz Boxwala: Bryn Rhodes: –ONC Leadership: Alicia Morton: –Project Management: Jamie Parker: –Use Case 2: Dave Shevlin: Virginia Rhiel: –Harmonization: Lynette Elliot: Anna Langhans:

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