1. Health eDecisions (HeD) All Hands Meeting May 16th, 2013

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

3. Agenda TopicTime Allotted Announcements5 minutes Work Stream 1 Update: HL7 Meeting Update 5 minutes Work Stream 2 Update: Pilots5 minutes vMR Overview – Dave Shields, Claude Nanjo 45 minutes C-CDA Overview - Calvin Beebe45 minutes Wrap up/Questions5 minutes

4. Announcements Vocabulary and Terminologies sub work will be meeting this week Friday 12:30-1:30 EDT –http://wiki.siframework.org/Health+eDecisions+Homepagehttp://wiki.siframework.org/Health+eDecisions+Homepage Updates from the HL7 Meeting –vMR updates We are starting the preparation process for balloting UC 2 through HL7 in September –Stay tuned for updates and ways to participate –We are submitting the Project Scope Statement (PSS) this week for Use Case 2 (due May 17 th ) AMIA????

5. HL7 Update We have completed a rough draft of the Implementation Guide –http://wiki.siframework.org/HeD+Pilot+Toolshttp://wiki.siframework.org/HeD+Pilot+Tools 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: http://wiki.siframework.org/HeD+Pilot+Tools http://wiki.siframework.org/HeD+Pilot+Tools 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 http://wiki.siframework.org/Health+eDecisions+Homepage )http://wiki.siframework.org/Health+eDecisions+Homepage 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

6. 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.

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

8. 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

9. 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 Fusion/ AllScripts Anything MU centered CDC (also may need Artifact supplier to help) Wolters Kluwer NewMentor (MU rule as example) VADocumentation Template Wolters Kluwer

10. vMR Overview Presented by Claude Nanjo and Dave Shields

11. Overview of C-CDA Health eDecisions All Hands Community Meeting May 16, 2013 C. Beebe

12. Presenter Calvin E. Beebe cbeebe@mayo.edu Technical Specialist Mayo Clinic, Rochester MN Co-editor - CDA R1, CDA R2 Author - CDA Certification Exam Co-chair - HL7 Structured Documents Member - HL7 Technical Steering Committee Treasure- HL7 Board of Directors

13. Today’s Topics –What’s in the C-CDA Implementation Guide –Review sample C-CDA document –Identify HL7 & other useful resources –Summary

14. 01/01/201114

15. Basic C-CDA 101 Technical Name: HL7 Implementation Guides for CDA Release 2: IHE Health Story Consolidation, DSTU Release 1.1 - US Realm Called: Consolidated CDA, C-CDA … –The C-CDA contains a library of CDA templates. –Updates 11 CDA document types, including CCD –Harmonizes previous HL7, IHE, HITSP efforts It consolidated previous document templates into a single library, resolving conflicts, ambiguities as needed!

16. HL7’s CDA vs. C-CDA CDA The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. C-CDA The HL7 Consolidated CDA is an implementation guide which specifies a library of templates and proscribes their use for a set of specific document types. defines a set of CDA documents! the schema for those documents!

17. Consolidated CDA (C-CDA) C-CDA History and Physical Discharge Summary Consultation Notes Diagnostic Imaging Rpt Procedure Note Operative Note Progress Note Unstructured Documents HL7 Health Story Implementation Guides CCDCCD ONC - CEHRT HITSP - C32, C80, C83 IHE – PCC HL7 – CCD HL7 – CDA Continuity of Care Document

18. Consolidated CDA The guide contains a library of CDA templates, incorporating and harmonizing previous efforts from: Health Level Seven (HL7) Integrating the Healthcare Enterprise (IHE) Health Information Technology Standards Panel (HITSP) It includes harmonized HL7 Health Story guides, HITSP C32, related components of IHE Patient Care Coordination, and the Continuity of Care (CCD). It includes all required CDA templates in Final Rules for Stage 1 Meaningful Use and can support Stage 2 Meaningful Use requirements.*

19. Templated CDA: C-CDA, QRDA 01/01/201119 Figure1: Templated CDA A QRDA Category I report is an individual-patient-level quality report. Each report contains quality data for one patient for one or more quality measures. (126 Entry Templates)

20. HL7 C-CDA Implementation Guide Document Organization –Introduction –General Header Template –Document-Level Templates –Section-Level Templates –Entry-Level Templates –Appendix Template IDs, Code Systems, Value Sets, Extensions, …

