FHIR Chat · No known allergy to specific drug and no evidence of disease

Stream: implementers

Topic: No known allergy to specific drug and no evidence of disease

Travis Stenerson (Aug 22 2017 at 19:36):

Quick question about negating specific items. If one wanted a record that a specific AllergyIntolerance is not present, or a specific disease is not present, what is the ideal resource to contain or record that? The negation sections of AllergyIntolerance and Condition point to a list with 'NKDA' as as EmptyReason, but the use case is in reference to specific conditions or intolerances that must be either ruled out or addressed.

Grahame Grieve (Aug 22 2017 at 21:57):

I think that what the AllergyIntolerance resource expects at the moment is that you'd use a single code 'no known allerges to [x]'

Michelle (Moseman) Miller (Aug 22 2017 at 22:31):

In context of AllergyIntolerance, there are multiple ways of handling negation as noted in http://build.fhir.org/allergyintolerance.html#9.1.3.3 - which is summarized as follows:

Use AllergyIntolerance.code (CodeableConcept) -- as long as a code exists, such as SNOMED 716184000 for No Known Latex Allergy
Use the extension http://build.fhir.org/extension-allergyintolerance-substanceexposurerisk.html -- this allows you to document both the specific drug (substance) and no-known-reaction-risk (exposureRisk)
Use List.emptyReason (not recommended, nor applicable when talking about a specific drug)

There are two primary ways of reporting "no known allergies" in the current specification: using the CodeableConcept, as described above, or using the List resource with emptyReason. The third available option is using the substanceExposureRisk extension. During the STU period, it is not recommended to use the List resource for "no known allergies" reporting purposes. The principal reason for this is to allow all allergy or intolerance data to be found and to be consistently queryable from the single location of the AllergyIntolerance resource

Michelle (Moseman) Miller (Aug 22 2017 at 22:35):

In context of Condition, refer to https://chat.fhir.org/#narrow/stream/implementers/topic/negated.20Condition and http://build.fhir.org/condition.html#9.2.3.4, which I would summarize as follows:

If the condition has been ruled out by diagnostic and clinical evidence, then you can use Condition.verificationStatus = refuted
It is common as part of checklists prior to admission, surgery, enrollment in trials, etc. to ask questions such as "are you pregnant", "do you have a history of hypertension", etc. This information should NOT be captured using the Condition resource but should instead be captured using QuestionnaireResponse or Observation. In this case, the combination of the question and answer would convey that a particular condition was not present.

Travis Stenerson (Aug 23 2017 at 00:37):

Thanks @Michelle (Moseman) Miller
That extension on AllergyIntolerance will work well for my purposes.

Regarding condition however, the conditions we will be asking about have never been associated with the patient, so 'refuted' seemed like the wrong approach when I read the sections you quoted. The use case is a CDS service verifying that something like Superior Vena Cava Obstruction is absent. We would just like a record of confirmation that the condition is absent. If 'refuted' is the suggested approach, that works. I was also considering a 'No evidence of disease' Observation, with values of the condition codes. Kind of a point in time observation that the patient does not have the sequalae under consideration. Any suggestions?

Grahame Grieve (Aug 23 2017 at 00:42):

I did not think that refuted meets your use case given it's definition

Travis Stenerson (Aug 23 2017 at 18:23):

@Grahame Grieve
I agree. Do you have a suggestion on how to record the absence of X disease? What do you think about an Observation code: 'no evidence of disease', valueCodeableConcept: 'disease code'.

Michelle (Moseman) Miller (Aug 23 2017 at 18:42):

Observation seems reasonable to me.

Rob Hausam (Aug 24 2017 at 14:02):

I think Observation is reasonable, but there are multiple ways potentially to use it. Observation code: 'no evidence of disease', valueCodeableConcept: 'disease code' is one possibility, but it sort of turns 'code' into a de facto "negation indicator". Another possibility that has been discussed (by the VA and others) is to put the disease code (finding) in the 'code' element and then use a 'value' of "absent" or "not present" (or similar). The most straightforward way might be to use a precoordinated code for "no evidence of xxx disease" (or equivalent), but then that could be either in 'code' or 'value'. We probably should review the PCWG Negation work on this, and I think it still needs further discussion to determine the best approaches and how to interoperate between them.

Eric Haas (Aug 24 2017 at 18:10):

