فلوی احراز هویت و صلاحیت پرستار
راهنمای پیادهسازی برای ثبتنام در پلتفرم
⚠️ یک تصحیح مهم از همان ابتدا: در ایران پرستاران عضو سازمان نظام پرستاری هستند و «شمارهٔ نظام پرستاری» دارند؛ «کد نظام پزشکی» مخصوص پزشکان (سازمان نظام پزشکی) است. این دو سامانهٔ کاملاً جدا هستند. در این سند هر دو پوشش داده شدهاند، اما برای پرستار، منبع درست نظام پرستاری است (و جالب اینکه برخلاف نظام پزشکی، استعلام نظام پرستاری API ندارد — به بخشهای ۴ و ۷ نگاه کنید).
۱. اصول طراحی (پیش از کدنویسی بخوانید)
- تفاوت «اظهار» و «دادهٔ رسمی». هر چیزی که پرستار تایپ میکند (نام، سابقه، شماره نظام) صرفاً ادعاست. ارزش واقعی وقتی ساخته میشود که آن ادعا را با یک منبع رسمی مستقل (ثبت احوال، نظام پرستاری، تأمین اجتماعی) تطبیق دهید.
- سه نوع منبع از نظر دسترسی:
خودکار با API و فقط ورودیهایی که پرستار داده، بینیاز از اقدام او نیازمند ورود یا تأیید پیامکیِ خودِ فرد دستی / آپلود فرم وب بدون API، یا آپلود مدرک، یا استعلام سازمانی
- هویت را «گره بزنید»، نه اینکه فقط چک کنید. سختترین تقلب این حوزه، استفاده از یک شمارهٔ نظامِ واقعی ولی دزدیدهشده است (سناریوی «پرستار قلابی»). پادزهر: نام و عکسِ روی رکورد نظام پرستاری را با هویت ثبت احوال و سلفیِ زندهٔ همان لحظه تطبیق دهید (بخش ۵).
- ارزان به گران. اول استعلامهای ارزان و قطعی (شاهکار) را اجرا کنید؛ اگر رد شد، اصلاً سراغ مراحل گران (احراز ویدیویی) نروید. این هم هزینه را پایین میآورد هم تجربهٔ کاربر را.
- همهٔ این APIها فقط B2B هستند. برای استفاده باید شرکت ثبتشده، احراز کسبوکار و
client credentialداشته باشید؛ و طبق رگولاتوری باید از کاربر رضایت صریح برای استعلام و نگهداری داده بگیرید. - «سال سابقه» را نمیتوان بیرضایت و خودکار کشید. هیچ API عمومیای با کد ملی، سالهای تجربهٔ بالینی را برنمیگرداند؛ این داده یا با رضایت/OTP خود فرد از تأمین اجتماعی میآید یا با آپلود گواهی سابقه (بخش ۴، گام ۶).
۲. دادههای ورودی که از پرستار میگیریم
برای اجرای کاملِ فلو، در فرم ثبتنام این فیلدها را جمع کنید (بعضی برای استعلامهای رسمی الزامیاند):
| فیلد | چرا لازم است | وضعیت |
|---|---|---|
| شمارهٔ موبایل | تطبیق با کد ملی در شاهکار؛ ارسال OTP | الزامی |
| کد ملی | کلید همهٔ استعلامهای هویتی و حرفهای | الزامی |
| تاریخ تولد | برای استعلام هویت ثبت احوال و احراز ویدیویی الزامی است (بدون آن دادهٔ کامل ثبت احوال برنمیگردد) | الزامی |
| شمارهٔ نظام پرستاری | راستیآزمایی صلاحیت در estelam.ino1.ir | الزامی |
| سریال پشت کارت ملی | ورودیِ احراز هویت ویدیوییِ (eKYC) | برای eKYC |
| ویدیوی سلفی (≈۵ ثانیه) | زندهسنجی + تطبیق چهره با عکس ثبت احوال | برای eKYC |
| کد پستی محل سکونت | تنها راه گرفتن آدرس رسمی (مسیر کد ملی→آدرس وجود ندارد) | اختیاری |
| شمارهٔ کارت یا شبای بانکی | تطبیق مالکیت حساب واریز با کد ملی | هنگام تسویه |
| گواهی سابقهٔ کار / مدرک تحصیلی (آپلود) | اثبات سابقه و کارشناسی پرستاری (که API ندارند) | آپلود |
۳. نقشهٔ کلی فلو (نمای پرنده)
estelam.ino1.ir → نام، مقطع، رشته، شهر، عکس. تطبیق متقابل با گام ۳ و ۴.۴. فلوی مرحلهبهمرحله
- ورودی
mobileNumber+nationalId(همان دو فیلدی که پرستار داده)- منبع / API
- سرویس شاهکار از طریق یکی از resellerها: Finnotech، U-ID/یوآیدی، api.ir، Shabanic، Zohal و … (همگی روی همان backend دولتی رگولاتوری مخابرات).
- خروجی
- فقط یک بولینِ
isMatched: true/false(بههمراه کد/پیام وضعیت). هیچ دادهٔ هویتی دیگری نمیدهد. - منطق تصمیم
- اگر
false→ یعنی سیمکارت بهنام این کد ملی نیست؛ ثبتنام را همینجا متوقف یا به بازبینی دستی بفرستید. اگرtrue→ ادامه. (ارزانترین استعلام؛ همیشه اول اجرا شود.)
- ورودی
- شمارهٔ موبایل (همان شمارهٔ تأییدشده در گام ۱)
- منبع / API
- هر سرویس پیامک (Kavenegar، ملیپیامک، IPPanel، …)
- خروجی
- تأیید اینکه کاربر همان لحظه به سیمکارت دسترسی دارد + ثبت رضایت قانونی برای استعلامها.
- منطق تصمیم
- شاهکار میگوید «سیم بهنام این کد ملی است»؛ OTP میگوید «کاربر همین حالا سیم را در دست دارد». ترکیب این دو، جعل شماره را بسیار سخت میکند.
- ورودی
nationalCode+birthDate(تاریخ تولد الزامی است)- منبع / API
- استعلام هویت ثبت احوال از Shabanic یا U-ID. توجه «صحتسنجی کد ملیِ» Finnotech فقط درصد تطبیق میدهد، نه خودِ داده — برای پر کردن پروفایل از سرویس «استعلام هویت» استفاده کنید.
- خروجی (فیلدها)
firstName،lastName،fatherName(نام پدر)،gender(جنسیت)،birthDate،deathStatus(وضعیت حیات — زنده/فوت)،idNo(شماره شناسنامه)،idSerial/idSerie(سری و سریال شناسنامه). شهر محل تولد بهصورت فیلد صریح برنمیگردد.- منطق تصمیم
- پروفایل را خودکار پر کنید و نامِ اظهارشدهٔ پرستار را با
firstName/lastNameِ رسمی تطبیق دهید. اگرdeathStatus= فوتشده → پرچم قرمز و توقف. این گام، «نام واقعیِ گرهخورده به کد ملی» را به دست میدهد که در گام ۵ بهکار میآید.
- ورودی
- ویدیوی سلفی (≈۵ ثانیه) +
nationalId+nationalIdSerial(سریال پشت کارت ملی) +birthDate+gender - منبع / API
- احراز هویت ویدیوییِ U-ID، api.ir یا VIDA/ویدا. (زندهسنجی ~۹۸٪، تطبیق چهره >۹۹٪ طبق اعلام ارائهدهنده.)
- خروجی
- یک enum وضعیت:
state=ACCEPTED/REJECTEDبههمراهreason(مثلاًFACE_NOT_MATCH_IDیا تأیید). خروجی عددِ درصد نیست، بلکه قبول/رد است. - منطق تصمیم
- این گام اثبات میکند فردِ زندهٔ پشت دوربین همان صاحب عکسِ ثبت احوالِ آن کد ملی است — یعنی صرفاً کسی نیست که کد ملیِ دیگری را تایپ کرده. اگر
REJECTED→ بازبینی دستی یا توقف.
- ورودی
- شمارهٔ نظام پرستاری یا نام و نام خانوادگی (تطبیق دقیق است؛ ورودیِ کد ملی ندارد)
- منبع
- سامانهٔ عمومی
estelam.ino1.ir(«استعلام پرستاران کشور») — بدون لاگین، بدون کپچا. API رسمی یا واسطهای ندارد؛ یا بررسی دستی است یا scrape شکنندهٔ صفحه (با CSRF token). - خروجی (فیلدها)
- نام، نام خانوادگی، شمارهٔ نظام، مقطع تحصیلی (مثلاً «کارشناس»)، رشتهٔ تحصیلی (مثلاً «پرستاری»)، شهر هیئتمدیره (شعبه/استان)، و عکس پرسنلی.
- چه چیزی نمیدهد
- مهم وضعیت فعال/منقضی، تاریخ ثبت/عضویت، تخصص و محل خدمت را نمیدهد. ⟶ یعنی «فعال بودن» و «سال سابقه» از این استعلام درنمیآید (برای آنها به گام ۶ و ۷ بروید).
- منطق تصمیم
- اینجاست که تطبیق متقابل انجام میشود: نامِ روی رکورد نظام پرستاری باید با نامِ ثبت احوال (گام ۳) بخواند، و عکسِ این رکورد باید با چهرهٔ سلفی (گام ۴) و عکس ثبت احوال همخوان باشد. این کار، شمارهٔ نظامِ «واقعی ولی دزدیدهشده» را لو میدهد.
- سابقهٔ کار
- تأمین اجتماعی (
eservices.tamin.ir/ اپ «تأمین من»). با کد ملیِ تنها قابل استخراج نیست؛ نیازمند لاگین یا OTP رویِ سیمکارتِ خود فرد است. خروجی: روزهای بیمه، دستمزد مبنا، سوابق تلفیقی، و مدت اشتغال نزد هر کارفرما. گزینهٔ عملی: یا API استعلام بیمهٔ مبتنیبر رضایت (کاربر OTP میزند)، یا از پرستار بخواهید «خروجی سابقه/گواهی سابقهٔ کار» را خودش بگیرد و آپلود کند. - مدرک تحصیلی
- مدرک پرستاری زیر نظر وزارت بهداشت است، نه وزارت علوم ⟶ سامانهٔ سجاد آن را تأیید نمیکند. منبع درست:
eg.behdasht.gov.ir(سامانهٔ دانشآموختگان). استعلامِ تأییدیه سازمانمحور است (شرکت شما درخواست رسمی میدهد، پاسخ به شما برمیگردد) و API عمومی ندارد. گزینهٔ عملی اولیه: آپلود دانشنامه/مدرک کارشناسی + بررسی بصری. - منطق تصمیم
- «سال سابقه» و «کارشناسی پرستاری» را بهعنوان دادهٔ اظهاری-با-مدرک ثبت کنید و در صورت نیاز با تأییدیهٔ رسمی ارتقا دهید. تاریخِ نبودِ این دادهها در APIهای ارزان را بهعنوان محدودیت بپذیرید.
- پروانهٔ صلاحیت حرفهای
- مدرک وزارت بهداشت (سامانههای
Rn.behdasht.gov.irوop.salamat.gov.ir) که صدورش مشروط به گزینش و گواهی عدم سوء پیشینه است. صدور self-service (لاگین خود فرد با کد ملی + OTP) است و API عمومی ندارد. ⟶ معتبر بودنِ این پروانه یعنی «سوءپیشینه و گزینش هنگام صدور بررسی شدهاند». - عدم سوء پیشینه
- گواهی رسمی که فقط خودِ فرد از
adliran.irبا رمز ثنا میگیرد؛ هیچ API شخصثالثی برای کشیدن آن وجود ندارد. ⟶ از پرستار بخواهید گواهی را بگیرد و آپلود کند، و دورهای تمدید کنید. - منطق تصمیم
- چون این دو سند برای کارِ مراقبت از افراد آسیبپذیر حیاتیاند، آنها را الزامی کنید (آپلود + بازبینی)، حتی اگر خودکار نیستند.
- ورودی
- شمارهٔ کارت یا شبا +
nationalCode(+ تاریخ تولد) - منبع / API
- تطبیق شبا/کارت با کد ملی (Shabanic / U-ID). یا «کارت به شبا»ی Shabanic که
IBAN، شماره حساب،depositOwners(نام صاحب حساب) و نام بانک را میدهد (~۵٬۰۰۰ تومان). - خروجی
- وضعیت تطبیق + نام صاحب حساب + نام بانک + وضعیت حساب (فعال/مسدود).
- منطق تصمیم
- اطمینان از اینکه پولِ پرستار به حسابِ خودِ او واریز میشود (نه واسطه). معمولاً هنگام اولین تسویه اجرا میشود، نه لزوماً در ثبتنام.
نتایج همهٔ گامها را در یک «کارت اعتماد» جمع کنید و بر اساس آن تأیید/رد/بازبینی انسانی را تصمیم بگیرید (بخش ۷ این سند).
۵. ماتریس تطبیق متقابل (قلبِ ضدِ تقلب)
ارزش فلو در تکتک استعلامها نیست، بلکه در همخوانیِ آنها با یکدیگر است. این جدول نشان میدهد کدام فیلد باید با کدام منبع بخواند تا هویت «گره» بخورد:
| چه چیزی باید با چه چیزی بخواند | منبعهای درگیر | اگر نخواند یعنی… |
|---|---|---|
| موبایل ↔ کد ملی | شاهکار (گام ۱) | سیمکارت بهنام شخص دیگری است / جعل شماره |
| نامِ اظهارشده ↔ نامِ ثبت احوال | فرم ثبتنام ↔ استعلام هویت (گام ۳) | کد ملیِ متعلق به فرد دیگری وارد شده |
| چهرهٔ سلفیِ زنده ↔ عکس ثبت احوال | eKYC (گام ۴) | فرد، صاحب واقعیِ کد ملی نیست (هویت دزدیده) |
| نام و عکسِ نظام پرستاری ↔ هویت ثبت احوال + سلفی | estelam.ino1.ir (گام ۵) ↔ گامهای ۳ و ۴ | شمارهٔ نظامِ واقعی ولی دزدیدهشده — خطرناکترین حالت |
| رشته/مقطعِ نظام پرستاری ↔ مدرک تحصیلی آپلودی | گام ۵ ↔ گام ۶ | مدرک جعلی یا ناهماهنگ |
| نام صاحب حساب ↔ کد ملی | تطبیق بانکی (گام ۸) | حساب واریز متعلق به شخص دیگری است |
درس کلیدی: یک شمارهٔ نظام پرستاریِ معتبر بهتنهایی چیزی را اثبات نمیکند، چون میتواند دزدیده شده باشد. آنچه اثبات میکند، زنجیرهٔ «کد ملی ← چهرهٔ زنده ← عکس ثبت احوال ← عکس نظام پرستاری ← نامِ یکسان در همه» است. این تنها سدّ واقعی در برابر سناریوی «پرستار قلابی» است.
۶. جدول «داده موردنیاز ← منبع / سرویس»
| دادهای که میخواهید | منبع / API | ورودی لازم | دسترسی |
|---|---|---|---|
| تطبیق موبایل ↔ کد ملی | شاهکار (Finnotech/U-ID/api.ir/…) | موبایل + کد ملی | خودکار |
| نام، نام خانوادگی، نام پدر، جنسیت | استعلام هویت ثبت احوال (Shabanic/U-ID) | کد ملی + تاریخ تولد | خودکار |
| شماره/سری/سریال شناسنامه | استعلام هویت ثبت احوال | کد ملی + تاریخ تولد | خودکار |
| وضعیت حیات (زنده/فوت) | استعلام هویت ثبت احوال (deathStatus) | کد ملی + تاریخ تولد | خودکار |
| تطبیق چهرهٔ زنده با عکس رسمی | eKYC ویدیویی (U-ID/api.ir/VIDA) | ویدیو + کد ملی + سریال کارت + تاریخ تولد + جنسیت | |
| صحت شمارهٔ نظام + مقطع/رشته/شهر + عکس | نظام پرستاری estelam.ino1.ir | شماره نظام یا نام (تطبیق دقیق) | دستی/Scrape |
| وضعیت فعال/منقضیِ عضویت نظام پرستاری | پورتال عضویت membership.ino1.ir | لاگین + OTP خود فرد | |
| سال سابقه / سوابق بیمه | تأمین اجتماعی eservices.tamin.ir | credential یا OTP خود فرد | |
| مدرک کارشناسی پرستاری | وزارت بهداشت eg.behdasht.gov.ir / آپلود | self-service فرد یا استعلام سازمانی | آپلود/دستی |
| غربالگری سوءپیشینه (غیرمستقیم) | پروانهٔ صلاحیت حرفهای + گواهی عدم سوء پیشینه | self-service فرد / آپلود گواهی | |
| تطبیق حساب واریز با کد ملی | تطبیق شبا/کارت با کد ملی (Shabanic/U-ID) | شبا یا کارت + کد ملی | خودکار |
| آدرس رسمی | استعلام آدرس با کد پستی | کد پستی (از خود فرد) | خودکار |
| کد نظام پزشکی (فقط اگر فرد پزشک باشد) | نظام پزشکی membersearch.irimc.org / API پادیوم | کد ملی یا شماره نظام | خودکار (B2B سلامت) |
| موبایل از کد ملی / هویت از موبایل (معکوس) | — | — | غیرقابلدسترس |
دو مسیر که برای شرکت خصوصی وجود ندارند و نباید رویشان حساب کنید: (۱) «کد ملی → شمارهٔ موبایل» یا «موبایل → هویت کامل» (فقط با دستور قضایی)، و (۲) «کد ملی → آدرس» (آدرس فقط با خودِ کد پستی بهدست میآید).
۷. جمعبندیِ تصمیم و امتیاز اعتماد
پیشنهاد میشود نتیجهٔ هر گام را به یک «کارت اعتماد» تبدیل کنید و سیاست تأیید را روی آن بنا کنید:
| سطح | شرط | نتیجه |
|---|---|---|
| هویت پایه ✅ | شاهکار + OTP + استعلام ثبت احوال (نام میخواند، حیات تأیید) موفق | اجازهٔ تکمیل پروفایل؛ هنوز قابلرزرو نیست |
| هویت قوی ✅✅ | + احراز ویدیوییِ ACCEPTED (تطبیق چهره) | هویت فرد قطعی است |
| صلاحیت حرفهای ✅✅✅ | + تطبیق نام/عکسِ نظام پرستاری با هویت + پروانهٔ صلاحیت + عدم سوء پیشینه | قابلرزرو برای خانوادهها (نشانِ «احرازشده») |
| بازبینی دستی ⚠️ | هر مغایرتی (نام نمیخواند، عکس مردد، شماره نظام یافت نشد) | صف بازبینی انسانی پیش از فعالسازی |
| رد ⛔ | شاهکار false، حیات=فوت، چهره REJECTED، یا سوءپیشینهٔ مشکلدار | عدم پذیرش |
نکتههای اجرایی: نتایج استعلامها را با مهر زمانی ذخیره کنید (هم برای حسابرسی، هم دفاع حقوقی)؛ مدارک حساس (مجوز، سوءپیشینه) را دورهای بازبینی/تمدید کنید نه فقط یکبار در ثبتنام؛ و هر استعلام را فقط با رضایت ثبتشدهٔ کاربر اجرا کنید.
۸. نکات حقوقی، حریم خصوصی و دسترسی
- پیشنیاز فنی: برای همهٔ APIها باید شرکت ثبتشده، احراز کسبوکار و
client credentialاز ارائهدهنده داشته باشید. APIهای هویتی به اشخاص حقیقی داده نمیشوند. - رضایت کاربر: طبق الزامات رگولاتوری، پیش از استعلام و نگهداری دادهٔ هویتی باید رضایت صریح بگیرید (متن رضایتنامه در فرم ثبتنام + لاگ OTP).
- کمینهسازی داده: فقط آنچه را که برای تصمیم لازم است ذخیره کنید؛ تصاویر سلفی و مدارک حساس را رمزنگاری و با دسترسی محدود نگه دارید.
- راهبردِ ارائهدهنده: ترجیحاً از یک ارائهدهندهٔ KYC جامع (مثل Finnotech یا U-ID) استفاده کنید تا اتصال به سرویسهای دولتیِ گِیتشده (شاهکار، ثبت احوال) را او مدیریت کند و بار انطباق روی دوش او باشد.
- محدودیتهای واقعی را بپذیرید: نظام پرستاری API ندارد (دستی/Scrape)؛ سابقه و مدرک و سوءپیشینه رضایتی/آپلودیاند؛ مسیرهای معکوس موبایل/آدرس بستهاند. فلو را حول این واقعیتها طراحی کنید، نه برخلافشان.
موارد با اطمینان پایینتر که پیش از کدنویسی باید با خودِ ارائهدهنده نهایی شوند: نام دقیق فیلدهای خروجی (مثل
idSerie/idSerialو enumهای eKYC)؛ قیمتها؛ امکان استعلامِ پروانهٔ صلاحیت حرفهای توسط شخص ثالث؛ پوششِ مدارک وزارت بهداشت توسط APIهای reseller؛ و جزئیات API نظام پزشکیِ پادیوم. اینها از مستندات/منابع ثانویه استخراج شدهاند و ممکن است در نسخهٔ قراردادی کمی فرق کنند.
۹. منابع
هویت و KYC:
Finnotech — شاهکار ·
Finnotech — صحتسنجی کد ملی ·
U-ID — API هویت ·
U-ID — شاهکار ·
U-ID — eKYC docs ·
Shabanic — استعلام ثبت احوال ·
Shabanic — کارت به شبا ·
Shabanic — تطبیق شبا با کد ملی ·
api.ir — زندهسنجی ·
VIDA ·
ملیپیامک — استعلام موبایل با کد ملی
صلاحیت حرفهای و سابقه:
نظام پرستاری — استعلام ·
نظام پرستاری — عضویت ·
heyvagroup — نظام پرستاری ·
صلاحیت حرفهای — اپراتور سلامت ·
heyvagroup — صلاحیت حرفهای ·
نظام پزشکی — جستجو ·
Podium — API نظام پزشکی ·
تأمین اجتماعی ·
وزارت بهداشت — دانشآموختگان ·
Ghabzino — سوابق بیمه