O3: Proposal to Remove Allergen Type Field from Allergy Table

jayasanka · November 27, 2023, 1:44am

Dear OpenMRS community,

We are currently working on enhancing the allergy form, and during our review, we observed that the allergen type, which is stored as a hard-coded enum (FOOD, DRUG, ENVIRONMENT, and OTHER), is stored in the allergy table in the database. However, upon further investigation, we discovered that this allergen type is not utilized anywhere in the system, and it does not contribute to any rendering in the user interface.

In light of this finding, we recently discussed this matter during an O3 squad call but were unable to identify any use cases or scenarios where the persisted allergen type field is beneficial. Consequently, we are considering the removal of this field from the database.

If you have any concerns regarding this proposed change, we invite you to share your thoughts and considerations. Your feedback is invaluable to us, and we want to ensure that any adjustments align with the needs and preferences of the OpenMRS community.

Please participate in the following poll to express your opinion:

I have no concerns.
I have concerns, and I’ll post them below.

0 voters

Thank you for your collaboration and input.

cc: @grace

dkayiwa · November 27, 2023, 10:32am

Are you referring to this? https://qa-refapp.openmrs.org/openmrs/allergyui/allergy.page?patientId=43&returnUrl=%2Fopenmrs%2Fcoreapps%2Fclinicianfacing%2Fpatient.page%3FpatientId%3D43%26&

In other words, do you want to show all the allergies on the same screen/page instead of grouping them by type (DRUG, FOOD, OTHER)?

kmakombe · November 27, 2023, 11:25am

I think we should retain the allergen type in the model.Does it mean that when it is not being used right now in O3 then that renders unnecessary? The grouping to me should stay for those who would want to categorize/group allergies

mseaton · November 27, 2023, 12:42pm

I don’t see a huge value in removing this field. We could certainly deprecate it and/or make it optional rather than required in the DB, and start to downplay it’s significance. I would want to understand better the reasons why it was added in the first place (review old talk posts, design discussions, tickets, etc), and then also understand the motivations behind removing this now.

ibacher · November 27, 2023, 1:34pm

I’m failing to see the issue here that we want a decision on. Why are we considering removing this from the database? What issue does it pose? Just because something isn’t driving UI functionality doesn’t mean that it’s useless (the UI functionality, for example, could be missing).

mogoodrich · November 27, 2023, 2:02pm

Agree with the above… I’m fine with deprecating it and/or making optional if we think we don’t want it going forward. At minimum, I thinking removing it would break the O2 allergies functionality.

akanter · November 27, 2023, 3:11pm

My comment is only when it comes to validating the code associated with the allergen. If you need to know whether the concept is a SNOMED concept versus and RxNORM concept versus a UNII… how do you know which system to validate the allergen with?

jayasanka · December 1, 2023, 8:43am

Thank you all for your inputs and for dedicating your time and offering valuable suggestions.

Let me provide some additional background information below; my apologies for not sharing many details in the initial post.

No, but it is indirectly related to this issue. The primary goal was to simplify the allergy form, as described in this ticket: O3-2614 and this epic: O3-2561. So, yes, we aimed to remove the groupings from the UI and display it on a single list. During my work on this, I observed that when we submit an allergy through the API, there’s a required field to submit the type of the allergen along with the allergen. For instance, if I submit an allergy for a patient for Fish, I need to explicitly add another property to the payload stating that Fish is a food allergen. Regardless of which property the client sends, it saves the allergen type as it is sent by the client. If the client sends the allergen type for “fish” as “drug,” it saves it as is; there’s no backend validation for this type, relying heavily on the client.

Even if we remove the categories from the allergy form UI and display it on a single list, it’s still feasible to fetch allergen categories somehow and send them along with the payload. However, my question remains: do we really need to store it in the first place if we don’t use it?

When I said we couldn’t find a utilization in the system, the only places I found are here, which seems no longer in use as the functionality has been moved to the core and rest api module. Additionally, I found it in the FHIR2 module where it translates the type to FHIR’s optional field AllergyIntolerance.category . A full list of usage can be found here. If we check the source codes, all the usage is to store the allergen type but not to use it.

Apart from that yes, this don’t seems contributed to any rendering. This is how it displays in allergies tables.

On a side note, here’s how the table looks; as you can see, the allergen type is stored as a non-null varchar.

Checking the structure, the allergen type can vary for different allergy records. Correct me if I’m wrong, but as per my understanding, the type of the allergen is agnostic from the patient or allergy record. i.e., “fish” is a food allergen regardless of the patient. If I’m correct, the relationship between allergen and allergy type should be 1…1. The allergen type, to me, is a derived attribute that shouldn’t be stored in the allergy table.

However, this might be a result of an implementation due to limitations with dealing with concept codes.

It seems I have two options here:

To keep it as it is and send the allergen type while creating an allergy.
To make the field optional.

