Under Construction

For more information about the COKA initiative, see here.

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:

1. Agree to standard format for expression – schema/model of FHIR Resources

FHIR Resources at Maturity Level 1

1. Evidence
2. EvidenceVariable
3. Statistic (Datatype)
4. OrderedDistribution (Datatype)

FHIR Resources at Maturity Level 0

1. Citation
2. EvidenceReport

2.Agree to common terminologies – codes systems, value sets

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:

• Study Design Code System to describe methodology characteristics of scientific observations such as randomized assignment, crossover allocation to cohorts, and qualitative analysis.
• Statistic Type Code System to describe the statistics reported such as mean, median, proportion, relative risk, absolute risk difference, p value, confidence interval, and I-squared measure of heterogeneity.
• Statistic Model Code System to describe the model characteristics such as linear regression, random-effects analysis, and tau estimation method.
• Risk Of Bias Code System to describe the concerns with methods or reporting of scientific observations such as comparator selection bias, gaps in blinding, and selective outcome reporting.

You can join any of the Expert Working Groups.

• 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

• Content Citation and Classification Tools Development Work Group
• Evidence Evaluation and Reporting Tools Development Work Group
• Systematic Meta-Review Project Group

4. Adapting tools for early adopter real-world implementation

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.

The “clinical trial reporter” can be:

• 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.

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

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.