Stream: implementers
Topic: negation/exclusion in AllergyIntolerance resource
Rob Hausam (May 22 2016 at 03:50):
I've worked out a strategy/proposal for handling negated/excluded statements in the AllergyIntolerance resource. It includes both renamed and additional elements to separate and handle the semantics involved - it's different from, but is along the lines of and should largely (or even completely) satisfy the concerns about mixed semantics that have been raised in recent negation discussions. I do expect that the proposed solution will be somewhat (or significantly) controversial, or it will at least generate significant discussion and questions. I've gone ahead and implemented this proposed strategy (including the elements, bindings, value sets, invariant, etc.) in my local build, as I think it is considerably easier to visualize and to be able to explore that way. I've checked it out with and have gotten some initial feedback from one of the Patient Care co-chairs so far. Long term, I think that a similar approach will likely be able to be used with the other FHIR clinical resources (Condition, Observation, etc.) - but there is not likely to be a "one size fits all" solution, as there are some uniquenesses across the clinical domains (especially, I think, with allergy/intolerance).
So, I'm wondering when is best to commit the changes? Should I go ahead and do that now? That would be easy for me to do, and would likely be the easiest way for others to review. Or do I need to further vet it first, prior to committing (and how much vetting does it need)?
Grahame Grieve (May 22 2016 at 03:53):
procedurally, I think PC co-chairs need to be ok with you committing so we can look at it. (That's at your discretion whether to check very time or just generally in advance)
Grahame Grieve (May 22 2016 at 03:55):
since we're not close to a freeze, I have no issue with you committing something speculative for people to look at. If it's big enough, we've sometimes created a second resource so people can compare, but in this case, they can compare with DSTU2, right?
Rob Hausam (May 22 2016 at 03:56):
yes - that would be the comparison - or with the STU 3 candidate
Erich Schulz (May 22 2016 at 03:59):
anythoughts of moving from svn to git?
Erich Schulz (May 22 2016 at 04:00):
I dragged one of my teams (almost) over and everyone is very happy... we actually retain svn but its use now limited to the final deployment phase
Rob Hausam (May 22 2016 at 04:00):
in the meantime, if anyone wants to take an initial look, you can do that at:
http://rhausam.no-ip.org/fhir/allergyintolerance.html
I'm thinking about adding some profiles, but haven't done that yet
my only request is that, if you really hate it, ask further questions before you blast it too hard :)
Erich Schulz (May 22 2016 at 04:01):
svn + git hasn't actually been painful at all just need to tell them both to ignore each other
Rob Hausam (May 22 2016 at 04:02):
Erich, sounds like that could be useful
Erich Schulz (May 22 2016 at 04:03):
the git branch and pull-request workflow is just awesome
Grahame Grieve (May 22 2016 at 04:07):
git vs svn is a subject for the committers stream. And it's been discussed before. often
Erich Schulz (May 22 2016 at 04:08):
we were a bit afraid when we started but just took it gently - tbh we're still not using the full git feature set (eg submodules)
Erich Schulz (May 22 2016 at 04:10):
@Grahame Grieve heh - i'm not surprised - speaking from experience I'd say "come on in, the water's fine" - just do it gradually and keep svn as the source of truth till everyone's comfortable
Erich Schulz (May 22 2016 at 04:11):
@Rob Hausam I followed that link and clicked "diff with DTSU2" and got no highligting
Erich Schulz (May 22 2016 at 04:11):
is it a new resource?
Grahame Grieve (May 22 2016 at 04:12):
the diff with dstu2 link will only work on the official versions - I have to massage it to be correct when I publish.
Grahame Grieve (May 22 2016 at 04:12):
but you can manually fix the URLs if you want
Rob Hausam (May 22 2016 at 04:12):
no, it isn't, but I'm only working from the current build on my server - and what Grahame said
Erich Schulz (May 22 2016 at 04:14):
erm... http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fhl7.org%2Ffhir%2FDSTU2%2Fallergyintolerance.html&doc2=http%3A%2F%2Fhl7.org%2Ffhir%2FDSTU2%2Fallergyintolerance.html
Erich Schulz (May 22 2016 at 04:14):
that's what it came up with
Grahame Grieve (May 22 2016 at 04:16):
yes, you have to replace one of those links with Rob's link. The build tooling doesn't know where the content is going to be published, so can't get it right in advance
Erich Schulz (May 22 2016 at 04:16):
mmm... cant do url encoding in my head!
Erich Schulz (May 22 2016 at 04:16):
http://services.w3.org/htmldiff?doc1=http%3A%2F%2Frhausam.no-ip.org/%2Ffhir%2FDSTU2%2Fallergyintolerance.html&doc2=http%3A%2F%2Fhl7.org%2Ffhir%2FDSTU2%2Fallergyintolerance.html
Erich Schulz (May 22 2016 at 04:17):
that's first go (not working)
Erich Schulz (May 22 2016 at 04:17):
ah
Erich Schulz (May 22 2016 at 04:17):
bingo
Erich Schulz (May 22 2016 at 04:18):
Rob Hausam (May 22 2016 at 04:19):
hmm - doesn't seem to be rendering too well for me
haven't tried to do this before
Erich Schulz (May 22 2016 at 04:20):
urg - yes rendering dizzying
Erich Schulz (May 22 2016 at 04:20):
did you reorder?
Erich Schulz (May 22 2016 at 04:20):
reordering is evil for diffs
Rob Hausam (May 22 2016 at 04:21):
no, I didn't
but I do note that my changes are showing up as strikeout text - the comparison appears to be reversed
Erich Schulz (May 22 2016 at 04:22):
oh i got them backwards :-)
Erich Schulz (May 22 2016 at 04:22):
'try that:
Erich Schulz (May 22 2016 at 04:22):
Erich Schulz (May 22 2016 at 04:23):
there's been some significant reodering somewhere...
Grahame Grieve (May 22 2016 at 04:24):
my immediate comment is that code/excludedCode are not differentiated from causativeAgent/excludedAgent, and I cannot imagine how they would be used usefully.
Grahame Grieve (May 22 2016 at 04:24):
nor is it obvious to me how you would deal with this if you have a text / uncoded allergy
Grahame Grieve (May 22 2016 at 04:25):
or a coding system that wasn't marked up with metadata for whether a code was an excluded or not
Rob Hausam (May 22 2016 at 04:27):
wow - yes - I didn't change it that much
could have added the new elements at the end, instead - that probably would be better for diff
@Grahame Grieve I think it does need more and better explanation for a lot of it
I think they actually are differentiated, and semantically there may be good reason to do so
but I'm also happy to be convinced that this is going at least a step too far - it's a proposal, and certainly subject to further input
Grahame Grieve (May 22 2016 at 04:32):
you'd be better of comparing to the STU3 candidate then. It got re-ordered before that
Grahame Grieve (May 22 2016 at 04:33):
Rob, well, up to you to explain it first then
Rob Hausam (May 22 2016 at 04:37):
I think text/uncoded goes in the CodeableConcept.text - for whichever element is appropriate for the case
and I added a code-all search parameter (don't know if that's a good name) that will let you search for a code value in any of the four elements - so you wouldn't need to know in advance which one was used (that doesn't help with text, of course)
substances (excluded or not) have a very different semantic from conditions and situations (in SNOMED terms)
I did try to explain the relationship with SNOMED CT modeling in the element comments (SNOMED isn't the only terminology option, but is the most important one to consider)
I think the comparison to STU3 candidate should work better
Rob Hausam (May 22 2016 at 04:41):
comparison is still fairly busy, but overall is much better against STU3
Erich Schulz (May 22 2016 at 04:43):
@Rob Hausam wow much better!
Erich Schulz (May 22 2016 at 04:45):
but the issue is - to echo @Grahame Grieve - is that there are now tow ways of saying exclude ie via status = refuted
Erich Schulz (May 22 2016 at 04:46):
if the goal is to be able to say "No Know Drug Allergies" (NKDA) - then isn't the simple thing to find the root classification code for "Medication"
Erich Schulz (May 22 2016 at 04:46):
then a single record that {status: "refuted", substance: <<medication root>>} ???
Rob Hausam (May 22 2016 at 04:47):
in our discussions I think we've generally agreed that refuted isn't the same as "excluded" - although I grant that there can be some considerable overlap
"refuted" is intended to say that an allergy or intolerance condition that was previously asserted has now been shown to be false
Erich Schulz (May 22 2016 at 04:49):
I suspect that sorting out the status values maybe the key
Erich Schulz (May 22 2016 at 04:49):
I can get the value of refuted
Erich Schulz (May 22 2016 at 04:51):
but if there were some other negative flavours that would capture the world
Rob Hausam (May 22 2016 at 04:51):
@Erich Schulz yes - that's certainly a possible/reasonable way to do it - but should we declare that it's the only way?
there is an existing pre-coordinated SNOMED CT code for NKDA - and if we do use that, should we not semantically differentiate that from the case of the 'Medication' code?
that's true for "positive" allergies/intolerances, too
Erich Schulz (May 22 2016 at 04:53):
well seems to me cleaner to clarify status than add new fields
Erich Schulz (May 22 2016 at 04:53):
i have no clue what exactly an "inactive allergy" is tho
Erich Schulz (May 22 2016 at 04:54):
or an active one really
Rob Hausam (May 22 2016 at 04:55):
to say "No known allergies", we could use the pre-coordinated SNOMED CT code for that - or use the top level hierarchy code for 'Substance' as the “excludedAgent"
@Erich Schulz - happy to entertain how we can use status to do all that we need
as I said, I expected to generate significant discussion - and I'm happy to be persuaded to make it simpler, if there is evidence to support that
Erich Schulz (May 22 2016 at 04:57):
ha - i think "eveidence" will be hard to come by - this seems like more an issue of style and preference rather than there being a single right way
Rob Hausam (May 22 2016 at 04:59):
originally I was entertaining the idea of sticking with a single coded element (renaming it to 'code') :)
agree that's likely about evidence, really
Erich Schulz (May 22 2016 at 04:59):
some of the things I'd like to be able to express are "not allergic to cephalosporins (as far as we can tell)" and "didn't react to cephalosporins last time, so should be fine this time too"
Erich Schulz (May 22 2016 at 05:02):
I can see (maybe) some merit in the snomed codes you identified here @Rob Hausam http://rhausam.no-ip.org/fhir/valueset-allergyintolerance-excluded-code.html but I think that they dont really belong in the allergyintolerance resource
Erich Schulz (May 22 2016 at 05:03):
these feel more like "condition" or "observation" codes to me
Rob Hausam (May 22 2016 at 05:03):
yes, I agree that we should be able to do that
and in this proposal we would probably do that with the code for the "cephalosporins" substance/medication class as the 'excludedAgent'
you could request a new pre-coordinated SNOMED CT code for it (likely in an extension) or use a post-coordinated expression, but that seems a lot less likely
Rob Hausam (May 22 2016 at 05:06):
that's part of the debate - should those codes be used, and, if so, where and how?
one thing we've heard clearly in the prior discussions is that many of us want to be able to get all of the information about allergies/intolerances in one place - and be able to use a straightforward query (e.g., of a single resource type) to get it
Erich Schulz (May 22 2016 at 05:10):
well my 2cw would be to delete inactive and active as meaningless and add negative codes in the form of has-previously-tolerated and not-previously-exposed, and I would leave substance as the single field to describe the agent(s) in question...
Erich Schulz (May 22 2016 at 05:11):
and to put things all in one place I would deprecate those snomed codes and instead use the root concepts in the hierarchy
Erich Schulz (May 22 2016 at 05:11):
</m2c> :-)
Rob Hausam (May 22 2016 at 05:11):
@Erich Schulz - do you think of "not allergic to cephalosporins (as far as we can tell)" and "didn't react to cephalosporins last time, so should be fine this time too" as significantly different?
my take is that the latter would be some level of evidence for the former
Erich Schulz (May 22 2016 at 05:13):
if someone is allergic to a related drug - eg penicillin then this makes a difference in if they get a drug or not
Erich Schulz (May 22 2016 at 05:13):
so it can make a real difference
Rob Hausam (May 22 2016 at 05:17):
@Erich Schulz, my take on what openEHR is doing is not like using negative codes in the form of has-previously-tolerated and not-previously-exposed
the "excluded" archetypes are more or less analogous to my "excludedCode" and "excludedAgent" elements
and I've also thought about creating an AllergyIntoleranceExcluded resource, which would be even more aligned with that - but would require querying two resource types to get all of the information
Rob Hausam (May 22 2016 at 05:19):
it's good to hear yoor thoughts - and I'm hoping (and expecting) to hear others
Erich Schulz (May 22 2016 at 05:20):
i can see merit of a second resource (although it just adds more noise)
Erich Schulz (May 22 2016 at 05:21):
ha - too many ways to skin a cat! I can see all these approaches being workable
Erich Schulz (May 22 2016 at 05:21):
but that status value list does give me hives
Rob Hausam (May 22 2016 at 05:27):
yes - agree
maybe it would be worth mocking up the "AllergyIntoleranceExcluded" resource, as well?
and maybe we could (temporarilly) include all of them in the build to make comparison easier
we can/should look again at the statuses
with the hives, maybe you're allergic to AllergyIntolerance? :)
Erich Schulz (May 22 2016 at 05:27):
heh
Erich Schulz (May 22 2016 at 05:29):
my real issue is that (as with all things)
Erich Schulz (May 22 2016 at 05:29):
is that "allergy" is just another risk
Erich Schulz (May 22 2016 at 05:29):
we maybe 100% sure the patient is allergic
Erich Schulz (May 22 2016 at 05:30):
or 70% (most commonly)
Erich Schulz (May 22 2016 at 05:30):
or maybe even 1%
Rob Hausam (May 22 2016 at 05:30):
right
Erich Schulz (May 22 2016 at 05:30):
or 99.999% sure there is no allergy
Erich Schulz (May 22 2016 at 05:31):
the vast majority of stated allergies are just made up
Erich Schulz (May 22 2016 at 05:31):
"I got a virus as a kid, then then mum made the gp give me penicillin, which is when i got a rash and some diarrhoea"
Erich Schulz (May 22 2016 at 05:33):
so splitting "known" and "refuted" allergies into 2 streams is always a bit problematic...
Rob Hausam (May 22 2016 at 05:40):
yeah, it is - but combining them, or using a "modifier element" to distinguish them, seems to be, too
DLBrown (May 23 2016 at 18:21):
Hi all-
DLBrown (May 23 2016 at 18:22):
Hi All - First time I've commented here, though I've been following FHIR for quite a while.
DLBrown (May 23 2016 at 18:22):
I wanted to chime in to support Erich Schulz comment on Allergies and Risks, and probability.
DLBrown (May 23 2016 at 18:23):
It would be great to examine a way to represent things like Allergy and Impression as accurately as possible. Making use of a coded value presents the same flexibility that we find useful for things like observations.
DLBrown (May 23 2016 at 18:25):
And, certainly for Allergies (AllergyIntolerance) this is quite germane. Representing Allergies in the problem list as real/true/canonical/verified is a very real problem, and source of mistrust for providers using the medical record.
DLBrown (May 23 2016 at 18:25):
There's a pretty good literature on the accuracy of patient-reported allergies, and it's grim.
Erich Schulz (May 24 2016 at 00:19):
thanks @DLBrown I think there is a similare issue with expressing uncertainty with timeperiod - still haven't see a way of expressing ideas like "while pregnant", "in childhood", "at night time", "years ago", "roughly 2004" - these are all clinicians may have have for many clinical statement found in many resources
David Hay (May 24 2016 at 01:39):
We used an extension for this - http:/fhir.hl7.org.nz/dstu2/StructureDefinition/al-TimeOfLife
Erich Schulz (May 24 2016 at 02:04):
@David Hay that url doesn't say much!
Erich Schulz (May 24 2016 at 02:05):
seems like a core notion required as an option anywhere period is used...
Erich Schulz (May 24 2016 at 02:06):
analogous to codeableConcept
David Hay (May 24 2016 at 02:10):
not that much to say 
Erich Schulz (May 24 2016 at 02:11):
erm more than The time of life when this allergy occurred (or was noted to occur) tho surely?
Erich Schulz (May 24 2016 at 02:11):
that's all i'm getting...
Grahame Grieve (May 24 2016 at 02:23):
Allergy/Intolerance is an important test case for FHIR, and has received a great deal of attention. It's an interesting case because everyone has to track allergy/intolerance statements, but there is a wide variation in how people actually do it, and litle prospect of getting people to see eye to eye on this.
Grahame Grieve (May 24 2016 at 02:23):
a certain set of researchers and specialists think that we should be quite proscriptive in the resource and make people be specific about their estimates
Erich Schulz (May 24 2016 at 02:24):
well that aint happening...
Grahame Grieve (May 24 2016 at 02:24):
but clinicians - and maintainers of existing records - generally go out of their way to avoid such things, and want to keep things very vague
Erich Schulz (May 24 2016 at 02:24):
there must be the option to record vague facts
Grahame Grieve (May 24 2016 at 02:25):
Cerner posted some analysis of 48million allergy statements in their client systems to the PC list a few months back - it was very interesting
Erich Schulz (May 24 2016 at 02:25):
they exist and often impossible to clarify
Erich Schulz (May 24 2016 at 02:25):
(vague facts that is)
Grahame Grieve (May 24 2016 at 02:25):
in fact, only yesterday I got to be asked the question by a registration nurse...
Erich Schulz (May 24 2016 at 02:26):
more to the point the cost of clarifying often exceeds the benefits
Grahame Grieve (May 24 2016 at 02:26):
it's almost like we need to separate allergy statement from allergy assessment - and in fact, I wonder if we could do a profile on RiskAssessment for a formal work up of a n allergy statement, on the grounds that the existing AllergyIntolerance represents an patient statement, possibly with supporting evidence
Grahame Grieve (May 24 2016 at 02:27):
and if you really cared - an inpatient allergist preparing a patient for treatment of something they believe they have an allergy to, for instance, then that's a totally different thing
Erich Schulz (May 24 2016 at 02:27):
there is an entire class of statements that have the same properties: period, probability and evedence....
Erich Schulz (May 24 2016 at 02:28):
in any situation certain vague facts will need clariying before proceeding - but many just remain asides
Erich Schulz (May 24 2016 at 02:28):
allergies and conditions both
Grahame Grieve (May 24 2016 at 02:28):
back to the topic - I'm extremely doubtful that Rob's proposed refactoring of the resource is viable in the real world. It's trying to be partly formal risk assessment, but the inputs are too vague to allow reasoning.
Erich Schulz (May 24 2016 at 02:29):
is "clinical impression" the way forward?
Grahame Grieve (May 24 2016 at 02:30):
well, I think that for formal assessmnent, yes, a combination of clinical impression and risk assessment. AllergyIntolerance is just the basic statement as kept by everybody as part of their risk management
Grahame Grieve (May 24 2016 at 02:30):
might need to be clearer about the scope, perhaps
Erich Schulz (May 24 2016 at 02:31):
it seems to me that expression of ambiguity (poth p and interval) are systemic weaknesses in FHIR as it stands
Grahame Grieve (May 24 2016 at 02:31):
we can't get agreement to that. And that's a sign that there's no data to populate it consistently.
Erich Schulz (May 24 2016 at 02:31):
let alone ambiguous ambiguity ;-)
Erich Schulz (May 24 2016 at 02:32):
mmm
Erich Schulz (May 24 2016 at 02:32):
it seems like FHIR is very close tho
Erich Schulz (May 24 2016 at 02:33):
and CodeableConcept seems like it provides an analogous type
Erich Schulz (May 24 2016 at 02:34):
i'm not imagining anything much more complex than that
Erich Schulz (May 24 2016 at 02:34):
this creates a nightmare for automated reasoning of course...
Erich Schulz (May 24 2016 at 02:34):
but that is the world....
Erich Schulz (May 24 2016 at 02:37):
observation.value is a precedent
Erich Schulz (May 24 2016 at 02:38):
ie need to allow expression of both precise numbers p=1 or p=0 or codeable fuzzy real work statements....
Erich Schulz (May 24 2016 at 02:39):
possible, unlikely, probable,
Erich Schulz (May 24 2016 at 02:40):
or sometime a range is possible p between 0.1 and 0.3 (based on some quantifyiable scoring)
Erich Schulz (May 24 2016 at 02:41):
if FHIR cant capture these ideas then clinicians are forced to record as narrative and there is zero chance of any automated processing...
Erich Schulz (May 24 2016 at 02:42):
the same with time periods - sometime an accurate to the microsecond time stamp is there, sometimes (often) its vaguer
Grahame Grieve (May 24 2016 at 02:45):
well, I think have time periods fine
Grahame Grieve (May 24 2016 at 02:46):
but I'm far from convined that clinicians would be willing to be more precise. I'm not one, I just get to to listen to them often
Erich Schulz (May 24 2016 at 02:47):
ie just using the "example" type coded values as alternative to quantative values anywhere there is a clinical statement that is negatable would be a tremendous step forward for expressivity
David Hay (May 24 2016 at 02:47):
and - after all - they are often recording what the patient has told them, and they may not have that degree of precision either...
Grahame Grieve (May 24 2016 at 02:48):
I'm not sure what you have in mind there Erich
Erich Schulz (May 24 2016 at 02:48):
the cost is complexity of reasoning - but any reasoning based on an incomplete dataset (because so much lost to narrative fields) wont be worth much
Erich Schulz (May 24 2016 at 02:48):
so in the context of this conversation...
Erich Schulz (May 24 2016 at 02:49):
allergy is nearly always not know with certainty
Erich Schulz (May 24 2016 at 02:49):
(very few folk get skin testing - and even that isn't 100% specific)
Erich Schulz (May 24 2016 at 02:50):
so every statement of allergy has an implied probability
Erich Schulz (May 24 2016 at 02:50):
simililarly "not allergic" is never actually 100%
Grahame Grieve (May 24 2016 at 02:50):
but what is that probability? Asking clinicians to be specific about that is problematic. I've listened to the discusison about that
Erich Schulz (May 24 2016 at 02:50):
sure
Erich Schulz (May 24 2016 at 02:50):
that is what I'm saying
Grahame Grieve (May 24 2016 at 02:51):
btw, my daughter is anaphylactic to cashew nuts. There is 100% certainty about that
Erich Schulz (May 24 2016 at 02:51):
have to allow clinicians to express what they know
Grahame Grieve (May 24 2016 at 02:51):
and that connects me with a community of people who are both utterly sure, and have had extensive skin testing...
Erich Schulz (May 24 2016 at 02:51):
cool
Erich Schulz (May 24 2016 at 02:51):
so when that is know that is worth saying
Erich Schulz (May 24 2016 at 02:52):
p=1
Erich Schulz (May 24 2016 at 02:52):
but mostly what allergy means "is patient says they are allergic to X so I am just going to pop that in this list"
Grahame Grieve (May 24 2016 at 02:52):
status confirmed, severity = high
Erich Schulz (May 24 2016 at 02:53):
you could could express that as probably
Grahame Grieve (May 24 2016 at 02:53):
as opposed to status = unconfirmed, which would be normal
Erich Schulz (May 24 2016 at 02:54):
but say you have an allergy to penicillin...
Grahame Grieve (May 24 2016 at 02:54):
I could. But then the problem is dose response. There's 100% certainty that my daughter is analphylactic to cashew nuts. but there's a rather low % chance that she'll actually have anaphylaxis, because it's strongly dose dependent
Erich Schulz (May 24 2016 at 02:54):
there is a degree of cross reactivity between penicillin and cefalosporins...
Erich Schulz (May 24 2016 at 02:54):
(from memory around 4%)
Rob Hausam (May 24 2016 at 02:55):
just jumping into today's discussion - still need to catch up
Erich Schulz (May 24 2016 at 02:56):
this is what exists currently...
Erich Schulz (May 24 2016 at 02:56):
http://www.clipular.com/c/5493992529068032.png?k=Gg2difzMUxt2FLTYQhqjQuOBdP4
Erich Schulz (May 24 2016 at 02:56):
i have no idea what the heck inactive means
Erich Schulz (May 24 2016 at 02:57):
looking at that value set it has the same systemic problem I see in condition
Erich Schulz (May 24 2016 at 02:57):
you can say p=1 and p=0 and very little inbetween
Grahame Grieve (May 24 2016 at 02:58):
unconfirmed is in between.
Erich Schulz (May 24 2016 at 02:59):
sometimes we can put a number on things
Grahame Grieve (May 24 2016 at 02:59):
much of the real work for this was done in association with openEHR. In that process, we considered a large number of models, that included various statements of probability.
Erich Schulz (May 24 2016 at 02:59):
and even subjective assessments have real world consequences
Grahame Grieve (May 24 2016 at 03:00):
we were unable to find any consensus about their meanings, and there was a significant percentage of stakeholders with real clinical experience passionately opposed to adding them.
Erich Schulz (May 24 2016 at 03:01):
what the heck is active and inactive btw?
Grahame Grieve (May 24 2016 at 03:01):
so we said to make them extensions. People can make extensions, gain experience using them, and we'll see how it plays out. note that no interest in this comes from the argonaut participants, who represent a large % of records for US EHRs. An openEHR is well connected in Europe and South America. And I know what the state of play here is in Australia - so we felt well informed
Grahame Grieve (May 24 2016 at 03:01):
inactive nearly didn't make the cut
Grahame Grieve (May 24 2016 at 03:02):
and in fact I'm not sure
Grahame Grieve (May 24 2016 at 03:02):
the definition isn't very useful
Erich Schulz (May 24 2016 at 03:02):
same with active - does that mean your covered in hives??
Rob Hausam (May 24 2016 at 03:03):
@Grahame Grieve, you said that "I'm extremely doubtful that Rob's proposed refactoring of the resource is viable in the real world" - I don't necessarily disagree
but we need to figure out what is really better
do you/we think that the openEHR approach seems better?
I'm happy to try to model this like that using two separate resources
I'm also willing to go back to a single resource and single coded element (mostly likely renamed to 'code' instead of 'substance')
Grahame Grieve (May 24 2016 at 03:04):
interesting. we've diverged from the openEHR model. I think both have changed, but their's would probably make you happier:
Grahame Grieve (May 24 2016 at 03:04):
Coded Text
Suspected [A low level of clinical certainty about the propensity of a reaction to the identified 'Substance'.]
Likely [A reasonable level of certainty about the propensity for a reaction to the identified 'Substance'.]
Confirmed [A high level of certainty about the propensity for a reaction to the identified 'Substance', which may include clinical evidence by testing or re-challenge.]
Resolved [The previously known reaction to the identified 'Substance' has been clinically reassessed and considered no longer to be an active risk.]
Refuted [The propensity for a reaction to the identified 'Substance' has been clinically reassessed or has been disproved with a high level of clinical certainty by re-exposure or deliberate challenge.]
Rob Hausam (May 24 2016 at 03:04):
or model all of them and get further opinions, from TermInfo, Patient Care and others
which I actually was thinking of doing tonight (after I write FHIR terminology questions!)
Grahame Grieve (May 24 2016 at 03:05):
Rob, I'm not sure how you think that our approach is different to the openEHR approach.
Grahame Grieve (May 24 2016 at 03:05):
other than the status codes, where I think we should have the same status codes + entered in error
Rob Hausam (May 24 2016 at 03:06):
primarily because there are two separate archetypes - one for "positive" allergies/intolerances, and the other for "excluded" statements
Grahame Grieve (May 24 2016 at 03:07):
ah ok. but that won't fly in fhir either - the problem is that you have to look somewhere else - somewhere unexpected - to find the exclusions. That was strongly identifed as a safety risk by the EHR providers, and I found that pretty persausive
Grahame Grieve (May 24 2016 at 03:08):
I'm not sure that it flys in openEHR either - I suspect that separation is not being used in practice; in Australia, we tried that model for the national program, and had to back away from it
Rob Hausam (May 24 2016 at 03:08):
exactly! - hence why I (and others) have been looking for an alternative
Grahame Grieve (May 24 2016 at 03:08):
and that was just in CDA
Erich Schulz (May 24 2016 at 03:09):
mmm - thank @Grahame Grieve - i think the extension approach is workable - i'm think as decision support systems come online that quantifiable risks will be more common - as both inputs and outputs
Grahame Grieve (May 24 2016 at 03:10):
then if that starts to grow consensus, we can improve the models. but we won't add speculative stuff that people 'should' do, because we've seen how that turns out
Rob Hausam (May 24 2016 at 03:10):
do we feel that a single 'code' element, with a value set binding that is broad enough to encompass substances, drug products and negated/excluded terms is adequate and "safe" enough?
that's where I started, and actually I would be rather happy to go back to it if we can get a reasonable degree of consensus
Grahame Grieve (May 24 2016 at 03:11):
GF#10067 for the status codes.
Rob Hausam (May 24 2016 at 03:12):
and I did propose the second "negated/excluded" element as an standard extension - with some expectation on my part that it wouldn't actually get picked up in practice - but it would be available if people really do want to use it and find it preferable
Grahame Grieve (May 24 2016 at 03:12):
well, the problem with that was negation in the terminology vs negation in the model, right? and the interplay between status, substance, and the definition of substance
Grahame Grieve (May 24 2016 at 03:13):
and the fact that terminology scope varies widely and peple are also comonly using text
Erich Schulz (May 24 2016 at 03:13):
+1 for 10067 :-)
Rob Hausam (May 24 2016 at 03:15):
yes - that's the issue with the "one element" approach - which we have now
but I'm not sure how big a problem the negation in terminology issue is - especially with SNOMED CT now having some additional resolve to actually solve their handling of negation issue
I have no problem with adjusting the status codes - just hadn't really gotten to that yet
Rob Hausam (May 24 2016 at 03:16):
also +1 for 10067
Grahame Grieve (May 24 2016 at 03:17):
well, I've been thinking about code vs agent and I don't see how this can do anything but muddy the waters
Grahame Grieve (May 24 2016 at 03:18):
the idea of introducing excludedCode is fine, but we haev to say eplicitly that if you have just text, the text might be an exclusion, though not processible
Grahame Grieve (May 24 2016 at 03:19):
so either there's an assertion: code.text.exists() implies exludedCode.empty() and excluded.text.empty()
Grahame Grieve (May 24 2016 at 03:20):
or else, there's an explicit statement in the resource concerning the record keeping status:
- I don't use terminologies, so I don't know what the text is
- I track exclusions separately , and text isn't exclusion
- I track everything precisely, and use codes properly
Grahame Grieve (May 24 2016 at 03:20):
I prefer the first approach, if we can get away with it.
Grahame Grieve (May 24 2016 at 03:21):
this allows everyone to populate the records, to interpret them safetly, and to use decision support safely where the source information handles exclusions well enough
Grahame Grieve (May 24 2016 at 03:21):
but I don't like the split between code and agent. when are they not the same thing?
Rob Hausam (May 24 2016 at 03:22):
possibly so - the reason I tried it was that the semantics of it, compared to the condition ("allergy to x") and negated/excluded situation ("no known allergy ..." or "no allergy to x") SNOMED codes are significantly different - but if we can exclude the use of the condition codes, or if systems can handle them showing up in the same field, and if they can handle the negated/excluded codes also in that same field, then I'm happy to go back to it
with adequate decision support logic that certainly can be done, and, if done adequately (which I expect is likely), that should be perfectly safe
Rob Hausam (May 24 2016 at 03:23):
"the idea of introducing excludedCode is fine, but we haev to say eplicitly that if you have just text, the text might be an exclusion, though not processible" - I agree with that
Grahame Grieve (May 24 2016 at 03:24):
I think it's not less safe than the source data. but it might not be perfectly safe.
Rob Hausam (May 24 2016 at 03:24):
"so either there's an assertion: code.text.exists() implies exludedCode.empty() and excluded.text.empty()" - we certainly might be able to do that (or something close to it)
Grahame Grieve (May 24 2016 at 03:24):
and way safer than forcing people to figure out whether it's a code or an agent and getting it wrong
Rob Hausam (May 24 2016 at 03:25):
"perfectly safe" is undoubtedly a stretch :)
Grahame Grieve (May 24 2016 at 03:25):
so if you remove the agent part, and add the constraint above, and document the assumption it's based on in the scope, then I'm happy
Rob Hausam (May 24 2016 at 03:27):
ok - I'm willing to give that a go
as I said, it's basically where I was before (without the extra constraint that you - reasonably - suggested)
Rob Hausam (May 24 2016 at 03:29):
so, if we do that, do you think excludedCode should be an extension? - because 80% of systems certainly do not do that now (and likely may not want to, even if it is offered)
or should we go ahead and "waive" the 80% rule in this case and make it core?
Grahame Grieve (May 24 2016 at 03:33):
this is how I think about this:
- handling 'not allergic to a class' is a core requirement
- splitting into a separate field for information processing reasons doesn't make it non-core
- the problem is how to deal with varying granularities
Grahame Grieve (May 24 2016 at 03:34):
so I don't think of this as an exception to the core rule
Rob Hausam (May 24 2016 at 03:38):
let me push back just a bit, if you don't mind
we actually have a rather low use (as we've seen in the collected data) for even positive statements of an allergy to a class - along with some expert opinion which states that doing that is almost always either erroneous or useless, even though there are a very few cases where it actually does make some sense
unless I'm really overlooking something, I believe there is even less evidence that there is a real need to be able to state "not allergic to a class" (even though it sounds like it should be the "right” thing to do)
so are you sure that it really is a core requirement?
Grahame Grieve (May 24 2016 at 03:39):
well, what I see is core:
- NKA, NKDA, Not allergic to Latex
Grahame Grieve (May 24 2016 at 03:40):
+ no adverse reactions to anaesthetics
+ no adverse reaction to contrast media
Rob Hausam (May 24 2016 at 03:41):
ok - if by class you mean only the unique cases of "substance" (the surrogate for NKA), "drug","food", "environment", then I agree
latex, of course, isn't a class
those cases are all easily handled in the terminology
Rob Hausam (May 24 2016 at 03:41):
didn't see the last two
Grahame Grieve (May 24 2016 at 03:41):
annd sometimes , penicillin or sulphonamies etc
Grahame Grieve (May 24 2016 at 03:42):
well, those are the functional things I see as core. I don't feel strongly that exclusion of a class generically is core
Rob Hausam (May 24 2016 at 03:43):
the last ones - especially the last two - are very soft
and none of those probably ever need to show up on the allergy list
Rob Hausam (May 24 2016 at 03:43):
they may need to be documented in some cases, but could be notes (or even observations, possibly)
Rob Hausam (May 24 2016 at 03:44):
my last statements are only referring to the "not allergic to ..." case - just to be clear
Grahame Grieve (May 24 2016 at 03:44):
well, that's easy to say, but at least some times orgnizational policy is that they should be up on the allergy list. I don't know how common that is
Rob Hausam (May 24 2016 at 03:48):
why don't we look through the negation requirments data that we've compiled (from the VA, Cerner, etc.) and see if they show up, and how often?
I'm happy to follow what the data suggests (even though obviously not "complete" and totally representative, it's a pretty extensive and useful compilation)
Grahame Grieve (May 24 2016 at 03:48):
that's a good idea. I'll see if I can acquire any extra data
Rob Hausam (May 24 2016 at 03:48):
that's great
Rob Hausam (May 24 2016 at 03:53):
I'll refactor my proposal according to what we've arrived at above
(I'll keep my other one around locally, at least for now)
Grahame Grieve (May 24 2016 at 03:53):
k great and we'll see how it goes
Rob Hausam (May 24 2016 at 03:53):
sure
Grahame Grieve (May 24 2016 at 04:02):
for those who haven't seen it, earlier US analysis on this:
Grahame Grieve (May 24 2016 at 04:02):
Disclaimer: I did a review of nearly 23 million negated allergy records, which originated from 60 distinct sources (US-based) across approximately 10 different EHRs. I had to use some systematic means to identify these negated allergy records, which risks a certain bias in my findings.
-
nearly 13M negated records (56%) had standard codes (almost exclusively SNOMED, likely driven from MU requirements, except rare cases where I see a presumably fake -1 RxNorm code for NKDA), such that this small finite list would be easily identifiable from other allergen codes. Examples include:
160244002 No known allergies
249683010 No known allergies
2579110013 NKA - No known allergies
409137002 No known drug allergies
2470950010 No known drug allergies
2579608012 NKDA - No known drug allergies
2791858012 No known history of drug allergy
2791859016 No known medicine allergy
2696018013 No known food allergy
428607008 No Known Environmental Allergies -
nearly 10M negated records (44%) I would categorize as “consistent freetext” or “proprietary codes” within a single source system, such that it seems reasonable for the vendor to identify these negation records provided all sources for the vendor are consistent. Stated another way, there is variance *across* different sources, but there is consistency *within* a given source system. Examples include:
Source 1 using Vendor A’s EHR:
NKA
NKDA
NKEA
NKFA
Source 2 using Vendor B’s EHR:
No Known Drug Allergy
Source 3 using Vendor C’s EHR:
N.K.D.A.
NKDA
NONE -
less than 1M records (<1%) I would classify as “inconsistent freetext” such that it would be difficult to identify due to all the permutations of misspellings, punctuation, spacing, abbreviations, verbose statements etc. Examples include:
Abbreviations:
no known
no known meds
Punctuation examples:
*No Known Allergies
no known allergies.
no known allergies!!!!!!
'No known allergies'
Misspelled words:
NO KNOWN ALELRGIES
NO KNOWN DRUG ALLEGIES
No Known Allegies
no known alllergy
no known alllergies
no known allergery
NO KNOWN ALLERGIEW
no known allergy's
Spacing:
NO KNOWN ALLERGIES
Verbose:
Denies, No known allergies
Denies, No Known Allergies.
mom sts no known medication allergies
mother sts no known medication allergies
pt sts no known medication allergies
NO KNOWN ALLERGIES TO DRUGS OR ANTIBIOTICS
NO known drug allergies, environmental allergies
Denies, Mom allergy pcn, No known allergies
no known allergies (food or drug)
Rob Hausam (May 24 2016 at 04:09):
yes - very helpful analysis from Michelle Miller
Michelle (Moseman) Miller (May 24 2016 at 23:33):
Just to confirm my understanding of the proposed changes:
- rename substance to code
- code is now optional
- code value set still includes exemplar negation codes, such as NKA and NKDA
- using the excludedCode extension is an optional/alternative way of making a negative assertion
- invariant to have only one of code or excludedCode
The ability to convey "No Latex Allergy" could be done 3 different ways (assuming #2 isn't treated as a double negative)
1) AllergyIntolerance.code = No Latex Allergy (e.g. SNOMED 409175002)
2) AllergyIntolerance.excludedCode (extension) = No Latex Allergy (e.g. SNOMED 409175002)
3) AllergyIntolerance.excludedCode (extension) = Latex (e.g. SNOMED 111088007)
Erich Schulz (May 24 2016 at 23:35):
eww?
Erich Schulz (May 24 2016 at 23:38):
how strong is the desire to support all the SNOMED composite "no known allergy to blah codes"
Erich Schulz (May 24 2016 at 23:41):
mixing them in with a structure that supports combination of "status" and "substance" seems a bit, erm, untidy
Erich Schulz (May 24 2016 at 23:43):
whereas using high-level substance codes together with some kind of negated "status" codes would allow the coding system hierarchy to cope with all possibilities by editing it's substance hierarchy and doing logic based on that
Rob Hausam (May 25 2016 at 00:33):
@Michelle (Moseman) Miller - yes, what you said is correct
Rob Hausam (May 25 2016 at 00:34):
@Erich Schulz - your concern is what earlier led me to consider separating out the casusative agents (substances/products) in separate elements
but I'll look further at the last part of your comment
Josh Mandel (May 25 2016 at 20:00):
Regarding:
1) AllergyIntolerance.code = No Latex Allergy (e.g. SNOMED 409175002)
2) AllergyIntolerance.excludedCode (extension) = No Latex Allergy (e.g. SNOMED 409175002)
3) AllergyIntolerance.excludedCode (extension) = Latex (e.g. SNOMED 111088007)
I'm not sure what good it's doing to have #1 and #3. Meanwhile, #2 is scary — if I'm excluding the concept of "no latex allergy"... ick. All this structure is just making the picture more confusing unless you can impose rules on how it's used.
Grahame Grieve (May 25 2016 at 21:35):
I think we're going to impose rules like that yes
Rob Hausam (May 25 2016 at 22:50):
@Josh Mandel and @Grahame Grieve - we need to decide which particular rules we really want to impose
and it's not really quite as simple as it seems on the surface (in my opinion and experience - and not mine only)
#1 and #3 don't seem to make sense for "latex" - but that's just one case
part of the question is, for what range of 'xx' do you need to be able to say "no xx allergy", and in what contexts?
for the allergy list - probably almost nothing beyond the 7 pre-coordinated "no known allergy" or "no x allergy" SNOMED CT codes - so #1 is an obvious solution
for clinical documentation in notes, on the other hand, you may like to have a whole lot more (e.g., "no allergy to cephalexin") - so #3 would be the obvious solution there, unless you just want to rely on text for that use case (as normally it wouldn't be involved in decision support - it's primarily or exclusively for legal documentation)
#2 is ugly, but will certainly happen, unless we tighten the bindings significantly - it can be dealt with (more or less) by stating that the interpretation of redundant negation is additive or reinforcing - not resulting in a positive statement
the obvious way to simplify it is to stay with a single element solution (renamed from 'substance' to 'code', as agreed by PC, at least) and allow likely any of the above codes to be used - in that approach, the way to do "no allergy to xx", beyond the 7 existing SNOMED CT codes (I'm talking only SNOMED here at the moment) would be either to request a new pre-coordinated code for whatever you want to say (cumbersome and relatively slow, in most cases, unless you manage your own extension), or use a post-coordinated expression (which most seem definitely to not want to do), or use text
I'm happy to stay with the single element approach - if we can get enough agreement on that
or listen to any coherent and practical approaches if there is something that we haven't adequately considered yet!
Erich Schulz (May 25 2016 at 23:05):
have read comments by @Rob Hausam and @Josh Mandel - I really think these legacy composite codes are making this very simple set of observations into a minefield. This is just a series of simple statements: [patient X]-[has Y relationship]-[with substance (class) Z].
Erich Schulz (May 25 2016 at 23:05):
everything can be expressed in that format
Erich Schulz (May 25 2016 at 23:06):
and best of all this structure allows delegation of substance classification trees to the 3rd party publishers (like SNOMED etc)
Grahame Grieve (May 25 2016 at 23:07):
sure. let's just abandon legacy data and systems. no one will mind
Erich Schulz (May 25 2016 at 23:07):
heh
Erich Schulz (May 25 2016 at 23:08):
i dont think this is at all abandoning anyone
Erich Schulz (May 25 2016 at 23:08):
all the composite codes map neatly into the Y-Z format above
Erich Schulz (May 25 2016 at 23:09):
where Y = "not known to be allergic too" and Z is whatever
Grahame Grieve (May 25 2016 at 23:10):
not if they're not codes. And not if you can't decompose the codes. Which is the case for almost all implementations. Even if they use decomposible codes from SCT
Grahame Grieve (May 25 2016 at 23:12):
but Erich offers an interesting possibility: just have code, which is loose, and can be just text. And then allow Erich's formal statement for anyone who can either populate it correctly in the first place, and/or retrospectively populate it from an expert system. Then the difference between legacy looseness and proper semantics is pretty clear
Rob Hausam (May 25 2016 at 23:14):
we were discussing today that the US ISA (Interoperability Standards Advisory) specifies the use of SNOMED CT "allergy to xx" codes
not everyone has to do what the US does - but it's an example of how it's not going to be especially simple to move away from these "legacy composite codes" (I believe they're used fairly extensively in the UK, too, if I recall correctly)
and, actually, these codes are generally reasonably well modeled within SNOMED CT - so I'm not sure whether it makes the most sense to move away from them, or make reasonable provision for being able to utilize them
Grahame Grieve (May 25 2016 at 23:14):
that's not really the terminfo negation agenda playing out, but it sounds like a promising approach to me
Grahame Grieve (May 25 2016 at 23:16):
isn't my take on Erich's proposal doing that - use the SCT codes in the code, and decompose them into SCT relationships in Erich's triples?
Erich Schulz (May 25 2016 at 23:17):
the key point being @Rob Hausam that there is a one to one mapping from these codes to the Y-Zformat
Erich Schulz (May 25 2016 at 23:18):
I presume by "modeled in SNOMED" that this means that for each code that somehow Y & Z are already contained in the snomed somehow
Rob Hausam (May 25 2016 at 23:20):
@Grahame Grieve well, it certainly might be - I wasn't completely sure that I followed it
@Erich Schulz yes, that's exactly what I meant by "modeled in SNOMED" - the Y & Z are already there
Erich Schulz (May 25 2016 at 23:20):
(this probably puts me a bit out on a limb - but I would also assert that the ability to perform
hierarchical logic is a core requirement of any decent application handling any clinical information for CDS or even list reconciliation)
Rob Hausam (May 25 2016 at 23:23):
with the additional caveats that the substance codes are only the Z, whereas the product codes are the Z along with part, but not all of the Y
Erich Schulz (May 25 2016 at 23:23):
@Rob Hausam I guess the path of least resistance (sensing the writing on the wall) is that if these negated codes are to be allowed then the set should be limited to those that have a standard modelling to a "Y-Z" pair
Erich Schulz (May 25 2016 at 23:24):
I'm looking at the way polymorphic observation values are handled
Erich Schulz (May 25 2016 at 23:25):
which are a more complex case of X-Y-Z
Erich Schulz (May 25 2016 at 23:25):
actually sorry scratch that
Erich Schulz (May 25 2016 at 23:25):
this is different
Erich Schulz (May 25 2016 at 23:26):
so this comes down to allowing either explicit assertion of Y-Z or use of a code that by itself expresses Y-Z...
Rob Hausam (May 25 2016 at 23:26):
@Erich Schulz that limit should be fine - all of the SNOMED CT codes (including primitive ones) should meet the "have a standard modelling to a "Y-Z" pair" criterion
Erich Schulz (May 25 2016 at 23:27):
where "Y" should be a very small list??
Rob Hausam (May 25 2016 at 23:29):
yes - I think so
it's "Causative agent" for the allergic conditions
and it's that plus a "Known absent" context wrapper for the negated ones
that probably covers everything (unless I've missed some or all of your point)
Erich Schulz (May 25 2016 at 23:30):
and it should be possible to always maps to an equivilant FHIR status & substance represention ??
Erich Schulz (May 25 2016 at 23:30):
hows that @Grahame Grieve - no legacy left behind ;-)
Rob Hausam (May 25 2016 at 23:33):
well, maybe not quite
do we still need an 'excludedCode' element that carries that semantic - or are you proposing to do the 'excluded' notion in status? - if the latter, that might be overloading status a bit too much?
Erich Schulz (May 25 2016 at 23:34):
@Rob Hausam i would have thougth status was the place
Erich Schulz (May 25 2016 at 23:36):
it being a fuzzy representation of probability?
Rob Hausam (May 25 2016 at 23:36):
we can discuss that, for sure - status doesn't do that now, though
Erich Schulz (May 25 2016 at 23:36):
noted
Rob Hausam (May 25 2016 at 23:36):
with the current list of codes
Erich Schulz (May 25 2016 at 23:41):
also worth noting that personally I would see it as a step forward for humanity to "deprecate" the use of negated codes... but doen't sound like that will fly
Rob Hausam (May 25 2016 at 23:45):
I probably wouldn't disagree - as long as we have a well understood and equally good (and hopefully better) way to do it in the information model
we didn't have that in V3 - even though it seemed to be "elegant"
I agree it will ultimately be better if we can do it in one place
Erich Schulz (May 25 2016 at 23:48):
if looking at adding values to status - its worth seperating "not known to be allergic to" and "has been previously exposed to without reaction"
Erich Schulz (May 25 2016 at 23:49):
i'm not sure it is every really practical to say "not allergic to" - as this can change from one does to another
Erich Schulz (May 25 2016 at 23:50):
tramadol is an interesting drug -because about 1/3 of people get a single dose then say they dont want any more...
Rob Hausam (May 25 2016 at 23:51):
I agree - that's why we always say (and the codes reflect) "no known allergy to .."
Erich Schulz (May 25 2016 at 23:51):
the other 2/3s find it fine
Erich Schulz (May 25 2016 at 23:51):
so if you know they have previous exposure without issues it makes it more likely to use it up front (because it has a few benefits)
Erich Schulz (May 25 2016 at 23:52):
history of cephalosporin exposure with a known penicillin allergy is another example where the distinction can be important
Rob Hausam (May 25 2016 at 23:53):
yes - true of some other drugs, as well - but I haven't actually seen that high a prevalence of intolerance to tramadol in patients I've prescribed it to
Erich Schulz (May 25 2016 at 23:53):
you must give it more gently ;-)
Rob Hausam (May 25 2016 at 23:56):
yes, it CAN be important - but practically it often isn't - however it's hard, and may be risky, to determine which is which
cross-allergy is becoming less and less recognized as a real issue - as I've seen and as I hear from the allergists
Rob Hausam (May 25 2016 at 23:58):
have to go for a bit - we should probably try to summarize where we think we've landed with this - at least in regard to what we want to do in the resource model itself (no matter what we may do in regard to transformations on the back end)?
Erich Schulz (May 25 2016 at 23:59):
i guess the point is that "previous exposure without reaction" is sufficiently different to "not known to be allergic to" to alter clinical practice
Rob Hausam (May 26 2016 at 00:00):
yes it is - gives a significantly higher degree of confidence in otherwise potentially questionable cases
Erich Schulz (May 26 2016 at 00:01):
i'm wondering if chucking in "no previous exposure to" is a bridge too far?
Erich Schulz (May 26 2016 at 00:02):
so both "previous exposure without reaction" and "no previous exposure to" would be refinements of the more commonly recorded "not known to be allergic to" ...
Erich Schulz (May 26 2016 at 00:03):
used to be important with streptokinase (showing my age)
Erich Schulz (May 26 2016 at 00:04):
(because you only gave it once because the incidence of becoming allergic was so high)
Rob Hausam (May 26 2016 at 00:05):
I'm from the streptokinase era, too :)
agree
Erich Schulz (May 26 2016 at 00:14):
summary: https://docs.google.com/document/d/1hytCtPIDp1NgvsRN90Nt-YXYNNCGIedvNyKxbxI9VG8/edit?usp=sharing
Grahame Grieve (May 26 2016 at 01:17):
not entirely sure that the pairs need to be 0..* - it feels like it sits on the edge of core
Grahame Grieve (May 26 2016 at 01:17):
make it a code not coding then (with mappings to SCT)
Grahame Grieve (May 26 2016 at 01:17):
well, Rob, are you interested in trying it? Go back to the existing allergyIntolerance model, change substance to code, make the definition horribly loose, and then add a new element with cardinality 0..*, and the 2 sub elements - relationship and substance, with example value sts from SCT.
Grahame Grieve (May 26 2016 at 01:17):
then we could write up a set of methods for populating the logic structures given common legacy inputs
Grahame Grieve (May 26 2016 at 01:17):
probably not, given how messy records are
Grahame Grieve (May 26 2016 at 01:17):
but hopefully often possible
Grahame Grieve (May 26 2016 at 01:17):
e.g. a refuted excluded means that we're no longer claiming that there isn't an exclusion.
Grahame Grieve (May 26 2016 at 01:17):
I don't think we need an excluded code. it would just go in the code. and then if you wanted semantics, you'd use the pair
Grahame Grieve (May 26 2016 at 01:17):
and not proposing to do excluded in the status. the status is the status of the assertion, not the status of the allergy
Erich Schulz (May 26 2016 at 01:24):
@Grahame Grieve if you are saying status is of the observation then shouldn't its allowed values be the same as status.observation?
Erich Schulz (May 26 2016 at 01:24):
ie registered | preliminary | final | amended +
Erich Schulz (May 26 2016 at 01:24):
?
Erich Schulz (May 26 2016 at 01:25):
~~or looking at condition.status... provisional | differential | confirmed | refuted | entered-in-error | unknown~~ (edit - actually that one is just as bad -see other thread)
Grahame Grieve (May 26 2016 at 01:26):
/
Grahame Grieve (May 26 2016 at 01:26):
oops. sorry?
Erich Schulz (May 26 2016 at 01:28):
wrt you comment "and not proposing to do excluded in the status. the status is the status of the assertion, not the status of the allergy"
Erich Schulz (May 26 2016 at 01:30):
i can see case for seperating notion of "certainty" from the notion of "status of this note"... maybe...
Erich Schulz (May 26 2016 at 01:33):
ie ("draft/preliminary/final/in-error") being a different dimension to ("certain"/"possible"/"unlikely"/"denied")
Erich Schulz (May 26 2016 at 01:38):
the ability to express (un)certainty is something required for all clinical statements as is the need to record the "status of the statement"
Erich Schulz (May 26 2016 at 01:38):
urg
Erich Schulz (May 26 2016 at 01:52):
and if the "status of the assertion" is to be seperated from the "the status of the allergy" it would make sense to differentiate codes that make a complete statement ie "Y-Z", from partial staments ie just "Y" (eg "not known to be allergic too")
Erich Schulz (May 26 2016 at 01:53):
and in this case the current AllergyIntolerance.statusvalue set would want further pruning?
Erich Schulz (May 26 2016 at 02:03):
the reason I'm going urg is I just realised the "entered-in-error" seems to often sit in a list of hetergenous qualifier statements...
Erich Schulz (May 26 2016 at 02:04):
hence the "status of attribute" vs "the status of the statement of the attribute" are often conflated
Erich Schulz (May 26 2016 at 02:15):
so would seem to me they either need to be seperated, or the conflation is accepted...
Grahame Grieve (May 26 2016 at 02:36):
again, we haven't been able to get agreement about uncertainty so it is an extension for now
Grahame Grieve (May 26 2016 at 02:36):
I don't know. I presume, Rob, you're going to build another straw man for us? let's what till we see that
Rob Hausam (May 26 2016 at 04:05):
just got back home
I'll go back and read through everything I missed while I was out - and see if I can make sense of it all :)
but yes, I'll do another straw man
Robert McClure (May 27 2016 at 15:17):
I've not made it all the way through the comments but some of the SNOMED modeling statements here are far enough from the actual truth to cause incorrect assumptions. Specifically the "No latex allergy" modeling in SCT does not exactly align with @Erich Schulz x-y-z model. All the "no allergy" concepts are "context" concepts which means the SCT model requires at least two "steps" away from the root concept to find the substance concept. My point here is that using the existing SCT model would not place a substance into the "Z" slot. For "No Latex Allergy" (409175002) the "Z" slot would have "Latext Allergy" - from which you can find the substance.
Robert McClure (May 27 2016 at 15:25):
Ok - I have another issue with all this. First, I understand that every concrete approach we come up with have vocal, powerful, knowledgable detractors - I don't think there is a solution that will make everyone happy. I suspect the big dividing line is when push comes to shove is the solution you are arguing for more for reasoning or more for human intrepretation. I sense that those weighted on the former don't like to mix semantic types into one slot, those on the latter are less concerned about mixing semantics in a slot and are more focused on seeing common things together. So I'd like to better understand if this analysis is correct - i.e.: do we need to choose among those two (in real practical systems)? If so - can we come to an agreement on which we will currently prefer?
Rob Hausam (May 27 2016 at 15:26):
Yes, it's definitely more complex than a simple x-y-z, as you say. I hadn't included that so far in this thread, but I did put a lot of that specifically into the earlier version of my proposal in the actual FHIR build (in my local build so far). I showed the actual SNOMED CT expressions for the concepts, and where the "Causative agent" (substance or product ) is represented (and with a product, the substance(s) are one level deeper). With the reworking of the proposal that is still in progress, I haven't yet migrated that to the current version, but I will - before further discussion in Patient Care next week.
Rob Hausam (May 27 2016 at 15:31):
You're probably on the right track generally in regard to the division, Rob. I don't know about answering your two questions. I think that's what we've been trying to do - in this thread, as well as in other discussions.
Erich Schulz (May 27 2016 at 22:27):
Mmm.. I am missing something. "no latex allergy" maybe modelled differently in snomed to the y-z catch all that I suggested. But I think that is a variation (joy of language)
Erich Schulz (May 27 2016 at 22:29):
Importantly "no latex allergy" can be expressed equally as Y-Z
Erich Schulz (May 27 2016 at 22:32):
(where Z is a substance and Y is a statement about a patient's allergy /intolerance to given substance)
Grahame Grieve (May 27 2016 at 22:58):
well, I think the fundamental tension is between people who really focus on what the information 'should be' vs those who are constrained by what already is in place. I'm looking fora solution that enables what should be but allows a graceful path forward.
Grahame Grieve (May 27 2016 at 22:59):
I didn't check that snomed ct model for these codes myself, but I agree with Erich: you should be able to do the transform. just difficult if SCT doesn't help (and sadly, typical for SCT - it's structure doesn't empower me to do what I want very often)
Erich Schulz (May 27 2016 at 23:02):
one of the many things on my radar is to ponder ways of developing 'sharable knowledge resources' - to seperate the role of ontology from knowledge representation (with SNOMEDs modeling being an simple case of knowledge representation)... but is another story...
Erich Schulz (May 27 2016 at 23:03):
@Grahame Grieve i would be surprised if a combination of (status+substance) OR compound-codedidnt meet all needs
Erich Schulz (May 27 2016 at 23:04):
and at least allow debate to move down a level into what the allowable values in the 3 fields are
Michael Osborne (May 28 2016 at 00:42):
Probably tangential to this, but the modeling of the SCT concept "Latex allergy" doesn't look correct. Both substances latex and rubber are siblings with a direct parent biopolymer, but latex allergy is modeled as a Rubber allergy, hence ends up having two role groups with causative agents rubber and latex. Strange.
Grahame Grieve (May 28 2016 at 00:43):
plenty of strange like that
Erich Schulz (May 28 2016 at 01:07):
hello @Michael Osborne ! <off-topic>yes all the more reason for seperating knowledge representation task from ontology publishing and having diverse ecosystem of knowledge maintainers </off-topic>
Erich Schulz (May 28 2016 at 01:15):
but I think SCT is probably right here - "latex allergy" is strictly a "rubber allergy" - although strictly not all "latexes" are biopolymers... so thanks to ambiguity of common-use language we'll never a 100% clean statements :-/ - but this is a tar-pit that FHIR cant fix
Michael Osborne (May 28 2016 at 01:36):
Sorry - Just catching up on these posts....That's a scary number of EHR's using SNOMED CT descriptions instead of concepts...That is really disturbing.
Erich Schulz (May 28 2016 at 02:03):
@Michael Osborne - it's a journey isn't it? main game is to give everyone a nice destination to get to (and maybe some way-points along the way) - free text is definitely better than a scanned pdf even if it isn't as a good as structured, tightly defined JSON...
Michael Osborne (May 28 2016 at 02:05):
@Erich Schulz Those people are really on the wrong train.
Rob Hausam (May 28 2016 at 02:23):
@Grahame Grieve - agree with "looking for a solution that enables what should be but allows a graceful path forward" - that's what I'm trying to get to (along with enough agreement to actually do it)
Rob Hausam (May 28 2016 at 02:27):
@Michael Osborne I also noticed the strangeness in the "Latex allergy" modeling - hadn't pursued the issue yet, but we probably should raise it
Erich Schulz (May 28 2016 at 05:19):
@Rob Hausam I think the root cause of "the latex problem" is simply imprecise common use language (hence its a tar-pit) - "latex allergy" really means rubber allergy if you use the precise meaning for latex (I dont think it would be possible to have an allergy to all synthetic latexes")
Rob Hausam (Jun 01 2016 at 14:14):
We discussed this further on the TermInfo call just now. There is definitely more work to do on status, and how it interacts with the decisions that we make regarding the elements. I'm getting back to making the further updates to my build for discussion - possibly some today on the PC Allergy/Intolerance call, and tomorrow on the PC FHIR call.
Daniel Karlsson (Jun 02 2016 at 06:56):
Hi All, we had discussions in TermInfo over the past weeks-months. Applying the "TermInfo methodology" we identified thw following potential overlaps between the AllergyIntolerance attributes and any reasonably complex terminology (with a slight focus on SNOMED CT):
Daniel Karlsson (Jun 02 2016 at 07:00):
- category (i.e. food | medication | environment | other ) has a potential overlap with substance and/or code. Of course, some terminologies like SNOMED CT reject "other"
- status - the status value set overlaps with the proposed substance/code value set, e.g. status = refuted (debatably) overlaps with substance = No know [Food|Drug|...] allergies (this we already discussed)
- type - a substance/code/whatever attribute value of No known allergies would imply that type = allergy.
Grahame Grieve (Jun 02 2016 at 07:03):
in the design, we've always know that category is redundent if the substance/code comes from a good terminology. But evn when it does, some systems still categorise it. hence the implementation note on it: "This data can be derived from the Substance where coding systems are used, and is effectively redundant in that situation"
Daniel Karlsson (Jun 02 2016 at 07:05):
(I keep pressing ENTER when I know I shouldn't)
- with the work Bruce Goldberg did on allergies/allergic reactions in SNOMED CT, there is know a (reasonably) clear distinction between SNOMED CT concepts, but there is no room for a "reaction code"
Grahame Grieve (Jun 02 2016 at 07:05):
with regard to status: I think it does not make sense to say that a 'no known allergies to something is refuted - so we should document that explicitly in the definitions of both elements, and in the narrative (and one day we might figure out how to make that an enforceable invariant - but we can make it partially enforceable if we go with the scheme that Erich and I outlined the other day that Rob is going to draft)
Daniel Karlsson (Jun 02 2016 at 07:06):
@Grahame Grieve it goes the other way around: if it's refuted the allergy cannot be known
Grahame Grieve (Jun 02 2016 at 07:06):
it's true that with a good terminology, you might be able to infer type, but even then, I think the allergists would challenge whether the terminologies can be correct on that - the real world situation is more obtuse than the terminologies describe
Grahame Grieve (Jun 02 2016 at 07:07):
and I don't agree. It makes perfect sense to say that the notion that the patient is allergic to contrast media as been refuted. That's a clear clinical case: when the patient refuses to accept what is evident to the clinical team
Grahame Grieve (Jun 02 2016 at 07:07):
my mother in law is a clear case ;-)
Grahame Grieve (Jun 02 2016 at 07:07):
and I don't understand the meaning of the Goldberg note
Daniel Karlsson (Jun 02 2016 at 07:10):
Concerning the "Goldberg variations" it is increasingly so that SNOMED CT distinguished between having an allergy and having an allergic reaction. That used to be an issue.
Grahame Grieve (Jun 02 2016 at 07:10):
ah ok
Daniel Karlsson (Jun 02 2016 at 07:10):
Definition of refuted: "A propensity for a reaction to the identified Substance has been disproven with a high level of clinical certainty, which may include testing or rechallenge, and is refuted."
Daniel Karlsson (Jun 02 2016 at 07:11):
That's not you mother in law, is it?
Grahame Grieve (Jun 02 2016 at 07:11):
right. so you'd need to nominate a substance in that case
Grahame Grieve (Jun 02 2016 at 07:11):
yep that's my mother in law. she claims she's allergic to something, and her team just smile and give it to her anyway
Daniel Karlsson (Jun 02 2016 at 07:12):
Is that even legal?
Grahame Grieve (Jun 02 2016 at 07:13):
why would it not be?
Daniel Karlsson (Jun 02 2016 at 07:13):
All in all, in TermInfo we have discussed the possibility of doing some implementation guide/profile/both/whatever it takes/etc. which is more strict and would make any such distinctions between model and terminology (more) clear(er).
Daniel Karlsson (Jun 02 2016 at 07:14):
I guess I don't know your mother in law
Daniel Karlsson (Jun 02 2016 at 07:15):
and compulsory care (it that's the English term) is allowed only in select cases
Grahame Grieve (Jun 02 2016 at 07:15):
if she just fronted at a hospital, made the claim, then you'd have to accept it at face value, and giving her the agent would be malpractice unless you had no choice. But when you have the same team year in year out and you won't accept that you're wrong, but the clinical notes are clear...
Daniel Karlsson (Jun 02 2016 at 07:16):
ok, I get the picture
Grahame Grieve (Jun 02 2016 at 07:16):
anyway, that's where refuted comes to the party
Daniel Karlsson (Jun 02 2016 at 07:17):
Still, even in this case "refuted" implies (at a minimum) "not known"
Grahame Grieve (Jun 02 2016 at 07:18):
does it? the intent is that int conveys "known not"
Daniel Karlsson (Jun 02 2016 at 07:18):
Unless you consider the patient as the bearer of this piece of knowledge
Daniel Karlsson (Jun 02 2016 at 07:19):
Just logic: if it's "known not" it cannot be "known"
Grahame Grieve (Jun 02 2016 at 07:20):
ok fair enough
Daniel Karlsson (Jun 02 2016 at 07:20):
Anyhow, in order to avoid such discussion having a loose and a strict level might be a solution
Daniel Karlsson (Jun 02 2016 at 07:24):
E.g. having the loose level as @Rob Hausam's proposal and then add a TermInfo profile/IG/whatever (sorry, I'm struggling a bit with the terminology, I'm fairly new to FHIR) which constrains the existing (combination of) attributes
Erich Schulz (Jun 02 2016 at 08:08):
i dont think Grahame's mother-in-law is in the 80%...
Erich Schulz (Jun 02 2016 at 08:10):
very common for a doctor to give a medication that a nurse (or the intern) has described as an allergy
Erich Schulz (Jun 02 2016 at 08:10):
morphine is notorious for having patients (and doctors) misdiagnose allergy where none exists
Erich Schulz (Jun 02 2016 at 08:12):
I'm not sure that the way "refuted" statements is really optimal...
Erich Schulz (Jun 02 2016 at 08:13):
it seems to me that a "refutation" (?new word?) belongs as a type of annotation that maybe applied to any statement
Erich Schulz (Jun 02 2016 at 08:14):
have a statement (A) that B is allergic to C. D then says "A is untrue because of E"
Erich Schulz (Jun 02 2016 at 08:15):
it is then an interesting question about should "the system" then describe B as allergic to C?
Erich Schulz (Jun 02 2016 at 08:16):
when you have 2 parties making contradicting statements it is reasonable for a 3rd agent to make an adjudication.
Erich Schulz (Jun 02 2016 at 08:17):
but this transcends allergy lists and applies to both medication and problem lists (and possibly observations)
Erich Schulz (Jun 02 2016 at 08:36):
I glanced through the discussion paper on reconcilliation but I probably skimmed it to quickly to really digest its implications
Erich Schulz (Jun 02 2016 at 08:39):
but issue is that at the point of care what is needed is a "best guess" set of statements about allergies - ie the set of conclusions (in terms of a "in conclusion the risk B is allergic C is X% (or 1 in Y)"
Erich Schulz (Jun 02 2016 at 08:44):
the set of statements along the lines of "GP says she's allergic" "admitting nurse says she's allergic" "intern refutes she's allergic" at some point needs to be collapsed into a single line
Erich Schulz (Jun 02 2016 at 08:45):
and interesting the commonest way I refute an allergy (by giving the medication in question) isn't currently recordable in the reaction history...
Erich Schulz (Jun 02 2016 at 08:47):
because in the "nurse says, GP says, intern says" scenario it is a record of past administration that commonly provides the evidence of no allergy...
Erich Schulz (Jun 02 2016 at 08:47):
i guess it could go in the medication record but is it possible to say "i gave kefzol and nothing happened"?
Erich Schulz (Jun 02 2016 at 08:49):
I guess the point of my ramble is that reconcilling different statements is complicated and I'm not sure how the "refuted" code value adds value to the reconcilliation process
Erich Schulz (Jun 02 2016 at 08:50):
typically the "refutation" (because not everyone is as brave/silly as anaesthetists) is that the nature of the reaction is documented: ("penicillin -> nausea")
Erich Schulz (Jun 02 2016 at 08:51):
which mean "patient not allergic to penicillin but has experienced a common benign side-effect"...
Erich Schulz (Jun 02 2016 at 08:52):
... as opposed to "penicillin -> severe wheeze and welts"
Erich Schulz (Jun 02 2016 at 09:00):
And I take @Grahame Grieve's point that systems are not currently quantifying probability but if CDSS is going to add and parse clinical information then in the future quantifification of risk will be how that manifests... (or that is how it seems to me at least)
Erich Schulz (Jun 02 2016 at 10:00):
@Daniel Karlsson fyi a patient stating "I am allergic to X" is different to saying "I dont want to receive X" - patients generally trust their doctors and if they are told that despite a possible previous reaction to X that X is still a good choice for them then vast majority will accept that.
Erich Schulz (Jun 02 2016 at 10:01):
but its a conversation you'd want to have before giving X to someone
Erich Schulz (Jun 02 2016 at 10:02):
If they still say "i dont want you to give me X" and a doctor gives it anyway that is called "assault" (by Australian law at least)
Erich Schulz (Jun 02 2016 at 10:31):
sorry another ramble - hopefully something vaguely helpful in there
Rob Hausam (Jun 02 2016 at 12:38):
look what happens when you take a little time to sleep :)
good discussion - any particular conclusions we think we can draw from it at this point?
I'll be trying to work on my proposal further today, prior to the PC FHIR call at 5:00 PM Eastern
particular we need to decide what to conclude and what to adjust with the status codes and how they interact with code
and we had further discussion yesterday on the PC Allergy call about whether we should keep the cardinality of code (formerly substance) at 1..1 (rather than 0..1 as I have it now) and not add the excludedCode extension - essentially to avoid giving extra optionality and opportunity for confusion, if not absolutely needed
Erich Schulz (Jun 02 2016 at 12:39):
never sleep ;-)
Michel Rutten (Jun 02 2016 at 12:40):
never REST ;p
Erich Schulz (Jun 02 2016 at 12:40):
are you saying it is on the cards to drop support for the "not allergic to latex" preconstructed codes? (that would make sense to me but I thought it was a non-starter because of history)
Rob Hausam (Jun 02 2016 at 12:43):
no, I wasn't saying that
I must not have written what I did say clearly enough - too early in the morning? :)
after discussing that possibility with the IHTSDO Terminology Editor's group yesterday, I think there is support from that point of view, at least, to definitely keep those codes is - IHTSDO plans to continue to support and add them, for one thing
Erich Schulz (Jun 02 2016 at 12:46):
drat
Michelle (Moseman) Miller (Jun 02 2016 at 13:03):
@Rob Hausam You know I will +1 your suggestion :)
"keep the cardinality of code (formerly substance) at 1..1 (rather than 0..1 as I have it now) and not add the excludedCode extension"
By doing so, code will still allow positive assertions (when the code doesn't include any negation) as well as negative assertions (No Known Allergy - holistically, No Known Drug Allergy - by category, No Latex Allergy - by substance/code). Since it isn't common practice to document all possible No <substance> Allergy, I think the value set is small enough that we can manage the pre-coordination for the few substances (like Latex) that will get recorded as No <substance> Allergy.
Erich Schulz (Jun 02 2016 at 13:08):
very unconvinced that allowing 20 semirandom "no X allergy" codes and requiring any other assertion of absent allergy to be said in another way is a great step forward for humanity
Erich Schulz (Jun 02 2016 at 13:09):
every time I give something "no allergy to X, check" goes through my mind as it should every practitioner...
Rob Hausam (Jun 02 2016 at 13:13):
the IHTSDO thought was that the primary use for the "allergy to x" codes might be the problem list, rather than the allergy list (the item would need to be on the allergy list, too!) - that will probably open up another discussion front :)
Michelle (Moseman) Miller (Jun 02 2016 at 13:49):
@Erich Schulz When PC discussed the prior proposal (to add an excludedCode extension), we questioned whether it would be a modifier extension. As such, we discussed whether it was safe to NOT know that a patient was NOT allergic to X (i.e. whether it was safe for implementations to ignore the extension). What do you think? That influences my opinion about how problematic it might be to represent negation (that doesn't have a pre-coordinated code available) as freetext (AllergyIntolerance.code.text). Additionally, do you think these negated assertions (no allergy to X) need to be computable? How are they used in decision support systems? Most decision support rules (e.g. drug/allergy or food/allergy interaction checking) I am aware of tend to look for the positive assertions.
Rob Hausam (Jun 02 2016 at 14:02):
@Erich Schulz - I totally agree with "every time I give something 'no allergy to X, check' goes through my mind as it should every practitioner"
so, where and how do you document that? and does it need to be computable, and, if so, how?
I think it goes in an encounter note of some type, where I record that I did ask the patient
but it doesn't go on the allergy list, and isn't involved in clinical decision support around prescribing or other substances to avoid (e.g., food, latex, etc.)
if so, the bottom line of that might be that for the AllergyIntolerance resource itself what we need to be able to document regarding "no X allergy" can be done with the existing codes (and possibly a few additional ones that we may want to add in the future)?
Rob Hausam (Jun 02 2016 at 14:03):
or we can also always use text, if there isn't an appropriate code (yet)
Erich Schulz (Jun 02 2016 at 23:28):
@Rob Hausam sometimes a postive statement of absent allergy makes the difference between giving a first-choice and second choice drug - this is most common when there is a higher risk - eg cross-reactivity with a known allergen (penicillin <-> cephalosporins), or a high baseline risk of intolerance (eg tramadol). And there is always a reason a secondline agent is second line (expense, efficacy, side-effects) - so a decision support system that understands negative allergy statements will make better choices and be able to choose first-line agents more often.
Erich Schulz (Jun 02 2016 at 23:29):
As I indicated above - the thing I'm struggling with is that the required information is actually repsresentable very simply.
Erich Schulz (Jun 02 2016 at 23:30):
All the information can be represented by a pair of codes - one for "allergy status" and another that points into some point of a substance classification.
Grahame Grieve (Jun 02 2016 at 23:30):
that's what Rob's going to draft...
Erich Schulz (Jun 02 2016 at 23:32):
oh I must have misunderstood his statement about the role of role of the composite "no known allergy" codes
Erich Schulz (Jun 02 2016 at 23:33):
the reason I think these are evil is they utterly fail to scale up to representent subtle but important differences in the known status of an allergy
Erich Schulz (Jun 02 2016 at 23:34):
eg the "not known to be allergic to", "previously exposed without reaction", "not previously exposed to" subtleties
Grahame Grieve (Jun 02 2016 at 23:34):
well, What Rob is drafting - if I've kept up corrrectly - is to keep the existing loose substance, but rename it to code, and making it looser, and retaining the use of those codes in that loose field. And adding a more tightly controlled pair of codes for systems to populate, where these pairs have tightly controlled meaning, and are computable. Systems that know how can populate them. Those that don't, won't
Rob Hausam (Jun 02 2016 at 23:39):
There are a lot of factors here. @Erich Schulz it would have been good to have you join us on the Patient Care FHIR call that ended about an hour ago - we spent an hour and a half talking further about this and what we are proposing to put into the build - including the issues of interaction with status and the notion of alignment with openEHR.
@Grahame Grieve that was the plan. There's been some further pushback on the "adding a more tightly controlled pair of codes" part, though. Erich's rationale is good, especially in theory and as an aspiration - I don't think I've ever seen anyone come remotely close to implementing it, though (so far). I'm working on it more tonight.
Grahame Grieve (Jun 02 2016 at 23:41):
let me guess. @Lloyd McKenzie pushed back? I'd like to add it so people can see what it looks like anyway - and so we can ascertain: is there resistance to the idea because there's a better way to make it computable, or because there's no agreement that systems would do that?
Erich Schulz (Jun 02 2016 at 23:48):
in terms of "not coming close to implementing it" @Rob Hausam - that is interesting - I'm really curious as to why - it is an extraordinary simple model - and far more tractable than there various hybrid options.
Grahame Grieve (Jun 02 2016 at 23:48):
Erich, have you seen this?
Erich Schulz (Jun 02 2016 at 23:49):
are there options for indicating deprecation of fields included for historical reasons?
Grahame Grieve (Jun 02 2016 at 23:49):
http://www.healthintersections.com.au/?p=2267
Grahame Grieve (Jun 02 2016 at 23:50):
if you look through these, you'll see the gap Rob is referring to. You're welcome to contribue counter examples. I had more examples than that but I couldn't publish them - but they were all consistent with those
Erich Schulz (Jun 03 2016 at 00:23):
sorry @Grahame Grieve - i'm not getting what the gap is
Rob Hausam (Jun 03 2016 at 00:24):
had to step out for a bit
Grahame Grieve (Jun 03 2016 at 00:26):
for all of those programs, populating the pair of codes would depend on the terminology they use having the knowledge, and them having access to it. Most allow text or local codes, or use some random code list with no knowledge, and those that do use a tx with the knowledge, usually don't have any access to it's knowledge. I'm working a new operation for the terminology service that will surface the knowledge. Perhaps this would be a useful test case, @Rob Hausam
Erich Schulz (Jun 03 2016 at 00:28):
sure I understand the need to cope with legacy noise
Erich Schulz (Jun 03 2016 at 00:29):
and the FHIR resouce seems 99% of the way there to addressing most issues
Erich Schulz (Jun 03 2016 at 00:29):
the issue is when defining as sharable structure how much noise does one allow and encourage moving forward
Rob Hausam (Jun 03 2016 at 00:31):
@Grahame Grieve a new one beyond $subsumes and $infer?
Grahame Grieve (Jun 03 2016 at 00:31):
no that would be $infer, I think
Rob Hausam (Jun 03 2016 at 00:31):
that's what I thought you might have meant
Rob Hausam (Jun 03 2016 at 00:37):
I'm not sure how exactly that's going to go, with the discussions you've had with Davide (and others) as an example
I'm gathering that it will (at least initially) be "simple decomposition", rather than any attempt at leveraging DL reasoning (etc.)
Grahame Grieve (Jun 03 2016 at 00:38):
I haven't got back to those discussions yet
Rob Hausam (Jun 03 2016 at 00:40):
sure - there's plenty to do :)
Erich Schulz (Jun 03 2016 at 01:03):
are you guys on the right thread?
Erich Schulz (Jun 03 2016 at 01:03):
or is this terminology services as applied to hierarchical substance reasoning?
Erich Schulz (Jun 03 2016 at 01:08):
The other thing worth noting @Grahame Grieve is that using a one of ~20 precordinated "no allergy to X" codes is that this does not remove the need for hierarchical reasoning. Any automated processing will require hierarchical reasoning - the only difference is the with the precordinated codes this is a 2 step process but but with a pair of codes there is always a single direct link into a susbstance classification within the terminology
Rob Hausam (Jun 03 2016 at 02:15):
actually it isn't Lloyd that has pushed back, @Grahame Grieve - he's actually been pretty quiet for the most part on all of this :)
Lloyd McKenzie (Jun 03 2016 at 02:18):
I wasn't even on the call :) Too snowed under with other things. Hope to surface next week. But I have no issues with Rob's proposal.
Rob Hausam (Jun 03 2016 at 02:22):
well, hopefully that's still the case when I get it done :) - I'm trying to take into account all of the various discussions and opinions - not a particularly easy task
Lloyd McKenzie (Jun 03 2016 at 02:26):
We're grateful for your services :)
Erich Schulz (Jun 03 2016 at 07:33):
go @Rob Hausam !!
Rob Hausam (Jun 08 2016 at 13:12):
hi, Yong
Last updated: Apr 12 2022 at 19:14 UTC
