Stream: implementers
Topic: Assertions of Condition Absence
Jeremy Rogers (Jan 19 2018 at 17:01):
What's the general mechanism for representing positive statements of absent phenomena, such as conditions, signs, symptoms, physical exam findings, allergies, intolerances or family histories that the patient does NOT have? The Condition resource documentation (https://www.hl7.org/fhir/condition.html#9.2.3.5) at least acknowledges the problem exists. But the AllergyIntolerance, FamilyMemberHistory and Obervation resource documentations appear silent on it. The Condition resource documentation itself is, I would contend, also seriously inaccurate when it claims that "Generally, electronic records do not contain assertions of conditions that a patient does not have".
Lloyd McKenzie (Jan 19 2018 at 17:10):
I don't think it's inaccurate, but it's perhaps a bit incomplete. EHRs don't contain a catalogue of all the conditions a patient doesn't have. They do occasionally include statements about things a patient used to have, things they were suspected of having but it turns out they don't or positive declarations of the absense of something when that verification is a necessary precursor to some form of therapy.
Lloyd McKenzie (Jan 19 2018 at 17:10):
If you'd like that wording cleaned up, feel free to submit a change proposal.
Jeremy Rogers (Jan 19 2018 at 17:13):
There over 400 precoordinated 'absence of X' codes in SNOMED CT and in its precursor clinical terminologies. They were collectively used to make somewhere north of 50 million new coded EPR items in the UK alone over the last 6 years, with the following 34 being routinely among the top 2000 most popular coded terms of any kind:
No abnormality detected - examination result (finding)
No known allergy (situation)
Lymphadenopathy absent (situation)
No vomiting (situation)
No history of migraine (situation)
No suicidal thoughts (situation)
No breathlessness (situation)
No cough (situation)
No family history of clinical finding (situation)
No pain (situation)
No edema present (situation)
No temperature symptom (situation)
No family history diabetes (situation)
No thoughts of deliberate self harm (situation)
No family history: Cardiovascular disease (situation)
On examination - meningism absent (situation)
No history of clinical finding in subject (situation)
No family history: Venous thrombosis (situation)
No smokers in the household (situation)
Rash absent (situation)
On examination - diabetic maculopathy absent both eyes (situation)
No family history: breast carcinoma (situation)
No family history: Ischemic heart disease (situation)
No family history of clinical finding (situation)
No headache (situation)
No family history: Cardiovascular disease (situation)
No nausea (situation)
No palpitations (situation)
No family history of stroke (situation)
No speech problem (situation)
No visual symptom (situation)
No significant drug interactions (finding)
No past history of venous thrombosis (situation)
It is, of course, true that statements of clinically significant negatives typically make up only a relatively small fragment of the coded EPR payload. Its equally true that less-than-comprehensive recording of them has long been a bugbear of CDSS researchers. So whilst low usage may be the present reality, it isn't necessarily where we want to remain.
And so a more general mechanism to cope with the list of clinically significant negative findings is required. Where is that? Entirely in the terminology? If so, then ONLY in a postcoordinating one AFAIK.
Jeremy Rogers (Jan 19 2018 at 17:15):
Nobody's going to exhaustively list the logically true and complete 90,000 conditions that every patent doesn't have. Just the 10 important ones.
Lloyd McKenzie (Jan 19 2018 at 17:15):
AllergyIntolerance has the notion of "refuted" as well as a discussion of how to convey "no known allergy". FamilyMemberHistory has not yet identified a common requirement to state that a particular family member did not have a condition. And statements like "no maternal history of breast cancer" are handled by Observation. With Observation, you can communicate negated findings just as you can communicate positive ones.
Jeremy Rogers (Jan 19 2018 at 17:17):
Neither refuted nor none known apply when (a) nobody ever said or thought you were allergic to peanuts (so, nothing to refute..) and (b) we know you're allergic to penicillin (so, not no known allergies) but (d) we know you're not allergic to peanuts and so you have no relevant allergy in the context of whether you can enter an environment that may contain peanuts. Like a school.
Lloyd McKenzie (Jan 19 2018 at 17:20):
I would expect "refuted" to be used there too, but agree some clarification would be good. Can you submit a change request?
Jeremy Rogers (Jan 19 2018 at 17:25):
Been staring at the Observation resource structure for a while but couldn't work out how to encode a negated/not present finding such as e.g. no suicidal thoughts. Perhaps there's a relevant exposition I should go read in the notes...
Jeremy Rogers (Jan 19 2018 at 17:26):
And not sure how to submit a change request as still new to this game!
Michelle (Moseman) Miller (Jan 19 2018 at 17:27):
Here is new guidance that was added to Observation around negated findings (guidance was added after STU3, so it should make R4 barring any negative feedback from the Jan 2018 ballot): http://build.fhir.org/observation.html#interop
Michelle (Moseman) Miller (Jan 19 2018 at 17:30):
BTW, "Propose a Change" is a link at the bottom of every page
Lloyd McKenzie (Jan 19 2018 at 17:33):
When proposing a change, you'll need to do a one-time registration and someone will try to make sure you're a real human being, after which you should receive a confirmation email and be good to go. Change proposals can be submitted by anyone and are essential to improving the quality of the spec.
Michelle (Moseman) Miller (Jan 19 2018 at 17:33):
Regarding FamilyMemberHistory, we do have the following guidance (added after STU3): http://build.fhir.org/familymemberhistory.html#9.4.2.4 that says
The FamilyMemberHistory.condition.code can be used to capture "No Known Problems" or negated conditions, such as "No history of malignant tumor of breast", for an individual family member
Jeremy Rogers (Jan 19 2018 at 17:35):
I guess you could clarify/alter the meaning of 'refuted' from the current implicit 'some (unreferenced) prior statement of presence exists AND this is hereby contested' to the more general 'this is a statement of absence; don't care whether it ever was previously thought true' and so using that verificationStatus could become the general mechanism I was asking about, especially if carried over to the related resources of allergies and family history. But then 'refuted' would seem the wrong word for the value, and we're also then back in the thorns of how to manage the overlap between that general mechanism in FHIR and e.g. SNOMED's capability to manage the same semantics via precoordination.
The motive for my asking the question BTW was to clarify whether in fact that age-old problem might in fact have 'gone away' as a result of FHIR choosing NOT to offer a general mechanism. Which seemed unlikely....and would have important ramifications for uptake of postcoordination.
Jeremy Rogers (Jan 19 2018 at 17:37):
Thanks Michelle ...that link at the bottom of the page is easy to miss!
Michelle (Moseman) Miller (Jan 19 2018 at 17:42):
Regarding AllergyIntolerance, guidance is in http://hl7.org/fhir/STU3/allergyintolerance.html#9.1.3.3. To summarize, there is an extension available, http://hl7.org/fhir/STU3/extension-allergyintolerance-substanceexposurerisk.html, which can be used to convey "No known risk of allergy or intolerance reaction upon exposure to the specified substance" -- but where a pre-coordinated codes exist, such as SNOMED's No Known Latex Allergy, it can be used in AllergyIntolerance.code without needing the extension.
Jeremy Rogers (Jan 19 2018 at 17:55):
Re: proposal for general solution to capture 'no FH of X' as 'Family history of (no personal history of X)' ... this doesn't sit comfortably, I must say. For one thing, I'm not sure that it doesn't blur the important logical distinction between the (not clinically very useful) notions of 'at least one family member does not have X' and the clinically far commoner one of 'NO family member has X'.
Also, that solution implies a general mechanism to encode 'no personal Hx of X', which I would have thought would therefore require FamilyMemberHistory.condition to be able to point to a reference to a suitable Observation resource that could utilise a general mechanism (Refuted?) to negate the regular observation of a 'personal history of X'. At the moment FamilyMemberHistory.condition grounds out in a codeable concept, which I think precludes an Observation reference?
Lloyd McKenzie (Jan 19 2018 at 18:04):
There's an extension to allow representing Observations specific to FamilyMembers. "family history" is typically a List that contains Observation instances and FamilyMemberHistory instances
Jeremy Rogers (Jan 19 2018 at 18:44):
Don't think that the draft AllergyIntolerance.substanceExposureRisk extension http://hl7.org/fhir/STU3/extension-allergyintolerance-substanceexposurerisk.html is really adequate for the use case in hand: using it to say that there's no risk of anything bad actually happening if exposed isn't clinically the same as saying 'not allergic to X'. The low risk may be the consequence of a treatment that may e.g. be discontinued or otherwise become ineffective. Clinically, it feels too much of a non sequitur: similar to attempting to argue that 'no risk of seizures' in a well-controlled epileptic is equivalent to saying 'doesn't have epilepsy'.
Michelle (Moseman) Miller (Jan 19 2018 at 19:44):
Feel free to log a change request to clarify the semantics of the codes in the value set (http://build.fhir.org/valueset-allerg-intol-substance-exp-risk.html). What I think I hear you saying is that the semantics of risk are unclear (e.g. whether risk is assessed in context of current treatment or not).
CC @Russell Leftwich @Rob Hausam
Jeremy Rogers (Jan 19 2018 at 20:27):
Not only in context of current treatment, no...if somebody sends me a message saying 'this individual has no risk of reacting to peanuts' then, clinically, I will assume that the reason they didn't say 'this individual is not allergic to peanuts' is because they in fact most likely are - otherwise, why mention the peanuts at all? - and so manage them accordingly. I would conjecture that you'd find that a common interpretation.
You might get away with a far stronger 'risk of reaction' statement such as 'this individual never has nor ever will react to peanuts' from which I'd probably infer that it was 99% also certain that they were not allergic/immunosensitised to peanuts, given the current state of known medical treatment for allergy and the unusually definitive strength of the statement that nothing bad either ever has or ever could happen if exposed.
But clinically that would be a very strange formulation of the traditional clinical message I'm interested in, and I doubt that you'd ever find the information input in anything like that presentation at source. Or, find a clinician who wants it displayed back to them that way at destination. Safer to send what was said, I would have thought. Dubiously indirected derivatives of it are risky.
Jay Lyle (Jan 19 2018 at 21:51):
1. Condition currently handles things you don't have if a) refuted, b) resolved, c) entered in error. There is no way to just say absent to rule out contraindications, unless we want to expand the definition of 'refuted' to cover that case; to which JR suggests that it might be better to have a separate value. I concur, in case that meeting happens without me. You refute propositions, not phenomena.
2. re Exposure Risk: seems sufficient to me, so-called to support intolerance irrespective of whether you know it's IgE-mediated (not, that is, to indicate "there is an allergy but I don't think it's a risk." I'd suggest criticality for that.) But if the name is ambiguous, perhaps it can be improved on.
3. SCT absence codes have some down sides. A) Your system might want to know it's absent without having to ask the terminology service, and B) you can't make logical inferences with negated concepts. So I like the extension, though I understand why a restful screen payload design would go the other way. Looking for suggestions on realistic ways to support translation.
Russell Leftwich (Jan 21 2018 at 23:31):
I think it fair to say that the semantics of risk are unclear. Regardless of mechanism there is the "risk" that the original assertion was incorrect and that either the reaction or the substance were incorrectly assessed. There is the mitigation of risk of recurrence of an immunologic reaction by the passage of time. All reactions are dose related (notwithstanding the fact that the occurrence of a a 1 in a billion probability will always make the news), and there is the possibility that the exposure will not be sufficient to cause a manifestation. And there is the assumption that the risk of exposure to a substance is greater than the risk of avoiding the substance. But all of this is not really related to assertion of absence of an allergy/intolerance condition. For that scenario, the risk is that the patient has had an adverse reaction since the historical assertion of absence of sensitivity. Best clinical practice would be to never use historical negation to make a decision about current treatment.
Peter Jordan (Jan 22 2018 at 00:44):
The point about not relying on historical negation certainly plays out in community settings, both inside and outside of healthcare facilities. Every time our football club (re)registers a kid for any sport-related activity, we have to ask if they have "any allergies" and it's essential to ask this question at any event where food is being supplied to children. Of course, this is predicated on the broader definition of 'allergy' used by the general public.
Rob Hausam (Jan 22 2018 at 18:46):
In FHIR (so far) we have avoided the use of the general "negation indicator" in the information model, I believe primarily due to the desire to not repeat the issues that arose with that approach in HL7 V3 and CDA, especially when used with a terminology like SNOMED CT that explicitly includes a model for negation (even if not in full description logic). The original V3 and more recent CDA TermInfo documents recommend that the negationInd attribute not be used when the terminology is SNOMED CT "because the context attributes can be used to specify the absence of a finding or the fact that a procedure has not been done" and "including both representations introduces potential for serious misinterpretation of combinations". In order to avoid the issues with combinations one of the approaches needed to be chosen, and the conclusion at the time (whether actually true or not) was that the use of the SNOMED CT context model is preferred as it would be safer (and therefore better) than using the negationInd attribute in the information model.
Instead of creating a general negation capability as in V3 (in all classes), in FHIR this is left up to each resource to handle it in the most appropriate way for the specific resource context (while still encouraging consistent approaches to the extent that is possible). Mostly this seems to be following the "negate in terminology" approach, and I think probably for some good reasons (although there is no question that there is some downside with this, too). The Condition resource has the discussion in 9.2.3.5 "Assertions of Condition Absence" that @Jeremy Rogers mentioned. And in 9.2.3.3 it states that "The Condition.code may also include such concepts as ..., as well as "no known problems" or "negated" conditions (e.g., "no X" or "no history of X"", and in the context that "Many of the code systems used for coding conditions will provide codes that define not only the condition itself, but may also specify a particular stage, location, or causality as part of the code" and that "This is particularly true if SNOMED CT is used for the condition, and especially if expressions are allowed." The statement that "Generally, electronic records do not contain assertions of conditions that a patient does not have" is probably too broad - probably instead it should say "Generally, the patient's problem list does not contain assertions of conditions that a patient does not have", which I believe is an accurate statement. Populating the problem list is likely the primary (not the only) use of the Condition resource (and that is consistent with the other discussion on using List.emptyReason to represent "no conditions/problems"). AllergyIntolerance has similar discussion in 9.1.3.3 Negated Allergies and Intolerances. In the R4 Draft for Comment ballot version of Observation (http://hl7.org/fhir/2018Jan/observation.html) there is a new section 10.1.4.2.3 on "Interoperability Issues using code value pairs in FHIR". That section at present doesn't directly address negative observations (we probably should add that), but it describes some of the options/issues in making the "code/value split" (whether the finding is positive or negative).
In regard specifically to using or re-purposing "refuted" to mean a more general statement of absence, that was not the intended meaning of that code and I don't think it would be a good idea to do it. At the very least I think we'd have to add a different status code. But I also don't think we should re-purpose the "status" element (of whichever variety exists in the various resources) for this. If (and it's a big if) we decide that we want to add a general capability for information model negation in FHIR, then I would strongly advocate for doing that explicitly.
And Russ's comment that "Best clinical practice would be to never use historical negation to make a decision about current treatment" shouldn't be overlooked. If someone has documented "no condition of x" for a patient at some point in time, then that is not something that needs to be managed now. And if someone documented "no allergy to x" at some point in time, then that doesn't mean that it's ok for me to administer "x" to the patient now because I'm relying on that prior documentation, without further verifying or attempting to verify it myself. So it might be necessary to have documentation of "no condition of x" or "no allergy to x" to show (at least for legal reasons) that it was considered, but it might not be necessary to code it, as it's unlikely (or much less likely) to be required for use in a computable way going forward. That's a primary reason why handling the negation in the terminology likely isn't as bad a solution as it would otherwise seem to be. We may not need to worry quite so much about having pre-coordinated codes (or a means to immediately get or create them) for all 90,000 conditions that a patient doesn't have. The number of those conditions that are clinically significant and that need to be computably encoded for any future decision making is finite and almost certainly can be known in advance.
So, although I don't think anyone can argue that it's perfect, it may well be that that the way in general that we are handling negated concepts in FHIR, primarily using terminology to place the negation as close to and in the context of the underlying clinical idea as possible, actually works reasonably well. And it may be at least as good or better than many of the alternatives that have been considered.
Rob Hausam (Jan 22 2018 at 18:52):
I apologize for the length of that post. And I'm ready for the flames! :)
Grahame Grieve (Jan 22 2018 at 19:56):
my main comment is that calling it 'the negation problem' is an artificial RIM derived perspective. It's a set of overlapping problems that are very complex - variations of shades of meaning, interplay between past, present, and future, and moving deck chairs around with regard to risk
Grahame Grieve (Jan 22 2018 at 19:57):
and so any relatively simple or unambiguous solution will be wrong :-(
Rob Hausam (Jan 22 2018 at 20:06):
I believe I agree with all of that - it's not only about "negation" (however broadly we want to define that).
Michael Lawley (Jan 23 2018 at 21:24):
@Rob Hausam says "avoided the use of the general "negation indicator" in the information model [because of]... a terminology like SNOMED CT that explicitly includes a model for negation...".
The problem is that SNOMED's "model of negation" is broken. It is not consistent, does not work properly with subsumption, and is incompatible, as modelled, with the description logic. IMO it should be completely ignored and the assertions of absence etc should be handled in the information model. Reasoning about negation in the terminology is particularly hard because scope is essential for negation and the context of use (i.e. the information model) affects the scope. Hence it is the only reasonably safe place to reason. The information model generally also has a closed world semantics rather than an open world semantics common to terminologies like SNOMED. Closed world semantics also help make reasoning about negation tractable.
Rob Hausam (Jan 23 2018 at 21:45):
@Michael Lawley I was primarily stating what the original V3 TermInfo position was (with significant input from David Markwell and others within the SNOMED CT community) and that there wasn't clear evidence brought forward at the time that it should be changed in the updated TermInfo for CDA R2. That doesn't necessarily mean, however, that that position is correct. I know that your position has been more in favor of using the information model. The problem with that, though, at least historically, is that the previous information model approaches used in HL7 V3 have also turned out to be either "broken" or at least to have been very difficult to understand and consistently apply. Your statement about the advantages of leveraging the scope and context of use and the closed world semantics in the information model sounds quite reasonable and attractive, but so far it doesn't seem to have worked out all that well in the prior practice. So the question then becomes something of "which approach is the least broken", which isn't resoundingly positive. That doesn't mean that a different and hopefully better approach to providing negation in the information model can't or shouldn't be used in FHIR, but it does at the very least suggest caution and careful deliberation if we do decide to go in that way.
Michael Lawley (Jan 23 2018 at 23:47):
Indeed, I wasn't suggesting that it is easy, or that just using the info model makes the problems go away. Rather, my position is that splitting the problem across the two makes it (much) harder.
Rob Hausam (Jan 24 2018 at 02:59):
I definitely agree with your point about (not) splitting it across the two - it's just that so far in FHIR we've mostly kept it in the terminology.
Grahame Grieve (Jan 24 2018 at 03:52):
long term, I believe that the only real solution is to reconcile the information and terminology models so they fully align. (e.g. define specific terminology for FHIR resources). But (before you all flip): there is no practical pathway towards that for many many reasons
Jeremy Rogers (Jan 24 2018 at 11:35):
Russell - I'd agree that in a purist clinical context there's not a lot of value in (and, correspondingly, very little operational use by clinicians of the notion of) statements to record that a patient is believed not to have some specific allergy or significant exposure reaction risk at some instant in time. The traditional catch-call expression of 'no known allergies' very obviously recognises the possibility that this information may be incomplete or wrong from the outset, or change over time even if completely true once. Caveat Lector.
As PJ says, the use case for this particular flavour of 'absence of <specified risk>' documentation may come more from social care settings. For example, school safeguarding records may need to record, for every attending child, the positive statement that they're not allergic to each common food allergen in order to justify a school policy of not prohibiting and policing their exclusion from all student lunchboxes. A catch-all entry of e.g. 429625007|No known food allergy| probably no longer provides sufficient granularity to allow a sane food allergen prohibition policy to be devised, now that food allergy is so much more common and recognised and nobody wants a policy where every single potential food allergen must be excluded from the canteen, because you don't know exactly which ones its actually safe to admit.
Of course, that whole-school record doesn't guarantee that no child could possibly turn blue the next time they encounter a kiwi fruit in the canteen. But, in that eventuality, the school would be able to defend itself: it becomes a far less likely adverse event than had they not bothered to establish the food allergy status of the entire school body at all and then design a bepoke allergen avoidance policy to fit, year on year. Risk mitigation, not risk obviation.
Similar safeguarding concerns and risk mitigation methods probably increasingly apply in care environments beyond the mainstream schooling (or recreational club) ones and that overlap more with mainstream clinical care, such as residential care homes. Hence I guess the possibility of needing to transfer safeguarding information of that granularity whenever care is transferred.
Rob Hausam (Jan 24 2018 at 12:36):
@Jeremy Rogers @Peter Jordan I agree that there is a need to be a bit fine-grained in the 'absence of <specified risk>' documentation for these school and other social care settings. But, even with that, there is still a finite "common food allergen" list that is known (or can determined) in advance, and pre-coordinated codes will either already exist or can be created to cover them. Of course, there is no way that in the school situation, for example, it will be asked for each child whether or not they are allergic to every ingredient that is anticipated to be used in food preparation over the course of the term, or if a new ingredient is added at any point that the entire student body will first be canvassed regarding whether they are allergic to it. This will be done only for the foods and ingredients on the "common food allergen" list, as already described. So I think that using pre-coordinated "no allergy to x" codes can still be a tractable solution for this scenario.
Jeremy Rogers (Jan 24 2018 at 12:39):
@Michael Lawley @Rob Hausam Completely agree that the worst of all possible worlds has applied for decades because both the information and terminology models have been concurrently offering overlapping , differently limited and/or differently broken mechanisms for negation. So at some level it may be an opportunity for progress if one model removes the functionality entirely, and thereby at least the overlap.
My concern now would be if the terminology IS to be the sole provider of a generalised but limited 'negation' mechanism, then both sides may yet need to put their houses more prominently in order on this point than they currently have. On the side of FHIR, guidance notes such as https://www.hl7.org/fhir/condition.html#9.2.3.4 or https://www.hl7.org/fhir/condition.html#9.2.3.5 or https://www.hl7.org/fhir/allergyintolerance.html#9.1.3.3 look to need revisiting/removing so as to more clearly signpost that 'absence of ' has been handed off outside FHIR. There's no need for any subtext alopng the lines of 'you don't really need this functionality, do you? There aren't enough 'absence of ..' type statements in the EPR anyway so lets just agree to forget about the problem'. Just point them at the terminology.
On the terminology (SNOMED CT) side, the currently published modelling of some precoordinated content, including that in some NRCs extensions, needs revisiting so that Michael's point about representational inconsistency is more addressed than it currently is. Its hard to understand or implement any guidance with respect to how this stuff is supposed to be represented if too much of the available content doesn't completely follow its own guidance.
Jeremy Rogers (Jan 24 2018 at 12:58):
@Rob Hausam I'd agree that the 'food allergen' use case appears likely to be manageable at least in the short to medium term by adding 40 or so common food allergen-specific pre-coordinated concepts. Though I wouldn't be at all surprised if in 10 years than list had grown to 100 or more, in the way that such lists do.
But that pre-coordinated approach clearly can't extend to all the phenomena that clinicians can and do want to be able to positively record the absence of, even if many such record entries can have only transient clinical currency and validity. So, to support and message the widest likely scope of 'absence of..' type utterances, SNOMED's general mechanism would have to be usable not only in-house (e.g. to author and model your 30-odd food allergen codes) but also externally. And, if its going to be used and required for non-food allergen use cases, there's an argument for saying there's less point providing pre-coordinated options for that narrow use case: use the same mechanism throughout.
Rob Hausam (Jan 24 2018 at 13:06):
@Jeremy Rogers I completely agree with all that you said above on 'negation'. Collectively we just haven't yet come to the point where we've felt able and ready to make a decision one way or the other on this - we're still straddling the fence. A significant part of that, I'm sure, is because each side (information model or terminology) is in command only of its own sphere and can't dictate what the other side should or must do - so instead both sides do it and we have the resulting awkwardness or even impossibility of how to understand and make it all work together. That, of course, gets to @Grahame Grieve's point that "the only real solution is to reconcile the information and terminology models so they fully align". How exactly to get to the point that both of you are describing, I still don't know for sure. I've had a dream (possibly a pipe dream) that a common RDF representation of both the information and terminology models and content might be part of that. But whether that's how we do it or whether we simply agree more explicitly on the boundaries and cooperation strategies, or however we choose to work it out, we should keep working toward getting there.
Rob Hausam (Jan 24 2018 at 13:12):
@Jeremy Rogers I agree with your subsequent comment, too - assuming that all of those cases where 'absence of' must be recorded also must be coded (and we could decide that all of them do, or that at least we must allow for that). We just need to decide where the practical and useful boundary for that actually is.
Grahame Grieve (Jan 24 2018 at 22:37):
a common representation may help create tooling that illustrates inconsistencies... but it won't solve them
Richard Townley-O'Neill (Jan 25 2018 at 05:17):
A given FHIR implementation could exclude all negative SNOMED CT codes from its value sets and do all of the negation in the information model, either with base attributes or extensions.
Last updated: Apr 12 2022 at 19:14 UTC
