Sharing guidelines knowledge: can the dream come true?

1. Sharing guidelines knowledge: can the dream come true? Medinfo panel Cape Town, September 15, 2010

2. Motivation • The vision of sharingexecutable clinical knowledge can be achieved only if we: • Standardize platforms for deploying scalable knowledge based services • Ensure services are mutually compatible and interoperable and free of institution-specific details • Develop reusable content and service components • Support automated cross-verification for quality and safety • Establish communities of practice who share, maintain, update, and improve content

3. Objectives • Raise awareness of the practical challenges involved in maintaining repositories of sharable executable clinical knowledge • Challenges with maintaining a repository • Defining what knowledge can be shared and how • Challenges in piecing together knowledge into a care plan and integrating it with EHR data • If the knowledge if free, what’s the business model and incentives for contributing knowledge?

4. Panel participants John Fox, Department of Engineering Science, University of Oxford, UK Robert Greenes, Ira A. Fulton Chair of the Department of Biomedical Informatics, Arizona State Univercity, Phoenix Sheizaf Rafaeli, Head of the Graduate School of Management and Sagy Internet Research Center, University of Haifa, Israel Mor Peleg, Head of the Department of Information Systems at the University of Haifa

5. What shall we discuss? John Fox Bob Greenes Mor Peleg Sheizaf Rafaeli Life-cycle approach for sharable knowledge-based patient-care services Methodology for distilling sharable knowledge from business/ implementation considerations Methods for weaving medical knowledge services into an application and for mapping clinical abstractions into EHRs Incentives and business models for a knowledge-sharing community

6. John Fox 20th Anniversary Gold Medal Award Options for addressing open-source publishing of medical knowledge, drawing on lessons learned in the OpenClinical project

7. OpenClinical: Open Source? John Fox University of Oxford (Engineering Science) UCL (Oncology, Royal Free Hospital) www.cossac.org

8. www.OpenClinical.org • Goal: To promote awareness and use of decision support, clinical workflow and other knowledge management technologies for improving quality and safety of patient care and clinical research. • A resource and portal for technologists, clinicians, healthcare providers and suppliers • Currently about 200,000 visitors a year (80% growth in 2010)

10. www.OpenClinical.net • Experimental project to explore how to develop content for high quality clinical decision support and workflow services at the point of care • Goal is to build a community of users, researchers and content providers who are willing to contribute to the development of a repository of open content, including applications and application components

11. OpenClinical.net test sitepro tem: modx.openclinical.net

12. Content development lifecycle • Prototype development model for open source content repository on www.OpenClinical.net • Currently limited to PROforma decision and process modelling language • Intended to eventually multiple representations (e.g. GLIF, ASBRU, GELLO, OWL ...)

13. Load from, save to repository

14. Download tools www.cossac.org/tallis

15. Web publishing (“publets”)

16. Integrate and Deploy

17. Key questions for open content • Quality and Safety • Quality lifecycles, safety culture, who is liable? • Reusability and interoperability • Open technical standards, who is developing them? • Functioning community (Sheizaf Rafaelli) • What will sustain the open source ethic? • Facilitating infrastructure (Bob Greenes) • Three organisations; too little? too much? • Sustainable business models • How do the proprietary/open source worlds coexist?

18. Sustainable business models (1) • Traditional standalone apps? • Issues of integration and localisation • Likes fragmentation; hates interoperability • Pay per patient (analogous to pay per view) • Who would/should actually pay? • No-one pays for Adjuvant! Online

19. Sustainable business models (2) • Standard medical publishing model • Commercially viable on a publishing model? (Clinical Evidence) • Discussion on www.berkerynoyes.com/ pages/innovations_in_evidence_based_medicine.aspx • Open Source with value-adding services? (c.f. Linux model) • Attractive model but how can we achieve critical mass of a content development community?

20. Towards an open content lifecycle? Ioannis Chronakis Vivek Patkar Richard Thomson Matt South Ali Rahmanzadeh

21. Thank you

22. Robert Greenes MUMPS Morningside Initiative Morris Collen Award Sharing medical knowledge involves separation between the medical content and the business/applications considerations

