Validating/linking encounters/forms, patient identifier types, program enrolments?

Often the OpenMRS data elements for forms/encounters, patient identifier types, program enrolments are used together for specific patients. E.g. a patient enrolled in the program ‘HIV program’ also needs to have a specific patient identifier type set or a particular form (like HIV intake) filled out. Entering one part of this, but omitting the other will lead to inconsistent data.

Is there an automatic way to enforce this kind of validation/data completion across ‘different OpenMRS data elements’ (and leave it not up to the user to remember it)?

I am not sure whether this exactly answers your question. But we are working on introducing program attributes in OpenMRS where we intend to capture program specific details like program-specific-patient-id at the time of enrolment. This is planned in 0.79 release.

I am also not sure if I am answering your exact question, but in observation forms one can define conditions to enabled / disable certain fields based on specific logic. See an example here:

Maybe this can help you in some cases.

Yes. These conditional forms are also helpful.

My initial question might be boiled down to the program enrolments. Often multiple OpenMRS logical data elements (not sure how to call them otherwise) need to be entered for specific types of patients. Mainly elements like patient identifier, program enrolment, and certain forms.

So a HIV patient enrolled in the HIV program might be assigned with an HIV patient identifier as well as an intake form is required. Without these part the logical data entry for the registration is not completed and any additional data entry (like follow up visits shouldn’t be possible). If the UI is not enforcing the data entry of these elements, the user might end up doing one, but not the other (and therefore creating inconsistent/invalid data).

Another example is a patient who was transferred out of the HIV program (became ‘inactive’ for a certain clinic). It shouldn’t be possible to enter a visit form for this patient as long as he is not re-registered/transfered-in again.

There is a configuration for “required” fields, which you can set in the config. This along with conditional rules might help you in achieving some of your requirement. I have not tried this yet though.

If I understand you scenario correctly, you would like to be able to ensure that a user does everything related to enrolment of the patient in a program. Usually it means:

  1. enrol in a program, with enrolment level details
  2. fill the intake form in the program

Since these are handled in two separate user transactions, how would one ensure the user also does 2 if he does 1. I also think this is one of the scenarios - another scenario could be that the intake date should be before follow up date. Again since these would be part of two different user transaction how do we do such validation.

While the scenario I gave above can be handled in Bahmni by Groovy rules, which would prevent follow up date before intake date. The example one provided by you doesn’t have a direct solution. One way to resolve this would be to run data quality tests to find out such discrepancies. This also points to the tension between product (and its choice of modularity) vs custom application (that can be made for the purpose).

Yes. This is the most common scenario (although there can be more complex ones).

And you are right. As this is often not even part of the same activity (or even done by the same user), this can not be controlled by ‘technical transactions’. You can not ensure that #2 is done right after #1, but you can make sure that unless #2 is done, there won’t be any further data entry.

I think for now I will go with simple rules as much as possible and try to define (or at least outline) data quality reports to catch these inconsistencies.

And I also agree about (generic) product vs. custom application. Yet I often see different ‘workflows’ at the clinics where various activities need to happen in order (often in terms of different encounters/forms, but also as discussed here).