How registration works

This page explains how a child gets into SBDMS and what happens to the record after that. Read it first if you are a parent, a health worker at a desk, or an admin who needs to understand the statuses you see in lists and reports.

Two steps: register, then verify

Every child record goes through two steps.

Register. Someone fills in the registration form. This can be a parent at home on their phone, or a staff member at a desk on camp day. The record is created with the status Self Registered.
Verify. A signed-in staff member checks the details with the family in person and confirms them. The status becomes Verified.

Why two steps? The registration form is public. Anyone with the link can use it, with no login, no SMS code and no email check. That keeps it easy for parents. Verification is the moment where staff physically meet the family and confirm the record is real. Only a Verified child can be given the drops on Prashan day. See Verifying a registration.

A staff member who is signed in can also do both steps at once. On the registration form they tick I have verified this information — register & verify now, and the child is created already Verified.

The three statuses

Status	How it happens	Can be dosed?
Self Registered	Created by the public form, by a staff member who did not tick the verify box, or by Bulk import.	No. The Prashan page shows Registration Not Verified and sends you to verify first.
Verified	Staff confirmed the record at a camp site, or registered and verified in one go.	Yes, through the normal Prashan page.
Org Verified	The child came from a school or children’s home list loaded by an admin. See Schools and children’s homes.	Yes. Usually from Org Mode; the Prashan Day page and Prashan Mode accept them too.

On a child’s profile the status shows as a small badge next to the name. A Verified badge is black; the other two are white with a black border. When a child is Verified, a green badge next to it names the camp site where verification happened.

UPC codes

Every child and every guardian gets a UPC (Unique Participant Code). It looks like QUQV-7135: four letters, a dash, four digits. The code is unique across all children and guardians, so it is the fastest way to find a record.

You can type a UPC into the search box on Participants or on the Prashan page.
The UPC is printed on every QR card.
A family that registers together gets one UPC for the guardian and one for each child.

Names in English letters

Child and guardian names are typed in English letters (A to Z), for example Sita Sharma, not सीता शर्मा. Every report, QR card and search uses the English spelling, so a name in Nepali letters could not be found. The forms drop Nepali letters as you type, and the server refuses a name in Nepali (Devanagari) letters with Names must be typed in English letters (A-Z). Nepali (Devanagari) letters are not accepted in name fields.

The rule applies when registering (by a parent or by staff), verifying, adding a child or a guardian, and editing a profile. Some older records already carry a name in Nepali letters. They stay as they are, and can still be verified and saved, until someone changes the name; the new name must then be in English letters.

QR cards

A QR card is a small printable card with the SBDMS title, the person’s name, a QR code and the UPC underneath. The QR code simply contains the UPC. Cards appear on the success screen right after registration and on every profile page. You can print them as a sticker, A5 or A4, or download a PNG. On Prashan day the family shows the card and staff use it to pull up the record without typing. See QR cards and scanning.

Preferred site and verified-at site

A child record carries two camp sites.

Preferred Campsite — chosen on the registration form. This is the camp the family plans to attend. It is required for every new registration. If a family registers by scanning a camp site’s poster QR, this field is filled in for them and a yellow banner at the top of the form names the site.
Verified at — the camp site where a staff member verified the child. It is set at verification time.

When staff verify a child, the system also moves the preferred site to the verifying site, so the two normally match after verification. If they differ when you submit the verification, a Different camp site box asks you to confirm, with Cancel and Yes, proceed, and the decision is logged. GeneralAdmin and SuperAdmin can later fix a wrong site from the profile with Change Verification Campsite.

Why does this matter? Reports and the “unverified” filters on the Participants page use these sites. A child verified at the wrong site shows up in the wrong site’s numbers.

“Already registered” detection

The system tries hard not to create the same child twice.

Guardian match. If the guardian name (ignoring case and spaces at the ends) and Phone 1 match an existing guardian, the existing guardian is reused. The success screen then says Linked to existing guardian.
Child match. If a guardian with the same Phone 1 already has a child with the same name (whatever spelling of the guardian’s name was typed), nothing is created. The form shows a Guardian already registered panel that sends the family to a health worker, and Go back returns to the form. It does not show the existing codes.

There is no “force create” override in the web app. If two different families really do share a guardian name, phone and child name, register the second child with a slightly different spelling or ask an admin.

Where each role fits

Role	Can do
Parent or public	Register on `/register`, save or print QR cards.
GeneralUser (health worker)	Register at a desk, register and verify in one go, verify a Self Registered child at their own site, dose school children in Org Mode.
LocationAdmin (site admin)	Everything above, plus load an organisation’s list of children for their site.
GeneralAdmin / SuperAdmin	Everything above at any site, plus bulk import from a spreadsheet, and Change Verification Campsite on a profile.