clean and refine product docs structure
This commit is contained in:
hamid
@@ -0,0 +1,52 @@
|
||||
# Nurse Identity & Credential Verification
|
||||
|
||||
[← Research overview](index.md)
|
||||
|
||||
> **Related:** the product requirement [Nurse Verification](../business/02-nurse-verification.md) and the schema [Verification & Credentials](../data-model/04-verification-and-credentials.md) implement the pipeline described here.
|
||||
|
||||
**The question "is this nurse really who they say, and really licensed?" splits into two checks that should be separate pipeline stages:**
|
||||
- **License check** — *are they a registered nurse?* (professional registry)
|
||||
- **Identity + background check** — *are they who they claim, with no disqualifying record?* (KYC + criminal record)
|
||||
|
||||
## 3.1 Global reference models (best practices to emulate)
|
||||
- **USA — Nursys / e-Notify (the gold standard):** the only national license database, fed by state Boards of Nursing; **e-Notify *pushes* license/discipline status changes** to enrolled employers via a documented **API**. ([NCSBN](https://www.ncsbn.org/nursing-regulation/licensure/license-verification.page), [Nursys](https://www.nursys.com/EN/ENDefault.aspx)) — *lesson: continuous monitoring, not one-time vetting.*
|
||||
- **UK — NMC register + DBS:** the NMC online register (free, updated daily, search by 8-char PIN) answers *"are they licensed?"*; the separate **DBS** criminal-record check answers *"are they safe?"* — *lesson: keep the two checks distinct.*
|
||||
- **Background-check vendors (Checkr, Sterling):** API-first, built to embed in gig/marketplace flows; a caregiver check bundles criminal history, license verification, healthcare sanctions/exclusions, abuse-registry, employment/education, and re-screening. ([Checkr](https://checkr.com/our-technology/background-check-api), [Sterling](https://apidocs.sterlingcheck.app/))
|
||||
|
||||
**A robust pipeline = consent → identity verification → license verification (primary source) → criminal + abuse-registry checks → employment/education → ongoing monitoring.**
|
||||
|
||||
## 3.2 Iran-specific tooling (the operative part)
|
||||
|
||||
Iran has a usable stack, but it's **fragmented across regulators**, and the most sensitive check (criminal record) is **consent-gated to the individual**, not freely pullable by a company.
|
||||
|
||||
### A) Professional license — "is this a real nurse?" (two authorities, check both)
|
||||
- **MoH professional-competency license — پروانه صلاحیت حرفهای** at **Rn.behdasht.gov.ir** — the newer, **more authoritative** credential. Issuing it already vets the nurse's **scientific, ethical, health, AND criminal-record (سوء پیشینه)** standing, and the MoH states it is **required even for private in-home nursing.** **[the single most important credential to demand — it bundles a criminal-record screen]** ([behdasht.gov.ir](https://behdasht.gov.ir/), [heyvagroup](https://www.heyvagroup.com/shownews/12145/))
|
||||
- **Iranian Nursing Organization (سازمان نظام پرستاری) — نظام پرستاری number** via `ino.ir` / `membership.ino1.ir`. Reportedly allows third-party lookup/validation of a nurse's membership number; use as a **cross-check.** ([heyvagroup](https://www.heyvagroup.com/shownews/11343/))
|
||||
- **No public B2B API was found for either** — realistic use today is **require upload + manual verification against the official record.** (The physician council's public `membersearch.irimc.org` shows what an equivalent nurse search could look like.) **[absence of API is "not found," not positively confirmed — verify via a B2B portal]**
|
||||
|
||||
### B) Identity verification — the *easy* layer (turnkey APIs exist)
|
||||
A competitive market of Iranian **e-KYC vendors** sells ready APIs — **buy this, don't build it:**
|
||||
- **Shahkar (شاهکار):** government service matching a **mobile SIM ↔ national ID (کد ملی)**; run by the CRA. Result in <1 sec. **Access is gated** (approval + agreement + indirect connection via the "سرو/Sarva" platform), so **consume it via a reseller** rather than integrating directly. ([fa.wikipedia](https://fa.wikipedia.org/wiki/سامانه_شاهکار), [Finnotech](https://finnotech.ir/))
|
||||
- **National-ID validity & name matching (صحتسنجی کد ملی):** name + surname + کد ملی → match.
|
||||
- **Face/liveness matching against the national-card or civil-registry (ثبت احوال) photo:** offered by **Finnotech, U-ID (یوآیدی), Jibbit (جیبیت), Farashensa (فراشناسا), Verify (ونیفای), Kavoshak (کاوشک)** and others — liveness + face match + OCR, often 5–13M+ verifications of track record. ([Asr-e Tarakonesh: 8 Iranian KYC firms](https://asretarakonesh.ir/index.php/2024/01/02/نگاهی-به-خدمات-۸-شرکت-ایرانی-فعال-در-حوز/))
|
||||
- These vendors handle the regulator-gated upstream connections for you; a registered company signs up and consumes REST APIs.
|
||||
|
||||
### C) Criminal record — گواهی عدم سوء پیشینه (consent-gated, no company API)
|
||||
- The official "no criminal record" certificate, obtained by the **individual** online via **adliran.ir** using their personal **ثنا (Sana)** password, or in person via **پلیس +۱۰**. ([heyvalaw](https://www.heyvalaw.com/web/articles/view/1865/))
|
||||
- **A platform cannot pull it** — there is **no third-party/employer API**; issuance is bound to the person's own ثنا password. **Realistic design: require the nurse to obtain their own certificate and upload it, then re-request periodically** — *and note it's already embedded in the MoH پروانه صلاحیت حرفهای*, so demanding that license partly covers it.
|
||||
|
||||
### D) Supporting rails
|
||||
- **ثنا (Sana):** the judiciary's e-identity/notification system — relevant mainly as the **gateway to the عدم سوء پیشینه certificate.**
|
||||
- **سجام (Sejam):** capital-market (securities) KYC — **largely irrelevant** here except as proof that strong non-in-person e-KYC rails exist in Iran.
|
||||
|
||||
## 3.3 Recommended verification pipeline for your platform
|
||||
|
||||
| Stage | Goal | Iran tool / how | Programmatic? |
|
||||
|---|---|---|---|
|
||||
| **0. Consent** | Lawful basis to verify + store data | Explicit in-app consent at onboarding | n/a |
|
||||
| **1. Identity** | Match person ↔ کد ملی ↔ phone ↔ face | **Shahkar** + **national-ID validity** + **video/photo liveness vs. national card**, via **one KYC vendor** (Finnotech / U-ID / Jibbit / Farashensa / Verify) | **Yes — off-the-shelf API** |
|
||||
| **2. License** | Verify nursing credential at source | **MoH پروانه صلاحیت حرفهای** (Rn.behdasht.gov.ir) as primary **+** **INO نظام پرستاری number** (ino.ir) as cross-check | **Manual** (no public API found) — require upload + verify |
|
||||
| **3. Criminal record** | No disqualifying record | **عدم سوء پیشینه** — nurse self-requests via adliran.ir/ثنا and uploads; *partly covered* by the MoH license | **No company API** — consent-gated, nurse-uploaded |
|
||||
| **4. Ongoing monitoring** | Catch revocations/expiry | Periodic re-verification of license validity + re-request of عدم سوء پیشینه (e.g. annually); re-run Shahkar on phone change | Semi-manual; emulate Nursys e-Notify |
|
||||
|
||||
**Practical rules:** (1) **Buy identity verification** through one KYC provider — it shifts the regulator-gated Shahkar/ثبت احوال access burden onto a vendor that already holds the agreements. (2) **Anchor the license check on the MoH پروانه صلاحیت حرفهای** (it's State-mandated for in-home nursing and bundles a criminal screen). (3) **Treat the criminal certificate as nurse-supplied + consent-gated.** (4) **Build continuous monitoring**, not one-and-done. (5) **Mind data-protection exposure** — routing through a licensed KYC intermediary keeps you compliant.
|
||||
Reference in New Issue
Block a user