Korábbi változatok

Under Construction

Extract from notes of 9/28/20 Meeting:

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

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

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:

...