UgandaEMR: Use cases for the Data Filter module

Not a comment on why this isn’t working, but you really don’t want to use a prefix wild-card here (the first %) and the second is maybe questionable. This is because prefix wild-cards remove the ability of databases to use any indices on the column, guaranteeing that you have to scan every row in the appointment_service call.

To add to @wyclif’s point, nothing in your filter is going to hide patients, unless you’ve got another filter you’re not sharing? That filter is explicitly applied to Appointments (and patient search is only filtered through FullText filters, so most likely there some other error that’s making the patients hidden from patient search).

1 Like

Thank you all. @ibacher @wyclif, it seams i had not disabled the datafilter_locationBasedPatientFullTextFilter

That said, i have successfully been able to create the filter using this and this so we can move forward by updating the documentation as we improve the logic Feel tree to comment on the commits this and this PR

I had done something like apts.name != 'Mental Health' but this didn’t work Maybe apts.name NOT LIKE 'Mental Health%' might be a better option

1 Like

Below are the steps i think need to be added to wiki.

Qn.

How to add a filter to the datafilter module without forking.

Answer

  1. Add the datafilter module into your distro using maven like here
  2. exclude all the filters appended to the datafilter module by default (unless you need them). For example, see how all filters were excluded using global properties and the initializer
  3. Create a custom module and add the datafilter module like here
  4. make your custom module depend on the datafilter module like here
  5. create your filter in the directory api/src/main/resources/filters/hibernate/filter_name.json like here
  6. append the filter to the omod module file as a resource to the build see this
  7. implement the DataFilterListener like here
  8. Your filter will only execute if DataFilterListener.supports returns true hence ensure that truly result like here
  9. Add parameters if any are specified. You can use the ImplDataFilterListener for a better context on how that can be done.
  10. add the custom module to your distro using maven
3 Likes

Right it out a little more narratively and a little less FAQ-like, i.e., just create a section “Adding a filter from an external module” and add it to the Wiki.

@wyclif @ibacher Can we use the data-filter to filter out some form fields tagged too sensitive?

Sample use case:

A psychiatrist, will capture all observations, including the most sensitive ones in a form, but a counselor should not see fields marked as “too sensitive”.

FYI, I am aware that this requirement is also achievable using privileges and the form buildershideWhenExpression like

“hideWhenExpression”: "isUserHavingTooSensitivePrivilege()"

However, we wish to explore this use-case using the data-filter if possible.

Can we use the data-filter to filter out some form fields tagged too sensitive?

If you mean filtering out the actual obs, yes. If you mean removing the field from the form, that’s what hideWhenExpressions are for.

Note that removing a field on a form can have a lot of implications for the form, i.e., ensuring that the field isn’t required if it can’t be shown, ensuring any dependent fields are also hidden. It’s the job of the form engine to sort that out.

1 Like

Form fields being persistent entities themselves, yes you can use datafilter to hide them if hideWhenExpression does not meet your use case.

Form fields

@wyclif @ibacher one thing that confuses me is how we shall tag these sensitive fields. Each form only specifies a single encounter-type so all observations created (sensitive and non-sensitive) will refer to the same encounter-type.

In otherwords, there is no way to assign a question in an ampath form a specific encounter-type which can have a sensitive privilege.

Sample form below

{
    "encounterType": "some_uuid",
    "pages": [
      {
        "label": "Privilege-based form fields using data filter module",
        "sections": [
          {
            "label": "First page with fields available to all users",
            "questions": [
              {
                "id": "sampleQuestion",
                "type": "obs",
                "questionOptions": {
                  "rendering": "textarea",
                  "concept": "fa8fedc0-c066-4da3-8dc1-2ad8621fc480"
           ...
          },
          {
            "label": "Second page with fields only allowed for users with privilege 'Sensitive Data Access'",
            "questions": [
              {
                "id": "diagnosis",
                "label": "Diagnosis by the psychiatrist",
                "type": "obs",
                "questionOptions": {
                  "rendering": "multiCheckbox",
                  "concept": "da33d74e-33b3-495a-9d7c-aa00a-aa0160",
                  "answers": [
                    {
                      "concept": "da33d74e-33b3-495a-9d7c-aa00a-aa0148",
                      "label": "Violence-related injuries",
                      "conceptMappings": []
                    },
                    {
                      "concept": "a33d74e-33b3-495a-9d7c-aa00a-aa0125",
                      "label": "Sexual violence",
                      "conceptMappings": []
                    }
                 ....
    ],
  }

which approach would you use @ibacher @wyclif

Why would sensitivity of questions be driven by encounter type? My gut reaction is that the sensitivity of a question depends on the code attached to the observation. But, again, data filter is not the right tool to try to control what is shown on a form. You should use the form engine for that.

If you mean concepts, they seam not to have any relationship with the privileges hence it looked like a dead end applying the data filter

Noted. Thanks @ibacher

Thanks for sharing this @jnsereko

Would this be the same path for a use case like

  1. Restricting a Doctor from accessing Billing and Laboratory, but access Service Queues, Appointments, wards and Patient Lists
  2. A Lab tech can only access Lab
  3. A Nurse can only access Registration App, and patient Queues.

Based on roles and privileges rather than location ?

cc @jonathan / @ibacher

DataFilter is a good fit for restricting users from specific data. It’s not a good fit for restricting users to specific apps, but the frontend already should support that via configuration (you’ll need to add appropriate privileges to your OpenMRS configuration and ensure they are assigned to appropriate roles).

1 Like

Centrally in one place like esm-core or we do this for every frontend we need to restrict access around ?

Basically the framework allows you to hide things for each extension point.

1 Like