Scheduled events not reassigned correctly after patient transfer on Android v3.2.0

Development - Développement SDK - Android Development
,
1

Description:

There appears to be a bug with the ‘Transfer’ feature on the DHIS2 Android app v3.2.0.

When transferring a patient from one facility (Org Unit A) to another (Org Unit B), the ownership of the patient is correctly reassigned. However, the scheduled event(s) (e.g., a follow-up visit) remains assigned to the original facility (Org Unit A).

As a result:

  • Users in the receiving facility (Org Unit B) cannot update the scheduled event.

  • A sync error occurs stating:

    User does not have write access to Organisation Unit A

This issue seems specific to scheduled events, as other parts of the patient record appear to transfer without issues.

Steps to Reproduce

  • Log in as User A (assigned to Facility A).

  • Transfer a patient to Facility B using the Transfer feature.

  • Log in as User B (assigned to Facility B).

  • Attempt to update a scheduled event for that patient.

  • Observe sync error.

Actual Result

  • Scheduled event remains assigned to Facility A.

  • User B gets sync error and cannot edit/update the event.
    (See picture attached)

Expected Result

  • Scheduled events should be reassigned to the new Org Unit (Facility B) along with patient ownership.

  • User B should be able to update the event without permission errors.

Environment

  • App Version: DHIS2 Android Capture App v3.2.0

  • User Role: Data Capture / Data Entry

  • Transfer Context: Both users are within the same district and part of the same user group.

image
image307×630 47.6 KB

@FerdyR @Rohit

I have opened a jira issue for this with a video attached showing more details. Here’s the link below:

1 Like
2

Hi @Msoo

Thank you for the detailed post. Just to keep this thread up to date, you can see the suggested fix in the ticket:

Fix
To align with web behavior:

Users should not be able to open schedule/overdue/skipped events if they don’t have access to >that OU (“enter event” button blocked) —> TBD UI change with @Marcos Campos

Open/Completed events can be open but the edition of them will depend on the access*

Notes:

*Access to the event is given by: the user’s capture org unit and also to the stage sharing >settings

** Scheduled events will be handled in ANDROAPP-7150: I cannot select the health facility >while making the schedule.

And quoting @nancyesp comment here:

Hi @Msoo Gber !

Thank you for the report. Thea team is currently analyzing the best approach to solve the issue, >and will be target to our next release in November.

Thanks!

1 Like
3

Hi @Gassim

I have checked the V3.3.0 released and I dont seem to find the fix to this issue. I don’t even find the ‘Transfer’ feature anymore. See screenshot attached.

Was there a replacement for this? Or do we have a new target version for this issue?

Thanks

No transfer
No transfer540×1170 54.2 KB

1 Like
4

Hi @Msoo, I apologize for the late reply.
Regarding the initial part of the post, there are two things we did in order to resolve this.

1- Modified the logic for creating and scheduling new events so that the default org unit used is the owner org unit instead of the enrollment org unit.
2- Displaying a message for previously created events in the original org unit if the user does not have access to the org unit the event was created in as well as not allowing the user to navigate to it, unless it has read only access and then the user will be able to navigate to the event, but unable to edit.

We have not modified anything regarding the display of the transfer menu option, and the the logic that displays that option or not is on whether the user must have search access to at least one other org unit, or the program has it.

Is it possible that the permissions of the user have been modified?

Kind regards,

Xavier

5

Hi @Xavier,
Thank you for the clarification, that was helpful.

I have tested the new behavior in detail, and while the two changes you described have removed the immediate sync error, they have introduced a significant programmatic risk that affects patient tracking and indicators.

Here is what I am now observing in practice:

After a patient is transferred from Facility A to Facility B, the ownership is correctly moved to Facility B. However:

  • The patient remains visible when logged into Facility A
  • Previously scheduled events remain in Facility A
  • New events can now be created in Facility B (by switching the event OU to the enrollment/owner OU)

This results in the same patient effectively existing in two facilities at the same time, with events split across OUs.

Because DHIS2 analytics and tracker indicators are OU-based, this creates a serious side effect:

  • Facility A continues to show a missed or overdue visit for the patient (from the original scheduled event that cannot be closed there)
  • Facility B shows the patient as seen and treated
  • At district/state level, the same patient is now counted as both “missed” in A and “active” in B

So while data entry is now technically possible, the transfer no longer results in a clean relocation of the patient’s care, instead it creates ghost visits and double counting.

In addition, because users only have write access in their own facility:

  • Facility B staff cannot close or delete the old scheduled event in Facility A
  • Facility A staff cannot edit or close events created in Facility B

This makes it impossible to reconcile the patient’s timeline after transfer.

From a program perspective (we are using this for national hypertension tracking), this breaks:

  • Missed visit indicators
  • Retention and continuity of care
  • Facility-level and aggregate reporting

The expected behavior for a transfer (from a service-delivery point of view) is that once ownership moves:

  • The patient should no longer appear in the source facility’s working lists
  • Scheduled events should either move with the ownership or be invalidated
  • Only the receiving facility should continue the care timeline

Right now, the fix solves the sync error but leaves the patient logically attached to two facilities, which creates inaccurate data at scale.

Kind regards,
Msoo