this also relates to the GF#13318 where rob and I have drafted some quidelines for using codes in observations. comments welcome....

Michelle (Moseman) Miller (Aug 24 2017 at 22:20):

@Eric Haas and @Rob Hausam - I can find examples where we have SNOMED Observation.codes that don't look like observable entity, procedure, clinical finding or event. Since this is only guidance, these examples might not matter, but I did find them while sampling some data.

Code = 50121007 Eye glasses, device (physical object)
Code = 336602003 Oxygen mask (physical object)
Code = 439343009 Tinetti falls efficacy scale (assessment scale)
Code = 425401001 Pain intensity rating scale (assessment scale)
Code = 8966001 Left eye structure (body structure)
Code = 102409004 Second hand cigarette smoke (substance)
Code = 119339001 Stool specimen (specimen)

Michelle (Moseman) Miller (Aug 25 2017 at 18:51):

Let me know if it would be helpful to see any of the corresponding values.... For example, when Observation.code is Eye Glasses, then I've seen values ranging from Yes/No as well as Kept with Patient/Left at Home.

Rob Hausam (Aug 26 2017 at 03:13):

I think that actually would be helpful, Michelle. I think this ultimately will show that there are a lot of different approaches being used out in the field. Providing usable guidance that can help to reduce the variability and improve interoperability isn't particularly clear cut or easy, but still is a desirable goal.

Travis Stenerson (Aug 26 2017 at 19:19):

I think it would be helpful to see all kinds of Observation examples. The specifics of Observations in FHIR made it tricky to cover all the types I've had to, particularly finding the 'code'/question field. That may be due to deficiencies in terminologies though. I think a set of valid, usable observations with different patterns of assertion or code-value pairings would be helpful to give new FHIR implementers an idea of what is and is not a valid observation. It's easy to understand LOINC like observations with lab values, but Observation seems to be the best Resource choice for so many other types of subjective and objective findings. Lots of examples would be very helpful to differentiate what should be an Observation, what should be a Clinical Impression, what should be a Condition, etc.

Michelle (Moseman) Miller (Aug 28 2017 at 13:23):

@Rob Hausam For Left Eye (which is one observation that is part of a larger neuro eye assessment), values might be Bloodshot , Clouded Over, Enucleated, Jaundice, Normal, Scleral Edema, Swollen Eyelids

Rob Hausam (Aug 28 2017 at 13:31):

Yes, those values make sense clinically (although that particular list is a bit of a random scattershot). It would be helpful to have more specific code which indicate the intent of the particular observation being made and narrow the choice of possible values - but, again, there are lots of different ways that can be organized.

Michelle (Moseman) Miller (Aug 28 2017 at 13:36):

I should add that many are "one off" examples as I was just looking for any example where there was variance from the drafted guidance (not taking volume into consideration). I will keep sampling data to provide a few more examples as time allows, but as I mentioned before, as long as the guidance is just guidance, it will fit most (just not all) use cases where SNOMED is used as the Observation.code.

Rob Hausam (Aug 28 2017 at 13:38):

Maybe you could provide the actual SNOMED CT codes (and/or the fully specificed names) that are used in 'code' and 'value' - at least for some of them?

Michelle (Moseman) Miller (Aug 28 2017 at 13:46):

Sure, if SNOMED codes have been mapped. Keep in mind much of this build is done using proprietary codes. We map to standards (such as SNOMED) on an as needed basis. For example:

Observation.code = SNOMED CT Eye glasses, device (physical object) 50121007
Observation.value =
SNOMED CT No (qualifier value) 373067005
SNOMED CT Yes (qualifier value) 373066001
or
Left at Home (not mapped yet, which might imply it would manifest as text only)
Kept with Patient (not mapped yet, which might imply it would manifest as text only)

Michael Hosking (Sep 04 2017 at 01:08):

Hi, similar issue,
I'm trying to understand how to best represent "Unknown Allergy"

Contextually, this relates to our organisation wanting to consistently represent the following concepts:
- known allergies
- no known allergies
- unknown /not yet asked/ allergies not recorded
- unable to load allergy data
- conflicting results returned

Travis Stenerson (Sep 04 2017 at 01:50):

By unknown allergy, do you mean that the patient experienced some allergic type event to a drug product, but the causal substance is not known? It sounds a bit more like an AdverseEvent. Or if there is some reaction that is going on, that could be a Condition. Or perhaps I'm not understanding the use case of 'Unknown Allergy'.

