For many implementations, we are seeing requirements for restrictions at data visualisation/access for users.
Example: Only specific care takers can access information of patients treated for HIV/AIDS/STD, Mental Health etc.
The requirements are often at encounter or program level. Some of the encounters are confidential, others are viewable without specific access. meaning - show info in general, other than those relevant for specific encounters bearing specific observations.
While in Bahmni we can model this at the patient level (a custom patient attribute), doing it at specific encounter level is not possible at this point.
I am wondering how we solution this. Suggestions are:
Do it at form level - Any data captured through specific form are marked as confidential. We wouldn’t have a way to store levels in the database though.
I am tending towards the 1st option. But this would mean change onto OpenMRS platform. Wonder if such requirements ever came up in Core, and/or others are coping with such requirements.
@angshuonline, openmrs-core had support for “view privilege” and “edit
privilege” on encounter types, which are intended to be applied to
encounters of those given types.
But the rest of the API does not generally respect these.
EncounterService.getEncounter(Integer) does, but search methods and getting
an encounter via a visit do not. IIRC in the legacy UI they were handled at
the UI layer on the encounter/forms screen.
So, the current OpenMRS core API does provide a way to do this (predating
FHIR), equivalent to your idea of doing it via forms.
(I’m typing this offline so I can’t look up how FHIR’s
encounter.confidentiality works and I can’t comment on how comparable it
is.)
I think “confidentiality” is much broader than just privileges here and also how FHIR defines confidentiality.
FHIR “confidentiality” is actually defined at the “Composition” resource level. OpenMRS encounter resource does not map to a FHIR encounter. In Bangladesh, we represent a “composition” bundle to an openmrs encounter and collection of all relevant resources within that encounter.
I think its beyond an encounter type. The encounter type can still be “OPD consultation” but the contents (or part of it) generated within the encounter would be confidential. Its does not seem right to put the same privilege restriction for all “OPD consultation” types.
Also in FHIR, the confidentiality has multiple levels - unrestricted -> low -> moderate -> normal -> restricted -> very restricted. Based on the level, and depending on profile of the person wanting access, applications can decide whether to allow access to the informations or not.