Összehasonlított verziók

Kulcs

  • Beillesztett sor.
  • Törölt sor.
  • Formázás megváltoztatva.

...


General RecommendationsAnticoagulationTesting/TriageOther (Long COVID, Vaccine, Steroids)
Key Definitions and Frameworks
  • [CPG on FHIR and BPM+ IGs do this separately - need to be combined and simplified (e.g., with helpful graphics); e.g., leverage L1-L4]
  • [Approach section from CPG on FHIR IG might be helpful in framing scope]



What to know/do (and why) Overview

For people looking for guidance repositories:

There are threads of work in HL7 and BPM+ community. Results of this work should be available in the coming weeks/months.

By end of Nov HL7 should publish details of how the DGWG got the ED use case guidance to L3.

Draft slide overview of VA considerations in making guidelines computable

Tips from DGWG, based on CPG on FHIR Implementation Guide:

  • Knowledge Elicitation: This goes through types of input that are needed, what needs to be made explicit and computable. Interactions with people developing the guideline. Getting information from guidance developer tools/artifacts into a DGWG tool (based on McMaster work) for making guidance computable. The DGWG template will be made available as part of this tool.
  • Terminology Management: reach out to terminology vendors for mappings about how terms are expressed in working systems (e.g., EHRs) and connect this to how guidance developers described terms. Narrative guidelines have clinicians as an audience (e.g., understand what terms like 'patients with diabetes' mean); for guidelines to be computerized, these terms must be expressed based on computable code sets. Fleshing out these terms/definitions is the lion's share of the work in making guidelines computable.
  • Execution Model: describes target representation that models the execution semantics that are necessary for any specific implementation (Sivaram/Matt to provide example). Has 'pragmatics' that consistently conveys guidance intent. Translates what SMEs, knowledge engineers, etc. know into system behavior. There are tools to facilitate this work (e.g., OMG BPM+ tools, OWL). 'Case' describes patient details, 'Plan' describes what is (or should be) done for specific patients.

The approach above is intended as a paradigm shift in the approach to developing guidance. Historically it has started with developing a text representation for the guidance that is directly applied by clinicians to enhance decisions and actions. The shift here is developing a computable representation of the guidance that serves as the 'source of truth' for subsequent implementation and modifications. When changes to the guidance model are made, these changes can then flow more seamlessly to CDS interventions, quality measures, eCase Reports, etc. This is more efficient than having a non-computable, text-based representation of the guidance as the 'source of truth,' since the former requires extensive adaptation (which introduces error, ambiguity, time delays, etc.) for implementation and modification.

(Sivaram/Matt to flesh this out) Use shared ontologies to ensure consistent guidelines, reduce rework. These get pulled into authoring tools...


--------------------

Regarding Terminologies: HL7 Project "Guidelines for a Standardized Terminology Knowledge base"

Regarding Value Sets recommend the following process (applies to anticoagulation, testing/triage, vaccines, steroids, and any other topic):

  1. Take inventory of what value sets you’ll need (be specific)
  2. Check Alliance website or Value Set Authority Center (VSAC), we might have already published some of them among the 600+ value sets
  3. If certain value sets are not present or you are unsure, contact Victor Lee (Victor_Lee@ClinicalArchitecture.com) to inquire or to request development

Clinical Architecture and other Alliance collaborators are donating our efforts, and Clinical Architecture is leveraging its software tooling, hosting infrastructure, and manual labor to donate all of the COVID-19-related value set content to the public domain (i.e., completely free, no strings attached). That being said, we all have day jobs, so we appreciate having as much lead time as possible to fulfill requests. Happy to take questions.

(VA has library of 100 knowledge artifacts - used HL7 KNART spec to make XML rendering. Using clinical content from these to represent as FHIR questionnaires. This other HL7 work outlined above resonates, and potentially could be leveraged to support VA efforts. There are only a handful of guidelines that VA pushes out from national - other CDS interventions are developed more locally by VA facilities using tools available in the HIT infrastructure. Question: How does the above process reconcile when there are competing recommendations on a particular topic. Answer: The HL7 CPG on FHIR IG addresses localization - can related to workflows, but can also reflect how organizations combine different external recommendations to make essentially a local guideline that differs from the external guidelines. There are 10 workflows and visio diagrams: Robert Lario and Linda Wedemeyer are expressing these in BPM+ as an experiment.)