21. Consolidated CDA Documents H&P Diagnostic Imaging Consult Surgical Operation Progress Procedure Discharge Summary Unstructured (Non-XML Body) Unstructured (Non-XML Body) CCD 9 Document Types

22. 74 C-CDA Sections Advance Directives Section (entries optional) Advance Directives Section (entries required) Allergies Section (entries optional) Allergies Section (entries required) Anesthesia Section Assessment and Plan Section Assessment Section Chief Complaint and Reason for Visit Section Chief Complaint Section Complications Section DICOM Object Catalog Section - DCM 121181 Discharge Diet Section Encounters Section (entries optional) Encounters Section (entries required) Family History Section Fetus Subject Context Findings Section (DIR) Functional Status Section General Status Section History of Past Illness Section History of Present Illness Section Hospital Admission Diagnosis Section Hospital Admission Medications Section (entries optional) Hospital Consultations Section Hospital Course Section Hospital Discharge Diagnosis Section Hospital Discharge Instructions Section Hospital Discharge Medications Section (entries optional) Hospital Discharge Medications Section (entries required) Hospital Discharge Physical Section Hospital Discharge Studies Summary Section Immunizations Section (entries optional) Immunizations Section (entries required) Implants Section Instructions Section Interventions Section Medical (General) History Section Medical Equipment Section Medications Administered Section Medications Section (entries optional) Medications Section (entries required) Objective Section Observer Context Operative Note Fluids Section Operative Note Surgical Procedure Section Payers Section Physical Exam Section Plan of Care Section Planned Procedure Section Postoperative Diagnosis Section Postprocedure Diagnosis Section Preoperative Diagnosis Section Problem Section (entries optional) Problem Section (entries required) Procedure Description Section Procedure Disposition Section Procedure Estimated Blood Loss Section Procedure Findings Section Procedure Implants Section Procedure Indications Section Procedure Specimens Taken Section Procedures Section (entries optional) Procedures Section (entries required) Reason for Referral Section Reason for Visit Section Results Section (entries optional) Results Section (entries required) Review of Systems Section Social History Section Subjective Section Surgery Description Section Surgical Drains Section Vital Signs Section (entries optional) Vital Signs Section (entries required)

23. 65 C-CDA Entries Admission Medication Advance Directive Observation Age Observation Allergy Observation Allergy Problem Act Allergy Status Observation Boundary Observation Code Observations Comment Activity Coverage Activity Discharge Medication Drug Vehicle Encounter Activities Estimated Date of Delivery Family History Death Observation Family History Observation Family History Organizer Health Status Observation Hospital Admission Diagnosis Hospital Discharge Diagnosis Immunization Activity Immunization Medication Information Immunization Refusal Reason Indication Instructions Medication Activity Medication Dispense Medication Information Medication Supply Order Medication Use - None Known (deprecated) Non-Medicinal Supply Activity Plan of Care Activity Act Plan of Care Activity Encounter Plan of Care Activity Observation Plan of Care Activity Procedure Plan of Care Activity Substance Administration Plan of Care Activity Supply Policy Activity Postprocedure Diagnosis Precondition for Substance Administration Pregnancy Observation Preoperative Diagnosis Problem Concern Act (Condition) Problem Observation Problem Status Procedure Activity Act Procedure Activity Observation Procedure Activity Procedure Procedure Context Product Instance Purpose of Reference Observation Quantity Measurement Observation Reaction Observation Referenced Frames Observation Result Observation Result Organizer Series Act Service Delivery Location Severity Observation Social History Observation Sop Instance Observation Study Act Text Observation Vital Sign Observation Vital Signs Organizer

