One of the common features of most clinical applications is the ability to catalog a list of substances that may cause an issue for the patient. This is typically labeled as “patient allergies,” even though the information entered may not be an allergy at all. In aprevious postwe discussed the rules of thumb when it comes to drug allergies, in this post we will focus on the design patterns we use today and why they might be limiting the effectiveness of how we manage intolerance information in general.
A Brief History
This notion has been around for a long time. As far as structured data goes it is one of the earliest clinical entities, along with medications, that we stored about the patient. The problem with it today is about 10 years ago, we stunted its evolutionary development and left it alone as “good enough”. Let's examine how this feature started and how it has evolved.
Originally patient allergies were just a free text list that was intended to be seen by the provider when they were ordering, dispensing or administering a medication. It was up to them to see the allergen and assess the risk of giving the patient a particular medication. Tracking this information in a discreet list rather than embedded in a note was a step in the right direction but it still required the provider to notice the allergy and know how it was related to other medications the provider was considering prescribing.
进化的第一步是把这个列表into a discreet coded list of drug allergens. The main benefit of coding this data was to allow the software to “help” evaluate the risk of a given medication for the patient. These coded drug allergens could be ingredients, drugs, brand names or classes. When a medication was ordered, dispensed or administered for a patient, it could be checked for overlap against the items in the allergy list. If there was an overlap, a warning was issued. This was a significant step because we no longer had to rely on the provider to understand all the details and nuance of brand name specific ingredients, allergy classes and allergy cross sensitivities. This however introduced a new problem. The software’s ability to traverse the expansive and convoluted web of relationships between medications resulted in a large number of “potential” alerts. These alerts ostensibly stand in the way of a patient receiving a medication. There was a need to filter the alerts so that only important ones interrupted the provider’s workflow. This led to the next evolutionary step.
为了筛选麻木er of alerts that were fired due to a potential allergy, the notion of severity and reaction were introduced. Severity was typically coded and the reaction might be coded but could also be free text. Severities were typically coded as “mild,” ”moderate,” ”severe” and “life threatening.” The first three were to essentially stratify the severity of the specified reaction where the fourth, “life threatening,” was used more as a “you can't override this” indicator. The severity level was typically used to determine whether you stop the provider’s workflow or just show the potential alert off to the side.
This was a good evolutionary step because it provided important information for both the software and the provider but for many systems this is where the evolution stopped. The problem is that how we think about and categorize substance intolerance has evolved beyond our clinical architecture.
Drug Intolerance Versus Drug Allergy
I have seen a number of conversations around the difference between a drug allergy and a drug intolerance. While it is true that an allergic reaction is physiologically different then a non-allergic reaction, I would argue from a systems design perspective they are both intolerances. In the case of an allergy, the intolerance reaction is an allergic reaction. The information you collect is the same (substance, reaction, severity, certainty) and the pattern you follow to evaluate other elements of the patient’s context is also the same if you support a class and cross sensitive branch for drugs or reactions that warrant it.
Substances
Patients have intolerances to things other than drugs. We have focused on drugs because we could automate the checking and we used drug terminologies to code these lists. The growing sensitivity to other types of intolerances like latex, peanuts, etc. and their impact on how providers interact with patients has brought them into focus. These non-drug allergies tend to fall into the following categories: food, environment, other substance.
We have followed a trend to add these types of intolerances into the same bucket as drugs. While I would agree that there is value to having these cataloged and potential overlap with drugs that necessitate overlap checking, there is no reason to combine them into a single intolerance list. Drugs, foods, environmental elements and other chemicals and substances deserve their own fields, managed pick lists and checking logic.
Knowing What You Don't Know
If you examine the aggregated allergy information for just about any health system you will find in the top ten allergens one of the following codes: “no known allergy,” “no known drug allergy,” “no known food allergy,” “no known substance allergy “or “unable to obtain.” The purpose of these codes is to allow the person documenting the patient state to putsomethingin the intolerance field that shows the provider they did indeed ask the question. It is the equivalent to pertinent negatives that are used for symptoms in a review of symptoms in an encounter note.
The problem with putting pertinent allergy negatives in a bucket designed for positives is twofold.
First, it is not a substance or class of substance. A good rule of thumb on system design is if you can’t say it without sounding like an idiot, it is likely not a good design. For example: “the patient has an intolerance to no history of drug allergies.”
Second, it has a completely different information requirement than a substance intolerance. For every substance intolerance you should capture a severity and reaction. What exactly would you use for the reaction and severity for “no known allergy”?
Lastly, an intolerance is a persistent piece of information. You are documenting something that is positive that effects the patients care. Pertinent negatives are transitory. On this date, we do not believe the patient has any allergies. The problem with putting a pertinent negative on the intolerance list is that we have a tendency to accumulate these things over time and share these lists with other entities. Pertinent negatives for substance intolerance are a status of the intolerance list, not an intolerance item. They are an explanation of why the intolerance pick list is empty.
By the way... The fact that we have common codes for “no drug allergy,” “no food allergy,” “no environmental allergy” and “no substance allergy” reinforces my point that these should each be separate lists in the patient’s clinical context.
Incremental Evolution
Substance intolerance is not rocket science, and APIs would not be difficult for us to get it right. There is an optimal pattern that would produce highly effective results. The problem is that it sits in the “good enough” bucket. If we intend to produce clinical systems that fulfill our aspirations around precision medicine, we will need to re-examine the “good enough” bucket from time to time and raise the bar.
As always, please feel free to share your thoughts and experience.
