Korábbi változatok

Under ConstructionEvolving Description of ACTS Collaborative Participant's COVID-19 Knowledge Ecosystem Efforts

For more information about the COKA initiative, see here. For overview presentation on making evidence computable see: AMDIS Ted Talk EBM on FHIR 2020 Oct 1 PPT

Steroids for COVID-19 Systematic Meta-Review Protocol; slides about this effort (see Assistive Technology Disclaimer).

See after the tables for important additional information

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.

Additional Information about COKA

For various use cases of supporting knowledge transfer with standards for data exchange the COKA efforts are occurring in 4 layers:

1. Standard development refining the schema for data exchange – FHIR Citation, Evidence, EvidenceReport and EvidenceVariable Resources
2. Terminology development – currently working on Code System Development for Study Design, Statistic Type, Statistic Model, and Risk of Bias concepts
3. Tools development – we have 2 tools development groups facilitating infrastructure support and sharing for tools developers
4. Content development for demonstration purposes – most implementations will be for content efforts by others; one current project initiated within the COKA effort is a Systematic Meta-Review for steroids as treatment for COVID-19

To Achieve Common formats/terminologies for managing/sharing data [see Appendix at bottom of this page for example]:

This is a draft list of the types of data that could be helpful to make the knowledge supply chain more efficient by making this data computable in ways that support automated update notification and evidence/guidance processing in the knowledge supply chain. COKA teams are working on ways to communicate these data in reusable interoperable standard form. If this ACTS exploration identifies a specific, high priority need for a standardized version of one or more of these items, the COKA teams developing these standards for data exchange and code systems can explore addressing this need as a priority in their work. The interplay in this area between the COKA and ACTS work are discussed in the COVID-19 Knowledge Accelerator (COKA) Knowledge Ecosystem Liaison Work Group, which meets Wednesday 8A ET (see here for WG details). 

• Citations that a new article exists -- Citation Resource
• Study design classifiers - Citation.classifier and Evidence.studyType but we are working on the Study Design Code System
• Population and Intervention classifiers -- Group Resource (used for Populations to harmonize with CDS artifacts from CPGonFHIR) and EvidenceVariable Resource
• Outcome classifiers - EvidenceVariable Resource
• Risk of Bias assessments -- Evidence.certainty.certaintySubcomponent but we are working on the Risk of Bias Code System
• Study Results -- Evidence Resource
• Synthesis Results -- Evidence Resource
• Summary of Findings (synthesis results plus certainty judgments) -- Evidence Resource and EvidenceReport Resource

If Collaborative participants need standards for other types of data exchange, COKA can discuss establishing this with the COKA/ACTS effort or coordinate with other groups to address this need.

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

The COKA Project Management Group created an Evidence Based Medicine-on-FHIR (EBMonFHIR) for HL7 Sep2020 WGM PowerPoint. This PPT can also serve as an introduction to COKA efforts.   The PPT series includes a 5-step answer to “What do we need to do in early developmental stages?” with:

...

We created a Code System Development Protocol. The Project Management Group registered the Code System Development Protocol at Open Science Framework (OSF) and will advance the project posting to a registry posting.  

We are working now on creating 4 Code Systems:

...

• Read the Invitation to join Expert Working Group
• Complete the Code System Development Intake Form

...

3. Develop tools for initial implementation – demonstrating that data exchange can work

Discussion of work being done by

...

4. Adapting tools for early adopter real-world implementation5. Develop an Implementation Guide.

These are often the “early stages” for standard development in HL7, but we are a little earlier because we are applying the standard to a community that (1) has not been functioning with computable expression for data exchange and (2) has not established universal standards for computable expression.   We are making great progress with what it takes for the earliest stages of introducing the computable layer to digital data expression.   We sincerely expect to get to #4 by the end of the calendar year.

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

COKA Drafting COKA Team is Drafting a “Protocol Draft for Feasibility Testing of Making Clinical Trial Results Computable”

The Goals are:

1. Establish feasibility (functionality, accuracy, acceptability, reproducibility) of a human-friendly data entry form to express clinical trial results in a standard for electronic data exchange (FHIR).
2. Measure usability (success rate, error rate, efficiency, subjective experience, learnability) for the data entry form.

...

• A person who is an investigator of a clinical trial, an author of a report expressing clinical trial findings, or a person contributing to the expression of clinical trial findings for the investigator or author
• A person who is summarizing a clinical trial report to express clinical trial findings for another purpose such as evaluating the clinical trial report, including the clinical trial report in synthesis work such as a systematic review, or reporting the clinical trial findings in a different format or to a different audience than the original clinical trial report

5. Develop an Implementation Guide.

These are often the “early stages” for standard development in HL7, but we are a little earlier because we are applying the standard to a community that (1) has not been functioning with computable expression for data exchange and (2) has not established universal standards for computable expression.   We are making great progress with what it takes for the earliest stages of introducing the computable layer to digital data expression.   We sincerely expect to get to #4 by the end of the calendar year.

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