Michael Hosking (Sep 04 2017 at 01:54):

Our definition of "Unknown allergy" means that - for a specific patient - there is an empty list of allergies associated to the patient record.

Peter Jordan (Sep 04 2017 at 02:59):

Why not use 716186003 |No known allergy| ?

Michael Hosking (Sep 04 2017 at 05:02):

Unknown and no known are different clinical concepts.

Unknown - means no one has asked whether the patient has an allergy and it is unknown whether the patient has any allergies
No known - means that a clinician has asked if the patient has an allergy and the patient has responded with something like "no, not that I know of"

Peter Jordan (Sep 04 2017 at 09:47):

Attempting to assign a clinical concept to the absence of any type of record, and treat it as a finding, might be heading down a slippery slope (the non-event driven health record)? However, I'm sure that this must have been the subject of many past (null flavor) debates and I'm also guessing that there is a good reason why it's not covered by a pre-coordinated SCT concept. There is also a non-clinical interpretation of "unknown allergy" as denoting the existence of an allergy that's not been completely diagnosed (e.g. I've got a nasty rash, which might be the result of an allergy but I haven't identified what caused it).

Michael Hosking (Sep 04 2017 at 21:44):

I agree, it does become complicated.
The use case we are attempting to satisfy is something along these lines:

An allergy or allergies are incorrectly uploaded to a patient record. The GP then needs to delete all Allergies and the status is shown as "Nil Known Allergies". If, at that point the GP is unable to ask the patient about their Allergy status then the patient will have an incorrect status. This status indicates to users that the patient has been asked about their Allergy status and provided information that they have No known Allergies. This could result in a clinician not asking the patient about their Allergy status. A status of "Unknown" identifies that there is a task that needs to be completed for the patient i.e. to ask the patient about their Allergy status.

Robert McClure (Sep 04 2017 at 22:15):

@Jay Lyle Has been working on this and the PC group has an ongoing project on this with a current ballot out. I'd suggest you talk to Jay, look at the ballot, and participate in the discussion. I'm not up on the current thinking in the group on "unasked question" type of unknown but I agree "status unknown" is different then "absence of". For that reason I'd be careful about using the phrase "Unknown" when what you mean is "Status of xx unknown"

Michael Hosking (Sep 04 2017 at 22:32):

Thanks @Robert McClure,
I agree that we need to be careful with the use of "Unknown" versus "Status of ... unknown". I will pass this message onto our internal group.
I'll get in touch with Jay and join the discussion.

Peter Jordan (Sep 04 2017 at 22:46):

Another factor to consider is how this information might be presented to a Patient using a portal or PHR. For several years, my patient portal just displayed a count of '0' on the Allergy Tab to indicate no records. That made perfect sense to me, because I realized that my GP hadn't asked me that question since I started using the portal and (meds aside) previous clinical records weren't uploaded to that portal product. Subsequently, I've been asked the question, it's been coded using 716186003 |No known allergy| and that term is presented to me by the portal. Granted, I may not be a typical patient, but that term will probably be easily understood by most; "allergy unknown" or "status of [xx] unknown" may make less sense to the average patient?

Michael Hosking (Sep 04 2017 at 23:06):

Thanks @Peter Jordan ,
I agree with the above, that we should also consider what makes most sense to a patient and a "No known allergy" concept would be clear to most English speaking patients.

For the purposes of information display to a patient, "No known allergy" makes sense because the clinician has done something to confirm with you, as a patient, about what you know about your own allergies
For the purposes of information display to a clinician, there needs to be more detail to determine whether this "No known allergy" has actually been confirmed with the patient. If the a clinician has not attempted to clarify the patient's allergy status, then we need to show this to the clinician to clearly specify that the clinician needs to find out more information about a patient's allergies based on something like an "Allergy status unknown" concept.

Peter Jordan (Sep 04 2017 at 23:31):

Thanks @Michael Hosking. In terms of primary care encounters, the PMS might handle that use case by presenting an alert to the clinician. However, I can see that it might be informative in other situations to state explicitly on a patient record that the status is unknown.

Michelle (Moseman) Miller (Sep 05 2017 at 18:03):

The current guidance in the FHIR specification for AllergyIntolerance says:

