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