From Earlier Discussions:

This is a draft list of the types of data that could be helpful to make the knowledge supply chain more efficient by making this data computable in ways that support automated update notification and evidence/guidance processing in the knowledge supply chain. COKA teams are working on ways to communicate these data in reusable interoperable standard form. If this ACTS exploration identifies a specific, high priority need for a standardized of version one or more of these items, the COKA teams developing these standards for data exchange and code systems can explore addressing this need as a priority in their work. The interplay in this area between the COKA and ACTS work are discussed in the COVID-19 Knowledge Accelerator (COKA) Knowledge Ecosystem Liaison Work Group, which meets Wednesday 8A ET (see here for WG details). 

• Citations that a new article exists -- Citation Resource
• Study design classifiers - Citation.classifier and Evidence.studyType but we are working on the Study Design Code System
• Population and Intervention classifiers -- Group Resource (used for Populations to harmonize with CDS artifacts from CPGonFHIR) and EvidenceVariable Resource
• Outcome classifiers - EvidenceVariable Resource
• Risk of Bias assessments -- Evidence.certainty.certaintySubcomponent but we are working on the Risk of Bias Code System
• Study Results -- Evidence Resource
• Synthesis Results -- Evidence Resource
• Summary of Findings (synthesis results plus certainty judgments) -- Evidence Resource and EvidenceReport Resource

Earlier Note from Jens Jap, SRDR Team: "my team is interested in ... the development of automated literature searches to assist in SR updates or at least signal an opportunity for one. A preliminary step to this effort was the development of a RCT classifier. I think this is similar to what you previously referred to as COKA enhanced tagging tool, at least in nature. Using these kinds of machine learning assisted tools can bring us a step closer to more automation and living SRs. " Response from David Tovey: "In terms of an RCT Classifier, you may be interested to know that a tool with exactly this name has been developed by James Thomas and his team at UCL in London. It is currently in use within Cochrane but it might be useful to reach out to James if you are interested to explore this. ... The tool is capable of assessing large bundles of citation and abstracts very quickly with an accuracy level that is at least as good as could be achieved manually."------

Appendix

As an example of developing a common format for managing/sharing data about certainty of evidence, below is a recent summary of one of the COKA efforts

 The group also summarized (in the Progress Report) a developing proposal for a FHIR Change Request:

• Title of change request: Simplify certainty element and prep for recursive use
• FHIR Resource affected: Evidence
• Use cases:

1) Report a simple overall certainty of evidence for a body of evidence using the GRADE rating system.

2) Report a detailed certainty of evidence for a body of evidence with many subcomponents using the GRADE rating system.

3) Report an overall risk of bias judgment for a single study using ROB-2 assessment tool.

4) Report a detailed risk of bias assessment with many subcomponents for a single study using ROB-2 assessment tool.

5) Report certainty ratings from different groups or individuals.

6) Report certainty ratings using different code systems.

• Best practices: Provide explicit expressions of what is being rated, what system is being used to rate it, what the rating is, and the rationale for the rating.

• RECOMMENDED APPROACH TO CHANGE THE FHIR SCHEMA:
• Evidence.certainty      0..*       BackboneElement
• Evidence.certainty.description   0..1      string
• Evidence.certainty.note              0..*       Annotation
• Evidence.certainty.type              0..1      CodeableConcept**
• Evidence.certainty.rating            0..*       CodeableConcept**
• Evidence.certainty.subcomponent     0..*       BackboneElement (see certainty element to repeat structure)

**code systems and value sets for these elements will need to be revised via UTG process to add relevant codes for the use cases.  For example https://terminology.hl7.org/1.0.0/CodeSystem-certainty-subcomponent-type.html will become CodeSystem-certainty-type and at a minimum will need a new code for "overall certainty"

• Recommended approach for implementation: If using more than one certainty element to convey certainty ratings for the same concept by different raters (individuals or groups/organizations), then use Evidence.certainty.type.text to express the rater/source matching the  Evidence.certainty.type.coding
• Importance/Tradeoffs: important to simplify the certainty element in general (which is done by moving up type and making the whole element recursive) to coordinate with use across Evidence and PlanDefinition resources; tradeoff is a breaking change for prior use of certaintySubcomponent elements but we are introducing this change before there are hundreds of such items.
• Backwards Compatibility: Type 1 - removal of element (certainty.certaintySubcomponent)
• Discussion: Create examples in JSON to show it before proceeding with the vote.

NEXT STEPS include (a) creating examples to show how this works in JSON and (b) defining the EvidenceCertaintyType and EvidenceCertaintyRating code systems and value sets needed quickly (and they will later be enhanced with the result of our Risk of Bias Code System Development).  If we can achieve these developments in the next week then we can submit this for vote for the October 7 HL7 CDS Work Group meeting.