I am Milinda Rukshan, a final year Undergraduate IT student from Sri Lanka. I am interested in applying for above project in GSoC '16 and currently working towards it. I followed the developer guide instructions to set up my env and get an idea about this module. I have already set up the OpenMRS and running. I hope to improve this module to support the discussed features in the project page.
The first thing i noted with the module is, when i uploaded it, from the very beginning i see the UI like below. (Note the duplicated ‘Patients Flags’ section) Can some one tell me whether this is a bug or a my fault? I am using patient flags version 1.3.4 in Windows 7.
The default view of module is, there are no existing flags as i saw and we have to create if needed. So in order to focus on ‘Add more default display points’ feature of the project, i would like to know what is meant by default display points? Current document provides a code to create display point but i am unclear what is the use of display points etc. Can any of you briefly explain pls.
Looking forward to learn more on the module using this time. Thanks!
Hi @pascal, @surangak, @mogoodrich ,
I’ve been meaning to write this message for over a week but I figured it would be best if I post it with all the details and ideas I have collected and maybe we can brainstorm over them.
Having been involved in the OpenMRS developer’s community for quite a while, I’ve been highly active on Talk, IRC, Fixed quite a few issues and attended Design and Dev calls as well.
Here is a comprehensive list of my contributions and community interactions. I hope this qualifies me as a fairly good applicant
Now, coming to the point, I’m really looking forward to the project ‘Patient Flags Module Enhancements’ along with developing ‘REST for the Patient Flags module’. I believe that we can work with these 2 projects in conjunction and merge them into one.
I’ve collected certain ideas that I’d like to share with you, even though they are unstructured at the moment. I have spoke to @mogoodrich and @ayeung about the same. Having worked with both of them in the past, they were extremely helpful and provided me with some great insights and ideas.
My main objective is to make the Patient Module highly ‘Patient Centric’. Here are some of the thoughts on the module and how we can improve them.
Create a bootstrapped UI which is simple to use and gives the user plenty of ways to create custom flags and triggers. This will be one of the main highlights of the project. I am looking to take inspiration from the Cohort Builder module.
Add a set of highly generic but useful flags (which can be enabled or disabled on the user’s discretion) which will match data/concepts to check directly with WHO standards. Let me explain. Suppose you have an extremely malnourished child. It will check the concepts associated with the patient and match with WHO standards, and then determine whether to raise an alert or not. This can be done for several diseases/ abnormalities such as blood pressure, diabetes etc.
For extending via REST, the code is to be written in the the omod component of the Patient Flags module. We could follow the pattern laid out in the REST web services module (naturally). A very similar task (e.i adding a REST API) was also undertaken for the Appointment Scheduling Module. The relevant code can be seen here. We can how a “Resource” class was created for each of the core Appointment Scheduling domain objects.
I hope you found these ideas worthy and I’d really be up for discussing some of the ideas you have in mind as well and brainstorm over it further
EDIT: As it so happens, I also brought the discussion of this module during today’s developer’s meeting here ( 2016-03-03). You can see the details in the notes.
Hoping for some positive feedback and lot’s of brainstorming
Thanks for the summary @bholagabbar
It comes to mind that it would be very helpful to make a UI Framework fragment/widget that you could include on a page to display relevant flags within the “UI 2.0” context. I could help with coming up with this requirement.
Awesome! It’d be great if you could tell me what you had anything specific in mind so I could probably start learning and hacking into it straight away!
Hey @mogoodrich. I’ve been playing around with the module over the weekend and there are a couple of improvements that come to mind.
1 . We should setup the UI in such a way that it becomes easy for the end user to add a custom flag without much knowledge of SQL, Groovy or the like.
We can incorporate commonly used formats for extraction from the database and represent them an easy to understand way in the UI. For eg, if the flag is a logic flag,
"CD4 COUNT" > 200 after 2009-02-03 then we can create a tabular UI which lists all the individual parameters in the queries into columns and extend this to to cater to several logical queries of of the same kind. Hope I was able to convey my idea,
2 . To support my previous idea, we can actually work on picking up features/integrating the Cohort Builder module (I had mentioned this in my initial post). Suppose we want to add a flag on patients with a particular flag/between certain encounters, we can make it very easy for the user to see which patients have to be added. We can show the user what he wants to add. Maybe even add a feature to import them to a sort of dashboard where the user can add the patients from. Have a look at the image below. Something similar (taken from the cohort builder)
3 . It would be highly beneficial if we created some sort of clickable drop down buttons which would actually help the user create flags and priorities without referring to the documentation (which is great but still sparse IMO). We should try and abstract it to an easy to use and understand level as much as possible. Otherwise, the purpose behind creating such essential tools gets lost because people in practice might not be able to use them
Also, in context of your previous comment, do display relevant flags in the 2.0 context (I’m assuming we’re shooting to get this module to work on OpenMRS 2.0+) I believe the steps involved would be to first add the dependencies and then finally create a UI that smelts with that of the ref app/new UI of OpenMRS.
What do you think?
I just finished writing up a proposal for the Patient Flags module REST API. I shared with @pascal for feedback, I will love to get your email so I could share with you too. In the mean time. I am still drafting up the Patient Flags module enhancements. I’ll share with you when I’m done.
For some reason I thought we already had the concept of a Cohort Flag in the module. If not, then I definitely think we should add it. Basically, we should be able to create a Cohort Definition using the existing Cohort Builder functionality, and then just test if the patient is a member of the cohort to determine if the flag should be shown.
Display Points vs Trigger Points
I had a question in private about this, so I will try to address it here (@jteich may need to correct me). The concepts of trigger points and display points are somewhat related, but there is a subtle difference (not currently implemented). In my view, a display point is just a location on the page where a flag is shown. A trigger point is an action that results in some flag being evaluated (and potentially resulting in some action such as showing a flag at a display point).
So, for example, when you open the patient dashboard and see some flags in the header, the trigger point is opening the patient dashboard, and the display point is the header of the patient dashboard.
Other examples that we could potentially implement:
- Trigger point: Filling in a form for encounter type X
- Display point: Global message displayed in the app header when user Z logs in or IM pushed to user Z
- Trigger point: Patient <2 yrs old arrives at facility (detected via registration encounter or vitals being captured)
- Display point: Notification pushed out to provider (or displayed on form in real time) if patient has not received all required vaccinations
The important thing about the above two examples is that we don’t rely on a user opening the patient dashboard to be notified of something.
Regarding the Cohort Flags, what I meant was to try and make it easy to search up patients that we need to add a flag for. Would it be wise to assign a cohort flag to all those patients that we have searched for? I was only looking to use the cohort builder for it’s great search functionality.
I’m not still quite sure how you’ve interpreted display points. Trigger points i guess are evaluated against everything in the system and whenever some new encounter/patient data is added and then triggered. Display point…it seems to be just a sort of notification to me.
@mogoodrich may have to correct me here, but my understanding is that flags are not assigned to patients. You create a flag definition (which, when evaluated returns a list of patients), and then when the flag is evaluated (trigger point), if the given patient is in the list returned, the flag is displayed somewhere (display point).
Yep, @pascal is correct, flags are not assigned. I started writing up a summary, but kept rewriting it and then determined that what I wrote in the wiki years ago was still the clearest…
“A flag is simply some criteria (stored in a string), and an associated message string. Whenever a Patient Dashboard is loaded, the selected patient is tested against all enabled flags in the system, and for all flags that evaluate true, the associated message string is displayed. The message string can be simple string, or a code for a localized message stored in message.properties.”
I can see the confusion, perhaps “flag” isn’t the best name, because you can’t “flag a patient”, which would apply associating it with that patient. This is also something I could see wanting to be able to do, because you might want to trigger an action when a patient is “flagged”, ie when a flag first evaluates to true, but not every time is evaluates to true. (Like sending out an email when a patient have gone more than a year without a primary care visit).
I just submitted my proposal for this project. I will be happy if someone could review.
Thanks everyone for your proposals. I will get around to reviewing them all and providing feedback this week.
I added some comments to the proposals by @zakaria.amine and @ch3ck. Although, @ch3ck, your proposals are already marked as
Complete on the GSoC website, so I don’t think you’ll be able to make any changes.
@bholagabbar did not submit for this project, and I don’t see proposals from @milindaruk or @ajaipreetg either.
Thanks for the reviews @pascal. I’ll make the recommended modifications.
Continue discussion in #dev, #software:add-on-modules, or request a new category