My friend @rajprakash34245 and I have been contributing to OpenMRS for the past 3-4 months. During this time, we came across this project that truly got to us, clinicians struggling to find the medications or diagnoses they use every day, scrolling through endless lists and wasting precious minutes that should be spent with patients.
We wanted to tackle this problem and help the OpenMRS community whatever way we can.
The issue is with Favorite-ing for Orders and Diagnosis Options, a feature that would let clinicians mark and instantly access the orders and diagnoses they use most, cutting out all that frustrating searching.
We’re truly passionate about building a solution that makes a real difference. We believe this feature will transform how clinicians work and bring meaningful improvement to healthcare facilities relying on OpenMRS.
We’ve done thorough research (thanks @ibacher for the helpful suggestions!) and attached a detailed document outlining our findings and proposed approach. We’d truly appreciate your time and feedback on this.
We’re very excited about the possibility of working on this and contributing further to the community!
We wanted to quickly share our current thinking on a few implementation aspects and would really appreciate your feedback on the approach we’ve taken:
Single Record & Unique Constraint: Planning a single record per user per orderable (UNIQUE(user_id, orderable_uuid)) to handle both manual favoriting and future auto-population (usage-based) in the same row.
Handling Retired Drugs: Retired drugs would be filtered out at display time but kept in the database for audit/history, and would automatically reappear if un-retired. Still exploring the best UX (separate section vs optional view).
Caching Strategy: Using useSWRImmutable with long-lived cache for favorites, since they only change on explicit user action, and invalidating via mutate() after star/unstar.
Module Delivery: Considering an esm-favorites-app for the frontend (within patient chart) and backend support in core, but open to better placement suggestions.
We’d love to hear your thoughts on whether these approaches align well with OpenMRS patterns, and if there are any pitfalls or preferred alternatives we should consider.
How about starting with some sort of proof of concept which stores data as a JSON string in the existing user_property table? The advantage of this is that you would not need to have any backend skills required for creating the backend module and hence quickly come up with an MVP that can be evaluated for feedback. It is during these evaluations that we could determine whether we actually need a new backend module for this, basing on the actual problems that you will have faced while using the existing user property table. That way, we would avoid over designing this by starting with the simplest solution that works.
For the initial implementation, manual favoriting makes sense.
For future iterations, I think it would be valuable to have the system suggest the most prescribed drugs to make it easier to build clinicians’ favorites without having to remember which drug is which.
I am also wondering if the system could support auto-population based on usage patterns (like build a suggested favorites list) - but allow clinicians to accept/reject.
Also, since prescribing patterns evolve (e.g., with new protocols), we need to think of how to keep favourites current.
@ckote@kmuiruri@PalladiumKenya Early feedback on this feature is much welcome. If I recall correctly, this was one of the requests from one of your implementations.
