Stream: Clinicians on FHIR
Topic: Proposal for a new resource
Grahame Grieve (Apr 09 2019 at 03:13):
I'm thinking that it's time for me to raise a new resource that I think we need. The resource would be named something like "ConditionDefinition" and it would have the following kinds of content:
- a code (possibly with qualifiers like severity and stage) that identified what the condition was
- references to formal definition of biological knowledge about this kind of condition in ontologies
- lab tests to display that are relevant to this kind of condition
- medication value sets that are relevant to this kind of condition
- plan definitions that are relevant to this kind of condition
- possibly: pre-conditions for diagnosing this kind of condition
- whether severity, bodyside and stage are relevant for this condition
- a reference to the units/specialists/organizations for this condition
This is intended to support application work flow around condition / problem management. it's not intended as an ontological statement of the biology of the condition.
With regard to SNOMED CT, I think that if you have a ConditionDefinition for a snomed code, some of the properties I have proposed might be inferred from looking at the specializations of the root concept, but most of the information is orthogonal to SNOMED CT. Even the inferrable information is only 'what is possible' not 'what is configured'
I've seen several systems in the last few weeks building work flows on some kind of equivalent definition.
@Viet Nguyen @Russell Leftwich @Susan Matney @Laura Heermann @Michelle (Moseman) Miller
Grahame Grieve (Apr 09 2019 at 03:13):
(oh and @Rob Hausam)
Dave Carlson (Apr 09 2019 at 03:53):
Grahame, I think there is, or should be, alignment with the emerging IG for Clinical Practice Guidelines on FHIR (CPGonFHIR). We will be reviewing related use cases in the Care Planning connectathon track in Montreal. Also adding @Bryn Rhodes
Grahame Grieve (Apr 09 2019 at 03:54):
well I always believe in alignment ;-) How would they relate?
Dave Carlson (Apr 09 2019 at 03:57):
Overlap with: pre-conditions for diagnosing this kind of condition, references to associated evidence (alignment with EBMonFHIR), lab tests that are relevant (order sets within the guideline PlanDefinition), medications that are relevant (part of the guideline)
Grahame Grieve (Apr 09 2019 at 04:00):
- how does the guide do preconditions for diagnosis? (EBMonFHIR = literature evidence - different kind of evidence)
- lab tests to display != to lab tests to order (in what I've been shown anyway)
- same for medications
Rob Hausam (Apr 09 2019 at 06:20):
I think this sounds interesting and probably useful. One or more examples to look at would probably be helpful.
Russell Leftwich (Apr 09 2019 at 12:57):
Probably should be diagnostic tests instead of just lab tests, body site instead of bodyside, and medication indication rather than specific medications
Dave Carlson (Apr 09 2019 at 16:28):
- how does the guide do preconditions for diagnosis? (EBMonFHIR = literature evidence - different kind of evidence)
- lab tests to display != to lab tests to order (in what I've been shown anyway)
- same for medications
Most guidelines for chronic conditions include screening criteria for diagnosis or preexisting conditions/history that indicate increased risk for the condition. We are considering how these screening conditions can be expressed in a computable guideline. For the labs and medications, sounds like a "flowsheet" concept.
Grahame Grieve (Apr 09 2019 at 19:55):
yes more flowsheet than biological definition. screening criteria.... we do need to express that in FHIR. I do not think that is what EBMonFHIR is doing, and I don't know if that's what I'm proposing. maybe what I'm proposing should also be that?
Russell Leftwich (Apr 10 2019 at 07:57):
Is there an example condition we might use to work through some of these concepts?
Grahame Grieve (Apr 10 2019 at 11:10):
no but I guess I should make one. (Having not been shouted down!)
Dave Carlson (Apr 10 2019 at 22:15):
Not shouted down, just clarifying the use case and boundaries :-)
Russell Leftwich (Apr 17 2019 at 02:50):
Two things have occurred to me the past week that support the idea of having a ConditionDefinition. One is the issue we discovered two years ago when starting the care plan/care management track in the connectathon. The health concern that is the reason for referral or related to the goal for the patient is not the diagnosis or on the problem list often. The diabetic is not referred to the foot doctor because of diabetes, but because of the risk of diabetic foot complications. Insulin is not used to treat the diabetes, it is used because the patient has insufficient insulin. The condition treated with the diabetic diet is not diabetes, it is the chronic elevation of blood glucose. What we also discovered was that there are no SNOMED CT codes for "risk of diabetic foot complications", or chronically elevated blood glucose. The second issue that has come up this week (again) is the clinical status of Condition. The available status values active, inactive not really appropriate for many conditions which are by definition self limited: a common cold, non-displaced wrist fracture. And conditions that by nature are not evident most of the time: migraine headache. Perhaps CoditionDefinition should have an element that reflects if a condition is self-limited, permanent (amputated leg), intermittently manifest, usually chronic.
Grahame Grieve (May 26 2019 at 21:43):
Ok: an initial draft here for people’s comment: http://build.fhir.org/conditiondefinition.html. (Should be there in a few minutes).
Grahame Grieve (May 26 2019 at 21:43):
I’m not entirely happy with ‘definition’ as part of the name - it’s not really the definition of a condition, so much as a set of system pointers for resources that are relevant when caring for a patient with the condition
Grahame Grieve (May 26 2019 at 21:45):
I do not think that the core definition of a problem - in an ontological sense, or a Description logic sense, is proper business for FHIR to take up - it belongs elsewhere
Grahame Grieve (May 26 2019 at 22:29):
Whoops. ConditionDefinition.code should be 1..1
Last updated: Apr 12 2022 at 19:14 UTC