23. Toward sharing of clinical decision support knowledge -A focus on rules Robert A. Greenes, MD, PhD Arizona State University Phoenix, AZ, USA

24. Purpose of this talk • Identify key challenges to CDS adoption with focus on rules • Expressed in terms of 3 hypotheses: • Sharing is key to widespread adoption of CDS • Sharing of rules is difficult • Sharing can be facilitated by a formal approach to rule refinement

25. Hypothesis 1: Sharing is key to widespread adoption of CDS • We know how to do CDS! • Over 40 years of study and experiments • Many evaluations showing effectiveness

26. Rules as a central focus • Importance of rules • Can serve as alerts, reminders, recommendations • Can be run in background as well as interactively • Can fire at point of need • Same logic can be used in multiple contexts • e.g., drug-lab interaction rule can fire in CPOE, as lab alert, or as part of ADE monitoring • Can invoke actions such as orders, scheduling, routing of information, as well as notifications • Relation to guidelines • Function as executable components when GLs are integrated with clinical systems • Poised for huge expansion • Knowledge explosion – genomics, new technologies, new tests, new treatments • Emphasis on quality measurement and reporting

27. Yet beyond basics, there is very little use of CDS • Positive experience not replicated and disseminated widely • Largely in academic centers • <30% penetration • Much less in small offices • Pace of adoption barely changing • Only scratching surface of potential uses • drug dose & interaction checks • simple alerts and reminders • personalized order sets • Narrative infobuttons, guidelines

28. Adoption challenges • Possible reasons • Users don’t want it • Bad implementations • Time-consuming, inappropriate • Disruptive • Adoption is difficult • Finding knowledge sources • Adapting to platform • Adapting to workflow and setting • Managing and updating knowledge • But new incentives and initiatives rewarding quality over volume can address #1 • Health care reform, efforts to reduce cost while preserving and enhancing safety and quality • And #2 AND #3 can be addressed by sharing of best practices knowledge • Including workflow adaptation experience

29. Hypothesis 2: Sharing of rules is difficult • Rules knowledge seems deceptively simple: • ON lab result serum K+ • IF K+ > 5.0 mEq/L • THEN Notify physician • Even complex logic has similar Event-Condition-Action (ECA) form • ONMedication Order Entry Captopril • IF Existing Med = Dyazide AND proposed Med = Captopril AND serum K+ > 5.0 • THEN page MD

30. Why is sharing not done? • Perception of proprietary value • Users, vendors don’t want to share • Non-uptake even with: • Standards like Arden Syntax for 15 years, GELLO for 5 years • Knowledge sources such as open rules library from Columbia since 1995, and guidelines.gov, Cochrane, EPCs, etc., - most not in computable form • Failure of initiatives such as IMKI in 2001 • Lack of robust knowledge management • To track variations, updates, interactions, multiple uses • Same basic rule logic in different contexts • Beyond capabilities of smaller organizations and practices to undertake • Embeddedness • In non-portable, non-standard formats & platforms • in clinical setting • in application • in workflow • in business processes

31. Example of difficulty in sharing • Consider simple medical rules, e.g., • If Diabetic, then check HbA1c every 6 months • If HbA1c > 6.5% then Notify • Multiple translations • Based on how triggered, how/when interact, what thresholds set, how notify • Actual form incorporates site-specific thresholds, modes of interaction, and workflow

32. Multiple rules have similar intent • Differences relate to how triggered, how delivered, thresholds, process/workflow integration • Challenge is to identify core medical knowledge and to develop a taxonomy to capture types of implementation differences

33. Setting-specific factors (“SSFs”) • Triggering/identification modes • Registry, encounter, periodic panel search, patient list for day, … • Inclusions, exclusions • Interaction modes, users, settings • Data mappings & definitions, e.g., • What is diabetes - code sets, value sets, constraint logic? • What is serum HbA1c procedure? • Data availability/entry requirements • Thresholds, constraints • Logic/operations approaches • Advance, late, due now, … • Exceptions • Refusal, lost to follow up, … • Actions/notifications • Message, pop-up, to do list, order, schedule, notation in chart, requirement for acknowledgment, escalation, alternate. …

