Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(feat) O3-2430: User should be able to look up frequency in dropdown by abbreviation #1767

Merged
merged 20 commits into from
May 17, 2024

Conversation

piyushmishra1416
Copy link
Contributor

@piyushmishra1416 piyushmishra1416 commented Mar 31, 2024

Requirements

  • This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
  • My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
  • My work includes tests or is validated by existing tests.

Summary

The medication frequency dropdown menu displays options such as "three times per day." With this update, users can now input "tid" in the dropdown menu and have "three times per day" as an option.

Screenshots

Screen.Recording.2024-03-31.at.11.48.45.AM.mov

Related Issue

https://issues.openmrs.org/browse/O3-2430

Other

@piyushmishra1416 piyushmishra1416 changed the title O3 2430 O3 2430-User should be able to look up frequency in dropdown by abbreviation Mar 31, 2024
@piyushmishra1416 piyushmishra1416 changed the title O3 2430-User should be able to look up frequency in dropdown by abbreviation (feat) O3 2430: User should be able to look up frequency in dropdown by abbreviation Mar 31, 2024
@piyushmishra1416
Copy link
Contributor Author

Hello @brandones, could you kindly review this Pull Request?

@brandones brandones self-requested a review April 1, 2024 02:34
@brandones
Copy link
Contributor

Thank you for your work on this, @piyushmishra1416 !

Unfortunately, I think this ticket is much more non-trivial than I expected. I don't think we want to hard-code the frequencies, if we can avoid it. Ideally we would want to pull the abbreviations from the short names of the frequency concepts. These concepts right now are obtained using the orderentryconfig REST endpoint, which only includes display and UUID. The backend code for this endpoint is in OrderEntryResourceConfig. Looking at it, it kind of looks like one could pass a custom representation in the URL? But honestly I don't really know, and don't know how you would structure a custom rep correctly for this endpoint. But to start you could try adding a v=custom:(uuid) parameter to the request and see if the endpoint uses that parameter at all.

Requesting support from @denniskigen, @ibacher, or @mogoodrich. If it's too much of a pain I say we just hard-code the abbreviations (though we'll need to make it more robust to non-default metadata).

@mogoodrich
Copy link
Member

