Hi all,
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.
@pascal@mogoodrich
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!
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.
Background:
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
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
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.
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
or
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 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.
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.