Under ConstructionEvolving Description of ACTS Collaborative Participant's COVID-19 Knowledge Ecosystem Efforts
| Identify Studies | Review Evidence |
|---|
Current Approach | |
|
| Pearls/Tips Learned |
|
|
| Desired Approach |
|
|
| Needs to Achieve Desired Approach | Check all that apply __Better source/input materials [Details: ] __Common format/terminologies for managing/sharing data [Details: ] __Other [Details:]
| Check all that apply __Better source/input materials [Details: ] __Common format/terminologies for managing/sharing data [Details: ] __Other [Details:] |
| Support We Can Provide Other Participants |
|
|
| Produce Guidance | Make Guidance Computable |
|---|
Current Approach | - (Brian Fengler to edit)
- Content Team, part of C19 Digital Guideline Working Group, consisting of frontline clinicians and representatives from professional societies and evidence ecosystem participants
- Content Team identifies need, prioritizes areas of focus, and participants form and lead the use case-specific Agile CPG Teams
- Using the Agile Approach to CPG Development (inclusive of Integrated Process) to concurrently Produce Guidance and Make Guidance Computable in Agile CPG Team
| - 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
|
| Pearls/Tips Learned | - Collaborate with Frontline clinicians (target users) AND Content Experts (domain and methodological) in an integrated, concurrent fashion
- Collaborate directly (integrated with as part of Agile CPG Team) with the Knowledge Engineering Team to Make Guidance Computable
- Clarify INTENT of Guidance to KE's
- Address ambiguity in narrative Guidance based on clarifications needed for KE (make content more accurate, less ambiguous)
| - 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)
|
| Desired Approach |
| - Build computable artifacts/assets on Real-World data to enable better design/ specification and Test-driven Development (Agile)
- Leverage mature Knowledge Base to implement Knowledge Architecture (e.g. CPG profiles) and design, develop, test, maintain, and reuse artifacts/ assets
- Concurrent Validation and Development using above
|
| Needs to Achieve Desired Approach | Check all that apply __Better source/input materials [Details: ] __Common format/terminologies for managing/sharing data [Details: ] __Other [Details:] | Check all that apply (in process) x__Better source/input materials [Details:] Helps if Evidence is EBM-on-FHIR x__Common format/terminologies for managing/sharing data [Details: ] Complete, Accurate, Unambiguous Data Definitions __Other [Details:] To Be Continued... |
| Support We Can Provide Other Participants |
|
|
| Implement Guidance (e.g., as CDS, eCQMs) | Analyze Results (e.g., care outcomes) | Apply Results (e.g., Quality Improvement, create evidence) |
|---|
Current Approach | |
|
|
| Pearls/Tips Learned |
|
|
|
| Desired Approach |
|
|
|
| Needs to Achieve Desired Approach | Check all that apply __Better source/input materials [Details: ] __Common format/terminologies for managing/sharing data [Details: ] __Other [Details:] | Check all that apply __Better source/input materials [Details: ] __Common format/terminologies for managing/sharing data [Details: ] __Other [Details:] | Check all that apply __Better source/input materials [Details: ] __Common format/terminologies for managing/sharing data [Details: ] __Other [Details:] |
| Support We Can Provide Other Participants |
|
|
|
Stakeholders can place comments at the bottom of any Learning Community page. If you need editing access to these Participant Window pages, please contact support@ahrq-acts.org.
Excerpts from 9/4/20 email exchange about using computable/standards-based evidence descriptions to make developing and updating computable, evidence-based clinical recommendations more efficient/effective.
Adapted version of note from Jerry Osheroff:
Below is a small excerpt from the HL7 CPG on FHIR Draft Computable Guideline L2 Template (Recommendation tab) being used by the C19HCC Digital Guidelines WG. The question the Learning Community is exploring is whether/how the trajectory of SRDR/COKA efforts to provide computable, standards-based input and out from SRDR could at some point and in some way lead to auto-populating/updating this type of information in some future version of this template:
Evidence supporting recommendation: | Quality of Evidence: | Relationship between Quality of Evidence - Strength of Recommendation: |
Build Evidence Table or reference Evidence Summary | Use GRADE or USPSTF |
|
Condition | Study Design | Author, Year | N | Statistically Significant? | Quality of Study | Magnitude of Benefit | Absolute Risk Reduction | Number Needed to Treat | Comments |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Response from Brian Alper (lead of EBM on FHIR and COKA) - [the rest of the back and forth below deals with an important issue that's downstream from the issue of computable evidence]:
...
The HL7 CPG IG is not first and foremost CDS, its very much intended to be a computer-interpretable expression of the guideline itself; then with: 1) the means to derive highly related artifacts such as ECA-Rule-based CDS, patient-specific, practice-level metrics that *may* be rolled up into Quality Measures, eCaseReports to provide all the detail of guideline ‘execution’ at the patient-level (when they met criteria for a recommendation, when CDS notified the clinician of the proposed action, when/if clinicians took said action [order/request], when said proposal or request was fulfilled [whether evidence of request or not], any desired metrics that were captured and how they may have evolved over time [e.g. “on/off path”, “on with a history of off”], and any provider Impressions that may qualify any of the afore mentioned); and 2) lots of human consumable narrative on how to implement an HL7 CPG across its entire lifecycle (from working with Guideline Developers & the Evidence Ecosystem to working with local Practices and their informatics and EHR teams, and numerous other ecosystem touchpoints between- not the least of which is getting the data semantics as applied in point of care clinical information systems nailed- not just a bunch of terms hurled at ehr’s). Not sure if it is the name, the specification, how we have presented it to date, or some other factor, but that the HL7 Clinical Practice Guideline Implementation Guide describes the process and patterns that afford the means to computationally express the intent of the guideline is a point oft missed.
--------------------------------------------------------------------
Excerpts from Toolkit Idea, outlined on this page
Tool 3: Create/Store/Access Computable Rationale for Guidance
- Develop a proof of concept web interface and an API that use the FHIR standard for data exchange (i.e., EvidenceReport and PlanDefinition Resources maintained by the COKA/EBM on FHIR/CPG on FHIR HL7 projects) to encode a recommendation's evidence basis, i.e., pertinent studies and systematic reviews encoded by tools 1 (computable study results) and 2 (computable systematic reviews) above. This computable guidance rationale tool will also encode the rationale and confidence for the recommendation.
- This enhanced, automated evidence processing for recommendations could be demonstrated to support data entry into the 'Evidence Supporting Recommendation' section of the C19HCC knowledge elicitation tool (see excerpt in diagram below). [Note - there are other templates for producing guidance, e.g., this one from GRADEpro, WHO "Digital Accelerator Kits", and others]
- Two functions that could be demonstrated are support for: 1) gathering and synthesizing the evolving evidence base pertinent to a recommendation and 2) assigning standard codes for the rationale behind and confidence in the recommendation.
Excerpt from Knowledge DRAFT Elicitation Tool:
Image Added
[intervening portions omitted]
Image Added
- Likewise, the proof concept tool could also demonstrate web-based connection to other guideline development/presentation software to facilitate use of standards-based, computable evidence in guideline development. For example, MAGICapp, used in the Australia National COVID-19 Living Guidelines initiative - see disease severity, section 4, pertinent to triage.
- The tool could contain a feature that notifies CDS and guideline developers/implementers that new systematic reviews on the topic of interest (testing/triage) is available.
- This tool uses EBM on FHIR and CPG on FHIR: leads for these efforts are closely engaged in the ACTS COVID Collaborative and could be involved in developing this toolkit
- Outputs from the use of the C19HCC knowledge elicitation tool are provided to the C19HCC Agile Knowledge Engineering teams, who create L3 guideline representations (i.e., in CQL and BPMN) and CDS/eCQMs/eCaseReports that are deployed in clinical settings.
- The resulting CDS interventions could be placed in CDS Connect; consider synergies between living computable evidence/ guidance as demonstrated in the proof of concept toolkit and the CDS Connect Authoring Tool.
Tool 4: Identify/Store/Access Terminology for Computable Recommendation Definition
- Develop a proof of concept tool that enables guideline and CDS developers to identify/gather (e.g., via web interfaces, APIs) appropriate standard coded concepts and/or value sets for the required data elements needed for guideline execution.
- For example, exposures, symptoms, high risk conditions, and special circumstances listed in the CDC Phone Line Advice triage algorithm (see page 6) that underlies part of the NACHC CDS intervention.
- Proof of concept tool addresses challenges that knowledge engineers currently face in identifying code sets and value sets needed to make concepts and data elements in clinical guidelines computable. In a leading effort to put the CPG on FHIR implementation guide for computable guidance into practice, members of the C19HCC Digital Guideline WG are using a knowledge elicitation tool (see figure below) to elicit these concepts/terms from SMEs and then manually searching code sets/value sets to obtain codes needed to make recommendations computable. This part of the concept demo toolkit provides an automated lookup function that maps concepts/terms to potentially matching items from pertinent value/code sets. These codes/value are needed to access pertinent data from EHRs to execute the recommendation.
- For example, the new tool could leverage the data dictionary being developed under the NACHC project to help computable guidance developers search code set repositories (e.g., from the COVID-19 Interoperability Alliance and others) to express guideline-related clinical data elements (e.g., body temperature) using specific, standard code sets (e.g., LOINC code, ICD-10, SNOMED, etc.).
Excerpt from Knowledge DRAFT Elicitation Tool:
Image Added