Derive observation type from the observation type's category - #748
Open
labkey-martyp wants to merge 2 commits into
Open
Derive observation type from the observation type's category#748labkey-martyp wants to merge 2 commits into
labkey-martyp wants to merge 2 commits into
Conversation
The Observations form offers every observation type, so it can no longer default the type to Clinical; the trigger script now derives it from the selected type's category, while every other form keeps setting the type explicitly. The Daily Observations buttons are now opt-in per section, so the behavior forms no longer inject clinical-category observations and orders typed as Behavior.
Derive on every save rather than only when the type is blank, so a re-opened draft or a saved template cannot keep a type left over from a different category. Every other form's type picker is filtered to the categories that agree with the value it sets, so deriving unconditionally gives those forms the same answer.
ankurjuneja
approved these changes
Aug 25, 2026
| * Returns the category of an observation type from ehr.observation_types, or null when the type has no | ||
| * category or is not found. Cached for the life of the save batch. | ||
| */ | ||
| public String getObservationTypeCategory(String observationType) |
Contributor
There was a problem hiding this comment.
does this cache ever need to be cleared for when ehr.observation_types is edited?
| if (_autoPopulateDailyObs) | ||
| if (_dailyObsOption != null) | ||
| { | ||
| defaults.add("NIRC_AUTO_POPULATE_DAILY_OBS"); |
Contributor
There was a problem hiding this comment.
I might have missed, but do we need NIRC_DAILY_CLINICAL_OBS_ORDERS and the dependency as no one is referencing it any more?
| // but their type pickers are filtered to the categories that agree with the value they set, so deriving | ||
| // here gives them the same answer. Deriving unconditionally also re-derives when a re-opened draft or a | ||
| // saved template carries a type left over from a different category. | ||
| row.type = triggerHelper.getObservationTypeCategory(row.category) === 'Behavior' ? 'Behavior' : 'Clinical'; |
Contributor
There was a problem hiding this comment.
should it be case insensitive check?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rationale
The Observations form let a user pick any observation type but stored every entry as Clinical, so behavior observations recorded there were filed as clinical and dropped out of the behavior views. The form cannot know the right value up front because it depends on which type the user picks for each row, so the type is now derived on save from that type's category. The behavior forms had the same mismatch from the other direction: their Daily Observations shortcut bypassed the type-filtered picker and wrote clinical-category observations and orders labeled as behavior. Rows already saved with a mismatched type need a one-time data fix; this change only affects new entries.
Related Pull Requests
None.
Changes
The Observations form no longer defaults an observation's type. The trigger script derives it from the selected observation type's category, while every other form continues to set the type explicitly, including scheduled entries that inherit it from their order.
The Daily Observations shortcut is now opt-in per form section rather than always present, so it appears only on the clinical forms.