Stream: implementers
Topic: negated Condition
David Hay (Sep 06 2016 at 02:25):
Did we come to a landing on how to express a negated condition? - eg 'the patient does not have asthma'. or 'I have ruled out meningitis as a diagnosis' ?
Michelle (Moseman) Miller (Sep 06 2016 at 18:44):
Unless I missed something while on maternity leave, I would have suggested using Condition.verificationStatus = refuted (which is defined as the condition has been ruled out by diagnostic and clinical evidence).
David Hay (Sep 06 2016 at 20:17):
nice!
Rob Hausam (Sep 06 2016 at 23:05):
The definition of "refuted" is "This condition has been ruled out by diagnostic and clinical evidence." Based on that, it works for the second example. It seems to be a bit of a stretch for the more generic "does not have" case in the first example, though. You certainly could argue that a clinician wouldn't state that "the patient does not have asthma" unless they had at least clinical evidence to support that, and that probably makes sense. But the asserter can also be a patient. There I don't think that "refuted" would fit, but maybe we don't need to be concerned about having a coded assertion of absence in that case, anyway? The alternatives are a pre-coordinated "no x" or "does not have x" code, or code.text.
Richard Townley-O'Neill (Sep 07 2016 at 00:36):
There needs to be some way to say "patient says that they are not allergic to peanuts" and using a status of refuted in AlleryIntolerance seems wrong for several reasons:
1) it being recorded in status suggests that it was suspected and is now refuted
2) this is an unconfirmed assertion that something is not so, it has both confidence and negation. Status has values for confidence, _unconfirmed_ and _confirmed_. Adding to _refuted_ a new code for _unconfirmed refutation_ means making the meaning of status unclear.
There seem to be two concepts: life cycle status of the resource and whether the resource is positive or negative.
Grahame Grieve (Sep 07 2016 at 00:47):
AllergyIntolerance is the place for that, not Condition
Richard Townley-O'Neill (Sep 07 2016 at 00:51):
Oops, yes.
How about "patient says that they have never had chicken pox"?
David Hay (Sep 07 2016 at 02:59):
If we expand the meaning of 'refuted' to allow for 'asserter denial' - that would cover it, would it not? (or add 'denied' as an option)
Richard Townley-O'Neill (Sep 07 2016 at 04:31):
That would cover it. But I think 'asserter denial' is outside the usual meaning of 'refuted'. Would it surprise people to discover that 'refuted' can mean 'claimed to not be so' and not just 'proved to not be so'?
Richard Townley-O'Neill (Sep 07 2016 at 04:35):
At the moment there are values for 'thought to be true but unconfirmed' (unconfirmed), 'confirmed to be true' (confirmed) and 'confirmed to be false' (refuted). I see you idea as expanding the scope of 'refuted' to include 'thought to be false but unconfirmed'.
John Moehrke (Sep 07 2016 at 12:29):
This means all queries need to not only look for the condition,. but also must include the not refuted (and all the future negative words). We are getting into dangerous triple negative space. I have broad concerns, but in this case I am expressing a concern brought up in the context of Privacy and Security policy enforcement. Protecting sensitive statements is hard enough without needing to include triple negative protection. (no specific meaning in the phrase triple negative except to convey that complexity lies here). I don't have the solution, but I understood a reason to leave the V3 space and do it better in FHIR was to simplify. Surely with greenfields we can come up with a more elegant solution...
Rob Hausam (Sep 07 2016 at 20:48):
I agree generally with @Richard Townley-O'Neill and @John Moehrke. The TermInfo project (in Vocab) intends to develop an IG for use of terminology (initially SNOMED CT, but including others) in FHIR. We do need to be careful to avoid overloading the meaning and intended use of 'status'. I agree that the life cycle status of the resource itself and the presence or absence of the entity that the resource represents are separate things, and I think we're generally best off keeping them separate (it's a bit muddy right now in some places, including Condition.verificationStatus and AllergyIntolerance.status, and we don't want to make that worse). We hope to address issues of this nature in the IG, and are planning to begin with AllergyIntolerance (where there's been considerable dicussion and a fair bit of work already done). That's the thought at present, anyway. It would be good to enterain further discussion of this and similar issues - and the terminology stream would be a good place for that.
Stephen Royce (Sep 09 2016 at 01:34):
There are a whole load of requirements in this space that FHIR does not appear to have properly considered yet. Not just with conditions, but allergies, medications, procedures, ... In Australia, we currently have a number of explicit models for this which we cannot easily translate into FHIR because of the lack of ability say things like "never had", "not currently taking", &c. Any of which may be asserted by a variety of people: patient, related person, practitioner, &c. While terminology may well provide some of the answers, it is a known issue that SNOMED has little in the way of cooncepts describing negation and is unlikely to have the kind of expression our models currently carry for some time to come. So I would think that there is a need to seriously consider having explicit model elements for negation.
Rob Hausam (Sep 09 2016 at 01:57):
Stephen, we do need to consider that - but the information model negation solutions in general certainly haven't been without their own problems
we should take a further look at the Australian examples, and it would be very helpful to make sure that we've included whatever use cases and examples you have in the Negation Requirements project - which will then feed into FHIR and, as much as possible, into the other standards families, as well
Stephen Royce (Sep 09 2016 at 02:01):
Which working group does this fall under? Is it Patient Care? If so, @Stephen Chu is aware of most of what we've done in this respect, but I can make sure he feeds our models to the WG.
Rob Hausam (Sep 09 2016 at 02:06):
Yes, it is Patient Care, and @Stephen Chu certainly is aware - we should at least verify that we have all of the relevant models and requirements - you can talk to him about that, and I will as well
Stephen Royce (Sep 09 2016 at 02:13):
Sweet. I'll give Stephen some material to share with the WG. 
Rob Hausam (Sep 09 2016 at 02:21):
sounds good - thanks!
Grahame Grieve (Sep 09 2016 at 03:55):
Is there any evidence that any of those negation models reflect actual clinical practice?
Stephen Royce (Sep 09 2016 at 07:25):
I couldn't tell you. I do know that the models, as they currently stand, are very poor from a data modelling practice perspective, but the basic ideas carried in them would seem to be useful; or, at least, to a non-clinician like me, they would seem to be useful! However, I have no idea whether or not current systems allow the recording of things like "not currently taking any medication", "not currently taking a particular medication", "no history of a given condition or procedure", "the patient has never undergone any procedures".
Stephen Royce (Sep 09 2016 at 07:32):
We (in the Agency) find ourselves on the horns of a dilemma here. On the one hand, FHIR's goal making things easy and straight for implementers is laudable and something we support; on the other we want to move forward what their systems record to foster a more sophisticated digital health ecosystem in Australia.
Grahame Grieve (Sep 09 2016 at 12:12):
those are separate discussions. FHIR ia the underlying techniology, but you can make your profiles as tight as you like. However expereince shows that it's not very easy to get clinicians to agree to this.
Rob Hausam (Sep 09 2016 at 15:08):
yes, I think we should be aware and cautious not to tread very far (if at all) beyond where there is evidence of actual clinical practice and need (e.g.. the FHIR 80% rule)
Stephen Royce (Sep 11 2016 at 23:45):
We don't want to make our profiles tight, we want to expand the models to include data items that may well be part of clinical practice, but do not currently fall within the 80% implementation boundary. That is, data items in models, the lack of which is restricting clinicians from properly recording their actual practice.
Stephen Royce (Sep 11 2016 at 23:47):
Model expansion, not tightening!
Grahame Grieve (Sep 12 2016 at 18:14):
typically, clinicians are not recordings things because they don't want to. Witnesss the howls of dismay here in USA where they are asked to
Grahame Grieve (Sep 12 2016 at 18:14):
but there's no reason you can't add whatever you want in your profiles
Stephen Royce (Sep 12 2016 at 23:15):
Yeah, I get all that. I suppose my thing is that, for example, the whole AllergyIntolerance resource is major overkill for an exclusion statement. I could profile it down, but even then, it will only work where negated SNOMED codes (or the like) exist. So if you want to record that a person is not allergic to obscure things (sunlight maybe?), that might be somewhat of a challenge without using modifier extensions (which I think we should be avoiding like the plague). On the other hand, if we had a dedicated exclusion statement resource for allergies, not only would the model be much simpler, but I'd have access to the whole SNOMED substance and finding hierarchies to express exactly what I wanted.
Stephen Royce (Sep 12 2016 at 23:16):
Also, I'm not proposing forcing clinicians to record stuff they don't want to; I'm proposing enabling them to record stuff they do want to.
Lloyd McKenzie (Sep 13 2016 at 01:01):
It's not just the clinicians - it's having multiple groups of clinicians who convince sufficient implementers to introduce the complexity of the additional resource into their persistence, user interface and external interface layers, including mapping existing data and then having clinicians use it. It would require quite a bit of passion and money to make that happen - and there's a lot of places where most people would probably look for more bang for the buck elsewhere
Stephen Royce (Sep 13 2016 at 01:11):
This is not just about persistence of data; e.g. I'm pretty sure most clinical systems have the capacity to persist information about particular things to which a person is not allergic. This is also about how already persisted information is exchanged. The model for exchanging non-allergies is heavy-weight and not easy to understand nor implement.
Stephen Royce (Sep 13 2016 at 01:13):
As far as whether or not expanding what's persisted in the space is worthwhile, that's not my job. My job is to provide the expanded models and others decide whether they're worth investing in, and, if so, how. I just need a means to have ready to go persistence models that people can use. For those building FHIR servers, a FHIR resource would be good!
Grahame Grieve (Sep 13 2016 at 04:37):
@Rob Hausam where did we get to with the AllergyIntolerance exlucsion statement stuff?
Rob Hausam (Sep 13 2016 at 16:57):
We have the discussion on Negated Allergies and Intolerances (http://hl7-fhir.github.io/allergyintolerance.html#9.1.3.2) about what we can do with AllergyIntolerance.code, and there is the substanceExposureRisk extension, which isn't a "dedicated exclusion statement" but allows for the full range of substance codes (or findings, as it's example) to be used in an exclusion statement, as Stephen is describing
Jay Lyle (Sep 14 2016 at 00:04):
There's a lot here.
If there are examples of negation requirements in AUS, let's try to make sure they are represented in the Negation project collection of requirements (http://wiki.hl7.org/index.php?title=Negation_Requirements). I'd point out that we are trying to collect actual requirements, not curious examples of what could conceivably go wrong, e.g., triple negation.
(The "patient reports never having had chicken pox" case is interesting: do we know of someone who has wanted to record that?)
For allergies, "patient says" no allergy to X is provenance, not a different flavor of negation. There's not a lot of confirmation testing in that domain, as I understand it.
For conditions, it may be different, but my preference would be to put provenance in provenance. Who refuted something may be germane, but if it is, you can ask. If the refutation criterion of "clinical evidence" excludes patient testimony, well, then we have more to do.
If we can keep the concepts of "absent" or "not done" separate from provenance and certainty, then SNOMED covers the need.
David Cai (Apr 05 2017 at 06:44):
Reading this old topic, if I want to say no known allergy intolerance, how do I do that?
Michelle (Moseman) Miller (Apr 05 2017 at 10:31):
AllergyIntolerance.code = NKA (SNOMED code)
For more information on negated allergies, refer to https://www.hl7.org/fhir/allergyintolerance.html#9.1.3.3
Last updated: Apr 12 2022 at 19:14 UTC
