OpenMRS Html Form Entry Module new features

The HTML Form Entry module gets new features with each and every new version of release to provide more functionalities to he users. The following is a simple note on the new features i was working on HFE module last few months.

1. HTML-348 : Allow checkbox styles for numeric observations

Earlier if a user need to enter numeric observations like numbers,quantities etc. there were only text boxes, drop down lists and radio buttons used in order to do it. With the new addition you can use checkboxes also to record numerical observations as well as to capture multiple numerical observations.

An example code segment in a form would be,

<obs conceptId="5497" answer="502" answerLabel="502" style="checkbox"/>
<obs conceptId="5497" answer="503" answerLabel="503" style="checkbox"/>
<obs conceptId="5497" answer="504" answerLabel="504" style="checkbox"/>

where it would generate this kind of a form as shown below.

2. HTML-92 : Handle checkbox style (multiple select) in single obs element


At past if a user needs to add two or more checkboxes as answers for a question concept it was needed to be defined one by one per each checkbox element as shown below.

<obs conceptId="1069" answerConceptId="664" answerLabel="No Complaints" style="checkbox" />
<obs conceptId="1069" answerConceptId="832" answerLabel="Weight Loss" style="checkbox" />
<obs conceptId="1069" answerConceptId="6029" answerLabel="Night Sweats" style="checkbox" />

However this is a tedious and time wasting job for the form designed therefore this new feature is added in order to provide the ability to define all the checkbox elements in a single tag definition.

The following is the format of how the new <repeat with=""> tag should be added in the html form.

<repeat with="[664,'No Complaints'], [832,'Weight Loss'],[5544,'Weight Gain']">
<obs conceptId="1069" answerConceptId="{0}" answerLabel="{1}" style="checkbox" />
</repeat>

An example form with multiple checkbox elements is as follows.

Down the lane with OpenMRS in GSoC 2012-Part III

It has been months after the GSoC 2012 finished and finally i managed to find time to write on the remaining tasks i did with my project :D Since it has been three months gone all the improvements can be found with the latest releases of HFE module. 

3. HTML-247 : Exit from care tag

Another newly created tag to the module tags list which is used to record the scenario when a patient exits care center. It operates in a similar manner to the exit from care functionality on the patient dashboard, providing a date field  and a reason dropdown to the user. Exiting a patient from care is not mandatory, however once the fields are filled out and submitted for a certain patient, the exit can't be undone, hence the fields can't be set back to empty. However it is possible to edit the date and reason fields.The possible reasons for exiting care are specified by setting the global property concept.reasonExitedCare. This should point to a question concept; the associated answer concepts will be used to populate the reason dropdown presented to the user.

• To exit a patient from care, the date field should be set to the date of the patient's exit and the reason dropdown set to the reason for the patient's exit selected from the list of given reasons.

If the patient is dead, the tag can be also used to mark a patient's death, by recording the cause of death in the additional dropdown that pops up. The user needs to select the reason dropdown answer as "Patient Died", then a new dropdown will be visible for the user to enter the 'Cause of Death'. The possible causes for patient's death are specified by setting the global property concept.causeOfDeath. This should point to a question concept; the associated answer concepts will be used to populate the cause of death dropdown presented to the user.

• To mark a patient as dead, the reason field should be set to Patient Died and the cause of death dropdown set to the cause for the death selected from the list of given causes.

If the exact cause is not given in the cause dropdown,  select the 'Cause of Death' dropdown answer as "Other Non-coded", as there will be another text field visible to manually enter the reason for the death. Here the user can type any of the reason,description etc. which caused the patient's death. 

Once the cause of death and other reason text fields are filled out and submitted for a certain patient, the death obs can't be undone. However it is possible to change the reason for exit field back to an answer other than "Patient Died", so the exit observation can be edited back. Then it will not display the death fields' entries but the death obs still exists. It is also possible to edit the cause of death and other reason fields too.

If things are not clear yet, here is a snapshot of what you can have with the <exitFromCare> tag.

 Go to the wiki page description from here.

So this was the end of my awesome GSoC time period with OpenMRS. The following is the complete project page of 'HTML FormEntry Module Enhancements' and the link for the final video demonstration is given below.

Final Demonstration Video : http://www.youtube.com/watch?v=u6pdK1J1oxk

Actually we were planning to work on few more tasks during this summer but had to halt one unfortuantely due to time constraints. Anyway this will not just be the end, though the GSoC ended neither did my contribution and engagements with OpenMRS :) More on them in the coming posts.....!

Down the lane with OpenMRS in GSoC 2012-Part II

The next task i was assigned is,

2. Creating a new tag to restrict all (or part of) an HTML Form by role 


The <restrictByRole> tag is the next newcomer to the HTML tag base of Form Entry Module. This feature is concerned to be implemented in a way that, some user with a particular role can be restricted from either viewing a certain HTML form (or a section in the form) by using the <restrictByRole> tag. The tag comes with two attributes as "include" and "exclude" where you can mention the names of the roles for whom you want to include or exclude the form restriction.

As an example if you don't need to make a certain table in your HTML form to be viewable to a Person which has "Data Manager" role assigned to him/her, you form description would be as follows,

<restrictByRole include="Data Manager">                   
  <table>
   <tr>
       <obs conceptId="6100" labelText="Restricted for Data Manager"/>
   </tr>
  </table>