24. 38 C-CDA Code Systems ISO 3166-1 Country Codes DCM Internet Society Language Vaccines administered (CVX) Adminstrative Gender ActMood Religious Affiliation RoleClass RoleCode AddressUse ActStatus MaritalStatus LOINC NUCC Health Care Provider Taxonomy ICD9 CM Procedures CPT-4 Confidentiality Code National Cancer Institute (NCI) Thesaurus US Postal Codes Race and Ethnicity - CDC HealthcareServiceLocation ActCode EntityNamePartQualifier EntityNameUse ASC X12 LanguageAbilityMode LanguageAbilityProficiency NDF-RT ActPriority Unique Ingredient Identifier (UNII) ActReason ObservationInterpretation ParticipationFunction Participationsignature Unified Code for Units of Measure (UCUM) RXNorm FIPS 5-2 (State) SNOMED CT S&I Companion Guide references (links) on CEHRT Vocabularies:  CDT – Dental Codes  ICD – 10 CM / PCS  CPT – AMA Procedure Codes  ISO 639-2 Language Codes  HCPCS – Procedure Codes  LOINC – Lab Codes  CVX – HL7 table 0292  OMB Race / Ethnicity Codes  RxNorm – Medication Codes  SNOMED CT – via UMLS

25. C-CDA Header Constraints It describes constraints that apply to the header for all documents within the scope of this implementation guide. –Header constraints specific to each document type are described in the appropriate document-specific section below. SHALL contain: –realmCode –typeId –templateId –id –code –title –effectiveTime –confidentialityCode –languageCode  recordTarget w/ 1 patient name in US realm format administrativeGenderCode birthtime (precise to the year)  serviceEvent effectiveTime performer  author  custodian ethnicity preferred Language race  encompassing Encounter healthcareFacility responsibleParty encounterParticipant addr name

26. MU 2 - Document Types With respect to the Consolidated CDA, certification will not focus on a specific document- level template… Surprise! Rather, certification will focus on an EHR technology’s ability to properly implement the US Realm header and the associated section-level templates necessary to support each certification criterion in which the Consolidated CDA is referenced and for the appropriate data specified in each of those certification criteria. Where vocabularies are specified in § 170.207 the accompanying section- template must be implemented using structured data, i.e. coded entries required. Unstructured Document template is not permitted.

27. Document Types S&I performed a goodness of fitness assessment and deemed the C-CDA CCD best fit. 01/01/201127 However… MU3 advocates that the visit document should not simply be EMR extracts (need exact language!) You may want to start thinking about generating clinical notes based on C-CDA MU2 requirements. I.e. H&P Notes, Consult Notes, Diagnostic Imaging Notes, Surgical Notes, Progress Notes, Discharge Summary Notes. All said, for MU2 – the CCD seems like the likely target.

28. Continuity of Care Document

30. Consolidated CDA Sections MU2 Data RequirementsConsolidated CDA SectionCCD Advance Directives (entries optional)O Medication allergiesAllergies (entries required)R Encounters (entries optional)O Family HistoryO Functional Status; Cognitive StatusFunctional StatusO Discharge instructions (Inpatient setting)Hospital Discharge Instructions ImmunizationsImmunizations (entries optional)O Clinical instructions; Recommended patient decision aidsInstructions Medical EquipmentO MedicationsMedications (entries required)R PayersO Care plan, including goals and instructions; Future appointments; Future scheduled tests; Referrals to other providers; Diagnostic tests pending Plan of Care or Assessment and PlanO ProblemsProblem (entries required)R ProceduresProcedures (entries required)O Reason for Referral Reason(s) for visit or Reason(s) for hospitalization (Inpatient setting) Reason for Visit or Chief Complaint or Chief Complaint and Reason for Visit Laboratory Tests; Values/results of laboratory testsResults (entries required)R Smoking statusSocial HistoryO Vital signsVital Signs (entries optional)O We’ll take peek a the Problem section

31. Problem Section & Entries This section lists and describes all relevant clinical problems at the time the document is generated. At a minimum, all pertinent current and historical problems should be listed.

32. Problem Section & Entries

33. Problem Section with Coded Entries Required Two types of Problem sections are supported, MU2 requires the use of coded entries.

34. Problem Section example

35. Problem Act Concern

39. Problem Concern Act example

40. Problem Observation

45. Problem observation example

46. at the C-CDA sample We will look at the sample C-CDA 01/01/201146

47. Validation of C-CDA documents Two alternative techniques have been established to validate C-CDA documents. MDHT – JAVA validation code solution –Available on the Open Health Tools Web Site Trifolia – Schematron (xPath) solution –Available on the HL7 Web Site