------------------


[Evidence synthesis teams would like to have something that summarizes for a COVID resource database, where are they pulling information from, what are their inclusion/exclusion criteria, why you might use one source vs. another]

[CPG on FHIR team would like to incorporate insight we generate here - including BPM+ synergies, back into that resource. The 'Integrated Process' about how to develop narrative and computable guidelines in parallel - will be published in about a month.]

Robert Lario - co-chairs OMG BPM+ activities. 3 languages - process modeling (BPMN), decision modeling (DMN), case/event (CMMN) modeling. VA using these to express clinical practice guidelines - sometimes just instructive, other times executable. All have execution models. BPM+ has its own ecosystem. Gaps and hard to do some things with BPM +. Started working on 3 other modeling languages. Situational data - how do you represent structure of data, etc. Provenance who owns/controls and access. and Pedigree: what produces what. Knowledge Package: Many languages/constructs used in a guideline (sequencing). How do you bundle these up into a CPG. How do you surface models, discuss dependencies. Focusing on how do you express knowledge in a clear and unambiguous way, and how to you create artifacts? CPG on FHIR speaks more to methodology - complements BPM+ which doesn't get into deep detail on this. Also not looking at curation and management of models.

Blackford: DGWG ran through effort to implement guidance based on CPG on FHIR. Would like to use a resource like this table to know which tools to use to make guidance computable in different circumstances. How do you implement this at scale.

Address dissemination and marketplaces. (HL7 Marketplaces spec)


Computable version of ACEP/EvidenceCare ED Severity Classification/Triage tool 


Case Study within HL7 CPG on FHIR Implementation Guide for how the C19 Digital Guideline WG supported development of the ACEP/EvidenceCare tool above.


HL7 Care Management Implementation Guide COVID-19 Severity Classification and Disposition (using ACEP/EvidenceCare tool as a use case)


Input Sources
  • See output repositories under Produce Guidance



Output Repositories


Standards


Initiatives



Tools/ Platforms


Other Best Practices

From C19HCC Digital Guideline WG:

  • Using CPG-on-FHIR standard for representing/ expressing the full intent of the Guidance in computer-interpretable artifacts (part of HL7 CPG-IG)
  • Using the Agile Approach to CPG Development (inclusive of Integrated Process) to concurrently Produce Guidance and Make Guidance Computable (part of HL7 CPG-IG)
  • Use Agile Knowledge Engineering methods, principles, and tools
    • Cross-functional Integrated team (Agile CPG Team)
    • Leverage composite nature of CPGs (e.g. can develop logic for inferences on patient information- CPG_CaseFeatures) to build incrementally and iteratively with rapid feedback
    • Pull knowledge engineers into Content design/reviews; pull domain SMEs into knowledge representation design/reviews
  • Leverage CPG-on-FHIR as a faithful expression of Guidance and its ability to create computationally derived CDS and Cognitive Support, patient-specific, practice-level digital Quality Measures/Metrics, eCaseReports, etc. to create computable artifacts used downstream in the Learning Health System and to provide closed-loop feedback/feedforward.
  • Leverage established tools and capabilities (e.g. BPM+ process and tooling, Clinical Ontology) to author computable Guidance and Open Source tooling to translated into HL7 CPG-on-FHIR to leverage derivative and native compute
  • tips:
    • Use established standards and work with standards community (to understand and evolve as needed)
    • Engage consumers/ users early and often
    • Engage downstream vendors (e.g Terminology vendor USED in the EHRs) early
    • Just because everyone everyone is using the same terminology systems doesn't mean they're agreeing how to use the actual terms- this needs to be considered and addressed to make ecosystem/supply chain work properly (feedforward from Evidence, but also feedback of data semantics back into evidence)
    • Learn from related communities of practice (e.g. Agile Software Engineering)



...