Skip to main content

TB-Refill Data Management Across Multiple Facilities

Executive summary​

Managing Tuberculosis medication refills (TB-refills) for patients across different facilities poses challenges in consistent data capture and synchronization, especially when clients travel or relocate. The described process ensures that patients receive timely TB-refills, regardless of their location, while maintaining accurate records. Clients registered at Facility A who require services at Facility B, either due to travel or permanent relocation, benefit from an offline data capture system at Facility B. For one-time events, data is relayed back to Facility A. In contrast, for permanent transfers, the client's entire record shifts to Facility B, but historical analytics remain at Facility A. Automated scripts facilitate data matching and transfer, with District Officers handling any discrepancies, leading to accurate record management across facilities.

This process saves time for health workers and data officers, ensures that patients are receiving the right medicine, in the right location, and improves the availability of data for decision making at all levels of the health service.

Proposed solution​

One-time Walk-in Event Transfer

  • A client registered in Facility A travels to another district.

  • Needs a TB-refill from a nearby Facility B during travel.

  • Must show a TB card with details to get the refill.

  • Facility B uses an offline capture app to enroll the event due to no internet access.

  • The event records the client's TB numbers, name, home facility, treatment data, and lab data.

  • Client later requests a transfer of this event back to Facility A.

  • Transfer status is initially set to "not yet transfer."

  • Once the internet is restored, the treatment data syncs to Facility A's server.

  • Lab results can take 2 weeks.

  • Scripts are executed to match TB numbers and name, and to process transfers.

  • Event data is added to the client's treatment and event record (TEI).

  • Special scripts ensure that incomplete lab data doesn't incorrectly finalize the transfer.

  • Once all data is imported, the script changes the event's transfer status and marks it complete.

Permanent Transfer

  • A client registered in Facility A moves to another district permanently.

  • Needs a TB-refill from Facility B post-move.

  • As before, the client must show their TB card to get the refill.

  • An event is enrolled with the client's details and a request for a permanent transfer to Facility B.

  • Analytics still pertain to Facility A even after the transfer.

  • Transfer processes, scripts, and TEI transfers are similar to the one-time transfer, but this time, the client's records move permanently to Facility B in the TB-surveillance system.

  • Facility B gains full rights to directly register lab results on the client's TEI.

User Scenario - Walk in Refill​

Jane Doe, a patient registered at Facility A for the TB-surveillance program, sometimes requires refills from other facilities due to travel. While Facility A remains her primary center due to proximity to her residence, there may be occasions when she requires a refill from Facility B. The following challenges and processes arise:

  • Challenge: Internet instability at Facility B can prevent the tracking of Jane's profile from Facility A, often leading to the creation of duplicate profiles. This can cause confusion when Jane returns to Facility A.

  • Solution: Facility B uses the "TB-refill event programme". This is a special program designed for patients like Jane who temporarily need a refill from another facility. This is termed as an "event transfer". Jane is registered in this program only once. Later, a script or a district officer will synchronize this data with the primary TB-surveillance program to update her drug dispensation and lab results.

  • Identification: The distinction between a one-time event transfer and a permanent one is controlled by a data element in the registration form.

  • Process at Facility B:

    1. Jane's details, including her home facility, are registered in the TB-refill event programme.

    2. Details from the "treatment" stages are added for consistency when matching records later.

    3. New data elements are added to determine if it's a one-time or permanent transfer and whether the transfer was done manually or by a script.

  • Transfer Process:

    1. Jane provides information such as her main facility and TB card details.

    2. The doctor at Facility B registers this data along with other relevant information.

    3. Jane requests an event transfer since she's returning home soon.

    4. The event status is set to "active - pending transfer" until the transfer occurs.

    5. Jane's TB card is updated, and she can leave Facility B.

  • Post-transfer Process:

    1. The script or district officer matches the event to the appropriate patient profile (TEI) and updates it.

    2. The event status is changed to "completed".

    3. Facility A, upon matching, can see the refill done at Facility B and plans for Jane's next treatment.

    4. The analytics count the refill under Facility A, even if done at Facility B, since Jane belongs to Facility A.

  • Working Lists:

    • Active - Pending Transfer: Lists all events awaiting transfer.

    • Completed - Transferred: Lists all events that have been transferred.

User Scenario - Self transfer​

Scenario: Jane Doe, initially registered at Facility A for TB treatment, needs to transfer to Facility B due to relocation.

  1. Background Information:

    • Jane was treated in Facility A which uses the TB-surveillance program. Her TB card is updated there.

    • Due to moving, she needs a TB-refill from the closest facility, now Facility B.

    • Facility B can access her profile from Facility A using DHIS2. However, internet connectivity issues may hinder this.

  2. Potential Problems:

    • Due to connectivity issues, Facility B might create a new profile for Jane, resulting in duplicate profiles.

    • This can cause data inconsistencies or missing data about her treatments.

  3. Solution – TB-Refill Event Programme:

    • For patients like Jane, transferring facilities, Facility B uses the TB-refill event programme during the initial treatment.

    • This facilitates a "permanent transfer", i.e., Jane will get all treatments from Facility B hereafter.

    • The transfer is signified by a data element in a registration form.

    • Once Jane gets her refill, a district officer or a script matches the event with her original profile to update the TB-surveillance program.

  4. Registration and Transfer Process:

    • On visiting Facility B, Jane's details are enrolled in their event program.

    • Details include her original facility (Facility A), visit date, and treatment details.

    • The doctor at Facility B asks if she wants a permanent transfer. If yes, the status is marked as "not yet transferred".

    • Jane's TB card is updated, but linking her profile between the two facilities is done by a script or district officer.

  5. Event Transfer Completion:

    • Once the transfer event is completed, Jane's profile is accessible in Facility B's TB surveillance program. Her treatment events from both facilities can be seen.

  6. Analytics and Working Lists:

    • Though Jane has moved to Facility B, analytics belong to Facility A.

    • The system maintains working lists to track patients:

      • Active-pending transfer.

      • Completed-transferred.

User Scenario - District officer​

Jane Doe underwent treatment at Facility B and labs were conducted on her. Now, it's time to match the refill event with the TEI in the TB-surveillance program.

District Officer's Responsibilities:

  1. Walk-in Refill Transfer:

    • There are three transfer statuses:

      • Automatically transferred

      • Manually transferred

      • Not yet transferred

    • Jane Doe's refill request results in a status: not yet transferred.

    • The data transfer process can be automatic (script-driven) or manual.

    • The transferred data shows Jane Doe's treatment details. Data consistency between TB-event and TB-tracker programs is crucial.

    • Manual transfer becomes necessary if the automatic process fails, commonly due to discrepancies in data entry or if the patient visits a facility outside of the district officer's purview.

    • The dashboard will display transfer statuses for quick references.

  2. Self (Permanent) Transfer:

    • Similar to walk-in refill, there are the same three transfer statuses.

    • In Jane's case, she requested a permanent transfer.

    • The transfer process can be automatic or manual.

    • Since it's a permanent transfer, Jane Doe's records also need to be shifted to the TB-surveillance program of Facility B, which requires manual intervention by the district officer.

    • The dashboard highlights permanent transfers.

    • For these transfers, certain fields like transfer type, facility, district, and contact info are to be filled out manually by the district officer.

To read more about the proposed solution and how it’s technically implemented, please read the continuation of this project at SQL script for transferring TB patient data