Thanks @brandones I agree we want to avoid hardcoding. What do we need beyond uuid and display? Can we build the order around uuid rather than abbrievations (sorry if the answer is obvious, I haven't dug too deeply into the code yet)

@brandones
Copy link
Contributor

@mogoodrich The thing we would need besides uuid and display would be the concept short names, which would be the actual abbreviations. The idea of this ticket is that we want to make it so the user can type an abbreviation into the input box and it will select the correct frequency concept. We do indeed build the order using the uuids.

@ibacher
Copy link
Member

ibacher commented Apr 1, 2024

Seems doable without even hardcoding the UUIDs per se, just changing how we load the order configuration to something like: /ws/rest/v1/orderentryconfig?v=custom:(uuid,display,names:(display,conceptNameType,locale)). That will get you all the concept names (unfortunately, it will load all the names for every concept, even ones where we don't want this feature). It seems like it's necessary to drop those that aren't in the current locale (but, I guess, include English if the current locale doesn't have any available names), but that should also include, e.g., "BID / TID", etc. for frequencies.

@brandones The short name isn't always the correct thing. For example, the short name for twice daily is "BD".

@brandones
Copy link
Contributor

Thanks so much @ibacher !

The short name isn't always the correct thing. For example, the short name for twice daily is "BD".

That's... odd. Should we forge ahead, and consider adding BID as a short name in the twice daily concept ?

@ibacher
Copy link
Member

ibacher commented Apr 3, 2024

consider adding BID as a short name in the twice daily concept ?

I mean, it makes sense to me. We probably need to talk to Andy about this, since I think we're just using a CIEL concept.

@brandones
Copy link
Contributor

@piyushmishra1416 Is it clear to you how to move forward with this, and will you move it forward?

@piyushmishra1416
Copy link
Contributor Author

piyushmishra1416 commented Apr 16, 2024

@piyushmishra1416 Is it clear to you how to move forward with this, and will you move it forward?

I am on this now @brandones. I was unable to fetch the short names from the backend. I was trying to work around this URL: /ws/rest/v1/orderentryconfig?v=custom:(uuid,display,names:(display,conceptNameType,locale)) and tried to fetch the short names using various combinations of this URL but unable to hit the correct URL. Could you please provide me some help with how to fetch the short names correctly? Thanks

@denniskigen
Copy link
Member

denniskigen commented Apr 19, 2024

We're you able to fetch the order frequency short names from the orderentryconfig endpoint, @piyushmishra1416?

@brandones
Copy link
Contributor

Yeah sorry for the lack of response from my end; this is not my area of expertise. Perhaps @mogoodrich would know how to get the custom: format right.

@denniskigen
Copy link
Member

Yeah. Some extra context:/ws/rest/v1/orderentryconfig?v=custom:(uuid,display,names:(display,conceptNameType,locale)) doesn't return an orderFrequencies property in its response, whereas /ws/rest/v1/orderentryconfig?v=full does. A custom: format would do the trick here.

@piyushmishra1416
Copy link
Contributor Author

Yes @denniskigen, I was getting the short names. ws/rest/v1/orderentryconfig?v=custom:(uuid,display,concept:(names:(display,uuid)) this URL does this task.

@piyushmishra1416
Copy link
Contributor Author

I have updated the PR. Please review it @denniskigen @brandones. Below is the attached video of the functionality.

feature.mov

export interface CommonConfigProps {
uuid: string;
display: string;
concept?: {
names: Names[];
}; //
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
}; //
};

@@ -34,7 +41,7 @@ export function useOrderConfig(): {
};
} {
const { data, error, isLoading, isValidating } = useSWRImmutable<{ data: OrderConfig }, Error>(
`${restBaseUrl}/orderentryconfig`,
`${restBaseUrl}/orderentryconfig?v=full`,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Were you not able to get it working with the custom format @piyushmishra1416 ? If not, please report the request payload size difference between the old call and the new one.

@piyushmishra1416
Copy link
Contributor Author

Fetching the data through this URL ws/rest/v1/orderentryconfig?v=custom:(uuid,display,concept:(names:(display,uuid)) only retrieves data for orderFrequency, not for other required data such as drugRoutes and drugDosingUnits. So now I have two options from here:

  • Either use this URL ws/rest/v1/orderentryconfig?v=full which has a payload of 870kb.

  • Call two different URLS; use the custom URL (ws/rest/v1/orderentryconfig?v=custom:(uuid,display,concept:(names:(display,uuid))) for orderFrequency and the other URL (ws/rest/v1/orderentryconfig) for the remaining fields.

What would be the correct approach to proceed from here @brandones ?

@brandones
Copy link
Contributor

Hmm, that is annoying. And that's a pretty big payload for full, so probably best to avoid that. I guess the ideal thing is to just modify the custom format to include whatever is needed for drug routes and drug dosing units. Do you think you can do that? Just look at what properties the default object includes and try adding those. You should only need to add the top-level properties, I think it will default to including the correct sub-properties for them.

@ibacher
Copy link
Member

ibacher commented Apr 26, 2024

What about using ?v=custom:(uuid,display). Still requires two calls (one to get everything else, then one to get the concepts for orderFrequencies)...

I'm inclined to think that this should be reported as an issue in the backend. The problem is that only the orderFrequencies have a concept property, so a request that has concept in the custom format will fail for most other categories.

@piyushmishra1416
Copy link
Contributor Author

What about using ?v=custom:(uuid,display). Still requires two calls (one to get everything else, then one to get the concepts for orderFrequencies)...

I'm inclined to think that this should be reported as an issue in the backend. The problem is that only the orderFrequencies have a concept property, so a request that has concept in the custom format will fail for most other categories.

Should I create a ticket for this @ibacher?

@ibacher
Copy link
Member

ibacher commented Apr 29, 2024

Yes, that's what I meant. It's a weird endpoint, so maybe there's a principled way to deal with this.

@brandones
Copy link
Contributor

In the meantime, can we do this for this PR so we can close it?

What about using ?v=custom:(uuid,display). Still requires two calls (one to get everything else, then one to get the concepts for orderFrequencies)...

@piyushmishra1416
Copy link
Contributor Author

Hello @brandones, can you please review this PR?

@denniskigen denniskigen requested a review from brandones May 7, 2024 17:42
@denniskigen denniskigen requested a review from ibacher May 8, 2024 23:29
@piyushmishra1416
Copy link
Contributor Author

Hello @ibacher, I fixed the changes could you please review the code?

@piyushmishra1416 piyushmishra1416 requested a review from ibacher May 13, 2024 08:36
@piyushmishra1416
Copy link
Contributor Author

Hello @brandones @ibacher @denniskigen, could you please review this PR?
Thanks a lot for your patience, guidance, and support on this PR.

@ibacher ibacher changed the title (feat) O3 2430: User should be able to look up frequency in dropdown by abbreviation (feat) O3-2430: User should be able to look up frequency in dropdown by abbreviation May 15, 2024
() => (menu) => {
return menu?.item?.names?.some((abbr) => abbr.toLowerCase().includes(menu?.inputValue?.toLowerCase()));
},
[],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is wrapping a function, its preferable to use useCallback() instead of useMemo().

I'd probably also do something like:

menu?.inputValue?.length ? menu.item?.names?.some((abbr) => abbr.toLowerCase().includes(menu.inputValue.toLowerCase())) : menu.item?.names ?? [];

And the complexity of that I think points to the fact that this shouldn't be a one-liner.

@ibacher ibacher dismissed brandones’s stale review May 17, 2024 18:48

Changes made as requested

Copy link
Member

@denniskigen denniskigen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@brandones brandones merged commit 0894ef4 into openmrs:main May 17, 2024
6 checks passed
@brandones
Copy link
Contributor

Yes!!! So glad to see this having made it across the finish line. I want to highlight that while often it's a bad sign if PRs get as old as this one, I think this is a clear exception— @piyushmishra1416 I really appreciate your responsiveness and collaborative effort as we figured out how to fix this one. That quick turnaround time makes a world of difference. Great work, much appreciated.

@piyushmishra1416
Copy link
Contributor Author

Thank you so much @brandones for your kind words and recognition. It means a lot.

@piyushmishra1416
Copy link
Contributor Author

I'm so happy that we have finalized this PR. It was a great team effort, and your constant guidance and support on this PR was invaluable. It was filled with lots of learning. Thanks a ton, @ibacher, @denniskigen, and @brandones for all your help and support.

denniskigen added a commit to kb019/openmrs-esm-patient-chart that referenced this pull request May 22, 2024
alaboso added a commit that referenced this pull request May 27, 2024
* (feat) O3-3156: Submitting the start visit form should mutate appointments (#1825)

* (fix) O3-2852: Fix the viewport size of the Start Visit form on tablet (#1765)

* Overlapping issue fixed in visit-form

* Make viewport height responsive - different values for desktop and tablet

---------

Co-authored-by: Mutesasira Moses <[email protected]>
Co-authored-by: Dennis Kigen <[email protected]>

* (refactor) O3-2626: Reuse useAllowedFileExtensions hook from Common Lib (#1827)

(refactor) Reuse allowedFileExtensions hook from Common Lib

* (feat) O3-3158: Conditionally render Patient Header in the Start Visit form (#1823)

* (feat) O3-3158: Visit Form should support (optionally) rendering Patient Header

* (feat) O3-3158: Visit Form should support (optionally) rendering Patient Header

---------

Co-authored-by: Dennis Kigen <[email protected]>

* (chore) Bump form-engine lib (#1828)

Bump form-engine lib

* (chore) Bump form-engine lib (#1829)

Bump form-engine lib

* (fix) Widen range to detect "current" data entry

* (fix) O3-3158: Follow-up commit fixing patientUuid sometimes undefined (#1831)

* (feat) O3 3128: Add extension slots to lab and drug order forms (#1818)

* (feat) Add slots to labs and drug form

* O3-3128 (feat) Enhance lab, orders and dispensing form with addition slot

* Fixup

---------

Co-authored-by: Dennis Kigen <[email protected]>

* (chore) Bump RFE version (#1833)

* Bump RFE version

* Update to next

* (fix) O3-3196: Fix diagnoses tags display on tablet (#1834)

* (fix) O3-3195: Fix rendering logic for the weight tile (#1835)

* (fix) return encounter type uuid from encounter type object (#1836)

return uuid from encounter type object

* (chore) Bump React form engine and yarn (#1837)

* (chore) Release v8.0.0 (#1839)

* (feat) O3-2430: User should be able to look up frequency in dropdown by abbreviation (#1767)

Co-authored-by: Dennis Kigen <[email protected]>
Co-authored-by: Ian <[email protected]>

* (chore) Release v8.0.1 (#1841)

Co-authored-by: Dennis Kigen <[email protected]>

* (chore) Bump react and related types (#1842)

* (chore) Bump react and related types

* Fixup

* Bump test deps to remove warnings

* (fix) O3-3158: Restore abortControllers

* Revert "(fix) O3-3158: Restore abortControllers"

This reverts commit 0895e27.

* (fix) O3-3158: Restore abortControllers (#1843)

* (chore) Bump react form engine

* (fix) O3-3175: Remove Breadcrumbs menu from Patient Chart (#1832)

* (fix)- O3-3175 Remove Breadcrumbs

* Remove translation strings

* Remove more occurrences of breadcrumbs

---------

Co-authored-by: Dennis Kigen <[email protected]>

* (feat) Update custom representation to match required properties for encounter observation (#1845)

* Make attachment upload modal span full-width

* (chore) Bump react form engine (#1846)

* (feat) O3-2626: Add the ability to upload multiple images in the Visit Note form (#1826)

Co-authored-by: Dennis Kigen <[email protected]>

* (fix) O3-3284: Display correctly formatted patient name throughout patient chart apps (#1849)

* Display formatted patient name in visit-header and patient-details-tile components

* Display formatted patient name in patient-banner component.

* Display formatted patient name in esm-patient-labs-app

* Display formatted patient name in esm-patient-medications-app

* Display formatted patient name in esm-patient-orders-app

* Display formatted patient name in esm-patient-vitals-app

* Bump core tooling

* (feat) O3-3165: Add confirmation modal when deleting repeat question (#1840)

* (feat): Add confirmation modal when deleting repeat question

* (refactor): register modal as extension

* (refactor): change modal registration name

* Bump form engine and core tooling

---------

Co-authored-by: Dennis Kigen <[email protected]>

---------

Co-authored-by: Mark Goodrich <[email protected]>
Co-authored-by: Madhu Lokesh <[email protected]>
Co-authored-by: Mutesasira Moses <[email protected]>
Co-authored-by: Dennis Kigen <[email protected]>
Co-authored-by: Samuel Male <[email protected]>
Co-authored-by: Ian <[email protected]>
Co-authored-by: Ian <[email protected]>
Co-authored-by: Donald Kibet <[email protected]>
Co-authored-by: Jamie Arodi <[email protected]>
Co-authored-by: Thembo Jonathan <[email protected]>
Co-authored-by: Piyush Mishra <[email protected]>
Co-authored-by: Vineet Sharma <[email protected]>
Co-authored-by: Bhargav kodali <[email protected]>
Co-authored-by: jwnasambu <[email protected]>
Co-authored-by: Gavin Falconer <[email protected]>
Co-authored-by: Nethmi Rodrigo <[email protected]>
arodidev pushed a commit to arodidev/openmrs-esm-patient-chart that referenced this pull request May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants