Background
One of the primary uses of OpenMRS is to collect data through clinical encounter forms (either HTML-based forms that are entered directly or through transcription of paper forms into the system). When a user selects a patient, they are taken to a patient dashboard, which includes a tab for form entry. Under this tab, the user is presented with a list of all available data entry forms in the system. When an implementation begins using OpenMRS and only has a few forms, this works well; however, as the number of available forms grows into dozens or even hundreds, it becomes difficult for users to find the form they need within the long list. Even more bothersome is the fact that, in many cases, there are forms that don't apply to the current user or patient (e.g., when a user who has selected a 40 year-old patient, they don't want to be bothered with pediatric forms designed for children in the list that are obviously inappropriate for their patient). As it stands, there is no mechanism within OpenMRS to restrict the list of available forms based on user or patient characteristics. The goal of this project is to add this capability and, in so doing, make a lot of OpenMRS implementations happier.
There are several contextual factors that could be taken into consideration when filtering the list of forms. For example:
- Patient characteristics like gender or age.
- User characteristics like their permissions or roles within the system.
- Location information (users working in Clinic X do not need to see forms specific to Clinic Y).
Requirements
- An administrator should be able to associate filter information with one or more forms.
- Users with the appropriate permission, should be able to relax the filtering (i.e., see forms without filtering).
- Filtering should be able to use contextual information (e.g., the currently selected patient and/or the currently authenticated user).
Assigned Developer
Goutham Vasireddi
Mentors and Other Interested Parties
Mentor: ~dkayiwa
Implementers
Ticket(s)
Design
- Create a table for form_filtering. form_id, form_filter_id. If a form's form_id is listed in this table, the associated filter MUST return true in order to be displayed in the list of forms
- Create a table for the filters and their parameters: form_filter. form_filter_id, class_name, properties (a key/value pairing)
- Create an interface FormFilter where the logic for each type of filtering will be stored. important method is "public boolean shouldDisplayForm(Patient p, User u)"
- Create an admin page for administrators to choose which forms get which filters
- The admin page should look for all implementations of FormFilter and allow the admin to choose one
- The admin page for each FormFilter should look at properties on the FormFilter to know what to ask of the admin
- answers to these properties are stored in form_filter.properties as "age=18,value=after" vs "age=18,value=before" (using AgeFormFilter as example)
- Create a GenderFormFilter that uses the patient's gender
- Create a RoleFormFilter that requires the current user to have a specific Role
- Create a PrivilegeFormFilter that requires the current user to have a specific Privilege
- Create a DateFormFilter that requires it be before or after a certain date to be displayed
- Create an AgeFormFilter that requires the patient be over or under a certain age
- Create a CohortFormFilter that is based on the patient being in the defined cohort – this should be added in by the ReportingCompatibility Module