@mksd any documentation on how to use the module
@ssmusoke at this stage not more than whatâs on the wiki and its code base.
Whatâs your use case?
This is probably an interesting module for the Point of Care functionality that we are developing within UgandaEMR
1 Like
But whatâd be your use case? Location-based access, patient associated with providers, ⊠?
@mksd Role based access plus location based access to patient records. Depending on the role a user can only access different parts of the patient records
Hi,
Any more information on Data Filter module? Risks of liking protected data? We would like to restrict access to concepts to some User Roles. @ssmusoke, did you manage to use it in Uganda?
@stratosilva can you provide more details on your filtering scenario. Whatâs the business use case that youâre trying to solve?
Hi Dimitri, A first thing is Roles-based access to display controls: in the screenshot below, no access to patient info, medical history, previous medical history and physical examination to social workers role (this info has been entered by a doctor role).
I donât think we can achieve this with Data Filter because Display Controls are coming out of the box and they are not metadata in the OpenMRS data model (not concepts).
Second use case: Looking at Medical History Display Control⊠Could we hide concepts related to HIV (for privacy purposes) using Data Filter, again depending on the role of the user?
Hi @stratosilva,
Yes you can achieve all that you describe with Data Filter. Data Filter allows to sneak in Hibernate filters based on pretty much whatever criteria you may come up with.
Your first use case is: I want certain obs to only be visible to certain roles. The headline is totally ok and thatâs exactly the kind of thing that we do with Data Filter in one of our implementations. The challenge is not on the technical level of what Data Filter can or cannot do, it lies on the business analysis of your use case. Have you got a clear criterion to implement? The criterion here is about knowing why a certain obs needs to be filtered, as in which obs are the subjects to filtering.
The second use case is actually the same as the first one: you want certain obs (HIV-related ones) to only be visible to certain roles. And it will lead you to the same kind of business analysis: how do we know, looking at any obs in the system, that it is an HIV obs?
Filtering strategies can possibly be highly implementation-specific, this is why I stress all the above. Letâs take a few examples on the HIV obs that are all equally valid depending on your exact use case:
- An HIV obs can be identified as such because it was recorded during a type of encounter dedicated to HIV care.
- An HIV obs can be identified as such because it was recorded at a location dedicated to HIV care.
- An HIV obs can be identified as such because it is defined by an HIV concept. This pushes the question further: how do we know that a given concept is an HIV concept? There are multiple possible answers: because it is mapped to a specific HIV source, or because it belongs to a specific HIV set, ⊠etc.
- âŠ
I guess a couple of conclusions:
- I would be surprised that you find business rules that cannot be implemented through an Hibernate filter. In short: Data Filter will work.
- In depth business analysis is needed to properly define the criteria that nail your use cases.
- Data Filter is primarily used in situations where data protection is crucial. The HIV-related data use case matches this for sure.
- Data Filter will only work if the Java layer of your application uses Hibernate.
If you are a dev youâll ask me: why do you mention the last point, of course OpenMRS uses Hibernate! My short answer to that is: yes indeed, but beware of custom modules (Iâm saying that because you use Bahmni). See for instance this thread.
1 Like
Thanks for your elaborated answer @mksd
I am more an Implementer than a dev so I could use some more documentation on Data Filter. I checked the wiki and I am definitely missing some more info to help me get started. I was particularly interested in your statement âData Filter is primarily used in situations where data protection is crucial.â because this is exactly our use case.
I understand a bit of Hibernate Filtering works but I think this solution would be hardcoded or implemented in some config files therefore hard to maintain in the long run. Ideally we would need to have the sharing properties of Display Controls and Concepts (shown in the Display Controls) stored in the database so we would have an easy way to setup WHO (user roles or privileges) can access WHAT (concepts / display controls (bahmni)) and HOW (read, write).
Filter definitions are currently provided as a JARâs resources (see an example here shipped with the module itself) that means that itâs not very configurable but it is very maintainable. Maintainability is not an issue, such filters are fully tested through the module that ships them (for example here for the filter above). Configurability could be more challenging. But there are ways to improve this, those ways have just not been explored further simply because this was never prioritised.
Note however that some part of the filtering is fully configurable using Iniz, see here: https://github.com/mekomsolutions/openmrs-module-initializer/blob/master/readme/datafiltermappings.md
Sure. I would need to dive in the details of how those display controls are configured to come to a definite conclusion. My gut feeling about this Bahmni use case is that it should be possible to come up with appropriate filtering strategies without adding more information in the database as it is currently the case now.
Iâm still not clear on the exact use case, but if you want to do something like
one would need role A to see obs defined by concept Aâ, concept Aâ, concept Aâ, âŠ
then thatâs enough for a criterion, the only thing missing is the SQL filter definition (and some module to ship it.) Actually I guess that such strategy could be shipped as one of the handful provided by the Data Filter module itself (alongside encounters/obs filtering by privilege and patients filtering by location).