Registries

Registries in BridgeERP HMS let you follow defined cohorts of patients over time — HIV/ART, TB, maternal-and-child health, cancer, diabetes, hypertension and other non-communicable diseases. Rather than hard-coding one screen per condition, a registry is defined with its own inclusion criteria and structured data elements, then patients are enrolled and tracked through outcome events. This gives programme managers a single, configurable framework for every chronic-disease and condition register the facility must keep.

Where to find it

The registries workbench is Public Health → Registries:

• Public Health → Registries → Registries — the registry definitions (model hms.registry.definition).
• Public Health → Registries → Enrollments — enrolled patients across all registries (hms.registry.patient).
• Public Health → Registries → Outcomes — recorded outcome events (hms.registry.outcome).
• Public Health → Registries → Dashboard — overview of registries.
• Public Health → Registries → Cross-Registry Report — patients seen across registries.
• Public Health → Registries → Configuration → Data Elements — the structured fields each registry captures (hms.registry.data.element).

Before you start

Define your registries before enrolling anyone. For each registry record the name, a unique code, a description and the human-readable inclusion criteria (for example, ICD-10 C-codes for a cancer registry). Then, under Configuration → Data Elements, add the structured fields you want to capture for that registry, each with a data type: Text, Integer, Decimal, Date, Selection or Yes/No. Selection elements carry their own list of allowed values.

Enrol a patient

1. Open the registry from Public Health → Registries → Registries and use its Patients action, or create directly under Enrollments.
2. Select the Registry and the Patient; the display name combines the two.
3. Set the Enrollment Date, the enrolling provider and, if applicable, the referring facility.
4. Capture the registry's data elements as data values on the enrolment.
5. Keep the Status current as the patient progresses: Active, Inactive, Lost to Follow-up, Completed or Died.

Record an outcome event

Outcomes are the events that punctuate a patient's registry journey. From an enrolment, record an outcome with its outcome type and event date. The available types include Death, Remission, Recurrence, Transplant, Rejection Episode, Cure / Resolution, Lost to Follow-up, Birth Event and Discharge. Each outcome is linked back to its enrolment and its registry, so survival, remission and loss-to-follow-up figures roll up per registry.

Enrolment field reference

Data element types

Configuration

Registry definitions and their data elements are managed under Public Health → Registries → Registries and Configuration → Data Elements. Because the data shape is configurable, you can stand up a new condition register — say a sickle-cell or a renal register — without code changes: define it, add its elements, and start enrolling.

Reporting

The Dashboard summarises enrolments per registry, while the Cross-Registry Report highlights patients who appear in more than one registry — useful for co-morbidity tracking (for example a patient in both the HIV and TB registers). Outcome events feed cohort survival and retention figures.

Why a configurable registry

A condition register is more than a list of patients — it is a longitudinal record that must answer questions like “how many of our enrolled patients are still in care twelve months on?” and “what proportion reached a defined outcome?”. Because every disease tracks different variables, BridgeERP HMS does not hard-code one screen per condition. Instead it separates the definition of a registry (its inclusion criteria and the data elements it captures) from the enrolments (the patients) and the outcomes (the events). The practical benefit is that a programme manager, not a developer, decides what a registry records: a renal register might capture a creatinine value and a dialysis-start date, while a cancer register captures a stage and a histology code, and both reuse the same enrolment and outcome machinery underneath.

This design also keeps cross-programme reporting honest. Because every enrolment points at the same shared patient record, a single person who appears in the HIV, TB and diabetes registers is recognised as one patient, and the Cross-Registry Report can surface that co-morbidity rather than triple-counting them. When a patient dies, the death recorded as a registry outcome in one register is visible against that same patient elsewhere, so cohorts stay internally consistent.

Lifecycle of an enrolment

An enrolment begins as Active on the day the patient meets the registry's inclusion criteria. Over time, structured data values are captured at each review, and outcome events punctuate the journey — a remission, a recurrence, a transplant, a discharge. The enrolment status is the single most important field to keep current: a patient who has genuinely disengaged should move to Lost to Follow-up, one who has completed a defined programme to Completed, and a death to Died (mirrored by a Death outcome event). Accurate status is what makes retention and survival figures trustworthy when they roll up to the dashboard and onward to statutory returns.

Tips & troubleshooting

Outcome event types

Outcome events punctuate a patient's registry journey and feed survival, remission and loss-to-follow-up figures.

Enrolment status lifecycle

The enrolment status is the single most important field to keep current for trustworthy retention and survival metrics.

Registries menus at a glance

Related

• Public Health overview
• Disease surveillance
• Community health workers