Stream: implementers
Topic: Conditions vs Problem Lists
Jeremy Rogers (Jan 24 2018 at 16:00):
If the List resource can contain 'a variety of resources (e.g. a problem list including Conditions, AllergyIntolerances, recent Procedures, etc.)', so that declaring whether something is a Problem or not can be achieved by explicitly listing it within a Problem List, what's the purpose of being able to separately and directly annotate with 'I'm a problem' only that subclass of all 'problems' that can be represented as instances of the Condition resource, via the Condition.Category element and its suggested valueset value of 'problem-list-item'? Is there some notion that things can be a problem but never appear explicitly within a Problem List instance? If so, why do only conditions get this capability? Why not all the other types of resource that are legitimate members of a Problem List?
Michelle (Moseman) Miller (Jan 24 2018 at 19:34):
There has been some resistance from implementers who dislike using List - and it partially stemmed from a discussion about how to represent no known problems/allergies (e.g. using List.emptyReason OR using Condition.code / AllergyIntolerance.code). For example, US Core IG doesn't require the use of List resources to represent the "problem list" or "allergy list" etc. Instead, the "problem list" is simply retrieved via Conditions (and Conditions can have a mix of problem list entries as well as encounter diagnoses) and the "allergy list" is retrieved via AllergyIntolerance.
As it pertains to Conditions, specifically, we have refined/clarified that Condition's scope 1) includes anything on the problem list, which represents items that have risen to a level of concern, and 2) those allergies/procedures/family hx that are on the problem list may also be represented using other resources as well.
Grahame Grieve (Jan 24 2018 at 22:39):
US Core is wrong to assume that all conditions are on the problem list; there is a long list of other reasons for the system to have conditions that are not part of the patient's problem list (but are still marked as a 'problem')
Lloyd McKenzie (Jan 24 2018 at 22:43):
It's also wrong to assume that there's only one problem list. The psychologist, gynecologist, GP, surgeon and physiotherapist are unlikely to have the same lists.
Jeremy Rogers (Jan 25 2018 at 12:12):
Codes for procedures (usually surgical) often find themselves classed as a 'problem' and so currently appear in many clinically curated Problem Lists and Patient Summaries. Whilst this might not be a semantically ideal thing to have done, that's real world Problem Lists for you. So if all problem list members must be cast as Condition resource instances to avoid the ceremony of a List resource, how does that work when the coded item the clinician put in the Problem list is in fact the code for a procedure?
Sometimes the procedure-as-problem is standing in for the post-surgical state it caused e.g. below knee amputation (procedure) instead of amputee (finding). Sometimes - as in my example - the clinicians do this because the set of procedure codes available offers more granularity as to the implicit post-surgical state than does the set of available explicit finding codes. Sometimes its the result of the explicitly available information being lost in the gaps between transfers of care because clinicians can manage perfectly well with only the implicit information: I've lost count of the number of primary care Patient Summaries I've seen that record a prior radical mastectomy (followed, in the prescribing record, by tamoxifen prescriptions) but no breast cancer diagnosis.
Sometimes, however, the 'problem' doesn't relate to some post-surgical complication or state.at all.. but rather to the fact that the procedure hasn't even actually happened yet. It may have been cancelled - possibly several times. Or the patient may currently be unfit for it, or have all manner of common anxieties in relation to some aspect of an upcoming procedure. In these contexts, the procedure code is often used as a convenient proxy for things that could in theory be separately represented as 'proper' conditions (anxiety, phobia, transport difficulties, economic consequence of work absence etc, all of the above...) but there's often not obviously a way in many source EPR applications to link those Conditions to their common root cause in the same Procedure resource, and where that procedure unambiguously has the equivalent of Procedure.Status=preparation state. But even if EPR 'causal linkage' capability was more ubiquitous, in practice few clinicians will (given the choice) author such a fine-grained and semantically rigorous representation of reality : its much easier to use the code for the procedure itself as a proxy for all of the above.
(In passing issue: the current definition for event staus 'preparation' is perhaps a tad hospital-centric in its world view. Does it also cover the period after being listed for and consenting to a procedure but before the day itself, when the patient is fretting at home in the community?)
So shoe-horning all members of real world problem lists into the Condition resource therefore looks problematic in respect of the above phenomenon. If you don't support it - ie you prohibit clinicians from continuing to place procedures directly into Problem Lists - then you're forcing a change in clinical coding practice. And some real problem lists won't be FHIRable until they've been manually clinically re-curated to comply with that new tighter, semantic constraint.
On the other hand, if you do seek to support passing procedure codes as problem-list-item Conditions, then this would require a significant challenge to the expected terminology binding for that resource, which currently excludes that possibility. And relaxing the terminology binding might even not be enough: the Condition resource doesn't offer elements equivalent to the Procedure.status valueset such as would be needed to distinguish between a procedure that was a 'problem' because it had happened (proxy for some post-surgical state) and one that had not (proxy for various anxieties). Casting procedures as Conditions would therefore required the reader to interpret them all as fundamentally ambiguous with respect to whether or not they actually ever happened. Similar issues I would suspect arise if codes for other typical problem list phenomena - e.g. family histories and allergies - have to be recast as a Condition resource purely in order to access that resource's simplistic mechanism for declaring membership of an unspecified Problem List.
Grahame Grieve (Jan 25 2018 at 13:10):
my experience is that it's common to see procedure codes and medication codes (and even diagnostic test codes) in the problem list, where they a proxies for the actual problem. That's why the condition code binding will only ever be an example binding - at least in the standard; in some circumstances, people may be able to tighten it up. So my view is: the code is a proxy for the condition. And I've never seen a formal procedure description in a problem list, so I don't anticipate things like condition.status code being a problem
Rob Hausam (Jan 25 2018 at 14:15):
I think that's a helpful and accurate analysis, @Jeremy Rogers. And I agree with @Grahame Grieve's response. The fact that the Condition.code binding is example allows clinicians the freedom to construct the problem list using the Condition resource in the ways that they feel is appropriate, as you have described (assuming that any jurisdictional and local profiles that apply also allow it). The fact that it's semantically messy and potentially allows for ambiguity is a concern, but that probably isn't as big a problem as it might sound, as the context of how these codes are used usually will be relatively clear (just as they are on the existing problem lists).
Michelle (Moseman) Miller (Jan 25 2018 at 14:22):
@Grahame Grieve per your comment:
US Core is wrong to assume that all conditions are on the problem list; there is a long list of other reasons for the system to have conditions that are not part of the patient's problem list (but are still marked as a 'problem')
I agree that not all conditions are on the problem list, which is why I support both US Core and the base FHIR specification having a Condition.category, which can be used to identify problem-list-items (defined as "an item on a problem list").
That said, I do agree with Lloyd that there can be multiple problem lists, but I don't think US Core has any requirements to expose practitioner-specific problem lists. As such, US Core is able to use Condition resource without List.
Jeremy Rogers (Jan 25 2018 at 14:42):
@Rob Hausam @Graham Grieve I'd completely agree that problem lists can be moved around between clinicians via the machine without running into too many problems even if the contents of e.g. the Problem List are semantically rather broad. Or even crazy. Truly wildly miscoded 'problems' abound in clinical records, commonly occurring because - in the context of the particular patient and the rest of their EPR content - everybody bar the machine is able to reach a common and unambiguous understanding. Temperature (attribute) or High temperature (physical force) in an EPR, for example, instead of pyrexia. But unless we have some idea of how we're going to turn the semantic constraint screw, we'll all soon be drinking from a FHIRhose of clinical data with such dubiously vague and inconsistent semantics that the machine itself isn't really safely able to help in understanding or acting on the data. Lumping everything into a single Condition bucket, rather than encouraging progressive semantic partition and precision, looks a retrograde step IMHO.
Grahame Grieve (Jan 26 2018 at 00:53):
@Michelle (Moseman) Miller - it's not enough to use Condition.category to different between 'the problem list' and conditions that are not part of the problem list. That will differentiate between "not on the problem list' and 'maybe on a problem list'. But there are 'on some problem list', 'once on some problem list', 'one on the problem list', 'reported to have been on some other problem list' etc. "The problem list" is not something that can be contained inside the resources that support the problem list
Grahame Grieve (Jan 26 2018 at 00:57):
@Jeremy Rogers : we definitely agree that we want information with good semantics, and that where it exists we don't to contribute to eroding the semantics. But I don't believe that this is discussion is framed that way. Problems should be actual problems - that is, condition resources. But I think you're saying: if users use proxies like procedures, then the system should support them being precisely imprecise, and use non-condition resources. I think that's the wrong way to push the complexity....
Jeremy Rogers (Jan 29 2018 at 17:28):
@Graham Grieve don't disagree that it would be useful to find a way to push/help clinicians to using fewer procedure codes as proxies for other more directly codable 'condition' type phenomena. My main worry is how to get from where we are - a lot of clinically relevant historical data already miscoded in this way - to where we want to be.
Designing terminology binding constraints too much for the way we want the world to be rather than for how it currently is risks excluding significant volumes of current Problem List items from being exchangeable without significant re-coding workloads falling upon the reluctant sending or receiving clinician. A broader question I'll pursue in another thread is what FHIR's role might best be in facilitating the kind of progressive improvement in clinical data quality and semantics that we all recognize to be a Good And Necessary Thing, but whilst still allowing the Sins of the Past to flow.
I also suspect there may be considerable professional clinical resistance to any attempt at imposing the same semantic 'no procedures as problems' constraint at the point of primary data capture. Recording 'mastectomy' as the problem is a lot more natural linguistically than is 'missing a breast', especially if the underlying problem for which the procedure is acting as the proxy isn't the unstated cancer diagnosis but e.g. the post-op cosmesis. Or (more likely) both. Human factors often prevent pushing the complexity to where it technically might more obviously belong.
Last updated: Apr 12 2022 at 19:14 UTC