Let me know what you think.

I’m not sure I fully understand your question. But, it stores only the code in the table. When fetching from FHIR API it fetch the concepts improted previously from the following three:

The stored allergen types are FOOD, DRUG, ENVIRONMENT, and OTHER.

akanter · December 1, 2023, 5:44pm

Since FHIR expects an allergy type field to be included, it seems like we need to keep that information. We are using value sets to determine the allergen type from CIEL. CIEL then is acting as the filter knowing which types to include where (with their associated coding). If you were building this out with an API to a terminology server, you would need to know that for drugs you go to an RxNORM server, for FOOD, ENVIRONMENT and OTHER you to go SNOMED, etc. Drug classes are also a different reference coded concept. There are not RxNORM codes for classes like “penicillins” (it is NDF-RT or Med-RT). When it comes to the coded allergen field, what is going in there?

burke · December 5, 2023, 1:43am

In FHIR, AllergyIntolerance.category (food | medication | environment | biologic) is optional and its use discouraged per the FHIR documentation:

This data element has been included because it is currently being captured in some clinical systems. This data can be derived from the substance where coding systems are used, and is effectively redundant in that situation. When searching on category, consider the implications of AllergyIntolerance resources without a category. For example, when searching on category = medication, medication allergies that don’t have a category valued will not be returned. Refer to search for more information on how to search category with a :missing modifier to get allergies that don’t have a category. Additionally, category should be used with caution because category can be subjective based on the sender.

In FHIR, AllergyIntolerance.type is used to discriminate between allergy vs. intolerance, which is much more clinically useful.

If we want to evolve toward FHIR, we would deprecate use of allergy.allergen_type for storing categories (FOOD, DRUG, ENVIRONMENT, OTHER) and work toward using it for FHIR’s type (ALLERGY vs. INTOLERANCE).

For the sake of backwards compatibility, we’d probably want to do this in separate steps (releases) – i.e., (1) deprecate current use of allergy types in OpenMRS, (2) remove existing data in this column, (3) refactor allergy type to be ALLERGY or INTOLERANCE, then (4) start using FHIR allergy types.

The primary use case for distinguishing allergy categories (DRUG, FOOD, ENVIRONMENT) is to assist users on entering common allergens across these categories. I think folks working on O3 weren’t thrilled with replicating OpenMRS v2’s approach to hardcoding these categories into the user interface. A compromise could be a concept set for preferred/common allergens used for displaying a convenient list of common allergens in the UI.

akanter · December 5, 2023, 3:23am

Burke, it has been a while since I have worked on the allergy and intolerance areas. Looking at this level 1 spec I am a little at a loss. I don’t see how the value set of codeable concepts for allergyintolerance.code be made up of SNOMED codes including “Allergy to x” rather than the substance x. I don’t see how they actually manage validation of codes from different systems “t is strongly recommended that this element be populated using a terminology, where possible. For example, some terminologies used include RxNorm, SNOMED CT, DM+D, NDFRT, ICD-9, IDC-10, UNII, and ATC.” If we don’t manage the concepts based on drug/non-drug/environment, etc. then I don’t know how you know which concept code to choose from, and once you have it, how you use it to actually provide CDSS. If the primary use case is to prevent prescription of a drug for which a patient has an allergy/intolerance, then conflating SNOMED-coded non-drug allergens with drugs seems like a bad idea. It is true that SNOMED should be able to trace both the products and the “allergy to x” back to the same substance, but I am not so confident that I would rely on that being complete. Does anyone have any latest input into this discussion?

jayasanka · December 12, 2023, 7:25am

Not sure how much this helps, but I wanted to provide some additional insight into how allergies are stored. The allergen list is populated with concepts from the following CIEL concept sets, which are already synchronized with the concepts table:

When an allergy is saved, it establishes a relationship with the relevant concept from the concept table. When translating an allergy to FHIR, the system reads the concept mapped to the allergen from the database and maps it to the AllergyIntolerance.code attribute. The category isn’t involved in this translation. However, if there are SAME-AS mappings to the concept, they will also be included in the AllergyIntolerance.code field (as an array).

As we do not record the substance, the same value will be mapped to the AllergyIntolerance.reaction.substance attribute.

In the meantime, I’ve identified an issue with translations, and I’ve posted it here.

akanter · December 12, 2023, 2:34pm

FYI, new version of CIEL will contain this convenience set:

akanter · December 12, 2023, 2:40pm

and this: (note there was a pre-existing concept 162760 Severity of adverse reaction:

jayasanka · December 13, 2023, 4:48am

I believe your response may have been intended for the following post: Reassessing Allergy Severity Mapping in FHIR

Indeed, it references the convenience sets mentioned above*. However, the concern arises as it attempts to correlate the severity of reactions with criticality.

*we do not store the criticality in the db.