48. Tools & Pending NIST testing The National Institute of Standards and Technology (NIST) provides a list of available validation tooling sites for interoperability specifications. NIST also provides tools for testing MU2 implementations. Validation: http://xreg2.nist.gov/hit-testing/ http://xreg2.nist.gov/hit-testing/ Testing: http://healthcare.nist.gov/use_testing/tools.html http://healthcare.nist.gov/use_testing/tools.html

49. Technique 1 - Schematron.xml CDA IG CCD.xsd XPath validation of Implementation Guide requirements Validates against generic CDA schema <Section code=Plan>.xPath,.xsl, Schematron Trifolia Workbench

50. Technique 2 – MDHT Validation Domain Model MDHT Model Driven Health Tools MDHT Model Driven Health Tools Add Custom Validations & Constraints Java API (Source Code) Java API (Source Code) Validation Code Generation Validation Code Generation Implementation Guide(s) The JAVA code can parse, validate and provides an code able object model !

51. Identify useful resources ToC Quickstart: http://wiki.siframework.org/Transitions+of+Care+Qui ckstart+Page http://wiki.siframework.org/Transitions+of+Care+Qui ckstart+Page CDA R2 Product Brief: http://www.hl7.org/implement/standards/product_bri ef.cfm?product_id=7 http://www.hl7.org/implement/standards/product_bri ef.cfm?product_id=7 Consolidated CDA Product Brief: http://www.hl7.org/implement/standards/ product_brief.cfm?product_id=258 http://www.hl7.org/implement/standards/ product_brief.cfm?product_id=258 HL7 FAQs: http://www.hl7.org/about/FAQs/index.cfmhttp://www.hl7.org/about/FAQs/index.cfm

52. Additional Tutorials Available at HL7 Or consider a future HL7 Ed Summit or On-site Training. Contact Mary Ann (maryann@HL7.org) to learn more about on-site trainingmaryann@HL7.org or to schedule on-site training for your organization.

53. For More Information…. Contact us! –cbeebe@mayo.educbeebe@mayo.edu HL7 C-CCD Implementation Guide –HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, Release 1 - US RealmHL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, Release 1 - US Realm S&I Framework – C-CDA Companion Guide –http://wiki.siframework.org/Companion+Guide+to+Consolidated+CDA+for+MU2http://wiki.siframework.org/Companion+Guide+to+Consolidated+CDA+for+MU2 Open Health CDA Tools: http://cdatools.org/ http://cdatools.org/ MDHT: https://www.projects.openhealthtools.org/sf/projects/mdht/ https://www.projects.openhealthtools.org/sf/projects/mdht/ –Validation: http://xreg2.nist.gov/hit-testing/http://xreg2.nist.gov/hit-testing/ –Testing: http://healthcare.nist.gov/use_testing/tools.htmlhttp://healthcare.nist.gov/use_testing/tools.html Trifolia Workbench: http://www.lantanagroup.com/resources/products/ http://www.lantanagroup.com/resources/products/ –Validation & CDA XSL Stylesheets: http://www.lantanagroup.com/resources/free-tools/http://www.lantanagroup.com/resources/free-tools/

54. Q & A Session 01/01/201154

55. Use Case 2

56. Update HeD UC2 Harmonization Progress & Decisions  Accomplishments to Date  Completed HITSC Evaluation of Standards  Evaluated Standards against the requirement of UC2 utilizing the UCR Crosswalk  Currently evaluating Implementation options and gaps in standards  Drafted relevant HL7 Project Scope Statements for anticipated work products to be balloted  Next Steps  Select Standards and determine Final Implementation approach  Begin Implementation Guide development  Submit 56

57. Update on Progress & Decisions: Viable Implementation Options 57 Implementation Option TransactionService Organizer/ Container PayloadTransport Notes/Rationale 3 II01 - Request DSSCCDA SOAP 1. Further discussion needed on utilization of vMR vs. CCDA and SOAP vs. REST 4 II01 - Request DSSCCDA REST 1.Further discussion needed on utilization of vMR vs. CCDA and SOAP vs. REST 2.There is currently implementation guidance on DSS to be used with SOAP, not REST 5 II01 - Request DSSVMR SOAP 1. Further discussion needed on utilization of vMR vs. CCDA and SOAP vs. REST 6 II01 - Request DSSVMR REST 1.Further discussion needed on utilization of vMR vs. CCDA and SOAP vs. REST 2.There is currently implementation guidance on DSS to be used with SOAP, not REST 9 II02 - Response DSSHeD UC1 IGVMRSOAP 1. Consistent with UC1 10 II02 - Response DSSHeD UC1 IGVMRREST 1.Consistent with UC1 2.There is currently implementation guidance on DSS to be used with SOAP, not REST

