Stream: implementers
Topic: no known allergies/medications/problems
David Hay (Apr 27 2016 at 17:43):
I recall a discussion on how to represent the statement 'no known allergies' (which I now can't find) - whether this is an empty list with a value for emptyReason, or (in the case of allergy) an AllergyIntolerance resource with a substance value having a negation code.
What is our current position on this, and the other lists (condition, medication)?
Lloyd McKenzie (Apr 27 2016 at 17:44):
Current leaning is an explicit record in the list, but I wouldn't say it's fully landed. There's work going on with "negation" in general.
David Hay (Apr 27 2016 at 18:00):
So a query for the 'current' list (http://hl7.org/fhir/2016May/lifecycle.html#current) that returns a List resource containing a domain specific resource with a 'negation' reason? (Rather than using the List.emptyReason)
Peter Bernhardt (Apr 27 2016 at 18:17):
Returning a list with no items and empty reason makes most sense if there are actually no allergies for the patient. Be easy enough for a consumer to process this and conclude the patient has not reported any allergies.
David Hay (Apr 27 2016 at 19:53):
actually it would be a bundle of course, containing the List and DomainResources...
Rob Hausam (Apr 27 2016 at 20:22):
There is ongoing work on this right now, particularly in the TermInfo project in Vocab and the Patient Care WG. What I am planning to propose to Patient Care (who owns the resource) from TermInfo is consistent with what you described, David, as an AllergyIntolerance resource with a substance value having a negation code. We will be proposing some changes, such as renaming the 'substance' element to 'code' to better reflect it's intended scope of use and the value set binding. In the earlier discussions we had moved away from using emptyReason, both because of limited flexibility (e.g., no way to say both "no known drug allergies" and "no known food allergies", as cardinality is 0..1), and maybe more importantly because there was significant desire that all allergy/intolerance data be returned by querying for AllergyIntolerance resources (and not needing to also query List).
There is also interest from a number of folks in separating out the "negated/excluded" statements into a separate element. The compromise that we're intending to propose for this is to create a standard extension including an 'excludedCode' element for this purpose, along with an invariant that either the 'code' or 'excludedCode' element may be populated, but not both. Plus a statement that if "double negation" should occur (e.g., a code or expression for "no allergy to penicillin" in the 'excludedCode' element), that it is to be interepreted as additive or reinforcing the negation, and not as resulting in a "logically positive" statement of allergy or intolerance.
Last updated: Apr 12 2022 at 19:14 UTC