34. Hypothesis 3: Sharing can be facilitated by a formal approach to rule refinement • Develop an Implementers’ Workbench • Start with EBM statement • Progress through codification and incorporation of SSFs • Output in a form that is consumable “directly” by the implementer site or vendor

35. Life Cycle of Rule Refinement Start with EBM statement Stage • Identify key elements and logic – who, when, what to be done • Structured headers, unstructured content • Medically specific • Formalize definitions and logic conditions • Structured headers, structured content (terms, code sets, etc.) • Medically specific • Specify adaptations for execution • Taxonomy of possible workflow scenarios and operational considerations • Selected particular workflow- and setting- specific attributes for particular sites • Convert to target representation, platform, for particular implementation • Host language (Drools, Java, Arden Syntax, …) • Host architecture: rules engine, SOA, other • Ready for execution

36. Four current projects addressing this challenge EBM statement • Identify key elements and logic – who, when, what to be done • Formalize definitions and logic conditions • Identify possible workflow scenarios – model rules, defining classes of operation • Convert to target representation, platform, for particular implementation Idealized life cycle / Morningside / KMR / AHRQ SCRCDS/ SHARP 2B

37. What we hope to accomplish • Implementers’ Workbench (IW) • Taxonomy of SSFs • Knowledge base of rules • Approach • Vendor, implementer, other project input, buy-in, collaboration • Taxonomy as amalgam of NQF expert panel, Morningside/SHARP/Advancing-CDS workflow studies, SCRCDS implementation considerations • Diabetes, USPS Task Force prevention and screening A&B recommendations, and Meaningful Use eMeasures converted to eRecommendations as initial foci • Prototyping, testing, and iterative refinement of IW

38. What we expect to share • Experience/know-how • Knowledge content • Methods/tools • Standards/models

39. Standards/models • Representation • Data model/code sets • Definitions • Templates • Taxonomies • Transformation processes

40. Where CDS should go from here? • Need for coordination • Multiple efforts underway • Need to coalesce and align these • Need sustainable process • Multi-stakeholder buy-in, participation, support, commitment to use • Need to demonstrate success • Small-scale trials • Larger-scale deployment built on success • Expansion to other kinds of CDS

41. Comments? Questions?

42. Mor Peleg GLIF3 New Investigator Award Biomedical Ontologies Process Mining K KDOM Data Weaving medical knowledge services into applications. Using a mapping ontology to map medical knowledge into institutional data

43. Implementing decision-support systems by piecing sharable knowledge components Mor Peleg, University of Haifa Medinfo panel, Cape Town, September 15, 2010

44. Motivation • Computerized guidelines have shown positive impacts on clinicians but they take time to develop • Solution: Share executable GL components, stored in Medical Knowledge Repository • Assemble computerized GLs from components • Map the GL’s medical terms into institutional EHR fields

45. Examples of medical resources that could be shared and assembled • Medical calculators • Risk-assessment tools • Drug databases • Controlled terminologies (e.g. SNOMED) • Authoring, validation, and execution tools for computer-interpretable GLs

46. Component interface Peleg, Fox, et al. (2005) LNCS 3581 pp.156-160.

47. The interface can be used for • Sharing components • Indexing and searching for components • Using the attributes: clinical sub-domain, relevant authoring stages, and goals • Assembling components into a GL • Specifying the guideline's skeleton language (e.g., GLIF, PROforma) into which components can be integrated

48. Example: providing advice on regimens for treating breast cancer Filter out non-beneficial and contraindicated therapies Is patient eligible for evaluating therapy choices? Adjuvant's life- expectancy calculator Get patient Data Present choices to user Prescribe regimen Calculate regimen Choose option

49. Using Standards • Skeleton can be any GL formalism • Eligibility criteria expressed in GELLO standard • Referring to the HL7-RIM patient data model

50. Integrating assembled guideline with EHR data RIM Peleg et al., JBI 2008 41(1):180-201 • Encode once but link to different EMRs • Global-as-View • Mapping Ontology + SQL Query Generator