I remember there only being 3 types (Drug, Food, Environment) when we built this feature, and surely “pollen” is an environmental allergen, not its own type. (RA-1283)
It’s impossible to make an appointment for my patient. I do Appointment Scheduling → Manage Appointments, and I get a blank screen (which is actually a 400 Bad Request error) for this crazy url. At a glance I think we need to get rid of the “breadcrumbOverride” here… (AM-184)
Can whoever is the Community Dev Lead prioritize getting these issues fixed? They make certain features of our demo unusable!
@dkayiwa, slow down with those changes to allergies; I think we need to analyze what went wrong here and clean things up correctly.
I see that when allergies were added to openmrs-core (in TRUNK-4747) the AllergyType enum was changed from this:
public enum AllergenType {
DRUG, FOOD, ENVIRONMENTAL
}
to this:
public enum AllergenType {
DRUG,
FOOD,
ENVIRONMENT,
ANIMAL,
PLANT,
POLLEN,
OTHER
}
(Also this list is duplicated as AllergyType, which we should delete.)
Googling around I cannot find any explanation of why this changed. Unless @burke or @jteich asked us to do this, I propose we change this back to the intended design.
The shorter list of 3 types from allergyapi is the correct one. (E.g. animal dander, plants, and pollen are all environmental allergens.)
So we should fix this. Now, unfortunately we’ve already released version 2.0 of openmrs-core with this bad list.
I propose we just remove ANIMAL, PLANT, POLLEN, and OTHER from the list, because they are incorrect (as opposed to deprecating enum values, if that’s even possible).
We also inadvertently changed the spelling from ENVIRONMENTAL to ENVIRONMENT; I guess we could leave this as ENVIRONMENT going forwards and change the allergyui module to use ENVIRONMENTAL with the allergyapi module, or ENVIRONMENT with openmrs-core. That’s technically more correct from the perspective of us as API maintainers. Although personally I would just fix the spelling to be what we want.
And we should release a maintenance 2.0.x to include this.
public enum AllergenType {
DRUG, FOOD, ENVIRONMENT, OTHER
}
public enum AllergyType {
ALLERGY, INTOLERANCE
}
We don’t have to implement AllergyType in this fix if we don’t already have it; however, the above would align us with FHIR.
If we’re fixing things here, I would favor aligning with FHIR’s AllergyIntolerance.category – i.e., DRUG, FOOD, ENVIRONMENT, OTHER.
Technically speaking, allergy type would be whether the allergic response is immune-mediated (ALLERGY vs. INTOLERANCE) and allergen type would specify the type of agent causing the response (DRUG, FOOD, ENVIRONMENT, or OTHER). In FHIR, they use “AllergyIntolerance.type” for the allergy type and “AllergyIntolerance.category” for the allergen type (given “type” and “category” are somewhat interchangeable terms, I favor our use choice of “allergen type” in this case).
allergy = response to a substance (allergen) – e.g., rash, anaphylaxis, etc.
allergen = substance to which you are allergic – penicillin, tree pollen, etc.
Yes, drug/food/environmental is the correct set – don’t know how those other four sub-categories got promoted.
Either “environment” or “environmental” is fine – environmental would be my choice as well – but see next item.
“Other” is reasonable as a data category, in that it supports FHIR, although we did not use that in the 2014 design work because in common usage Environmental is already the wastebasket category for anything that’s not a drug or a food.
We include the following in Environmental at Partners, and I brought this list to the OpenMRS allergy development in 2014: bee stings, animal dander, dust, latex, mold, pollen, ragweed, adhesive tape, other (both the Food and Environmental sections have an option to choose Other and then write something in a text box). As you can see, some of these are natural and some are products; latex is both. People are happy finding latex there, because it’s the only place to look. Another odd one is IV Contrast Media for radiology, which technically is a drug but is hard to find because docs and nurses don’t know the real name to look up – metrizamide, iohexol, etc. – and the patients sure don’t remember it.
I would propose having one tab in the UI named Environmental/Other or probably just Other, which includes all the above choices as well as IV Contrast Media. Under the hood, the dictionary is welcome to assign any of these items to the Environmental category or the Other category.
[should be “4.”] We also ignored the Allergy vs Intolerance distinction in the practical design – as does every commercial EHR I know of – because, again, users have a hard time knowing the precise biochemical difference and it’s not clinically very important. The important thing to know is the nature and severity of the reaction. Technically, the proper collective term for the whole set is Intolerance, and practically everyone calls it Allergy, so we kept the name that is in common usage. Note that even FHIR has “no known allergies”, etc., but not “no known intolerances”.
Not quite sure I follow all the discussion around “ENVIRONMENT” vs “ENVIRONMENTAL” but this commit from a couple weeks ago is a blocker, unless I’m missing something:
When I try to open the clinical dashboard, and specifically the allergies widget, for an existing patient with an environmental allergy it stack traces, because the enum is stored directly in the allergen_type column in the allergy table, and so we get:
java.lang.IllegalArgumentException: No enum constant org.openmrs.module.allergyapi.AllergenType.ENVIRONMENTAL
… when Hibernate tries to load an existing environmental allergy.
I agree that we should not have retroactively change the enum value in the
allergyapi module. We should revert this while we decide on an approach
going forward.
Possible approaches:
We do make the change that’s in this commit, but we pair it with a
liquibase changeset to migrate the data
allergyapi module supports both enum values (ENVIRONMENT and
ENVIRONMENTAL) and openmrs-core 2.x lines do the migration.
I noticed that those who entered them using the legacyui, they stored ENVIRONMENT. Because it is what the platform used. Those who used the allergyapi module have ENVIRONMENTAL. Either of the two requires a liquibase changeset to convert ENVIRONMENT to ENVIRONMENTAL or ENVIRONMENTAL to ENVIRONMENT.
I’m fine with the either… sounds like Darius votes for changeset to convert ENVIRONMENTAL to ENVIRONMENT… can we go ahead and do this (and avoid reverting) or do we need more discussion?
Personally I like the wording “environmental” better, but since FHIR calls it “environment” and that’s what was already in openmrs-core through our latest release I vote for ENVIRONMENT.
I don’t see any reason not to just go ahead and add this liquibase migration.
(Burke already voted for ENVIRONMENT on an openmrs-core ticket.)
As some of us may be aware, Darius is currently away on vacation and hence he will be unable to review this https://issues.openmrs.org/browse/RA-1283 issue .It’s marked community priority and thus needs quick attention. Can someone look into it?
