Download
health edecisions initiative closing ceremony march 27 2014 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Health eDecisions Initiative – Closing Ceremony March 27, 2014 PowerPoint Presentation
Download Presentation
Health eDecisions Initiative – Closing Ceremony March 27, 2014

Health eDecisions Initiative – Closing Ceremony March 27, 2014

160 Views Download Presentation
Download Presentation

Health eDecisions Initiative – Closing Ceremony March 27, 2014

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Health eDecisions Initiative – Closing CeremonyMarch 27, 2014

  2. Meeting Etiquette • As a reminder all participants on this call are muted. If you want to ask questions or make comments please use the “Chat” feature on the web meeting • Send your “chat” to All Panelists in order to ensure the comments are addressed publically To find the chat feature look for the chat bubble at the top of the meeting window From S&I Framework to Participants: Could you please explain how the terminologies are used in this instance? All Panelists

  3. Agenda • Introduction • Doug Fridsma, MD, PhD- Chief Science Officer & Director, Office of Science & Technology – Office of the National Coordinator • Background of HeD Initiative • Kensaku Kawamoto, MD, PhD -Initiative Coordinator, Health eDecisions-Associate Chief Medical Information Officer, Univ. of Utah Health Sciences Center • Accomplishments • Howard Strasberg, MD, MS - VP Medical Informatics, Clinical Solutions -Wolters Kluwer Health • HeD Key Deliverable 1: Foundational CDS Information Model • Claude NanjoMPH- Health eDecisions Subject Matter Expert-Sr. Software Architect ,Cognitive Medical Systems • HeD Key Deliverable 2: HL7 CDS Knowledge Artifact Implementation Guide (IG) • Aziz Boxwala, MD, PhD - Subject Matter Expert, Health eDecisions-President - Meliorix, Inc. • HeD Key Deliverable 3: HL7 Decision Support Service IG • Bryn Rhodes –Health eDecisions Subject Matter Expert – Software Architect , Veracity Solutions • Pilots • Julie Scherer, PhD -Chief Data Scientist -Motive Medical Intelligence • Robin Williams, RN - Manager Solution Management- Allscripts • Real World Applications • Daryl Chertcoff - Project Manager -HLN Consulting, LLC • Julie Scherer, PhD -Chief Data Scientist -Motive Medical Intelligence • Robin Williams, RN - Manager Solution Management- Allscripts • Howard Strasberg, MD, MS - VP Medical Informatics, Clinical Solutions -Wolters Kluwer • Path Forward • Kensaku Kawamoto, MD, PhD

  4. HeD Goal • To define and validate standards that facilitate the emergence of systems and services whereby CDS interventions can be shared or accessed by any healthcare stakeholder via an importable format or via a CDS Web service • In short, to define and validate standards that enable CDS sharing at scale

  5. Health eDecisions (HeD) • ONC-sponsored, public-private initiative to develop and validate standards to enable CDS at scale (http://wiki.siframework.org/Health+eDecisions+Homepage ) • Seek to inform future MU EHR certification criteria • this work built on the work done under the ONC funded “Advancing CDS” contract with RAND. • Built shareable CDS interventions and placed them in the CDSC repository. • When contract ended next logical step was to take this work to the S&I Framework and launch an initiative • Brief timeline • April 2012: face-to-face planning discussion, DC • June 2012: initiative kickoff • Jan, May, Sept 2013, Jan 2014: HL7 ballots • March 2013+: pilots

  6. Relevant Prior Work • Standard, universal format for CDS knowledge • HL7 Arden Syntax, HL7 GELLO, HL7 Order Sets, ASTM GEM, GLIF3, CDS Consortium L3 model, SAGE, Asbru, PROforma, PRODIGY, AHRQ eRecommendations, etc. • Standard interface for submitting patient data and obtaining patient-specific care guidance • HL7 Decision Support Service • OpenCDS, CDS Consortium ECRS, SEBASTIAN, etc. • Standard information model for CDS • HL7 Virtual Medical Record Ref. Kawamoto K et al. Open Medical Informatics Journal. 2010, 4:235-44.

  7. Accomplishments Howard Strasberg, MD, MS VP Medical Informatics, Clinical Solutions Wolters Kluwer Health

  8. We did it… • The HeD community drafted and established consensus for 2 Use Cases: • Use Case 1 and Functional Requirements: CDS Artifact Sharing • Use Case 2: CDS Guidance as a Service (including Functional Requirements) • We have submitted 6 artifacts to HL7 which are all now Draft Standards for Trial Use (DSTU) • Clinical Decision Support Knowledge Artifact Implementation Guide (UC 1) • Rules, Order Sets and Documentation Templates • Decision Support Service (DSS) Implementation Guide (UC 2) • Virtual Medical Record (vMR) Logical Model • vMR XML Specification • vMR Templates • DSS Standard • We have completed pilots for both use cases which include 5 pilot ecosystems • Formal pilots for UC 1 • Pilots of slightly earlier versions of standards for UC 2 • We have been included in the proposed voluntary 2015 EHR Certification Criteria

  9. Standards Overview

  10. HeD Key Deliverable 1: Foundational CDS Information Model Claude Nanjo M.P.H Sr. Software Architect, Cognitive Medical Systems Subject Matter Expert, Health eDecisions

  11. Underlying Information Model • Need • Standard CDS data model that is simple and intuitive for a typical CDS knowledge engineer to understand and use • Relevant Prior Work Evaluated • HL7 Consolidated Clinical Document Architecture (C-CDA) • HL7 Quality Reporting Document Architecture (QRDA) • HL7 Fast Healthcare Interoperability Resources (FHIR) • HL7 Virtual Medical Record (vMR) • IHC Clinical Element Models, OpenEHR templates, others • Decision • HL7 vMR with templates derived from C-CDA and QRDA

  12. Example Challenge without VMR Blood Pressure Systolic = 120 mmHg Diastolic = 80 mmHg Code = BP Value = 120/80 mmHg Observation Code = BP Value = 120/80 mmHg Observation Code = BP Observation Code = SBP Value = 120 mmHG Observation Code = DSP Value = 80 mmHg Vital Signs Type = BP Value = 120/80 Units = mmHg

  13. Why Not Just Use C-CDA as the vMR? <entry typeCode="DRIV"> <actclassCode="ACT"moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.3"/> <id root="ec8a6ff8-ed4b-4f7e-82c3-e98e58b45de7"/> <code code="CONC" codeSystem="2.16.840.1.113883.5.6" displayName="Concern"/> <statusCode code="completed"/> <effectiveTime><low value="20070103"/></effectiveTime> <entryRelationshiptypeCode="SUBJ"> <observationclassCode="OBS"moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.4"/> <id root="ab1791b0-5c71-11db-b0de-0800200c9a66"/> <code code="409586006" codeSystem="2.16.840.1.113883.6.96" displayName="Complaint"/> <statusCode code="completed"/> <effectiveTime><low value="19500101"/></effectiveTime> <value xsi:type="CD" code="195967001" codeSystem="2.16.840.1.113883.6.96" displayName="Asthma"/> <entryRelationshiptypeCode="REFR"> <observationclassCode="OBS"moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.6"/> <code xsi:type="CE" code="33999-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Status"/> <statusCode code="completed"/> <value xsi:type="CD" code="55561003" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Active"/> </observation> </entryRelationship> </observation> </entryRelationship> </act> </entry> CCDA 1.1 representation of “Patient has had asthma since 1950”

  14. Why Not Just Use C-CDA as the vMR? Sample CDS expression that “Patient currently has active asthma” using CCDA 1.1 Data Model entry[@typeCode=“DRIV” and act[@classCode=“ACT” and @moodCode=“EVN” and templateId[@root=“2.16.840.1.113883.10.20.22.4.3”] and code[@codeSystem=“2.16.840.1.113883.5.6” and @code=“CONC”] and statusCode[@code=“completed”] and entryRelationship[@typeCode=“SUBJ” and observation[@classCode=“OBS” and @moodCode=“EVN” and templateId[@root=“2.16.840.1.113883.10.20.22.4.4”] and code[@codeSystem=“2.16.840.1.113883.6.96” and @code=“409586006”] and statusCode[@code=“completed”] and effectiveTime[low[@value<=“20130814”]] and value[@xsi:type=“CD” and @codeSystem=“2.16.840.1.113883.6.96” and @code=“95967001”] and entryRelationship[@typeCode=“REFR” and observation[@classCode=“OBS” and @moodCode=“EVN” and templateId[@root=“2.16.840.1.113883.10.20.22.4.6”] and code[@xsi:type=“CE” and @codeSystem=“2.16.840.1.113883.6.1” and @code=“33999-4” ] and statusCode[@code=“completed”] and value [@xsi:type=“CD” and @codeSystem=“2.16.840.1.113883.6.96” and @code=“55561003” ] ] ] ] ] ]

  15. vMR Representation of Equivalent Content vMR representation of “Patient has had asthma since 1950” <clinicalStatement xsi:type="vmr:Problem"> <templateId root="2.16.840.1.113883.3.1829.11.7.2.5"/> <conditionCodecodeSystem="2.16.840.1.113883.6.96" code="195967001"><displayName value="Asthma"/></conditionCode> <conditionEffectiveTime><low value="19500101"/><conditionEffectiveTime> <conditionStatuscodeSystem="2.16.840.1.113883.6.96" code="55561003"><displayName value="Active"/></conditionStatus> </clinicalStatement> Sample CDS expression for “Patient currently has active asthma” using vMR clinicalStatement[@xsi:type=“vmr:Problem” and templateId[@root=“2.16.840.1.113883.3.1829.11.7.2.5”] and conditionCode[@codeSystem=“2.16.840.1.113883.6.96” and @code=“195967001”] and conditionEffectiveTime[low[@value<=“20130814”]] and conditionStatus[@codeSystem=“2.16.840.1.113883.6.96” and @code=“55561003”] ]

  16. Simplification – Data Types Constrained HL7 Version 3 Release 2 Data Type Model for Integer used in vMR HL7 Version 3 Release 2 Data Type Model for Integer Value of the INT

  17. Example vMR Template Example: <clinicalStatement xsi:type="vmr:Problem"> <templateId root="2.16.840.1.113883.3.1829.11.7.2.4“ identifierName=“ActiveProblemListEntryCodeOnly”/> <conditionCode codeSystem="2.16.840.1.113883.6.96" code="195967001"><displayName value="Asthma"/></conditionCode> </clinicalStatement>

  18. HeD Key Deliverable 2: HL7 CDS Knowledge Artifact Implementation Guide (IG)(HeD Use Case 1 IG) Aziz Boxwala, MD, PhD President, Meliorix, Inc. Subject Matter Expert, Health eDecisions

  19. Goal • CDS interventions must be made shareable and implementable so that they can be acquired and deployed by any organization.

  20. Use Case Overview

  21. Knowledge Artifact Schema • Schemas defined by composition of components • Currently supported CDS interventions • Event-condition-action rules • Order sets • Structured documentation templates • In future, can be expanded • E.g., Plans of care, infobutton rules/knowledge, relevant data display

  22. External Data Example Addressing the curly braces issue using HeD expression language and the VMR <def name="PertussisProblems"> <expression xsi:type="ClinicalRequest"dataType="vmr:Problem" cardinality="Multiple“ isInitial="true"useValueSets="true"dateProperty="diagnosticEventTime.begin"codeProperty="problemCode"triggerType="DataElementAdded"> <description>Pertussis problem</description> <codes xsi:type="ValueSet" id="2.16.840.1.114222.4.11.7005" version="1"/> </expression> </def>

  23. Conditions Example <condition> <logic xsi:type="And"> <description>(Patient lives in SD or Care encounter was in SD) and (Diagnosed with Pertussis or Cause of Death was Pertussis or culture results positive for pertussis)</description> <operand xsi:type="Or"> <operand xsi:type="ExpressionRef" name="PatientLivesInSDCounty"/> <operand xsi:type="ExpressionRef" name="EncounterWasInSDCounty"/> </operand> <operand xsi:type="Or"> <!--Necessary clinical conditions --> <operand xsi:type="ExpressionRef" name="HasActivePertussisProblems"/> <operand xsi:type="ExpressionRef" name="DeathWasCausedByPertussis"/> <operand xsi:type="ExpressionRef" name="HasPositivePertussisCulture"/> </operand> </logic> <conditionRole value="ApplicableScenario"/> </condition>

  24. Communication Action <simpleAction xsi:type="CreateAction"> <actionSentence xsi:type="ObjectExpression" objectType="vmr:CommunicationProposal"> <property name="message"> <value xsi:type="ComplexLiteral"> <value xsi:type="dt:ED" value="This patient has or is suspected of having pertussis. Patients diagnosed with or suspected of having pertussis must be reported to County of San Diego Health and Human Services Agency within one working day of identification or suspicion"/> </value> </property> </actionSentence> </simpleAction>

  25. HeD Key Deliverable 3: HL7 Decision Support Service IG(HeD Use Case 2 IG) Bryn Rhodes Software Architect, Veracity Solutions. Subject Matter Expert, Health eDecisions

  26. Goal • Allow any organization to easily obtain CDS guidance through a secure, standard Web service interface.

  27. Use Case Overview CDS Guidance Requestor CDS Guidance Supplier CDS Request (patient data) CDS Guidance (care guidance)

  28. Sample CDS Guidance Services

  29. Key Standards • HL7 Decision Support Service (DSS) • Defines SOAP and REST Web service interfaces for CDS guidance services • HL7 Virtual Medical Record (vMR) • Provides easy-to-understand data model for CDS • HL7 Consolidated CDA (C-CDA) and Quality Reporting Document Architecture (QRDA) • Terminology bindings and value sets largely being adopted within vMR as vMR templates

  30. Sample CDS Guidance Service Implementers • OpenCDS (www.opencds.org) • Multi-institutional open-source effort led by Univ. of Utah • Implements HL7 DSS and vMR; will support HeD UC 2 • 200+ members from 150+ organizations • Example implementation: Immunization Calculation Engine (ICE), led by HLN Consulting, and used by eClinicalWorks • Enterprise Clinical Rules Service • Part of CDS Consortium effort • Epic EHR • Will support CDS Guidance Services in 2014 release

  31. Use Case 1 Pilots Julie Scherer, PhD Chief Data Scientist , Motive Medical Intelligence Robin Williams, RN Manager Solution Management, Allscripts

  32. Use Case 1 Pilots Goal • Goal • The goal of this pilot is to produce, consume, and, where feasible, execute implementable CDS interventions. • Event condition action rules (ECA Rules) • Order sets • Documentation templates • Pilot Scope • Apply defined aspects of the Implementation Guide in a real-world setting. • Modify the Implementation Guide to ensure it is usable. • Submit explicit feedback to sub-workgroups such as vMR and vocabulary and terminology to close gaps. • Evaluate the technology, standards, and model (VMR). • Provide a test bed to evaluate the interaction of technology, implementation support, and operational infrastructure required to meet Health eDecisions’ use case 1 objectives at the stakeholder or organization levels. • Demonstrate that intents of artifacts (including structures and semantics) are communicated either by direct execution or by translation to native format. • Ensure completeness and consumability of artifacts.

  33. UC 1 Pilot Teams

  34. UC 1 Pilot Findings • Syntax translation was straightforward • Shared heritage of HeD and CREF provided very close mapping of operators • Data model translation required changes to the rule implementation • Negation rationale: observation of documentedreason for not prescribing versus allergy to aspirin • Medication: aspirin as a substance versus antithrombotic therapy as a class • Procedures: performed procedure versus encounters with procedure code • Gaps in guidance modeling • Action models differed in messaging granularity, specificity of severity, and action proposal architecture • HeD rule implementation was modified to meet CREF requirements • We could represent the reporting criteria in a fully computable manner in HeD • HeD's expressivity exceeded that of the target's systems rule capabilities in one area (but there was an approach to achieve almost equivalent functionality in the vendor system) • The process revealed gaps in the vendor’s CDS (e.g., location of encounter), resulting in plans to add new capability based on lessons learned from the pilot • A standard terminology for orders would be helpful for CDS and would benefit Health eDecisions Use Case 1 and 2 • Meanwhile, terminology guidance needs to be more prescriptive

  35. In Support of UC 1 Pilots: HeD Schema Framework Tool • HeD Schema Framework is a set of .NET technologies that serves as a foundation for implementing functionality related to the HeD Schema • For example, the following types of applications could be built using the foundation provided by this framework: • Semantic Validation • Translation • Evaluation • Visual Designers • Developed as Open Source with a Berkeley 3-Clause License • Hosted on Google Code Repository • http://code.google.com/p/health-e-decisions/ • http://code.google.com/p/health-e-decisions/source/browse/trunk/src/framework/Deploy/HeDArtifactUtility_20130502.zip

  36. Application of Use Case 2: Immunization Calculation Engine (ICE) Open Source Immunization Decision Support System for Integration with Health Information Systems Daryl Chertcoff Project Manager HLN Consulting, LLC URL: www.hln.com/ice Email: ice@hln.com

  37. Agenda • Overview of the ICE Project and Software • Lessons Learned (and continue to learn!)

  38. Overview of the ICE Project

  39. Immunization Forecasting Isn’t Easy… • Increasingly complex rules • Evolving recommendations from ACIP • Increasing pressure to collaborate with the larger Health IT landscape • Ongoing use of aging software architectures, despite growing demand • Competitive funding environment 39

  40. “Create a freely available immunization decision support system that promotes clinical best practices, adapts to changing requirements, and easily integrates with other health information systems.” ICE Project Goals

  41. ICE Project Principles Collaborative Leverage the experience of CDS and immunization professionals (including but not limited to) New York City Citywide Immunization Registry Alabama Department of Public Health CDS software and standards innovators (CDC CDSi workgroup, OpenCDS team) Share the solution with the community Rule set and test cases freely available Release under a standard open source license (LGPL v3) Flexible Easier configuration and maintenance of the rules More thorough, less time consuming regression testing process Standalone Service – no tight integration with other software 41

  42. ICE Project Principles (cont’d) • Benefit from Standards • Lower barriers to adoption of immunization forecasting engines • Facilitate maintenance • Foster interoperability across Healthcare IT systems and CDS engines • Ensure consistency between decision support used by public health registries and decision support used by other clinical systems

  43. Project Overview • Documentation of the Rules • Software executable Test Cases • ICE CDS Service • 14 vaccine groups, from infant to adult • CDS Administration Tool (CAT) • Graphical User Interface for non-technical subject matter experts (SMEs) to author and test rules • Strategy for ongoing support within the open source community • A few vaccine groups remain to be implemented; remaining rules successfully deployed in a production setting by a large EHR vendor (eClinicalWorks) • Wiki site available at http://www.cdsframework.org • General website: http://www.hln.com/ice

  44. Sample ICE Deployment 44

  45. ICE Web Service Standards-Based HL7 Virtual Medical Record (vMR) Release 1 HL7 Decision Support Service (DSS) Release 1 Operates on the OpenCDS platform (www.opencds.org) Complete knowledge authoring platform; provides messaging and reasoning over the vMR data model Separates terminology management from logic engineering Reference implementation for DSS and vMR standards Inputs: DOB, gender, immunization history, disease immunity, Immunization schedule identifier, date of evaluation (via DSS) Outputs: Validity of immunization history, immunization recommendations + reasons Rules are implemented in Drools; DSL (“sentence templates”) available for rule authors 45

  46. CDS Administration Tool (CAT) • Optional GUIfor authoring and testing rules • Geared for “non-developer” SMEs to view and/or configure rules; develop test cases • Supports creation, maintenance, importing & exporting: • OpenCDS concepts and codes • Rules • Supporting data • Test cases (ICE-specific module) • Defining immunization schedule parameters (ICE-specific module) • Extensible “plug-in” architecture • May be used in conjunction with other development environments

  47. Sample Varicella Rule

  48. Live Testing (Test Results View)

  49. Wiki Documentation of Ruleshttp://www.cdsframework.org

  50. ICE Lessons Learned