Search for a patient
Before anyone is registered, treated or billed, the receptionist has to answer one question: do we already know this person? Finding the existing record — rather than creating a second one — is the single most important habit at the front desk, because a duplicate splits a patient's history, allergies, balances and insurance across two files. BridgeERP HMS makes the search forgiving (one box, many identifiers) and backs it with an Enterprise Master Patient Index (EMPI) that catches duplicates the search misses.
Where to find it
You search in three places, depending on what you are doing:
- Reception → Reception → Reception Desktop — the global search box at the top of the front-desk console; the everyday tool.
- Reception → Reception → + Returning Patient — the lookup wizard (model
hms.reception.lookup.wizard) that searches, shows quick stats and starts a new visit in one flow. - HMS Core → Integration → EMPI — the duplicate-detection engine: Candidates, Review Queue, Patient Identifiers, Merge Log and Dashboard.
Searching across ID types
You do not have to know which document the patient is carrying. A single search term is matched, at the same time, against the patient's name, phone, National ID, NHIF/SHA number and MRN. So a patient who only remembers their phone number, and one who hands over a National ID card, are both found by typing what you have into the same box.
The identifiers recognised across the suite are:
| Identifier | Field / kind | Notes |
|---|---|---|
| National ID | national_id | Primary identifier for Kenyan adults; checked for uniqueness per facility. |
| Passport Number | passport_no | For non-citizens and patients without a National ID. |
| NHIF / SHA Number | nhif_no / sha_no | National insurer membership; also used for eligibility checks. |
| Huduma Number | huduma_no | National registration number where issued. |
| MRN | mrn | The facility's own Medical Record Number. |
| Phone | phone / mobile | Often the fastest match for walk-ins. |
The EMPI keeps these in a dedicated Patient Identifiers register (model hms.empi.identifier) whose kind can be National ID, NHIF/SHA, Passport, Foreign ID, MRN, Insurance Member ID or Phone. That register is what lets the index recognise the same person even when two records were typed slightly differently.
Finding an existing patient
- On the Reception Desktop, click into the search box and type any identifier — surname, phone, ID or NHIF number.
- Read the result rows. Each shows the patient name, payment mode and any active insurance scheme as a badge, plus a red flag where there is something to check.
- If exactly one row is obviously your patient, click it to load them and continue to register the visit.
- If several rows look similar, widen the term (add a first name, or switch to the ID number) to disambiguate before you pick one.
- If no row matches, the desktop offers New Patient — but first try a second identifier, because a missing match is the moment duplicates are born.
The Returning-Patient lookup
The + Returning Patient wizard is the quickest path for someone already in the system. It takes a single Search term, lists matching candidates, and when you pick one it shows decision-useful stats before you commit:
| Field | What it tells you |
|---|---|
| Recent Visit Count | Visits in the last 30 days — a sense of how active the patient is. |
| Outstanding Count | Open balances that may need settling before service. |
| Active Rx Count | Live prescriptions, useful for pharmacy or refill visits. |
| Last Visit Payment Mode | How they paid last time (cash, insurance, corporate). |
| Last Visit Insurance | The scheme used on the previous visit. |
From here you choose a Visit Type and Department and use New Visit to register the day's encounter without retyping any demographics.
EMPI & de-duplication
Search depends on clean data; the EMPI keeps it clean. A scoring engine compares pairs of patient records and proposes candidates (model hms.empi.candidate) for merging. Each candidate carries a match score (0–100), the list of fields that matched, and a band:
| Band | Score | What happens |
|---|---|---|
| Auto-merge | ≥ 95 | High confidence; the system can merge automatically. |
| Needs steward | 70–94 | Sent to the Review Queue for a human decision. |
| Low | < 70 | Kept but not actioned; auto-rejected after 90 days. |
A candidate's status moves through Pending, Auto-merged, Needs Steward, Rejected or Merged. A data steward works the Review Queue, approving genuine duplicates (recorded in the Merge Log) and rejecting coincidental matches. If a merge was wrong, an Unmerge Request reverses it. The thresholds themselves are set under Match Rules and Facility Config.
How the match score is built
The score that decides a candidate's band is the sum of the rules that fired when two records were compared. Each rule contributes a default weight (an administrator can re-weight them under Match Rules), and the total is capped at 100. These are the default weights.
| Rule | Default weight | Fires when |
|---|---|---|
| Exact National ID | 100 | Normalised National IDs are identical — on its own enough to auto-merge. |
| Exact NHIF / SHA | 90 | Normalised NHIF/SHA numbers match. |
| Exact Passport | 85 | Normalised passport numbers match. |
| Exact Phone | 80 | Normalised phone numbers match. |
| Exact DOB + Last Name | 60 | Same date of birth and same surname. |
| Fuzzy Name | 30 | Jaro–Winkler name similarity ≥ 0.85 (weight scaled by closeness). |
| Soundex Name | 20 | Names sound alike (same Soundex) but are spelt differently. |
So two records sharing a National ID reach 100 and auto-merge, while a fuzzy-name plus matching-phone pair lands in the steward band rather than merging blindly — which is exactly why doubtful cases route to a human.
Roles & access
Front-desk staff in the Reception group can search and open patients and raise EMPI candidates implicitly by creating records. Merging, rejecting and unmerging are steward/Administrator tasks, so a busy receptionist cannot accidentally collapse two patients together.
Tips & troubleshooting
| Symptom | Likely cause & fix |
|---|---|
| Patient swears they have visited but nothing is found | Try a different identifier (phone instead of name); a typo in one field hides the record from that one search but not from others. |
| Two records for the same person keep appearing | A genuine duplicate — check the EMPI Candidates list; a steward should merge them. |
| National ID rejected as already in use | The number is unique per facility; the patient already exists — load that record instead of creating a new one. |