Allergies Not Reviewed, Not Asked

When a sending system does not have any information about allergies being reviewed or the statement is about allergies not being asked yet, then the List resource should be used to indicate the List.emptyReason.code="notasked".

Michael Hosking (Sep 06 2017 at 00:19):

Thanks @Michelle M Miller,
I have reviewed this spec and it is helpful to understand this for the purposes of FHIR enabled systems. Our current requirement is requiring mapping from FHIR to v2.x through an integration engine.

Clinical Use Case - 'Delete' incorrect allergy details against an individual patient's record within a CIS. They want to have this displayed in such a way that represents "This patient's allergy status is unknown" to communicate to other clinicians that they need to confirm the patient's allergy status.

Based on the clinical use case above - technically in the Clinical Data Store - we cannot simply 'delete' and leave the allergy as an empty field. We need to display this to reflect the above unknown allergy status for this patient. Since our system is translating from FHIR to v2.x through the IE, we need a consistent semantic value.

Do you have any suggestions of how this could be represented? In a post-coordinated SNOMED CT expression, or even the individual "Unknown" SNOMED CT within an AL1 segment?

Peter Jordan (Sep 06 2017 at 01:45):

@Michael Hosking What about representing this using the SNOMED CT general information qualifier concept 1631000175102 |Patient not asked|

Cooper Thompson (Nov 15 2017 at 21:17):

How would we expect the transition from NKA to having allergies look for the AllergyIntolerance resource with a code of 1631000175102 |Patient not asked| or 716186003 |No known allergy (situation)|? That NKA resource needs a FHIR ID to be returned in a search bundle, so it needs to be independently retrievable. If at some point in the future, allergies are documented on the patient, and a client attempts to read the NKA resource that it got before the allergies were added, what should that resource look like? Should it be deleted? clinicalStatus=resolved? verificationStatus=refuted?

Cooper Thompson (Nov 15 2017 at 21:18):

Also - for the distinction between No known allergy and Not asked, would we want those to be the same resource where the code gets updated? Or two different resources, where the "Not Asked" resource gets deleted once you actually ask the patient and create a new "No known allergies" resource?

Grahame Grieve (Nov 16 2017 at 02:27):

"If at some point in the future, allergies are documented on the patient" - I think you are asking a system implementation question here, and the answer is , irrespective of how you do this internally, you present this an an AllergyIntolerance status, and need to remove it. It's actually obscure to me how you would remove it though

Michelle (Moseman) Miller (Dec 11 2017 at 15:33):

@Cooper Thompson I apologize in my delay responding! I will just add that the spec does provide guidance in section http://build.fhir.org/allergyintolerance.html#9.1.3.3 as follows:

If a new allergy is discovered, the negated allergy record must be updated with the "refuted" verificationStatus - to ensure that systems referring to this record are aware that this is no longer true.

While this same section says it's ok to represent the NKA with AllergyIntolerance resource, the "Not Asked" was intended to use List.emptyReason

When a sending system does not have any information about allergies being reviewed or the statement is about allergies not being asked yet, then the List resource should be used to indicate the List.emptyReason.code="notasked".

Cooper Thompson (Dec 11 2017 at 20:00):

I saw the List stuff but I guess I didn't fully understand that. Is the intent that if a client does a search on AllergyIntolerance, that the server can return either a Bundle of AllergyIntolerance resources, or a List? Or a Bundle with a single List entry? Wouldn't it make more sense to have a Bundle.emptyReason instead of flipping the entire output over to a List?

And I guess I wasn't clear that the bit about negated allergies would also apply to the "Allergies Reviewed, None Identified" resource. The STU note discourages Lists:

STU Note: ... During the STU period, it is not recommended to use the List resource
 for "no known allergies" reporting purposes.

so we looked at using the CodeableConcept, which I think means to send an actual AllergyIntolerance resource. The phrase in the note "using the CodeableConcept, as described above" is a bit unclear about what description above it is referring to. I was assuming it was referring to the use of AllergyIntolerance.code = 716186003 |No known allergy. I do like that approach over Lists, but then you have to refute that resource once you document an allergy, so if someone does an AllergyIntolerance.create to add an allergy, the server may need to automatically delete/refute the NKA one, otherwise allergy documentation is in a wonky state.

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · No known allergy to specific drug and no evidence of disease · implementers