58. Update on Progress & Decisions: Non Viable Implementation Options  For the request transaction, vMR or CCDA should be used for both the Organizer/Container and Payload, instead of a combination of both. They are not meant to be separated in this manner. All implementation options that combined vMR and CCDA were eliminated  CCDA is not a commonly used standard for the response transaction, therefore any implementation option that had CCDA as the Item Payload standard was eliminated  Adoptability of HL7 Version 3 Order Set Standard for the response transaction was decided to be low, therefore any implementation option that had HL7 Version 3 Order Set Item Payload standard was eliminated 58

59. Update on Progress & Decisions: vMR Questions/Gaps VMR is a domain model and not an implementation model. We need to make sure the richness is not lost when it is translated into a message format. Who's going to propose an implementation or is that up to one of us. How well can VMR model a regimen as an addition to the record – capturing Temporal relationships, Conditional relationships, How well can a VMR model the alteration of a ACT, an ActAct Relation, or even part of a Regimen Can the VMR model the response from an Inference engine that uses the argumentation approach rather than just the simple if () then style of a rules engine. Recommended First choice.... Do this (pros and cons) Recommended Second choice... Do that (pros and cons) Etc. 59

60. Appendix 60

61. 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

62. 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

63. 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)

64. CDS Guidance Request Transaction: Service Standards Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale Decision Support Service (DSS) HITSC Rating:* M: 78.69 A: 88.6 SI: 33.33 T: 72.71 (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: 90.08 A: 92.11 SI: 47.62 T: 82.07 (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

65. CDS Guidance Response Transaction: Service Standards Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale Decision Support Service (DSS) HITSC Rating:* M: 78.69 A: 88.6 SI: 33.33 T: 72.71 (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: 90.08 A: 92.11 SI: 47.62 T: 82.07 (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

66. 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: 61.39 A: 86.84 SI: 35.71 T: 64.62 (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: 53.59 A: 80.70 SI: 33.33 T: 58.48 (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

67. CDS Guidance Request Transaction: Organizer/Container Rationale (continued…) Standard Summary of Findings from UCR Crosswalk Keep?Rationale Virtual Medical Record (vMR) HITSC Rating:* M: 78.06 A: 81.58 SI: 33.33 T: 70.08 (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

68. 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: 61.39 A: 86.84 SI: 35.71 T: 64.62 (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: 53.59 A: 80.70 SI: 33.33 T: 58.48 (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

69. CDS Guidance Response Transaction: Organizer/Container Rationale (continued…) Standard Summary of Findings from UCR Crosswalk Keep?Rationale Virtual Medical Record (vMR) HITSC Rating:* M: 78.06 A: 81.58 SI: 33.33 T: 70.08 (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: 46.20 A: 75.44 SI: 33.33 T: 53.31 (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

70. CDS Guidance Request Transaction: Item Payloads Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale Context Aware Retrieval Application (Infobutton) HITSC Rating M: 90.08 A: 92.11 SI: 47.62 T: 82.07 (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: 78.06 A: 81.58 SI: 33.33 T: 70.08 (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

71. CDS Guidance Request Transaction: Item Payloads Rationale (Continued…) Standard Summary of Findings from UCR Crosswalk Keep?Rationale Consolidated CDA HITSC Rating:* M: 53.59 A: 80.70 SI: 33.33 T: 58.48 (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: 46.20 A: 75.44 SI: 33.33 T: 53.31 (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

72. CDS Guidance Response Transaction: Item Payloads Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale Context Aware Retrieval Application (Infobutton) HITSC Rating:* M: 90.08 A: 92.11 SI: 47.62 T: 82.07 (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: 78.06 A: 81.58 SI: 33.33 T: 70.08 (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

73. CDS Guidance Response Transaction: Item Payloads Rationale (Continued…) Standard Summary of Findings from UCR Crosswalk Keep?Rationale Consolidated CDA HITSC Rating:* M: 53.59 A: 80.70 SI: 33.33 T: 58.48 (Y) Fits: Clinical; (P) Partially Fits: (N) Does not Fit: Context, Supporting Evidence; Supporting Resource; Actions; Attribute Value List; Response Metadata; Exceptions No 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 However, CCDA is not a commonly used standard for the response transaction * M: Maturity A: Adoptability SI: S&I Specific T: Total HL7 Version 3 Standard: Order Set Publication, Release 1 HITSC Rating:* M: 46.20 A: 75.44 SI: 33.33 T: 53.31 (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 model contains recommendations for clinical actions, which is applicable to the types of outputs relevant in the Use Case Unsure of adoptibility of this standard in CDS Guidance

74. CDS Guidance Request Transaction: Transport Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale SOAP HITSC Rating:* M: 100.00 A: 100.00 SI: 100.00 T: 100.00 (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: 100.00 A: 100.00 SI: 42.86 T: 88.30 (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

75. CDS Guidance Response Transaction: Transport Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale SOAP HITSC Rating:* M: 100.00 A: 100.00 SI: 100.00 T: 100.00 (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: 100.00 A: 100.00 SI: 42.86 T: 88.30 (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

76. CDS Guidance Request Transaction: Authentication/Authorization Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale SAML HITSC Rating:* M: 100.00 A: 100.00 SI: 100.00 T: 100.00 (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

77. CDS Guidance Response Transaction: Authentication/Authorization Rationale Standard Summary of Findings from UCR Crosswalk Keep?Rationale SAML HITSC Rating:* M: 100.00 A: 100.00 SI: 100.00 T: 100.00 (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

78. CDS Guidance Request Transaction: Encryption Standard Summary of Findings from UCR Crosswalk Keep?Rationale TLS HITSC Rating:* M: 100.00 A: 100.00 SI: 42.86 T: 88.30 (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

79. CDS Guidance Response Transaction: Encryption Standard Summary of Findings from UCR Crosswalk Keep?Rationale TLS HITSC Rating:* M: 100.00 A: 100.00 SI: 42.86 T: 88.30 (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

80. 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

81. 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

82. 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)

83. 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

84. Work Stream 1 – HL7: –Next HL7 meeting TBD –(see HeD Homepage wiki for meeting details: http://wiki.siframework.org/Health+eDecisions+Homepagehttp://wiki.siframework.org/Health+eDecisions+Homepage Work Stream 2 – Pilots: –We continue our Pilot activities –Next Pilots meeting: May 20th, 1-2:30 pm EDT see HeD home page wiki for meeting details: http://wiki.siframework.org/Health+eDecisions+Homepage http://wiki.siframework.org/Health+eDecisions+Homepage –Updates on Pilot Activities, Review of Timelines Work Stream 3 – Use Case 2: –Data Elements and Standards Sub Work Group Next Meeting: May 22nd, 2013 Homepage wiki for meetings: http://wiki.siframework.org/Health+eDecisions+Homepage http://wiki.siframework.org/Health+eDecisions+Homepage All Hands Community Meeting –We will reviewing candidate standards –Next meeting May 23rd, 2013(see the HeD Homepage wiki for meeting details: http://wiki.siframework.org/Health+eDecisions+Homepage http://wiki.siframework.org/Health+eDecisions+Homepage Next Steps

85. Questions?

86. Contact Information For questions, please contact your support leads –Coordinator: Ken Kawamoto: kensaku.kawamoto@utah.edukensaku.kawamoto@utah.edu –Co-Coordinators: Aziz Boxwala: aziz.boxwala@meliorix.comaziz.boxwala@meliorix.com Bryn Rhodes: bryn@veracitysolutions.combryn@veracitysolutions.com –ONC Leadership: Alicia Morton: alicia.morton@hhs.govalicia.morton@hhs.gov –Project Management: Jamie Parker: jamie.parker@esacinc.comjamie.parker@esacinc.com –Use Case 2: Dave Shevlin: d.s.shevlin@accenturefederal.comd.s.shevlin@accenturefederal.com Virginia Rhiel: virginia.riehl@verizon.netvirginia.riehl@verizon.net –Harmonization: Lynette Elliot: lynette.elliott@esacinc.comlynette.elliott@esacinc.com Anna Langhans: anna.langhans@accenture.comanna.langhans@accenture.com

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