Annotated FHIR-36131 - Getting issue details... STATUS to simplify discussion in BRR Call. For purpose fo clarity I aligned identical or similar changes. in addition, changes which are not identical but similar are set in bold.
Option 1 An example using Option 1 based on Eligibility Criteria for Bariatric Surgery Randomized Trial can be viewed at https://fevir.net/resources/EvidenceVariablePlusCharacteristic/32064 | Option 2 An example using Option 2 based on Eligibility Criteria for Bariatric Surgery Randomized Trial can be found at https://fevir.net/resources/EvidenceVariablePlusCharacteristic/32120 | Explanation Why was this added? What does the change make possible? How does it make it possible? If there are differences between Option 1 and and Option 2 please highlight the differences. | ||
|---|---|---|---|---|
| 1 | Addition of copyright 0..1 markdown | 1 | Addition of copyright 0..1 markdown | Added to support shareable, re-usable expressions/definitions of eligibility criteria. Makes it possible to specify the license terms for re-use. |
| 2 | Addition of approvalDate 0..1 dateTime | 2 | Addition of approvalDate 0..1 dateTime | Added to support shareable, re-usable expressions/definitions of eligibility criteria. Makes it possible to specify the date when the resource is approved for use. |
| 3 | Addition of lastReviewDate 0..1 dateTime | 3 | Addition of lastReviewDate 0..1 dateTime | Added to support shareable, re-usable expressions/definitions of eligibility criteria. Makes it possible to specify the date when the resource content was last reviewed. |
| 4 | Addition of effectivePeriod 0..1 Period | 4 | Addition of effectivePeriod 0..1 Period | Added to support shareable, re-usable expressions/definitions of eligibility criteria. Makes it possible to specify the time period within which the resource content is approved for use. |
| 5 | Addition of characteristic.lilnkId 0..1 id | 5 | Addition of characteristic.lilnkId 0..1 id | Added to simplify internal referencing of characteristics by other characteristics. Makes it possible to describe multiple inter-related characteristics without having to create separate resources for each characteristic. |
| 6 | Change datatype of characteristic.note 0..* from Annotation to string | 6 | Change datatype of characteristic.note 0..* from Annotation to string | Changed to simplify the resource structure, provenance data for the note is not necessary at the element level as additional resources can be created in the uncommon event it is needed. |
| -- | - | -- | ||
| -- | 7 | Change cardinality of characteristic.definition[x] from 1..1 to 0..1 (and add a rule that either definition[x] is used OR both type[x] and value[x] is used but not BOTH definition and type/value) | OPTION 2 SEPARATES THE APPROACH TO USING A DEFINITION (with one definition[x] element) OR USING A CODE/VALUE PAIR (with one type[x] element plus one value[x] element) | |
| 7 | Change datatype of characteristic.type 0..1 from CodeableConcept to type[x] CodeableConcept | Reference(EvidenceVariable) | id | 8 | Change datatype of characteristic.type 0..1 from CodeableConcept to type[x] CodeableConcept | Reference(EvidenceVariable) | id | Changed to support referencing characteristics by Reference (external EvidenceVariable Resource) or id (internal characteristic element) in addition to CodeableConcept. Makes it possible to define a characteristic of another characteristic, e.g. number of doses of an acceptable vaccine where the acceptable vaccine is defined as a referenced characteristic. |
| 8 | Change datatype of characteristic.definition[x] 1..1 to add more datatypes resulting in CodeableConcept | boolean | Quantity | Range | Reference() | canonical() | Expression | 9 | Addition of characteristic.value[x] 0..1 CodeableConcept | boolean | Quantity | Range | Reference() | Added datatypes to support boolean, Quantity, and Range. Makes it possible to define quantitative characteristics. OPTION 1 LOOKS SIMPLER FOR THE RESOURCE STRUCTURE BUT REQUIRES THE IMPLEMENTER TO ALWAYS USE DEFINITION[X] AND CONSIDER ADDING TYPE[X] OPTIONALLY WHEN A CODE/VALUE PAIR IS DESIRED. OPTION 2 SEPARATES THE APPROACH FOR SINGLE-ITEM DEFINITIONS AND TWO-ITEM CODE/VALUE PAIRS TO DEFINE A CHARACTERISTIC. |
| -- | -- | |||
| 9 | Addition of characteristic.offset 0..1 CodeableConcept | 10 | Addition of characteristic.offset 0..1 CodeableConcept | Added to support comparative characteristics, e.g. 5 mg/dL below the reference range. |
| 10 | Change datatype of characteristic.timeFromEvent.event 0..1 from CodeableConcept to event[x] CodeableConcept | Reference() | dateTime | id | 11 | Change datatype of characteristic.timeFromEvent.event 0..1 from CodeableConcept to event[x] CodeableConcept | Reference() | dateTime | id | Added datatypes of Reference() and id to support time offset from a referenced characteristic. Added datatype of dateTime to support "time period" without requiring an additional data element. |
| 11 | Change datatype of characteristic.timeFromEvent.note 0..* from Annotation to string | 12 | Change datatype of characteristic.timeFromEvent.note 0..* from Annotation to string | Changed to simplify the resource structure, provenance data for the note is not necessary at the element level as additional resources can be created in the uncommon event it is needed. |
| 12 | Addition of characteristic.combination 0..1 BackboneElement | 13 | Addition of characteristic.combination 0..1 BackboneElement | Added to support characteristics specifying combinations of other characteristics. |
| 13 | Addition of characteristic.combination.code 1..1 code (all-of | any-of | at-least | at-most | net-effect) | 14 | Addition of characteristic.combination.code 1..1 code (all-of | any-of | at-least | at-most | net-effect) | Added to support characteristics specifying combinations of other characteristics. |
| 14 | Addition of characteristic.combination.threshold 0..1 positiveInt | 15 | Addition of characteristic.combination.threshold 0..1 positiveInt | Added to support characteristics specifying combinations of other characteristics. |
| 15 | Addition of characteristic.combination.characteristic 1..* see characteristic | 16 | Addition of characteristic.combination.characteristic 1..* see characteristic | Added to support characteristics specifying combinations of other characteristics. |
As per BRR and EBM consensus we Proceed with Option 2 and also remove EvidenceVariable.characteristicCombination as discussed by BR&R March 1st
Follow-up Discussion in Run-up to Connectathon
https://confluence.hl7.org/x/nSKkBQ
Further Examples
Brian showed how the structured elig criteria could be represented in the EvidenceVariable (EV) resource – did a detail walkthrough with examples from a Diabetes Surgery Study. Demo on the FEVIR platform –
https://fevir.net/resources/Project/32444
Examples of Inclusion Criteria: (detail walk thru of how each criteria would be represented in the EV resource – go to https://fevir.net/resources/Project/32444)
- Age 30 to 67 years at eligibility visit
- Diagnosed with T2DM at least 6 months prior to enrollment, under the active care of a doctor for at least the six months prior to enrollment, and HbA1c ≥ 8.0%. (this would be considered a combination of 3 characteristics)
- Diagnosed with T2DM at least 6 months prior to enrollment
- under the active care of a doctor for at least the six months prior to enrollment
- and HbA1c ≥ 8.0%
- Body Mass Index (BMI) ≥ 30.0 kg/m2 and ≤ 39.9 kg/m2 at eligibility visit.
- Willingness to accept random assignment to either treatment group.
Examples of Exclusion Criteria:
- Current evidence of congestive heart failure, angina pectoris, or symptomatic peripheral vascular disease.
- Cardiac stress test indicating that surgery or IMM would not be safe.
- Significant anemia (hemoglobin 1.0 g or more below normal range)
2 Comments
Lorenz Rosenau
Thank you for your proposal.
Some thoughts on the presented points:
5/5, 7/7, 7/8, 12/13, 13/14-15/16 all share the common goal to express the complete set of criteria in a single EvidenceVariable. I honestly don't see the advantage of this overhead. Instead, I propose offering a value[x] 0..* with valueReference to reference other EvidenceVariables.
This offers multiple advantages:
10/11 further requires a change in the description of EvidenceVariable.characteristic.timeFromEvent to express retrospective periods.
Further, I want to raise awareness for the usage of type as i currently view it:
It seems that the assumption is made that there is always a code to identify the criteria uniquely.
However, this is not the case: ATC codes can represent the concepts of Medication, Medication administration, and Medication statement. The proposed changes could model the different contexts in which ATC codes are used as types and use value[x] to specify the code further.
Contrary laboratory values encoded with Loinc would typically be modeled using type and value.
Finally, to express complex data ypes like a tissue specimen that is "available" and was extracted from the "liver." The type would be, i.e., the snomed code for tissue specimen and the values, references to the type status with the value "available" and the bodyside "liver."
Resulting in a total of 3 different usages of type: As "context on the concept," "the concept identifier," "the attribute identifier for a parent concept."
With the goal to use the characteristics as an input to use the characteristic as a intermidate query representation for CQL, FHIR Search, AQL, etc. in mind this could be challenging. As a translator of any kind will require a known set of types to translate the concepts to queries dependent on the underlying data model. Consequently, independent bindings and clearly identifiable attributes should be prefered.
As a final remark, it remains unclear why we change the characteristic of EvidenceVariable, if we don't use its characteristicCombination of EvidenceVariable, but extend the characteristic itself. In that case, we would be better off modifying Group.characteristic and not using a Group of EvidenceVariable. But maybe I am unaware of the other use-cases for EvidenceVariiable outside expressing I/E criteria in research studies that require the same changes, which would underline the argument to have a Characteristic Resource that can be used in both: EvidenceVariable and Group.
Brian S. Alper
Lorenz – your comment about confusion between EvidenceVariable.characteristicCombination and EvidenceVariable.characteristic.combination shows that we can simplify EvidenceVariable further by removing EvidenceVariable.characteristicCombination – when you wish to specify it you just make the combination part of a characteristic.
EvidenceVariable has many elements for complex characteristics already because it is used for exposures, outcomes, measured variables, other variables than just population/sample/eligibility criteria. We propose enhancing EvidenceVariable for this to leverage the improvements for other evidence variables and support this use for Group without having to create a net new resource for FHIR.
We also think it is easier to manage multiple internal characteristic elements by id than create full resources for each characteristic if they are not otherwise being independently used.