</restrictByRole>

So this table would not be shown to any person with the 'Data Manager' role but only to the users who belongs to that role.
In the same way this can be used with "exclude" attribute, in where the corresponding section would only be not restricted to the mentioned role.

An example form would be like,

1.0 These rows in the table are not restricted for the user Admin, who has "System Developer" role

2.0 If a user who is not a "System Developer" opens the form, if would look like this

That is where we are heading towards at the moment. There are two more tasks to do during the summer so i look forward for those also very enthusiastically!

Down the lane with OpenMRS in GSoC 2012 ..............

Time flows lot faster and i can't believe that it has almost come up the time for GSoC mid evaluations too.  I did have a quite busy but amazing time of two months so far with GSoC where it helped me to learn about many new things and technologies. So thought to have a little flashback on the things done so far.

The following are the tasks which i have already finished by the time of mid evaluation for this GSoC with HTML Form Entry module in OpenMRS.

1. Add autocomplete search functionality to encounter provider and encounter location widgets in HTML Form Entry

There are a lot of names as locations and encounter provider persons  in the system where it is displayed in a drop down list of options at the current module, but due to the long list of options it will be time taking to load and submit the location and provider values with the HTML form. 

At present, HFE module provides auto complete functionality with the <obs> tag, (stands for observation entries), where it does follows the JQuery AJAX calls to populate the source for the auto complete. However this feature is tightly coupled for Concept classes and ids, therefore it is not reusable for the Locations and Providers. The intention of my task is providing a generalized auto complete mechanism through out the module, which uses a pre-populated list of options as the source and which can be used with any other field (as DrugOrder etc.) in the future too. 

Encounter location and provider have been implemented by having two dedicated widgets for each such as, LocationWidget (for <encounterLocation>) and PersonStubWidget (for <encounterProvider>) tags. In addtion to that there is another encounter provider is introduced with htmlformentry 1.9 onwards which too uses a dedicated widget named ProviderWidget with <encounterProviderAndRole> tag. The intention of the task is replace the dedicated  widgets for location, provider etc. and implement a common auto complete mechanism over the Html Form Entry module by just using AutoCompleteWidget and the DropDownWidget for the fields. In that case when a user needs to add auto complete functionality into any other field, it can be easily done by using the new, generalized AutoCompleteWidget.

Here are few of the snapshots from new functionality!

 

 

 

 

 

 

 

And also it works with Options which has special characters like ã,é etc. and which have double quotes,single quotes in middle too :) Auto complete functionality is added into <encounterLocation>, <encounterProvider> and <encounterProviderAndRole> usingthe new AutocompleteWidget and LocationWidget and ProviderWidget in the module is replaced with the new AutocompleteWidget or a default DropDownWidget, hence they have been deprecated for future occurrences. 

The following is the link for the demonstration video i did regarding this new functionality at the second GSoC progress presentation at OpenMRS on 21st June 2012. The next post will explain the second task i have completed. I am eagerly waiting to see my changes have been integrated into HFE module soon :)

GSoC 2012 Autocomplete Demo

The presentation slides can be found Here!

How to Install Eclipse Indigo 3.7 in Ubutnu 11.10

This is a brief tutorial on how to install Eclipse Indigo IDE 3.7.0 in Ubuntu 10.10. Downloading and installation is straight forward but many users might have difficulties in opening and running eclipse as not setting the JRE/JDK path correctly. Let's see how this can be done.

1. First download the Eclipse IDE (I selected Eclipse IDE for Java EE Developers) from http://www.eclipse.org/downloads/ page. Download either 32 bit or 64 bit version from a suitable mirror from the selection.

2.This will download 'eclipse-jee-indigo-SR1-linux-gtk-x86_64.tar.gz' package into your computer. Extract the package to a location in the hard drive.You will see that 'eclipse' directory is being created after the extraction. 

3.Open 'eclipse' directory and there will be following files and directories. Click the 'eclipse' executable icon. 

Fig.1: contents in the eclipse directory

4.If all the configurations are correct, the IDE will be started by clicking this icon and you can just start coding etc. But in most of the cases it will not start at first time and you will see the following error message. 

"A Java Runtime Environment (JRE) or Java Development Kit (JDK) must be available in order to run Eclipse. No Java virtual machine was found after searching the following locations:[SOME PATH IN YOUR COMPUTER] java in your current PATH" 

Fig.2: JDK or JRE path missing in eclipse

5. This error occurs mainly because of the IDE can't find the correct path to the JDK or JRE in our computer. Therefore we have to explicitly configure the path to JDK or JRE in the IDE configuration file. 'eclipse.ini' is the initialization file which carries out important configurations to run eclipse. This file can be found in our eclipse_home directory (See the figure 1 to identify eclipse.ini file).

6. Open the file in a text editor and add the following lines to the beginning of file. Replace the '/usr/lib/jvm/jdk1.7.0/bin' path with the PATH to JDK_HOME/bin in your local computer. Then save the file.
 -vm
/usr/lib/jvm/jdk1.7.0/bin

7. Now we have configured JAVA path for the Eclipse IDE. Click the 'eclipse' icon back and this time it will start the IDE successfully. Happy coding :)

Fig.3: Eclipse Indigo 3.7.0