The HTML Form Entry module allows anyone with basic HTML skills and a knowledge of the OpenMRS system to create forms to enter and edit patient data within the system. It allow users to write forms using HTML combined with a set of special tags that reference different aspects of the OpenMRS data model.
The tags provided by the module has been steady expanding with each new release, but there is consistently a backlog of new tags and improvements to existing tags that the community has requested. This main objective of this GSoC project is taking on some of these suggestions into action.
The following are the improved features/new features that has been added into the Html Form Entry with this project.
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 addition 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.
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 exclude="Data Manager">
<obs conceptId = "6100" labelText="Restricted for Data Manager">
So this table would not be shown to any person with the 'Data Manager' role but only to the users who doesn't have that role. In the same way this can be used with "include" attribute, in where the corresponding section would only be not restricted to the mentioned role.
An example form would be like, as,
<restrictByRole include="System Developer">
<obs conceptId = "6100" labelText="Not Restricted for System Developer">
A new tag to the module tagbase which is used to record the scenario where a patient exits care. 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.
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.
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.
The mid-term video demonstration of the project:
The final video demonstration of the project:
The mid-term presentation of the project:
Module documentation with the new features: