diff --git a/.claude/settings.local.json b/.claude/settings.local.json
index c7161c2..dcce089 100644
--- a/.claude/settings.local.json
+++ b/.claude/settings.local.json
@@ -32,7 +32,12 @@
       "Bash(node -e \"const p = require\\('c:/Users/Lenovo/Desktop/balinyaar/client/node_modules/next-intl/package.json'\\); console.log\\(JSON.stringify\\(p.exports['./plugin'] || p.exports, null, 2\\).substring\\(0, 1000\\)\\);\")",
       "Bash(xargs grep -l \"HEADER_LOCALE_NAME\\\\|X-NEXT-INTL\")",
       "Bash(xargs ls)",
-      "Bash(xargs grep \"AppStoreProvider\")"
+      "Bash(xargs grep \"AppStoreProvider\")",
+      "Bash(node -e \"const p = require\\('./node_modules/notistack/package.json'\\); console.log\\('version:', p.version\\); console.log\\('peerDeps:', JSON.stringify\\(p.peerDependencies, null, 2\\)\\)\")",
+      "Bash(node -e \"const n = require\\('c:/Users/Lenovo/Desktop/balinyaar/client/node_modules/notistack'\\); console.log\\(Object.keys\\(n\\)\\)\")",
+      "Bash(Get-ChildItem -Path \"c:\\\\Users\\\\Lenovo\\\\Desktop\\\\balinyaar\\\\client\" -Force)",
+      "Bash(Select-Object Name, PSIsContainer)",
+      "Bash(npm audit *)"
     ],
     "defaultMode": "bypassPermissions"
   }
diff --git a/product/Home-Nursing-Platform-Research-FA.md b/product/Home-Nursing-Platform-Research-FA.md
new file mode 100644
index 0000000..282037b
--- /dev/null
+++ b/product/Home-Nursing-Platform-Research-FA.md
@@ -0,0 +1,292 @@
+# ساخت پلتفرم پرستاری خصوصی در منزل در ایران — گزارش تحقیق و استراتژی
+
+> **ایده:** پلتفرمی که به خانواده‌ها در ایران کمک می‌کند به‌سادگی پرستار خصوصی و احرازهویت‌شده برای عزیزانشان پیدا و استخدام کنند — مراقبت از سالمند، دورهٔ نقاهت پس از جراحی، مراقبت از نوزاد، و مدیریت بیماری‌های مزمن.
+
+**تاریخ تهیه:** ۱۴۰۵/۰۳/۲۶ (2026-06-16)  ·  **دامنه:** (۱) تحلیل بازار و رقبا، (۲) مشکلات و ریسک‌ها، (۳) احراز هویت و اعتبارسنجی صلاحیت پرستار، (۴) چارچوب حقوقی ایران، به‌علاوهٔ توصیه‌های عملی.
+
+**یادداشتی دربارهٔ منابع.** این گزارش ترکیبی است از: (الف) یک مرحلهٔ تحقیق با راستی‌آزمایی متخاصمانه (adversarial) دربارهٔ **چارچوب حقوقی ایران و رقبای داخلی** (ادعاهایی که از فرایند رأی‌گیری سه‌گانه عبور کرده‌اند با **✅ تأییدشده** علامت خورده‌اند؛ ادعاهایی که *رد* شده‌اند صریحاً مشخص شده‌اند)، و (ب) تحقیق هدفمند وب دربارهٔ **پلتفرم‌های خارجی، نمونه‌های شکست/ریسک، و ابزارهای احراز هویت**. هرجا یک واقعیت از صفحهٔ تبلیغاتی خودِ یک شرکت آمده باشد، به‌عنوان «خوداظهاری/حسابرسی‌نشده» علامت خورده؛ و هرجا بر دانش مدل تکیه دارد (نه منبع واکشی‌شده)، با **[تأییدنشده — پیش از اتکا راستی‌آزمایی شود]** علامت خورده است. ارقام سرمایه‌گذاری و هر مقررات دهه‌های گذشته را «پیش از انتشار راستی‌آزمایی کنید».
+
+---
+
+## خلاصهٔ مدیریتی
+
+**می‌توانید این کسب‌وکار را قانوناً در ایران بسازید — اما این یک *فعالیت درمانی دارای مجوز* است، نه یک مارکت‌پلیس آزاد برای راه‌اندازی.** اعتبار اصلی عبارت است از **پروانهٔ تأسیس** به‌علاوهٔ **پروانهٔ مسئول فنی** از وزارت بهداشت، که از طریق **معاونت درمان** و پس از تصویب **کمیسیون قانونی تشخیص امور پزشکی (موضوع مادهٔ ۲۰)** صادر می‌شود. **✅ تأییدشده**
+
+**دو مسیر قانونی وجود دارد و انتخاب میان آن‌ها تعیین‌کننده است:**
+- **مرکز خدمات پرستاری در منزل** (مرکز مشاوره و ارائه مراقبت‌های پرستاری در منزل) — تحت نظر سازمان نظام پرستاری؛ یک **پرستار** (کارشناسی + ۵ سال سابقهٔ بالینی) می‌تواند مؤسس و مسئول فنی باشد. **این گزینهٔ درست برای ایدهٔ شماست.** **✅ تأییدشده**
+- **مرکز خدمات و مراقبت‌های بالینی در منزل** — **هم مؤسس و هم مسئول فنی باید پزشک باشند.** مگر اینکه شریک پزشک داشته باشید، از این مسیر پرهیز کنید. **✅ تأییدشده**
+
+**بازار واقعی و از پیش رقابتی است** — آسانیسم، اسنپ دکتر، سلامت اول و هیراد همگی امروز فعال‌اند — **اما عمدتاً در تهران/کرج متمرکزند و بیشتر به‌صورت اعزام مستقیم نیرو کار می‌کنند، نه به‌عنوان مارکت‌پلیس مبتنی بر اعتماد.** این، شکاف بازار شماست. **✅ تأییدشده**
+
+**سخت‌ترین مسئله، اعتماد و ایمنی است، نه فناوری.** هر داستان عبرت‌آموز در خارج (جریمه‌های نظارتی Care.com، پروندهٔ کلاهبرداری هویتی «پرستار قلابی»، احکام طبقه‌بندی نادرست نیروی کار) به یک قاعده می‌رسد: **مالک فرایند احراز صلاحیت خودتان باشید؛ هرگز آن را به خانواده‌ها واگذار نکنید، و هرگز یک بررسی ایمنی که واقعاً انجام نمی‌دهید را تبلیغ نکنید.**
+
+**خبر خوب دربارهٔ احراز هویت:** ایران یک بازار رقابتی از APIهای آمادهٔ احراز هویت (KYC) دارد (تطبیق شمارهٔ موبایل با کد ملی از طریق **شاهکار**، تطبیق چهره/زنده‌بودن با کارت ملی) که احراز هویت را به ساده‌ترین لایه تبدیل می‌کند. لایهٔ مجوز سخت‌تر است (API عمومی B2B وجود ندارد)، اما **پروانهٔ صلاحیت حرفه‌ای** پرستار از وزارت بهداشت همان اعتباری است که باید مطالبه کنید — چون از پیش شامل بررسی سوء‌پیشینه است.
+
+**جمع‌بندی استراتژیک:** به‌عنوان **مرکز خدمات پرستاری در منزل** ثبت کنید، از همان ابتدا با مراکز دارای مجوز همکاری کنید (مدل آسانیسم) تا سریع حرکت کنید، **اعتماد احرازشده را به کل برند خود تبدیل کنید**، **شهرهای کم‌تر پوشش‌داده‌شده خارج از تهران** را هدف بگیرید، و روی درآمد B2B/نهادی (مسیرهای ترخیص بیمارستانی، بیمه‌گرها، مزایای کارکنان شرکت‌ها) علاوه بر پرداخت مستقیم خانواده‌ها بسازید.
+
+---
+
+# ۱. تحلیل بازار و رقبا
+
+## ۱.۱ بازیگران ایرانی (کسانی که واقعاً با آن‌ها رقابت می‌کنید) ✅ تأییدشده
+
+بازار داخلی **فعال و در حال رشد** است — تا سال ۱۳۹۸ حدود **۷۰۰ شرکت خدمات درمانی در منزل** ثبت شده بودند، با تلاش رسمی برای رساندن آن به حدود ۱٬۰۰۰ (که اکنون تقریباً مطمئناً بیشتر است). **✅ تأییدشده** (منبع واحد سال ۱۳۹۸؛ آن را یک کفِ تاریخی بدانید). رهبران بازار:
+
+| بازیگر | مدل | بخش‌های هدف | نکات قابل‌توجه | قیمت‌گذاری |
+|---|---|---|---|---|
+| **آسانیسم** | مارکت‌پلیس/تطبیق که نیرو را **از طریق مراکز دارای مجوزِ همکار** تأمین می‌کند (مدل واسطه‌ای) | سالمند، کودک، پس از جراحی، مزمن، بالینی (تزریقات، پانسمان، تعویض سوند، خون‌گیری در منزل) | احراز هویت مراقبین، رعایت پروتکل‌های بهداشتی، سفتهٔ تضمین حدود ۴۰ میلیون تومان، و دورهٔ آزمایشی ۲۴–۴۸ ساعته را تبلیغ می‌کند. **تمرکز ~۹۹٪ در تهران/کرج**، ~۱٬۶۵۰ مراقب فعال در ۴ مرکز همکار (خوداظهاری، حسابرسی‌نشده) | فعلی (۱۴۰۴/۱۴۰۵) |
+| **اسنپ دکتر** | عمودیِ سلامتِ اسنپ (بزرگ‌ترین سوپراَپ ایران)؛ اعزام مدیریت‌شده | سالمند، پس از جراحی (مراقبت از زخم، کشیدن بخیه)، نوزاد/کودک، مزمن (سکته مغزی، سرطان، پارکینسون، MS، آلزایمر) | فعال در تهران، کرج، قم، شیراز، کرمانشاه، اصفهان، مشهد. دارای **مجوز عمومی واسطه‌گری پزشکی آنلاین («پل ارتباطی»)** — **نه** مجوز اختصاصی پرستاری در منزل از وزارت بهداشت (این ادعا رد شد) | — |
+| **سلامت اول** | **اعزام مستقیم پرستارهای خودش** (نه مارکت‌پلیس باز) — شرکت پرستار را انتخاب می‌کند | مراقبت از سالمند (ساعتی / روزانه / شبانه‌روزی) | **۳٬۰۰۰+ نیروی فعال**، مرکز تماس ۲۴/۷ (۱۵۲۷)، تهران + حومه (کرج، پردیس). دارای **پروانهٔ رسمی وزارت بهداشت شمارهٔ ۳-۳۸۸۱۸۰** | «توافقی»؛ شیفت‌های شبانه‌روزی به‌ازای هر ساعت ارزان‌تر |
+| **هیراد** | اپ‌محور (کافه‌بازار، مایکت)؛ اعزام/کاریابی مدیریت‌شده | سالمند، کودک/نوزاد، پس از جراحی/نقاهت، تزریقات در منزل، آزمایش در منزل | هر دو سمت را نشان می‌دهد (خانواده‌ها درخواست می‌دهند؛ پرستاران «کارهای موجود» را می‌بینند)؛ «استخدام بدون هزینه» را تبلیغ می‌کند. اعلام می‌کند تحت مجوز وزارت بهداشت فعالیت می‌کند. اقبال محدود | — |
+
+**نتیجه‌گیری برای شما:**
+۱. **مدل غالب، اعزام مستقیم/مدیریت‌شده است، نه مارکت‌پلیس دوطرفهٔ واقعیِ مبتنی بر اعتماد.** حتی بازیگران «شبه‌مارکت‌پلیس» (آسانیسم، هیراد) عملاً مثل آژانس‌های نیروی مدیریت‌شده کار می‌کنند. یک تجربهٔ واقعاً شفاف، مبتنی بر نظرات کاربران، که در آن خانواده پرستار را انتخاب می‌کند، هنوز نسبتاً باز است.
+۲. **تمرکز جغرافیایی شدید است.** تهران/کرج غالب‌اند؛ شهرهای ردهٔ دوم (مشهد، اصفهان، شیراز، تبریز، اهواز، قم) کم‌پوشش‌اند. **این روشن‌ترین فضای خالی بازار است.**
+۳. **قیمت‌گذاری مبهم و توافقی است.** قیمت‌گذاری شفاف و از پیش‌اعلام‌شده یک تمایز ارزشمند برای خانواده‌هاست.
+۴. **«دارای مجوز» یک سیگنال اعتماد واقعی است** — سلامت اول شمارهٔ پروانهٔ وزارت بهداشت خود را برجسته نمایش می‌دهد. شما هم باید این کار را بکنید.
+
+> ⚠️ **ادعاهای ردشده که نباید تکرار شوند:** اسنپ دکتر مجوز اختصاصی پرستاری در منزل از وزارت بهداشت **ندارد** (فقط مجوز عمومی واسطه‌گری)؛ یک نمونهٔ قیمت‌گذاری به‌تفکیک شهر و به‌ازای هر خدمت که به آن نسبت داده شده بود نیز رد شد. اعداد نیروی انسانی رقبا (۱٬۶۵۰ / ۳٬۰۰۰) ارقام تبلیغاتی خوداظهاری‌اند.
+
+## ۱.۲ پلتفرم‌های خارجی (مدل‌هایی برای یادگیری)
+
+پلتفرم‌های خارجی در **چهار مدل ساختاری** دسته‌بندی می‌شوند — دانستن اینکه از کدام مدل تقلید می‌کنید، از هر ویژگی منفرد مهم‌تر است:
+
+۱. **مارکت‌پلیس مصرف‌کنندهٔ خالص** — خانواده‌ها را مستقیم به مراقبینِ *خوداشتغال* وصل می‌کند؛ پلتفرم هیچ‌کس را استخدام نمی‌کند (Care.com، Curam). ارزان برای مقیاس‌پذیری، اما کنترل کیفیت ضعیف و ریسک حقوقی جدی بابت طبقه‌بندی نادرست نیروی کار.
+۲. **مدیریت‌شده / نیروی استخدامی «تمام‌پشته» (full-stack)** — شرکت نیروهای خودش را استخدام، آموزش، احراز و اعزام می‌کند و فناوری را روی آن سوار می‌کند (Honor، Cera، Homage، Portea). کیفیت و دفاع‌پذیری بالاتر؛ سرمایه‌بَر.
+۳. **پلتفرم تأمین نیرو برای مراکز** — شیفت‌های بیمارستان/خانهٔ سالمندان را پر می‌کند، نه مصرف‌کننده (Florence، Vivian Health).
+۴. **تجمیع تقاضا + ادغام با پرداخت‌کننده (بیمه)** — مدل‌های جذب سرنخ / همراهی / بیمه (Papa، Pflege.de).
+
+**روشن‌ترین درس از داده‌ها: سرمایه و قراردادهای پایدار به‌سمت مدل‌های مدیریت‌شده/تمام‌پشته و ادغام‌شده با بیمه جریان دارند، در حالی که مارکت‌پلیس‌های خالصِ پیمانکار مستقل مدام به سقف قانون کار برمی‌خورند.**
+
+### جدول مقایسه (منتخب؛ ارقام سرمایه تقریبی — پیش از اتکا راستی‌آزمایی شود)
+
+| پلتفرم | کشور | مدل | ویژگی شاخص | کسب درآمد | تمایز / دستاورد |
+|---|---|---|---|---|---|
+| **Care.com** | آمریکا | مارکت‌پلیس اشتراکی خالص | پروفایل، نظرات، بررسی پیشینهٔ *اختیاریِ پولی* | اشتراک خانواده + مراقب؛ افزونهٔ بررسی پیشینه؛ **بدون سهم از دستمزد** | بزرگ‌ترین/گسترده‌ترین. **داستان عبرت** — تسویهٔ ۸٫۵ میلیون دلاری FTC (۲۰۲۴)، ۱ میلیون دلار Marin DA (۲۰۲۰) |
+| **Honor** | آمریکا | تمام‌پشتهٔ مدیریت‌شده + فرنچایز | پلتفرم فناوری+عملیات؛ جذب شبکهٔ جهانی Home Instead | B2B + فرنچایز؛ مراقبت ساعتی | یونیکورن (~۱٫۲۵ میلیارد دلار+)؛ ~۲٫۱ میلیارد دلار با Home Instead؛ ۱۰۰هزار+ مراقب |
+| **Papa** | آمریکا | همراهی + مراقبتِ پرداخت‌شده توسط بیمه | «Papa Pals» همراهی برای تنهایی؛ راهبری مراقبت | **قرارداد B2B با Medicare Advantage / Medicaid / کارفرماها** | تنهایی را به یک نیاز سلامتیِ قابل‌صورت‌حساب تبدیل کرد؛ ۱۵۰ میلیون دلار Series D |
+| **Cera** | بریتانیا | تمام‌پشتهٔ مدیریت‌شده + هوش مصنوعی پیش‌بین | پیش‌بینی زمین‌خوردن/بستری روزها قبل؛ ثبت علائم حیاتی توسط مراقب | **B2B با NHS و ۱۵۰+ شهرداری** | مالکیت هم‌زمان نیرو *و* داده؛ یونیکورن ~۱ میلیارد دلار (۲۰۲۵) |
+| **Florence** | بریتانیا | مارکت‌پلیس تأمین نیرو برای مراکز | رزرو فوری شیفت؛ برنامه/حقوق/آموزش؛ بررسی DBS | کمیسیون به‌ازای شیفت + SaaS | حذف واسطه‌های گران آژانس پرستاری |
+| **Curam** | بریتانیا | مارکت‌پلیس خالص (خوداشتغال) | بررسی DBS + احراز بیومتریک؛ بیمهٔ همراه | **کمیسیون ۱۲٫۵٪ + مالیات** (مراقب ~۸۵٪ نگه می‌دارد) | مدل کم‌کارمزدِ خوداشتغال |
+| **Homage** | سنگاپور (+مالزی/استرالیا) | **مارکت‌پلیس گزینش‌شده + تطبیق انسانی** | الگوریتم نامزدها را پیشنهاد می‌دهد، *کارکنان* تطبیق نهایی را انجام می‌دهند؛ تله‌مدیسین؛ ادغام با یارانهٔ دولتی | حاشیهٔ ساعتی (~۳–۶ دلار سنگاپور) + بسته‌ها + B2B | شبکهٔ گزینش‌شدهٔ توانمند بالینی؛ ۳۰ میلیون دلار Series C (Temasek). **بهترین تناسب مدل برای ایران** |
+| **Portea Medical** | هند | ارائه‌دهندهٔ بالینی مدیریت‌شده | فیزیوتراپی، پرستاری، ویزیت پزشک، آزمایش، **اجارهٔ تجهیزات**؛ بستهٔ «NRI» برای مهاجران | اشتراک + به‌ازای ویزیت + اجاره | بزرگ‌ترین در هند؛ ~۱۱۴ میلیون دلار جذب کرده |
+| **Nightingales / Care24 / HCAH** | هند | ارائه‌دهندگان بالینی مدیریت‌شده | برنامه‌های مزمن/تخصصی؛ **صورت‌حساب بیمه‌ایِ بدون پرداخت نقدی** (HCAH، ۴۰+ بیمه‌گر) | اشتراک + به‌ازای ویزیت + B2B | بازار به‌سرعت در حال تجمیع (هر دو خریداری شدند) |
+| **Manzil / NMC Homecare** | امارات | سلامت خانگی بالینی دارای مجوز | اعتباربخشی JCI؛ یکپارچه با بیمارستان؛ تزریق وریدی، فیزیوتراپی، مادر و نوزاد | حق‌الزحمه‌محور، **صورت‌حساب بیمه‌ای** | اعتبار بالینی درجه‌یک |
+| **Veteranpoolen** | سوئد | تأمین نیرو با استخدام **بازنشستگان** | قیمت‌گذاری متناسب با کسر مالیاتی RUT (۵۰٪) سوئد | کارمزد یارانه‌ای RUT + فرنچایز | تأمین نیروی منحصربه‌فرد (بازنشستگان فعال) |
+| **Bakıcıburada** | ترکیه | آگهی‌های طبقه‌بندی‌شدهٔ مراقب | تأیید هویت + سوءپیشینه؛ کشف روی نقشه | کارمزد آگهی/اشتراک | بدون سرمایهٔ ریسک‌پذیر؛ **نزدیک‌ترین آنالوگ به بازار واقع‌بینانهٔ مرحلهٔ اولیهٔ ایران** |
+
+### مهم‌ترین سیگنال‌های منطقه‌ای
+- **هند نزدیک‌ترین آنالوگ است** (جمعیت زیاد، پوشش عمومیِ کم، پرداخت از جیب خانواده). نکتهٔ گویا: **هیچ مارکت‌پلیس خالصِ خانواده‌به‌مراقب در آنجا غالب نیست** — همهٔ رهبران مدلِ بالینیِ مدیریت‌شده/استخدامی دارند، چون کشور فاقد آموزش ساختاریافتهٔ پیراپزشکی است، پس **احراز و کنترل کیفیت *خودِ محصول* است.**
+- در **آلمان** تنها تلاش برای تطبیق مراقبِ مدیریت‌شده (Careship) **ورشکست شد**؛ بازماندگان مدل‌های کم‌سرمایهٔ جذب‌سرنخ/آگهی + کالای مصرفیِ یارانه‌ایِ بیمه‌اند.
+- **ترکیه** عمدتاً آگهی‌های طبقه‌بندی‌شدهٔ خوداتکا و آژانس‌های کوچک است — تصویری واقع‌بینانه از آیندهٔ نزدیک ایران.
+
+### پنج ایدهٔ قابل‌انتقال برای یک بنیان‌گذار ایرانی
+۱. **یک «اوبر برای پرستارها»ی خالص از پیمانکاران مستقل نسازید.** روشن‌ترین شکست‌ها (ورشکستگی Careship؛ بازطبقه‌بندی نظافتچیان گیگِ Helpling به‌عنوان کارمند؛ رسوایی‌های کیفیت Care.com) همگی مدل‌های گیگ خالص‌اند. برای مراقبت، نقطهٔ بهینهٔ اثبات‌شده یک **مارکت‌پلیس گزینش‌شده + احراز انسانی** است (مدل **Homage**: الگوریتم نامزدها را رو می‌کند، *تیم شما* تطبیق نهایی را انجام می‌دهد و مالک احراز/آموزش است).
+۲. **احراز و آموزش را به محصول اصلی تبدیل کنید، نه افزونهٔ پولی.** در هر بازاری با زیرساخت ضعیف صدور مجوز، برندگان مالک کیفیت مراقب‌اند. در ایران، **زیرساخت اعتماد، کلِ ارزش پیشنهادی است** — آن را به‌صورت پیش‌فرض بسته‌بندی کنید؛ مثل Care.com آن را به‌صورت آپ‌سل نفروشید.
+۳. **زود به‌سمت پرداخت‌کنندگان نهادی B2B حرکت کنید.** ارزشمندترین خروجی‌ها از طریق نهادها کسب درآمد می‌کنند: Cera (NHS)، Papa (Medicare Advantage)، HCAH (بیمه‌گرها). آنالوگ‌های ایران: **سازمان تأمین اجتماعی، بیمهٔ سلامت/بیمه‌گرها، ارجاع‌های ترخیص بیمارستانی، و مزایای کارکنان شرکت‌ها.** ترخیص پس از جراحی/سکته یک کانال جذب با نیت بالاست.
+۴. **دو موتور درآمدی را روی هم سوار کنید و دنبال یک قلابِ یارانه باشید.** (الف) کارمزد/حاشیهٔ ساعتی روی مراقبت مدیریت‌شده، به‌علاوهٔ (ب) اشتراک/جذب‌سرنخ. جعبهٔ کالای مصرفیِ بیمه‌ایِ آلمان و کسر مالیاتی ۵۰٪ RUT سوئد قدرت **اتصال به یک یارانهٔ موجود** را نشان می‌دهند تا خدمت برای خانواده ارزان به‌نظر برسد — بررسی کنید آیا بیمه‌گر، خیریه یا موقوفهٔ سالمندان ایرانی می‌تواند ویزیت‌ها را یارانه دهد.
+۵. **یک ردهٔ سبک‌ترِ «همراهی / کمک در امور روزمره» را جداگانه محصول‌سازی کنید.** Papa یک کسب‌وکار در مسیر یونیکورن را نه روی پرستاری ماهر بلکه روی *همراهی سالمندانِ منزوی* ساخت — مهارت کمتر، تأمین نیروی آسان‌تر، بازار وسیع‌تر، و آپ‌سل به مراقبت بالینی هنگام تشدید نیاز. با توجه به دیاسپورای بزرگ ایران، زاویهٔ **«فرزندان دور که هزینهٔ مراقبت از والدینشان در وطن را می‌پردازند»** (بستهٔ NRI پورتیا؛ کاربران مهاجرِ Homage) مستقیماً مرتبط است.
+
+> **کم‌ریسک‌ترین نقطهٔ ورود:** رویکرد «SaaS برای ارائه‌دهندگان» شرکت Birdie — فروش نرم‌افزار زمان‌بندی/انطباق/داشبورد خانواده *به* آژانس‌های موجود مراقبت در منزل ایران به‌جای رقابت مستقیم — اگر صدور مجوز/طبقه‌بندی نیروی کار در ابتدا مانعی جدی شد، ارزش نگه‌داشتن در آستین را دارد.
+
+---
+
+# ۲. مشکلات و ریسک‌ها
+
+این حوزه دو ویژگی غیرعادی و خطرناک را با هم دارد: خریداران **افراد آسیب‌پذیرند** (سالمند، پس از جراحی، نوزاد، بیمار مزمن) و خدمت **بدون نظارت، داخل خانهٔ خصوصی** انجام می‌شود. این ترکیب هر ریسک معمول مارکت‌پلیس را تشدید می‌کند و ابعاد مرگ‌وزندگی به آن می‌افزاید.
+
+**مهم‌ترین درس استراتژیک:** *پلتفرمی که ایمنی را تبلیغ کند ولی احراز واقعی را به خانواده‌ها واگذار کند، سرانجام با فاجعهٔ نظارتی، حقوقی و اعتباری روبه‌رو خواهد شد.*
+
+## ۲.۱ شکست‌های اعتماد و ایمنی
+**ریسک:** اتصال غریبه‌ها به افراد آسیب‌پذیر بدون احراز دقیقِ *تحت‌مالکیت پلتفرم*، راه را برای سرقت، سوءاستفاده، کلاهبرداری و آسیب مرگبار باز می‌کند — و افکار عمومی *پلتفرم* را مقصر می‌داند.
+
+**نمونه‌های واقعی:**
+- **Care.com / تحقیق وال‌استریت‌ژورنال (۲۰۱۹):** طی ~۶ سال، **۹ مراقب فهرست‌شده در Care.com که سابقهٔ پلیسی داشتند، بعداً به جرایمی متهم شدند که هنگام مراقبت از کودک یا سالمند رخ داد — از جمله سرقت، کودک‌آزاری، تجاوز جنسی و قتل.** سایت همچنین صدها آگهی مهدکودک داشت که به‌دروغ ادعای مجوز ایالتی می‌کردند. ([Daily Beast/WSJ](https://www.thedailybeast.com/wsj-kids-assaulted-died-in-hands-of-carecom-caregivers/))
+- **پاک‌سازی انبوه آگهی‌ها:** Care.com حدود **۴۶٬۵۹۴ آگهی مهدکودک (~۴۵٪ آن پایگاه داده)** را پس از کشف جعلی/ناموجود بودن حذف کرد. ([Engadget](https://www.engadget.com/2019-03-31-care-com-pulls-47000-daycare-listings.html))
+- **«پرستار قلابی» (Shannon Womack، ۲۰۲۵):** ادعا می‌شود با **۲۰+ نام مستعار و ۷ شمارهٔ تأمین اجتماعی**، با سرقت مدارک چهار پرستار واقعی، خود را پرستار جا زده و با **ارائهٔ مدارک جعلی از طریق آژانس‌های تأمین نیرو** در **۹+ مرکز** کار کرده — حتی یک شرکت قلابی برای خوداعزامی ساخته است. متهم به **۴۳ فقره** اتهام، از جمله به‌خطرانداختن فرد وابسته به مراقبت و سرقت دارو از سالمندان. ([Nurse.org](https://nurse.org/news/fake-nurse-arrested-shannon-womack-nursing-fraud/)) — *درس کلیدی برای یک مارکت‌پلیس پرستار: حتی آژانس‌هایی که فکر می‌کردند احراز می‌کنند، با هویت سرقتی + مدارک جعلی شکست خوردند.*
+
+**راهکارهای کاهش ریسک:**
+- **مالک احراز خودتان باشید؛ هرگز به خانواده‌ها واگذار نکنید.** احراز هویت + سوءپیشینه + اعتبارسنجی مجوز را به‌عنوان یک *دروازهٔ اجباریِ تحت‌مالکیت پلتفرم* پیش از قابل‌رزرو شدن هر پرستار قرار دهید.
+- **اعتبار را در منبع رسمی راستی‌آزمایی کنید**، نه با فایل آپلودی (که دقیقاً همان چیزی است که جعل می‌شود). در ایران: سامانهٔ **سازمان نظام پرستاری** و **پروانهٔ صلاحیت حرفه‌ای** وزارت بهداشت (بخش ۳ را ببینید).
+- **هر پروفایل را به کد ملی + سلفی زنده گره بزنید** تا الگوی نام‌های مستعار/هویت سرقتی خنثی شود.
+- **به‌صورت دوره‌ای بازبینی کنید** (انقضای مجوز، تعلیق‌ها، سوابق جدید).
+
+## ۲.۲ مسئولیت حقوقی و قرار گرفتن در معرض دعوا
+**ریسک:** سه نوع قرارگیری در معرض ریسک روی هم انباشته می‌شوند — **(الف) طبقه‌بندی نادرست نیروی کار** (نامیدن پرستارها به‌عنوان «پیمانکار» در حالی که قانون آن‌ها را کارمند می‌داند)، **(ب) مسئولیت نیابتی / استخدام سهل‌انگارانه** (وقتی مراقب به بیمار آسیب می‌زند)، و **(ج) شکاف‌های بیمه‌ای**. دفاعِ «ما فقط یک پلتفرم فناوری بی‌طرفیم» در سراسر جهان در حال فرسایش است.
+
+**نمونه‌های واقعی:**
+- **حکم ۱۰ میلیون دلاری کالیفرنیا علیه TLC Home Care** بابت طبقه‌بندی نادرست نیروهای منزل به‌عنوان پیمانکار (۲۰۲۳). ([HRMorning](https://www.hrmorning.com/news/worker-misclassification-tlc-home-care/))
+- دادگاه‌های فدرال مکرراً مراقبینِ منزل را **کارمند، نه پیمانکار** تشخیص می‌دهند — *هرچه مراقبت را برای کیفیت بیشتر استانداردسازی و نظارت کنید، بیشتر شبیه کارفرما به‌نظر می‌رسید.* ([Ogletree Deakins](https://ogletree.com/insights-resources/blog-posts/federal-court-finds-in-home-caregivers-were-employees-not-independent-contractors-under-economic-realities-control-test/))
+
+**راهکارهای کاهش ریسک:**
+- **مدل را آگاهانه انتخاب کنید:** یا یک *مارکت‌پلیس بی‌طرف واقعی* (کنترل حداقلی؛ خانواده کارفرماست) یا یک *مدل کامل آژانس/کارفرما* (حقوق، نظارت، بیمه). **میانهٔ خطرناک — کنترل زیاد برای «کیفیت» اما طبقه‌بندی پیمانکار برای «هزینه» — دقیقاً همان چیزی است که احکام طبقه‌بندی نادرست را فعال می‌کند.**
+- **[تأییدنشده — با وکیل محلی بررسی شود]** تعهدات قانون کار و تأمین اجتماعی ایران به رابطهٔ استخدامی تعلق می‌گیرند؛ *پیش* از راه‌اندازی، طبقه‌بندی را درست انجام دهید. (به شکاف قانون کار برای پرستاران منزل در بخش ۴.۵ توجه کنید — این مسئله دوسویه است: هزینهٔ الزامیِ کمتر، اما وضعیت حل‌نشده.)
+- **بیمهٔ مسئولیت عمومی + حرفه‌ای در سطح پلتفرم داشته باشید**، و از پرستارها هم بخواهید بیمهٔ خود را داشته باشند.
+- **هر مرحلهٔ احراز را مستند کنید** — هم پیشگیری است و هم دفاع حقوقی شما در برابر دعاوی استخدام سهل‌انگارانه.
+
+## ۲.۳ مشکلات عملیاتی و کنترل کیفیت
+**ریسک:** جابه‌جایی شدید مراقب، غیبت‌هایی که بیمار آسیب‌پذیر را بی‌سرپرست می‌گذارند، تنوع گستردهٔ کیفیت، نظارت از راه دور تقریباً غیرممکن، و **حذف واسطه (disintermediation)** (جفت‌شدن خانواده + پرستار خارج از پلتفرم برای فرار از کارمزد).
+
+**داده‌های واقعی:**
+- جابه‌جایی مراقب در ۲۰۲۴ به **~۷۹٪** رسید، با **~۷۰٪ ترک کار طی ۱۰۰ روز اول**؛ هر خروج **۲٬۶۰۰ تا ۵٬۰۰۰ دلار** هزینه دارد و مشتری اغلب همراه مراقب می‌رود. ([ShiftCare](https://shiftcare.com/us/blog/caregiver-retention-in-2026-what-the-data-tells-us-about-turnover))
+- **حذف واسطه، حالت شکستِ قابل‌پیش‌بینی** برای خدمات تکراری و مبتنی بر رابطه است — وقتی اعتماد شکل گرفت، خانواده و پرستار خصوصی معامله می‌کنند. تاکتیک‌های تنبیهی ضدِ حذف واسطه معمولاً نتیجهٔ معکوس می‌دهند. ([Sharetribe](https://www.sharetribe.com/academy/how-to-discourage-people-from-going-around-your-payment-system/))
+
+**راهکارهای کاهش ریسک:**
+- **تأیید الکترونیکی ویزیت (EVV):** ورود/خروج با GPS و مهر زمانی، با هشدار خودکار ویزیت ازدست‌رفته، تا غیبت‌ها فوری اعزام جایگزین را فعال کنند.
+- **تضمین پوشش/جایگزین:** یک ذخیرهٔ پرستار آماده و وعدهٔ پرکردن سریع غیبت — دلیل اصلی استفاده از شما به‌جای استخدام خصوصی.
+- **با ارزش‌آفرینیِ ماندگار بر حذف واسطه غلبه کنید، نه با قفل‌کردن:** زمان‌بندی/پرداخت یکپارچه، تضمین جایگزین، بیمه‌ای که *فقط* روی رزروهای داخل پلتفرم اعمال می‌شود، و نظرات/حمایت در اختلافات که با خروج از پلتفرم از بین می‌رود.
+- **تطبیق مبتنی بر تداوم:** یک پرستار اصلی + جایگزین مشخص برای هر بیمار؛ تداوم را به‌عنوان یک KPI ردیابی کنید.
+
+## ۲.۴ ریسک‌های پرداخت و کلاهبرداری
+**ریسک:** پرداخت خارج از پلتفرم (سمت مالیِ حذف واسطه)، نظرات جعلی، کلاهبرداری هویتی، جعل مدرک، و **سوءاستفادهٔ مالی از سالمند.**
+
+**داده‌های واقعی:**
+- کلاهبرداری در مارکت‌پلیس‌های گیگ حدود **۲ برابر** سایر جاهاست؛ یک گزارش ۲۰۲۵ افزایش ۲۱٪ سالانه را گزارش کرد که **>۹۰٪ آن جعل هویت بود**. ([Security Boulevard](https://securityboulevard.com/2024/05/when-the-gig-is-fraud-building-trust-for-online-marketplaces-with-identity-verification/))
+- **سوءاستفادهٔ مالی از سالمند:** بررسی CFPB نشان داد جایی که قربانی مرتکب را می‌شناخت، **۱ نفر از هر ۹ نفر یک مراقب غیرخانوادگی بود، با میانگین خسارت ۵۷٬۸۰۰ دلار.** ([AARP](https://www.aarp.org/money/scams-fraud/financial-abuse-home-care-aide/))
+- **جریمه‌های Care.com:** **۲۰۲۰ — ۱ میلیون دلار Marin County DA** (ادعای دروغین که بررسی‌ها رجیستری ملی متخلفان جنسی را جست‌وجو می‌کنند؛ تمدیدهای خودکار نادرست)؛ **۲۰۲۴ — ۸٫۵ میلیون دلار FTC** (تورم تعداد مشاغل موجود — بیش از نیمی از آگهی‌ها از کاربرانی بود که نمی‌توانستند واقعاً استخدام کنند — به‌علاوهٔ الگوی فریبندهٔ لغو اشتراک). ([CNBC](https://www.cnbc.com/2024/08/26/carecom-reaches-8point5-million-us-ftc-settlement-over-job-listings-renewals-.html))
+
+**راهکارهای کاهش ریسک:**
+- **احراز هویت قوی هنگام ثبت‌نام** (گره به کد ملی + تشخیص زنده‌بودن) برای *هم* پرستار *و هم* خانوادهٔ پرداخت‌کننده.
+- **نظرات را به رزروهای کامل‌شده و احرازشده داخل پلتفرم گره بزنید.**
+- **پرداخت امانی (escrow) داخل پلتفرم با حل اختلاف** — هم کلاهبرداری را کم می‌کند *و هم* قوی‌ترین اهرم ضدِ حذف واسطه است.
+- **از دارایی مالی مشتریان محافظت کنید** (به خانواده‌ها توصیه کنید: کارت‌ها را امن نگه دارند، دسترسی فقط‌خواندنی، مراقب تغییرات ناگهانی وکالت/وصیت باشند)؛ ضمانت پرستار در برابر سرقت را در نظر بگیرید.
+- **هرگز تضمین یا بررسی‌ای که انجام نمی‌دهید را تبلیغ نکنید، و لغو اشتراک را واقعاً آسان کنید** — هر جریمهٔ Care.com به تبلیغ فریبندهٔ ایمنی یا الگوهای تاریک برمی‌گردد.
+
+## ۲.۵ پویایی‌های اعتماد ویژهٔ مراقبت از افراد آسیب‌پذیر در منزل
+خدمت **به‌تنهایی، بدون مشاهده، داخل خانه** و به افرادی ارائه می‌شود که اغلب **نمی‌توانند به‌طور قابل‌اتکا گزارش دهند** چه رخ داده (نوزاد؛ بیماران دمانس، پس از بیهوشی، یا دارای اختلال شناختی). عدم تقارن اطلاعات شدید است و یک حادثهٔ منفرد می‌تواند یک برند شکننده را نابود کند.
+
+**راهکارها:** جبران عدم‌مشاهده با **نظارت ساختاریافته** — EVV، تماس‌های نظارتیِ دوره‌ای توسط پرستار ارشد، گزارش‌های مراقبتیِ قابل‌رؤیت برای خانواده، دوربین‌های داخل منزل با رضایت در فضاهای مشترک؛ یک **حلقهٔ بازخورد دوطرفه** که بیمار تنها منبع آن نباشد؛ **پروتکل‌های واکنش سریع به حادثه** با تعلیق فوری در صورت شکایت معتبر؛ و **تطبیق صلاحیت با حدّت بیماری** (موارد پرحدّت پس از جراحی/تنفسی فقط به پرستارهای احرازشده؛ همراهی‌های سبک به مراقبان سطح پایین‌تر).
+
+---
+
+# ۳. احراز هویت و اعتبارسنجی صلاحیت پرستار
+
+**پرسش «آیا این پرستار واقعاً همان است که می‌گوید و واقعاً دارای مجوز است؟» به دو بررسی تقسیم می‌شود که باید مراحل جداگانهٔ خط لوله باشند:**
+- **بررسی مجوز** — *آیا پرستار رسمی است؟* (سامانهٔ ثبت حرفه‌ای)
+- **بررسی هویت + پیشینه** — *آیا همان است که ادعا می‌کند، بدون سابقهٔ ردکننده؟* (KYC + سوءپیشینه)
+
+## ۳.۱ مدل‌های مرجع جهانی (بهترین رویه‌ها برای الگوبرداری)
+- **آمریکا — Nursys / e-Notify (استاندارد طلایی):** تنها پایگاه دادهٔ ملی مجوز، تغذیه‌شده توسط هیئت‌های ایالتی پرستاری؛ **e-Notify تغییرات وضعیت مجوز/انضباطی را *پوش* می‌کند** به کارفرمایان ثبت‌نام‌شده از طریق یک **API**. — *درس: نظارت پیوسته، نه احراز یک‌باره.*
+- **بریتانیا — سامانهٔ NMC + DBS:** سامانهٔ آنلاین NMC (رایگان، به‌روزرسانی روزانه) به پرسش *«آیا دارای مجوز است؟»* پاسخ می‌دهد؛ بررسی جداگانهٔ سوءپیشینهٔ **DBS** به *«آیا ایمن است؟»* — *درس: دو بررسی را مجزا نگه دارید.*
+- **شرکت‌های بررسی پیشینه (Checkr، Sterling):** API-محور، ساخته‌شده برای جاسازی در جریان‌های گیگ/مارکت‌پلیس؛ یک بررسی مراقب شامل سابقهٔ کیفری، اعتبارسنجی مجوز، تحریم‌های درمانی، رجیستری سوءاستفاده، اشتغال/تحصیلات، و بازبینی مجدد است.
+
+**یک خط لولهٔ مستحکم = رضایت ← احراز هویت ← اعتبارسنجی مجوز (منبع اصلی) ← بررسی سوءپیشینه + رجیستری سوءاستفاده ← اشتغال/تحصیلات ← نظارت پیوسته.**
+
+## ۳.۲ ابزارهای مخصوص ایران (بخش عملیاتی)
+
+ایران یک پشتهٔ قابل‌استفاده دارد، اما **میان نهادهای ناظر پراکنده است**، و حساس‌ترین بررسی (سوءپیشینه) **محدود به رضایت فرد** است، نه قابل‌استخراج آزاد توسط یک شرکت.
+
+### الف) مجوز حرفه‌ای — «آیا این یک پرستار واقعی است؟» (دو مرجع، هر دو را بررسی کنید)
+- **پروانهٔ صلاحیت حرفه‌ای وزارت بهداشت** در **Rn.behdasht.gov.ir** — اعتبارِ جدیدتر و **معتبرتر**. صدور آن از پیش وضعیت **علمی، اخلاقی، سلامت، و سوءپیشینهٔ** پرستار را بررسی می‌کند، و وزارت بهداشت اعلام کرده که این پروانه **حتی برای پرستاری خصوصی در منزل لازم است.** **[مهم‌ترین اعتبار برای مطالبه — چون شامل بررسی سوءپیشینه است]** ([behdasht.gov.ir](https://behdasht.gov.ir/))
+- **شمارهٔ نظام پرستاریِ سازمان نظام پرستاری** از طریق `ino.ir` / `membership.ino1.ir`. طبق گزارش‌ها امکان استعلام/اعتبارسنجی شمارهٔ عضویت یک پرستار توسط شخص ثالث وجود دارد؛ به‌عنوان **بررسی متقاطع** استفاده کنید. ([heyvagroup](https://www.heyvagroup.com/shownews/11343/))
+- **برای هیچ‌کدام یک API عمومی B2B یافت نشد** — استفادهٔ واقع‌بینانهٔ امروزی **مطالبهٔ آپلود + راستی‌آزمایی دستی در برابر سابقهٔ رسمی** است. (جست‌وجوی عضو عمومیِ نظام پزشکی در `membersearch.irimc.org` نشان می‌دهد یک جست‌وجوی معادل پرستاری چطور می‌تواند باشد.) **[نبود API «یافت نشد» است، نه قطعاً تأییدشده — از طریق یک پورتال B2B بررسی شود]**
+
+### ب) احراز هویت — لایهٔ *آسان* (APIهای آماده وجود دارند)
+یک بازار رقابتی از **فروشندگان e-KYC** ایرانی APIهای آماده می‌فروشند — **این را بخرید، نسازید:**
+- **شاهکار:** سرویس دولتی تطبیق **شمارهٔ موبایل ↔ کد ملی**؛ توسط سازمان تنظیم مقررات (CRA). نتیجه در <۱ ثانیه. **دسترسی محدود است** (تأیید + قرارداد + اتصال غیرمستقیم از طریق پلتفرم «سرو»)، پس **آن را از طریق یک فروشنده مصرف کنید**، نه مستقیم. ([fa.wikipedia](https://fa.wikipedia.org/wiki/سامانه_شاهکار))
+- **صحت‌سنجی کد ملی:** نام + نام خانوادگی + کد ملی ← تطبیق.
+- **تطبیق چهره/زنده‌بودن با عکس کارت ملی یا ثبت احوال:** ارائه‌شده توسط **فینوتک، یوآیدی، جیبیت، فراشناسا، ونیفای، کاوشک** و دیگران — زنده‌بودن + تطبیق چهره + OCR، اغلب با ۵–۱۳ میلیون+ سابقهٔ احراز. ([عصر تراکنش: ۸ شرکت ایرانی KYC](https://asretarakonesh.ir/index.php/2024/01/02/نگاهی-به-خدمات-۸-شرکت-ایرانی-فعال-در-حوز/))
+- این فروشندگان اتصالات بالادستیِ محدودشده توسط ناظر را برای شما مدیریت می‌کنند؛ یک شرکت ثبت‌شده ثبت‌نام و APIهای REST را مصرف می‌کند.
+
+### ج) سوءپیشینه — گواهی عدم سوء پیشینه (محدود به رضایت، بدون API شرکتی)
+- گواهی رسمی «عدم سوءپیشینه»، که توسط **خودِ فرد** به‌صورت آنلاین از طریق **adliran.ir** با رمز شخصی **ثنا** یا حضوری از طریق **پلیس +۱۰** دریافت می‌شود. ([heyvalaw](https://www.heyvalaw.com/web/articles/view/1865/))
+- **یک پلتفرم نمی‌تواند آن را استخراج کند** — هیچ API شخص‌ثالث/کارفرما وجود ندارد؛ صدور به رمز شخصی ثنای فرد گره خورده است. **طراحی واقع‌بینانه: از پرستار بخواهید گواهی خود را دریافت و آپلود کند، سپس به‌صورت دوره‌ای دوباره درخواست شود** — *و توجه کنید این بررسی از پیش در پروانهٔ صلاحیت حرفه‌ای وزارت بهداشت گنجانده شده*، پس مطالبهٔ آن پروانه بخشی از این را پوشش می‌دهد.
+
+### د) ریل‌های پشتیبان
+- **ثنا:** سامانهٔ هویت/ابلاغ الکترونیک قوهٔ قضائیه — عمدتاً به‌عنوان **دروازهٔ دریافت گواهی عدم سوء پیشینه** مرتبط است.
+- **سجام:** KYC بازار سرمایه (اوراق بهادار) — **عمدتاً نامرتبط** اینجا، جز به‌عنوان گواهی بر اینکه ریل‌های قویِ e-KYC غیرحضوری در ایران وجود دارند.
+
+## ۳.۳ خط لولهٔ پیشنهادیِ احراز برای پلتفرم شما
+
+| مرحله | هدف | ابزار ایران / روش | برنامه‌پذیر؟ |
+|---|---|---|---|
+| **۰. رضایت** | مبنای قانونی برای احراز + ذخیرهٔ داده | رضایت صریح داخل اپ هنگام ثبت‌نام | — |
+| **۱. هویت** | تطبیق فرد ↔ کد ملی ↔ موبایل ↔ چهره | **شاهکار** + **صحت‌سنجی کد ملی** + **تطبیق زنده‌بودن ویدیو/عکس با کارت ملی**، از طریق **یک فروشندهٔ KYC** (فینوتک / یوآیدی / جیبیت / فراشناسا / ونیفای) | **بله — API آماده** |
+| **۲. مجوز** | اعتبارسنجی صلاحیت پرستاری در منبع | **پروانهٔ صلاحیت حرفه‌ای وزارت بهداشت** (Rn.behdasht.gov.ir) به‌عنوان اصلی **+** **شمارهٔ نظام پرستاری** (ino.ir) به‌عنوان بررسی متقاطع | **دستی** (API عمومی یافت نشد) — آپلود + راستی‌آزمایی |
+| **۳. سوءپیشینه** | بدون سابقهٔ ردکننده | **عدم سوء پیشینه** — پرستار خودش از adliran.ir/ثنا درخواست و آپلود می‌کند؛ *بخشی* با پروانهٔ وزارت بهداشت پوشش داده می‌شود | **بدون API شرکتی** — محدود به رضایت، آپلود توسط پرستار |
+| **۴. نظارت پیوسته** | کشف لغو/انقضا | راستی‌آزمایی دوره‌ای اعتبار مجوز + درخواست مجدد عدم سوء پیشینه (مثلاً سالانه)؛ اجرای مجدد شاهکار هنگام تغییر موبایل | نیمه‌دستی؛ تقلید از Nursys e-Notify |
+
+**قواعد عملی:** (۱) **احراز هویت را بخرید** از طریق یک ارائه‌دهندهٔ KYC — این بار دسترسیِ محدودشدهٔ شاهکار/ثبت احوال را به فروشنده‌ای منتقل می‌کند که از پیش قراردادها را دارد. (۲) **بررسی مجوز را روی پروانهٔ صلاحیت حرفه‌ای وزارت بهداشت لنگر کنید** (الزامی دولتی برای پرستاری در منزل و شامل بررسی سوءپیشینه). (۳) **گواهی سوءپیشینه را خوداظهاری + محدود به رضایت بدانید.** (۴) **نظارت پیوسته بسازید**، نه یک‌باره. (۵) **مراقب قرارگیری در معرض حفاظت داده باشید** — مسیریابی از طریق یک واسط KYC دارای مجوز شما را منطبق نگه می‌دارد.
+
+---
+
+# ۴. چارچوب حقوقی در ایران
+
+**پاسخ کوتاه: هیچ قانونی *علیه* این ایده وجود ندارد — اما این یک فعالیت درمانی نظارت‌شده است که نیازمند مجوز وزارت بهداشت است. فعالیتِ بدون پروانه همان چیزی است که غیرقانونی است، و جریمه‌ها تا لغو دائم و ارجاع قضایی تشدید می‌شوند.** **✅ تأییدشده**
+
+## ۴.۱ چارچوب حاکم ✅ تأییدشده
+- صدور مجوز از طریق **معاونت درمان وزارت بهداشت**، پس از تصویب **کمیسیون قانونی تشخیص امور پزشکی (موضوع مادهٔ ۲۰)**، تحت **قانون امور پزشکی مصوب ۱۳۳۴ (اصلاحیهٔ ۱۳۶۷)** و **آیین‌نامهٔ مراقبت در منزل مصوب ۱۳۷۸/۷/۱۷** (۲۱ ماده، ۶ تبصره) جریان دارد.
+- **به هر مرکز یک پروانهٔ تأسیس و یک پروانهٔ مسئول فنی اعطا می‌شود.**
+- منابع: [arakmu.ac.ir](https://arakmu.ac.ir/vct/fa/regulation/1063/)، [mcls.gov.ir/fa/law/61](https://www.mcls.gov.ir/fa/law/61)، [qavanin.ir (مادهٔ ۲۰)](https://qavanin.ir/Law/TreeText/83385).
+
+## ۴.۲ دو مسیر — مسیر پرستاری را انتخاب کنید ✅ تأییدشده
+| | **مرکز خدمات پرستاری در منزل** (گزینهٔ شما) | مرکز خدمات و مراقبت‌های بالینی در منزل |
+|---|---|---|
+| نام | مرکز مشاوره و ارائه مراقبت‌های پرستاری در منزل | مرکز خدمات و مراقبت‌های بالینی در منزل |
+| تحت نظر | سازمان نظام پرستاری | مستقیماً وزارت بهداشت |
+| چه کسی مؤسس/مسئول فنی شود | **یک پرستار** — کارشناسی پرستاری + **۵ سال سابقهٔ بالینی** (می‌تواند هم مؤسس و هم مسئول فنی باشد) | **هم مؤسس و هم مسئول فنی باید پزشک باشند** |
+| تناسب با ایدهٔ شما | ✅ پرستاری در منزل برای سالمند / پس از جراحی / نوزاد / مزمن | فقط اگر شریک پزشک داشته باشید |
+
+> ⚠️ ادعای «مؤسس/مسئول فنی برای *همهٔ* مراقبت‌های منزل باید پزشک باشند» **رد شد** — این قاعده **فقط برای مسیر بالینی** است. مسیر خدمات پرستاری یک پرستار واجد شرایط را مجاز می‌داند. منابع: [mcls.gov.ir/fa/law/61](https://www.mcls.gov.ir/fa/law/61)، [irannurse.ir](https://irannurse.ir)، [vct.iums.ac.ir](https://vct.iums.ac.ir).
+
+## ۴.۳ نحوهٔ عملکرد الزامیِ مدل ✅ تأییدشده
+- **مراقبت باید در منزل بیمار ارائه شود؛ انجام خدمات (تزریقات، پانسمان، واکسیناسیون، ویزیت) در محل ستادی مرکز ممنوع است.** بنابراین مرکز دارای مجوز یک **نهاد اعزام/هماهنگی است، نه درمانگاه مراجعه‌حضوری** — که از نظر ساختاری *با یک پلتفرم تطبیق/اعزام سازگار است.*
+- پس از **موافقت اصولی**، مؤسس **حداکثر یک سال** فرصت دارد مرکز را برای بازدید نهایی آماده کند.
+
+## ۴.۴ الزام تجارت آنلاین — نماد اعتماد الکترونیکی (e-namad) ✅ تأییدشده
+- یک **نماد اعتماد الکترونیکی** برای سایت ایرانی‌ای که خدمات/فروش آنلاین ارائه می‌دهد لازم است — که شامل پلتفرم شما می‌شود. **تنها توسط مرکز توسعه تجارت الکترونیکی** زیر نظر وزارت صنعت، معدن و تجارت صادر می‌شود.
+- برای یک سایت درآمدزا **عملاً الزامی است** چون قواعد PSP/شاپرک برای دریافت درگاه پرداخت اینترنتی (IPG) نیاز به نماد دارند. (توجه: وضعیت «الزامی» نوساناتی نظارتی داشته.) منابع: [ecommerce.gov.ir](https://ecommerce.gov.ir)، [راهنمای نت‌افراز](https://www.netafraz.com/blog/getting-enamad-complete-guide/).
+
+## ۴.۵ شکاف قانون کار و به‌رسمیت‌شناختن بازار (⚠️ اطمینان متوسط)
+- **پرستاران منزل خارج از شمول رژیم «مشاغل سخت و زیان‌آور»اند** که از حقوق بیمه/بازنشستگی پرستاران بیمارستانی بهره‌مند می‌کند، چون قانون به‌طور خاص از کارکنان شرکت‌های مراقبت در منزل نام نبرده. تا سال ۱۳۹۸، **~۷۰۰ شرکت خدمات درمانی در منزل** ثبت شده بودند (هدف ~۱٬۰۰۰)؛ این شکاف طبق گزارش‌ها تا ۱۴۰۲–۱۴۰۴ بدون قانونگذاری حل‌کننده ادامه داشت. منبع: [مصاحبهٔ ایلنا با عضو شورای‌عالی نظام پرستاری](https://www.ilna.ir/بخش-کارگری-9/797233). *(منبع واحد ۱۳۹۸؛ ارقام کفِ تاریخی‌اند — وضعیت فعلی را بررسی کنید.)*
+
+## ۴.۶ سایر تعهداتی که باید برنامه‌ریزی کنید
+- **مالیات و ثبت شرکت** (ثبت شرکت، پروندهٔ مالیاتی، ارزش افزوده در صورت لزوم) — استاندارد برای هر کسب‌وکار ایرانی. **[جزئیات با حسابدار بررسی شود]**
+- **بیمه/تأمین اجتماعی** پرستارها بسته به اینکه آن‌ها را کارمند یا پیمانکار طبقه‌بندی کنید متفاوت است (بخش ۲.۲ را ببینید). **[مشاورهٔ قانون کار بگیرید — مهم‌ترین تصمیم ساختاری]**
+- **نردبان جریمهٔ عدم انطباق:** تذکر شفاهی/کتبی ← تعطیلی ۱–۳ ماه ← تعطیلی ۳ ماه–۱ سال ← **لغو دائم پروانه + ارجاع به مراجع قضایی.** فعالیتِ بدون مجوز ریسک حقوقی واقعی است. **✅ تأییدشده**
+
+---
+
+# ۵. توصیه‌های عملی و راهبرد ورود به بازار
+
+**۱. اکنون قالب قانونی را انتخاب کنید: یک «مرکز خدمات پرستاری در منزل» ثبت کنید.** یا خودتان (اگر پرستار با کارشناسی + ۵ سال سابقه هستید) یا یک هم‌بنیان‌گذار پرستار به‌عنوان مؤسس/مسئول فنی. اگر بعداً می‌خواهید خدمات بالینیِ زیرنظر پزشک ارائه دهید، یک شریک پزشک و مسیر بالینی را جداگانه اضافه کنید.
+
+**۲. سریع وارد بازار شوید با مدل آسانیسم — با مراکز دارای مجوز همکاری کنید** در حالی که پروانهٔ خودتان در فرایند است. این به شما اجازه می‌دهد لایهٔ فناوری/برند/مارکت‌پلیس را قانونی و سریع راه‌اندازی کنید، سپس به‌مرور تأمین نیرو را داخلی کنید.
+
+**۳. اعتماد احرازشده را به کلِ برند خود تبدیل کنید.** یک نشان احرازِ قابل‌رؤیت را بسته‌بندی (نه آپ‌سل) کنید: ✓ هویت احرازشده (شاهکار + تطبیق چهره)، ✓ پروانهٔ صلاحیت حرفه‌ای وزارت بهداشت تأییدشده، ✓ شمارهٔ نظام پرستاری، ✓ عدم سوء پیشینه در پرونده، ✓ دورهٔ آزمایشی + تضمین. شمارهٔ پروانهٔ خود را مثل سلامت اول نمایش دهید.
+
+**۴. جغرافیایی را ببرید که دیگران نادیده می‌گیرند.** تهران/کرج اشباع و متمرکزند؛ **شهرهای ردهٔ دوم** (مشهد، اصفهان، شیراز، تبریز، اهواز، قم) را هدف بگیرید که رقبا در آن‌ها کم‌حضورند.
+
+**۵. احراز را بخرید، نسازید.** یک فروشندهٔ KYC (فینوتک یا یوآیدی) را برای شاهکار + کد ملی + تشخیص زنده‌بودن یکپارچه کنید؛ پروانهٔ صلاحیت حرفه‌ای + شمارهٔ نظام پرستاری را برای لایهٔ مجوز مطالبه کنید؛ عدم سوء پیشینهٔ آپلودشده توسط پرستار را بخواهید.
+
+**۶. مدل استخدام را پیش از مقیاس‌دهی با وکیل تصمیم بگیرید** — مارکت‌پلیس بی‌طرف در برابر کارفرما/آژانس. از دام «کنترل برای کیفیت + پیمانکار برای هزینه» که مسئولیت طبقه‌بندی نادرست را فعال می‌کند پرهیز کنید. صرف‌نظر از انتخاب، بیمهٔ مسئولیت پلتفرم داشته باشید.
+
+**۷. از روز اول علیه حذف واسطه مهندسی کنید:** پرداخت امانی + حل اختلاف داخل پلتفرم، تضمین پوشش پرستار جایگزین، EVV ورود/خروج، و حمایت‌هایی که فقط داخل پلتفرم اعمال می‌شوند.
+
+**۸. زود چرخهٔ نهادی را بسازید:** مشارکت‌های ارجاع ترخیص بیمارستانی (پس از جراحی، پس از سکته)، و قراردادهای آزمایشی B2B با بیمه‌گرها (سلامت / تأمین اجتماعی)، خیریه‌ها یا کارفرمایان برای یارانه‌دادن ویزیت‌ها.
+
+**۹. یک ردهٔ سبک‌ترِ «همراهی / کمک روزمره» اضافه کنید** (مدل Papa) — محدودیت تأمین نیروی کمتر، بازار وسیع‌تر، و خوراک‌دهنده به پرستاری ماهر هنگام تشدید نیاز. **دیاسپورا** را هدف بگیرید («برای مراقبت از والدینت در وطن هزینه کن»).
+
+**۱۰. هرگز ایمنی را بیش از حد تبلیغ نکنید.** هر جریمهٔ Care.com به ادعای بررسی‌ای که انجام نشده یا لغو با الگوی تاریک برمی‌گردد. کمتر وعده دهید، بیشتر احراز کنید، لغو را آسان کنید.
+
+---
+
+## پرسش‌های باز / مواردی که باید پیش از راه‌اندازی راستی‌آزمایی شوند
+۱. **تعداد فعلی (۱۴۰۴–۱۴۰۵) شرکت‌های ثبت‌شده** و وضعیت کنونی شکاف قانون کارِ سخت و زیان‌آور برای پرستاران منزل — آیا قانونی آن را حل کرده است؟
+۲. **الزامات کامل سرمایه، مکان، نیروی انسانی و بیمه** به‌طور خاص برای مسیر مرکز خدمات پرستاری، و اینکه آیا یک **مارکت‌پلیس فناوری‌محور** می‌تواند با پیمانکاری *فقط* به مراکز دارای مجوزِ همکار (مدل آسانیسم) فعالیت کند بدون داشتن پروانهٔ خودش در ابتدا.
+۳. آیا **نظام پرستاری / وزارت بهداشت هیچ API اعتبارسنجی B2B** پشت یک پورتال ارائه می‌دهند (تاکنون فقط از طریق جست‌وجوی عمومی «یافت نشد»).
+۴. **جزئیات مالیات، ارزش افزوده و ساختار شرکت** با یک حسابدار محلی؛ **طبقه‌بندی استخدام** با یک وکیل قانون کار.
+
+---
+
+### منابع (منتخب)
+
+**ایران — حقوقی و بازار داخلی (تأییدشده):** arakmu.ac.ir/vct/fa/regulation/1063/ · mcls.gov.ir/fa/law/61 · qavanin.ir/Law/TreeText/83385 · irannurse.ir · vct.iums.ac.ir · ilna.ir/بخش-کارگری-9/797233 · ecommerce.gov.ir · netafraz.com/blog/getting-enamad-complete-guide/ · asanism.com · snapp.doctor/home-nursing/ · salamateaval.com · myket.ir/app/hirad.sc.com
+
+**پلتفرم‌های خارجی:** techcrunch.com (Honor، Cera، Vivian، Birdie، Portea) · ftc.gov و cnbc.com (Care.com FTC) · mobihealthnews.com (Papa) · florence.co.uk · techcrunch.com/technode.global (Homage) · tvmcapitalhealthcare.com (Manzil) · quartr.com (Veteranpoolen)
+
+**ریسک‌ها و شکست‌ها:** thedailybeast.com و backgroundchecks.com (Care.com/WSJ) · engadget.com (پاک‌سازی آگهی‌ها) · nurse.org و washingtonpost.com (پرستار قلابی Womack) · hrmorning.com و ogletree.com (طبقه‌بندی نادرست) · shiftcare.com و axiscare.com (جابه‌جایی نیرو) · sharetribe.com (حذف واسطه) · aarp.org (سوءاستفادهٔ مالی از سالمند) · pymnts.com (Care.com ۱ میلیون دلار Marin)
+
+**ابزار احراز:** ncsbn.org و nursys.com (Nursys) · nmc.org.uk (NMC) · checkr.com و sterlingcheck.app (شرکت‌های بررسی پیشینه) · behdasht.gov.ir و heyvagroup.com (مجوز وزارت بهداشت/نظام پرستاری) · fa.wikipedia.org/سامانه_شاهکار (شاهکار) · finnotech.ir (KYC) · asretarakonesh.ir (۸ شرکت ایرانی KYC) · heyvalaw.com (عدم سوء پیشینه از طریق ثنا)
+
+*این گزارش از یک مرحلهٔ تحقیقِ راستی‌آزمایی‌شدهٔ متخاصمانه (چارچوب حقوقی ایران + رقبای داخلی) به‌علاوهٔ سه عامل تحقیقاتی هدفمند (رقبای خارجی، نمونه‌های ریسک/شکست، ابزار احراز) تدوین شده است. مقررات دهه‌های گذشته، آمار خوداظهاریِ رقبا و ارقام سرمایه را پیش از تصمیم‌گیری یا انتشار با منابع اولیهٔ روز راستی‌آزمایی کنید.*
diff --git a/product/Home-Nursing-Platform-Research.md b/product/Home-Nursing-Platform-Research.md
new file mode 100644
index 0000000..909729d
--- /dev/null
+++ b/product/Home-Nursing-Platform-Research.md
@@ -0,0 +1,293 @@
+# Building a Private Home-Nursing Platform in Iran — Research & Strategy Report
+
+> **Idea:** A platform that helps families in Iran easily find and hire vetted private/home-care nurses for their loved ones — elderly care, post-surgery recovery, infant/newborn care, and chronic-illness management.
+
+**Prepared:** 2026-06-16  ·  **Scope:** (1) competitor & market analysis, (2) problems & risks, (3) nurse identity & credential verification, (4) Iranian legal landscape, plus actionable recommendations.
+
+**A note on sourcing.** This report combines (a) an adversarially fact-checked research pass on the **Iranian legal framework and local competitors** (claims that survived a 3-vote verification process are marked **✅ verified**; claims that were *disproven* are flagged explicitly), and (b) targeted web research on **foreign platforms, risk/failure cases, and verification tooling**. Where a fact comes from a company's own marketing page it is noted as self-reported/unaudited; where it leans on model knowledge rather than a fetched source it is flagged **[unverified — confirm before relying on it]**. Treat funding figures and any decades-old regulations as "verify before publishing."
+
+---
+
+## Executive Summary
+
+**You can legally build this in Iran — but it is a *licensed healthcare activity*, not a free-to-launch marketplace.** The operative credential is a Ministry of Health **establishment permit (پروانه تأسیس)** plus a **technical-director license (پروانه مسئول فنی)**, granted by the MoH Treatment Deputy (معاونت درمان) after approval by the Article-20 medical-affairs commission. **✅ verified**
+
+There are **two regulatory tracks, and the choice is decisive:**
+- **Home *nursing* services center** (مرکز مشاوره و ارائه مراقبت‌های پرستاری در منزل) — governed via the Iranian Nursing Organization; a **nurse** (BSc + 5 yrs clinical experience) can be founder and technical director. **This is the right vehicle for your idea.** **✅ verified**
+- **Home *clinical* care center** (مرکز خدمات و مراقبت‌های بالینی در منزل) — **both founder and technical director must be physicians.** Avoid unless you bring a physician partner. **✅ verified**
+
+**The market is real and already competitive** — Asanism, Snapp Doctor, Salamat Aval, and Hirad all operate today — **but they are heavily concentrated in Tehran/Karaj and run mostly as direct-dispatch staffing, not as trust-first marketplaces.** That is your gap. **✅ verified**
+
+**The hardest problem is trust and safety, not technology.** Every cautionary tale abroad (Care.com's regulatory settlements, the "imposter nurse" credential-fraud case, gig-marketplace misclassification judgments) points to one rule: **own the vetting; never offload it to families, and never market a safety check you don't actually perform.**
+
+**The good news on verification:** Iran has a competitive market of off-the-shelf KYC APIs (Shahkar phone↔national-ID matching, face/liveness matching against the national card) that make identity verification the *easy* layer. The license layer is harder (no public B2B API), but the MoH's **پروانه صلاحیت حرفه‌ای** nurse-competency license is the credential to demand — it already bundles a criminal-record screen.
+
+**Bottom line strategy:** Register as a **home-nursing services center**, partner early with already-licensed centers (the Asanism model) to move fast, make **verified trust your entire brand**, target **under-served cities outside Tehran**, and build toward **B2B/institutional revenue** (hospital post-discharge pipelines, insurers, employer benefits) on top of consumer pay.
+
+---
+
+# 1. Competitor & Market Analysis
+
+## 1.1 Iranian players (the people you'll actually compete with) ✅ verified
+
+The local market is **active and growing** — as of 2019 roughly **700 home-medical-service companies** were registered, with an official push toward ~1,000 (almost certainly higher now). **✅ verified** (single 2019 source; treat as a historical floor). The leaders:
+
+| Player | Model | Target segments | Notable facts | Pricing |
+|---|---|---|---|---|
+| **Asanism (آسانیسم)** | Matching/marketplace that supplies caregivers **through licensed partner centers** (intermediary model) | Elderly, childcare, post-surgical, chronic, clinical (injections, dressing, catheter, in-home blood draws) | Markets identity-vetting (احراز هویت), health-protocol compliance, a reported ~40M toman security promissory note, and 24–48 hr trial periods. **~99% concentrated in Tehran/Karaj**, ~1,650 active caregivers across 4 partner facilities (self-reported, unaudited) | Listed, current (1404/1405) |
+| **Snapp Doctor (اسنپ دکتر)** | Health vertical of Snapp (Iran's largest super-app); managed dispatch | Elderly, post-surgical (wound care, suture removal), infant/child, chronic (stroke, cancer, Parkinson's, MS, Alzheimer's) | Operates in Tehran, Karaj, Qom, Shiraz, Kermanshah, Isfahan, Mashhad. Holds a **general online-medical-intermediary ("پل ارتباطی") license** — **NOT** a specific home-nursing MoH authorization (this was a disproven claim) | — |
+| **Salamat Aval (سلامت اول)** | **Direct dispatch of its own nurses** (not an open marketplace) — the company picks the nurse | Elderly care (hourly / daily / 24-hour) | **3,000+ active personnel**, 24/7 call center (1527), Tehran + suburbs (Karaj, Pardis). Holds **official MoH license no. 388180-3** | "توافقی" (negotiable); 24-hr shifts cost less per hour |
+| **Hirad (هیراد)** | App-based (Cafe Bazaar, Myket) managed staffing/dispatch | Eldercare, childcare/infant, post-surgery/recovery, home injections, home lab tests | Shows both sides (families request; nurses "view available jobs"); advertises "استخدام بدون هزینه" (no placement fee). States it operates under MoH authorization. Modest adoption | — |
+
+**What this tells you:**
+1. **The dominant model is direct/managed dispatch, not a true trust-first two-sided marketplace.** Even "marketplace-ish" players (Asanism, Hirad) function as managed staffing agencies. A genuinely transparent, review-driven, family-chooses-the-nurse experience is still relatively open.
+2. **Geographic concentration is extreme.** Tehran/Karaj dominate; second-tier cities (Mashhad, Isfahan, Shiraz, Tabriz, Ahvaz, Qom) are thinly served. **This is the clearest white space.**
+3. **Pricing is opaque and negotiable (توافقی).** Transparent, upfront pricing is a differentiator families would value.
+4. **"Licensed" is a real trust signal** — Salamat Aval advertises its MoH permit number prominently. You should too.
+
+> ⚠️ **Disproven claims to not repeat:** Snapp Doctor does **not** hold a home-nursing-specific MoH license (only a general intermediary license); a per-procedure city-pricing example attributed to it was also disproven. Competitor headcounts (1,650 / 3,000) are self-reported marketing numbers.
+
+## 1.2 Foreign platforms (models to learn from)
+
+Foreign platforms cluster into **four structural models** — knowing which one you're imitating matters more than any single feature:
+
+1. **Pure consumer marketplace** — connects families directly to *self-employed* caregivers; the platform employs no one (Care.com, Curam). Cheap to scale, weak quality control, serious worker-misclassification legal risk.
+2. **Managed / employed "full-stack"** — company hires, trains, vets, and dispatches its own staff, with tech on top (Honor, Cera, Homage, Portea). Higher quality and defensibility; capital-intensive.
+3. **Staffing platform for facilities** — fills hospital/care-home shifts, not consumer-facing (Florence, Vivian Health).
+4. **Demand-aggregation + payor integration** — lead-gen / companionship / insurance plays (Papa, Pflege.de).
+
+**The clearest lesson from the data: capital and durable contracts flow to the managed/full-stack and payor-integrated models, while pure independent-contractor marketplaces keep hitting a labor-law ceiling.**
+
+### Comparison table (selected; funding figures approximate — verify before relying)
+
+| Platform | Country | Model | Standout features | Monetization | Differentiator / outcome |
+|---|---|---|---|---|---|
+| **Care.com** | US | Pure subscription marketplace | Profiles, reviews, *optional paid* background checks | Family + caregiver subscriptions; check add-ons; **no cut of wages** | Largest/broadest. **Cautionary tale** — FTC $8.5M settlement (2024), Marin DA $1M (2020) |
+| **Honor** | US | Managed full-stack + franchise | Tech+ops platform; absorbed Home Instead's global network | B2B + franchise; hourly care | Unicorn (~$1.25B+); ~$2.1B combined w/ Home Instead; 100k+ caregivers |
+| **Papa** | US | Companionship + payor-billed | "Papa Pals" companionship for loneliness; care navigation | **B2B contracts w/ Medicare Advantage / Medicaid / employers** | Reframed loneliness as a billable health need; $150M Series D |
+| **Cera** | UK | Managed full-stack + predictive AI | Predicts falls/hospitalizations days ahead; carers log vitals | **B2B w/ NHS & 150+ councils** | Owns workforce *and* data; ~$1B unicorn (2025) |
+| **Florence** | UK | Staffing marketplace for facilities | Instant shift-booking; rota/payroll/training; DBS vetting | Per-shift commission + SaaS | Disintermediates expensive nursing agencies |
+| **Curam** | UK | Pure marketplace (self-employed) | DBS + biometric ID checks; bundled insurance | **12.5% + VAT commission** (carers keep ~85%) | Lowest-fee self-employed model |
+| **Homage** | Singapore (+MY/AU) | **Curated marketplace + human matching** | Algorithm surfaces candidates, *staff* makes final match; telehealth; gov-subsidy integration | Per-hour spread (~S$3–6/hr) + packages + B2B | Clinically-capable curated network; $30M Series C (Temasek). **Best model fit for Iran** |
+| **Portea Medical** | India | Managed clinical provider | Physio, nursing, doctor visits, labs, **equipment rental**; diaspora "NRI package" | Subscription + per-visit + rental | Largest in India; ~$114M raised |
+| **Nightingales / Care24 / HCAH** | India | Managed clinical providers | Chronic/specialty programs; **insurance-billed cashless** (HCAH, 40+ insurers) | Subscription + per-visit + B2B | Market consolidating fast (both acquired) |
+| **Manzil / NMC Homecare** | UAE | Licensed clinical home-health | JCI-accredited; hospital-integrated; IV, physio, mother & baby | Fee-for-service, **insurance-billed** | Premium clinical credibility |
+| **Veteranpoolen** | Sweden | Staffing employing **retirees** | Priced for Sweden's RUT 50% tax deduction | RUT-subsidized fees + franchise | Unique labor supply (active pensioners) |
+| **Bakıcıburada** | Turkey | Caregiver classifieds | ID + criminal-record verification; map discovery | Listing/subscription fees | Bootstrapped; **closest analog to a realistic early-stage Iran market** |
+
+### Most relevant regional signals
+- **India is the closest comparator** (large population, low public coverage, family-pays-out-of-pocket). Tellingly, **no pure family-to-caregiver marketplace dominates there** — every leader runs a managed/employed clinical model, because the country lacks structured paramedical training, so **vetting and quality control *are* the product.**
+- **Germany's** one attempt at managed carer-matching (Careship) went **insolvent**; the survivors are capital-light lead-gen/classifieds + insurance-subsidized consumables.
+- **Turkey** is mostly bootstrapped classifieds and small agencies — a realistic near-term picture for Iran.
+
+### Five transferable ideas for an Iran-based founder
+1. **Don't build a pure "Uber-for-nurses" of independent contractors.** The clearest blow-ups (Careship insolvency; Helpling's gig cleaners reclassified as employees; Care.com's quality scandals) are all pure gig models. For care, the proven sweet spot is a **curated marketplace + human vetting** hybrid (the **Homage** model: algorithm surfaces candidates, *your team* makes the final match and owns screening/training).
+2. **Make vetting & training the core product, not a paid add-on.** In every market with weak licensing infrastructure, winners *own* caregiver quality (background/ID checks, training academies, continuity of carer). In Iran, **trust infrastructure is the entire value proposition** — bundle it in; don't upsell it the way Care.com did.
+3. **Build toward B2B/institutional payors early.** The highest-value outcomes monetize through institutions: Cera (NHS), Papa (Medicare Advantage), HCAH (insurers). Iran's analogs: **Social Security Organization (تأمین اجتماعی), Salamat/health insurers, hospital post-discharge referrals, and corporate employee benefits.** Hospital post-surgery/post-stroke discharge is a high-intent acquisition channel.
+4. **Stack two revenue engines and look for a subsidy hook.** (a) per-hour take-rate/markup on managed care, plus (b) subscription/lead-gen. Germany's insurance-funded consumables box and Sweden's RUT 50% tax deduction show the power of **plugging into an existing subsidy so the service feels cheap to the family** — scout whether any Iranian insurer, charity, or elder-care endowment could subsidize visits.
+5. **Productize "companionship / daily-living help" as a separate, lighter tier.** Papa built a unicorn-track business on *companionship for isolated seniors*, not skilled nursing — lower-skill, easier to staff, broader market, and upsells to clinical care as needs escalate. Given Iran's large diaspora, a **"remote children paying for a parent's care back home"** angle (Portea's NRI package; Homage's diaspora users) is directly relevant.
+
+> **Lowest-risk entry wedge:** Birdie's "SaaS-for-providers" approach — sell scheduling/compliance/family-dashboard software *to* existing Iranian home-care agencies rather than competing head-on — is worth keeping in your back pocket if licensing/labor classification proves to be a hard early barrier.
+
+---
+
+# 2. Problems & Risks
+
+This sector pairs two unusually dangerous features: the buyers are **vulnerable people** (elderly, post-surgical, infants, chronically ill) and the service happens **unsupervised, inside a private home**. That combination amplifies every standard marketplace risk and adds life-and-death stakes.
+
+**The single most important strategic lesson:** *a platform that markets safety while pushing the actual vetting onto families will eventually face regulatory, legal, and reputational catastrophe.*
+
+## 2.1 Trust & safety failures
+**Risk:** Connecting strangers to vulnerable people without rigorous *platform-owned* vetting enables theft, abuse, fraud, and fatal harm — and the public blames the *platform*.
+
+**Real cases:**
+- **Care.com / Wall Street Journal (2019):** Over ~6 years, **nine caregivers listed on Care.com who had police records were later accused of crimes while a child or elder was in their care — including theft, abuse, sexual assault, and murder.** The site also carried hundreds of day-care listings falsely claiming state licensing. Standard membership performed only a "preliminary screening," not a real background check; stronger checks cost extra. ([Daily Beast/WSJ](https://www.thedailybeast.com/wsj-kids-assaulted-died-in-hands-of-carecom-caregivers/), [BackgroundChecks.com](https://www.backgroundchecks.com/blog/care-com-comes-under-fire-for-background-check-policies))
+- **Mass listing purge:** Care.com pulled **~46,594 day-care listings (~45% of that database)** after many were found to be false, nonexistent, or falsely claiming licensing. ([Engadget](https://www.engadget.com/2019-03-31-care-com-pulls-47000-daycare-listings.html))
+- **The "imposter nurse" (Shannon Womack, 2025):** Allegedly posed as a nurse using **20+ aliases and 7 SSNs**, stealing four real nurses' credentials, and worked at **9+ facilities** by submitting **forged documents through staffing agencies** — even creating a fake LLC to self-deploy. Charged with **43 counts** including endangering a care-dependent person and stealing medication from seniors. ([Nurse.org](https://nurse.org/news/fake-nurse-arrested-shannon-womack-nursing-fraud/), [Washington Post](https://www.washingtonpost.com/nation/2025/07/23/pennsylvania-fake-nurse-shannon-womack/)) — *the key cautionary tale for a nurse marketplace: even agencies that thought they were verifying were defeated by stolen-identity + forged documents.*
+
+**Mitigations:**
+- **Own the vetting; never delegate it to families.** Make identity + criminal-record + license verification a *platform-performed, non-optional* gate before any nurse is bookable.
+- **Verify credentials at the authoritative source**, not via uploaded PDFs (which are exactly what gets forged). In Iran: the **Iranian Nursing Organization** registry and the MoH **پروانه صلاحیت حرفه‌ای** (see §3).
+- **Bind every profile to the national ID + a liveness selfie** to defeat the aliases/stolen-identity pattern.
+- **Re-verify periodically** (license expiry, suspensions, new records).
+
+## 2.2 Liability & legal exposure
+**Risk:** Three exposures stack — **(a) worker misclassification** (calling nurses "contractors" when the law treats them as employees), **(b) vicarious liability / negligent hiring** (sued when a caregiver harms a patient), and **(c) insurance gaps**. The "we're just a neutral tech platform" defense is eroding worldwide.
+
+**Real cases:**
+- **$10M California judgment against TLC Home Care** for misclassifying in-home workers as contractors (2023). ([HRMorning](https://www.hrmorning.com/news/worker-misclassification-tlc-home-care/))
+- Federal courts repeatedly find in-home caregivers are **employees, not contractors**, under the "economic realities/control" test — *the more you standardize and supervise care for quality, the more you look like an employer.* ([Ogletree Deakins](https://ogletree.com/insights-resources/blog-posts/federal-court-finds-in-home-caregivers-were-employees-not-independent-contractors-under-economic-realities-control-test/))
+- Home-care agencies are routinely held liable under *respondeat superior* and for **negligent hiring/supervision**. ([Nursing Home Law Center](https://www.nursinghomelawcenter.org/news/home-health-aide-lawsuit/))
+
+**Mitigations:**
+- **Decide the model deliberately:** either a *true neutral marketplace* (minimal control; family is the employer) or a *full agency/employer model* (payroll, supervision, insurance). **The dangerous middle — heavy control for "quality" but contractor classification for cost — is exactly what triggers misclassification judgments.**
+- **[unverified — confirm with local counsel]** Iranian labor law (قانون کار) and social-security (تأمین اجتماعی) obligations attach to employment relationships; classify correctly *before* launch. (Note the documented labor-law gap for home-care nurses — see §4.5 — cuts both ways: less mandated cost, but unresolved status.)
+- **Carry platform-level general + professional liability insurance**, and require nurses to carry their own.
+- **Document every vetting step** — it's both prevention and your legal defense against negligent-hiring claims.
+
+## 2.3 Operational & quality-control problems
+**Risk:** Extreme caregiver churn, no-shows that strand a vulnerable patient, wide quality variance, near-impossible remote monitoring, and **disintermediation** (families + nurses pairing off-platform to dodge fees).
+
+**Real data:**
+- Caregiver turnover hit **~79% in 2024**, with **~70% of new hires quitting within 100 days**; each departure costs **$2,600–$5,000** and clients often leave with the caregiver. ([ShiftCare](https://shiftcare.com/us/blog/caregiver-retention-in-2026-what-the-data-tells-us-about-turnover), [AxisCare](https://axiscare.com/blog/understanding-the-90-day-turnover/))
+- **Disintermediation is the predictable failure mode** for recurring, relationship-based services — once trust forms, families and nurses transact privately. Punitive anti-leakage tactics tend to backfire. ([Sharetribe](https://www.sharetribe.com/academy/how-to-discourage-people-from-going-around-your-payment-system/))
+
+**Mitigations:**
+- **Electronic Visit Verification (EVV):** GPS/time-stamped clock-in/out with automated missed-visit alerts, so no-shows trigger an instant backup dispatch.
+- **Backup/coverage guarantee:** a bench of available nurses and a promise to fill no-shows fast — a core reason to use you instead of hiring privately.
+- **Beat leakage with retained value, not lock-in:** integrated scheduling/payments, the backup guarantee, insurance that *only* applies to on-platform bookings, and reviews/dispute protection that vanish if they go offline.
+- **Continuity-first matching:** a primary nurse + named backup per patient; track continuity as a KPI.
+
+## 2.4 Payment & fraud risks
+**Risk:** Off-platform payment (the financial side of leakage), fake reviews, identity fraud, credential forgery, and **financial elder abuse.**
+
+**Real data:**
+- Gig-marketplace fraud runs ~**2× the rate** elsewhere; one 2025 report cited a 21% YoY rise, **>90% of it impersonation**. ([Security Boulevard](https://securityboulevard.com/2024/05/when-the-gig-is-fraud-building-trust-for-online-marketplaces-with-identity-verification/))
+- **Financial elder abuse:** a CFPB review found that where the victim knew the perpetrator, **1 in 9 was a non-family caregiver, average loss $57,800.** ([AARP](https://www.aarp.org/money/scams-fraud/financial-abuse-home-care-aide/))
+- **Care.com penalties:** **2020 — $1M Marin County DA** (falsely claimed checks searched the National Sex Offender Registry; improper auto-renewals); **2024 — $8.5M FTC** (inflated available-job counts — more than half of postings came from users who couldn't actually hire — plus dark-pattern cancellation). ([CNBC](https://www.cnbc.com/2024/08/26/carecom-reaches-8point5-million-us-ftc-settlement-over-job-listings-renewals-.html), [PYMNTS](https://www.pymnts.com/legal/2020/care-com-pays-1m-settlement-over-auto-renewal-background-check-allegations/))
+
+**Mitigations:**
+- **Strong identity verification at onboarding** (national-ID binding + liveness) for both nurses *and* paying families.
+- **Tie reviews to verified, completed, on-platform bookings.**
+- **In-platform escrow/payment with dispute resolution** — reduces fraud *and* is your strongest anti-leakage lever (buyer protection only if they pay through you).
+- **Protect clients' finances** (advise families: secure cards, view-only monitoring, watch for sudden POA/will changes); consider bonding nurses against theft.
+- **Never advertise a guarantee or check you don't deliver, and make cancellation genuinely easy** — every Care.com penalty traces to deceptive safety marketing or dark patterns.
+
+## 2.5 Trust dynamics unique to caring for vulnerable people at home
+The service is delivered **alone, unobserved, inside the home**, to people who often **cannot reliably report** what happened (infants; dementia, post-anesthesia, cognitively impaired patients). Information asymmetry is extreme and a single incident can destroy a fragile brand.
+
+**Mitigations:** compensate for unobservability with **structured oversight** — EVV, periodic supervisory tele-check-ins by a senior nurse, family-visible care logs, consented in-home cameras in common areas; a **two-way feedback loop** the patient isn't the sole source of (structured family check-ins, easy in-app concern flagging, monitoring for AARP "red flags"); **rapid-response incident protocols** with immediate suspension on credible complaints; and **match qualification to acuity** (route high-acuity post-surgical/ventilator cases only to verified RNs; reserve aide-level providers for companionship).
+
+---
+
+# 3. Nurse Identity & Credential Verification
+
+**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.
+
+---
+
+# 4. Legal Landscape in Iran
+
+**Short answer: there is no law *against* the idea — but it is a regulated healthcare activity that requires Ministry of Health licensing. Operating without a permit is what's illegal, and penalties escalate to permanent revocation and judicial referral.** **✅ verified**
+
+## 4.1 The governing framework ✅ verified
+- Licensing flows through the **MoH Treatment Deputy (معاونت درمان)**, after approval by the **Article-20 medical-affairs commission** (کمیسیون قانونی تشخیص امور پزشکی موضوع ماده ۲۰), under the **Medical Affairs Law of 1334 (amended 1367)** and the **home-care bylaw approved 1378/7/17 (9 Oct 1999)** — 21 articles, 6 notes.
+- **Each center receives one establishment permit (پروانه تأسیس) and one technical-director license (پروانه مسئول فنی).**
+- Sources: [arakmu.ac.ir bylaw](https://arakmu.ac.ir/vct/fa/regulation/1063/), [mcls.gov.ir/fa/law/61](https://www.mcls.gov.ir/fa/law/61), [qavanin.ir (Article-20)](https://qavanin.ir/Law/TreeText/83385).
+
+## 4.2 The two tracks — pick the nursing track ✅ verified
+| | **Home Nursing Services Center** (your vehicle) | Home Clinical Care Center |
+|---|---|---|
+| Persian name | مرکز مشاوره و ارائه مراقبت‌های پرستاری در منزل | مرکز خدمات و مراقبت‌های بالینی در منزل |
+| Governed via | Iranian Nursing Organization (نظام پرستاری) | MoH directly |
+| Who can found / direct | **A nurse** — BSc nursing + **≥5 years clinical experience** (can be both founder & technical director) | **Both founder & technical director must be physicians** |
+| Fit for your idea | ✅ Elderly / post-surgery / infant / chronic home nursing | Only if you bring a physician partner |
+
+> ⚠️ A claim that "founder/director must be physicians for *all* home care" was **disproven** — that rule applies **only to the clinical-care track.** The nursing-services track allows a qualified nurse. Sources: [mcls.gov.ir/fa/law/61](https://www.mcls.gov.ir/fa/law/61), [irannurse.ir](https://irannurse.ir), [vct.iums.ac.ir](https://vct.iums.ac.ir).
+
+## 4.3 How the model must operate ✅ verified
+- **Care must be delivered in the patient's home; performing services (injections, dressing, vaccination, visits) at the center's HQ is prohibited.** The licensed center is therefore a **dispatch/coordination entity, not a walk-in clinic** — which structurally *fits a matchmaking/dispatch platform.*
+- After **principal approval (موافقت اصولی)**, the founder has **up to one year** to ready the center for final inspection before operating.
+
+## 4.4 Online-commerce requirement — e-namad ✅ verified
+- An **e-namad (نماد اعتماد الکترونیکی, electronic trust symbol)** is required for an Iranian site providing online services/sales — which includes your platform. Issued **only by the Center for E-Commerce Development (مرکز توسعه تجارت الکترونیکی)** under the Ministry of Industry, Mine and Trade.
+- It is **de facto mandatory for a monetized site** because PSP/Shaparak rules require e-namad to obtain an online payment gateway (IPG). (Note: "mandatory" status has had some regulatory flux.) Sources: [ecommerce.gov.ir](https://ecommerce.gov.ir), [netafraz guide](https://www.netafraz.com/blog/getting-enamad-complete-guide/).
+
+## 4.5 Labor-law gap & market recognition (⚠️ medium confidence)
+- **Home-care nurses fall outside the "arduous/hazardous work" (سخت و زیان‌آور) regime** that benefits hospital nurses' insurance/retirement, because the law doesn't specifically name staff of home-care companies. As of 2019, **~700 home-medical-service companies were registered** (target ~1,000); the gap reportedly persisted into 1402–1404 with no closing legislation. Source: [ILNA interview w/ INO Supreme Council member](https://www.ilna.ir/بخش-کارگری-9/797233). *(Single 2019 source; figures are a historical floor — confirm current status.)*
+
+## 4.6 Other obligations to plan for
+- **Taxation & company registration** (ثبت شرکت, tax file, VAT where applicable) — standard for any Iranian business. **[confirm specifics with an accountant]**
+- **Insurance/social-security (تأمین اجتماعی)** treatment of nurses depends on whether you classify them as employees or contractors (see §2.2). **[get labor-law counsel — this is the highest-stakes structural decision]**
+- **Penalty ladder for non-compliance:** verbal/written warning → 1–3 month closure → 3 month–1 year closure → **permanent revocation + referral to judicial authorities.** Operating unlicensed is the real legal risk. **✅ verified**
+
+---
+
+# 5. Actionable Recommendations & Go-To-Market
+
+**1. Choose the legal vehicle now: register a *Home Nursing Services Center*.** Either you (if a nurse with BSc + 5 yrs experience) or a nurse co-founder serves as founder/technical director. If you want to offer physician-supervised clinical services later, add a physician partner and the clinical-care track separately.
+
+**2. Go to market fast via the Asanism model — partner with already-licensed centers** while your own permit is in process. This lets you launch the tech/brand/marketplace layer legally and quickly, then bring supply in-house over time.
+
+**3. Make verified trust your entire brand.** Bundle (not upsell) a visible vetting badge: ✓ identity verified (Shahkar + face match), ✓ MoH پروانه صلاحیت حرفه‌ای confirmed, ✓ نظام پرستاری number, ✓ عدم سوء پیشینه on file, ✓ trial period + security guarantee. Display your own license number like Salamat Aval does.
+
+**4. Win the geography others ignore.** Tehran/Karaj are saturated and concentrated; **target second-tier cities** (Mashhad, Isfahan, Shiraz, Tabriz, Ahvaz, Qom) where incumbents are thin.
+
+**5. Buy verification, don't build it.** Integrate one KYC vendor (Finnotech or U-ID) for Shahkar + national-ID + liveness; require the MoH competency license + INO number for the license layer; require nurse-uploaded عدم سوء پیشینه.
+
+**6. Decide the employment model with counsel before scaling** — neutral marketplace vs. employer/agency. Avoid the "control-for-quality + contractor-for-cost" trap that triggers misclassification liability. Carry platform liability insurance regardless.
+
+**7. Engineer against disintermediation from day one:** in-platform escrow payment + dispute resolution, a backup-nurse coverage guarantee, EVV check-in/out, and protections that only apply on-platform.
+
+**8. Build the institutional flywheel early:** hospital post-discharge referral partnerships (post-surgery, post-stroke), and pilot B2B contracts with insurers (Salamat / تأمین اجتماعی), charities, or employers to subsidize visits.
+
+**9. Add a lighter "companionship / daily-living" tier** (the Papa model) — lower supply constraint, broader market, and a feeder into skilled-nursing as needs escalate. Court the **diaspora** ("pay for your parent's care back home").
+
+**10. Never over-market safety.** Every Care.com penalty traces to claiming a check it didn't perform or a dark-pattern cancellation. Under-promise, over-verify, make cancellation easy.
+
+---
+
+## Key Open Questions / To Verify Before Launch
+1. **Current (1404–1405) registered-company count** and the present status of the سخت و زیان‌آور labor-law gap — has any legislation closed it?
+2. **Full capital, facility, staffing, and insurance requirements** for the nursing-services-center track specifically, and whether a **tech-first marketplace** can operate by subcontracting *only* to already-licensed partner centers (the Asanism model) without holding its own permit initially.
+3. Whether the **INO / MoH offer any B2B verification API** behind a portal (only "not found" via public search so far).
+4. **Tax, VAT, and company-structure specifics** with a local accountant; **employment classification** with a labor lawyer.
+
+---
+
+### Sources (selected)
+
+**Iran — legal & local market (verified):** arakmu.ac.ir/vct/fa/regulation/1063/ · mcls.gov.ir/fa/law/61 · qavanin.ir/Law/TreeText/83385 · irannurse.ir · vct.iums.ac.ir · ilna.ir/بخش-کارگری-9/797233 · ecommerce.gov.ir · netafraz.com/blog/getting-enamad-complete-guide/ · asanism.com · snapp.doctor/home-nursing/ · salamateaval.com · myket.ir/app/hirad.sc.com
+
+**Foreign platforms:** techcrunch.com (Honor, Cera, Vivian, Birdie, Portea) · ftc.gov & cnbc.com (Care.com FTC) · mobihealthnews.com (Papa) · florence.co.uk · techcrunch.com/technode.global (Homage) · tvmcapitalhealthcare.com (Manzil) · quartr.com (Veteranpoolen)
+
+**Risks & failures:** thedailybeast.com & backgroundchecks.com (Care.com/WSJ) · engadget.com (listing purge) · nurse.org & washingtonpost.com (Womack imposter nurse) · hrmorning.com & ogletree.com (misclassification) · shiftcare.com & axiscare.com (turnover) · sharetribe.com (disintermediation) · aarp.org (financial elder abuse) · pymnts.com (Care.com $1M Marin)
+
+**Verification tooling:** ncsbn.org & nursys.com (Nursys) · nmc.org.uk (NMC) · checkr.com & sterlingcheck.app (background vendors) · behdasht.gov.ir & heyvagroup.com (MoH/INO licensing) · fa.wikipedia.org/سامانه_شاهکار (Shahkar) · finnotech.ir (KYC) · asretarakonesh.ir (8 Iranian KYC firms) · heyvalaw.com (عدم سوء پیشینه via ثنا)
+
+*Report compiled from an adversarially-verified research pass (Iranian legal framework + local competitors) plus three targeted research agents (foreign competitors, risk/failure cases, verification tooling). Verify decades-old regulations, self-reported competitor stats, and funding figures against current primary sources before making decisions or publishing.*
diff --git a/product/database-model.md b/product/database-model.md
new file mode 100644
index 0000000..f39978e
--- /dev/null
+++ b/product/database-model.md
@@ -0,0 +1,1256 @@
+# Balinyaar — Database Model
+
+## Platform Summary
+
+Balinyaar is a hybrid home nursing marketplace in Iran. Independent nurses (and in future, nursing company employees) register, list configurable services with their own pricing, and undergo a multi-step verification pipeline. Families search, pick a nurse and service variant, submit a booking request, and pay through the platform after the nurse accepts. The platform holds payment in escrow and releases weekly payouts to nurses after service completion is confirmed via EVV. All post-booking communication runs through a ticket system inspectable by admins.
+
+---
+
+## Design Principles
+
+1. **Monetary values** stored as `BIGINT` in Iranian Rials (IRR). Toman conversion is a display concern only.
+2. **PII fields** (national ID, IBAN, phone, addresses, clinical data) are marked **(encrypted)** — column-level or application-level encryption; actual mechanism is implementation-specific.
+3. **Soft deletes** on `users` and `nurse_profiles` via `deleted_at`. Audit and payment records are never deleted.
+4. **Audit trail** is append-only. All state transitions on bookings, payments, verifications, and reviews produce a row in `audit_logs`.
+5. **Enum-like fields** use `NVARCHAR(50)` with application-enforced constraints. Admin-managed catalog tables (ServiceCategory, VerificationStepType) are rows, not enums — they can be extended without schema changes.
+6. **Platform fee** is captured at booking time and never derived from current config, so historical records remain accurate after fee changes.
+7. **Snapshot fields** (e.g., `variant_snapshot_json`, `address_snapshot_json` on bookings) protect historical accuracy from future edits to linked records.
+8. **Multi-language** — all admin-managed catalog tables carry `name_fa` / `name_en` pairs.
+9. **All timestamps** are `DATETIME2(7)` in UTC. Persian calendar display is a UI concern.
+10. **String fields** use `NVARCHAR` throughout to support Persian/Arabic characters.
+
+---
+
+## Entity Catalog
+
+---
+
+### Domain 1 — Identity & Access
+
+---
+
+#### `users`
+
+The single identity record for every human actor on the platform: nurses, customers, and admin staff. Role determines which profile sub-table is populated. Phone number is the primary login credential (OTP); email is secondary. National ID is populated only after the KYC step completes.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `email` | NVARCHAR(255) UNIQUE NULL | **(encrypted)** — optional at registration; required for admin accounts |
+| `phone` | NVARCHAR(20) UNIQUE NOT NULL | **(encrypted)** — used for OTP login and Shahkar matching |
+| `national_id` | NVARCHAR(20) UNIQUE NULL | **(encrypted)** — populated after KYC identity step passes |
+| `national_id_verified_at` | DATETIME2 NULL | |
+| `first_name` | NVARCHAR(100) NOT NULL | |
+| `last_name` | NVARCHAR(100) NOT NULL | |
+| `avatar_url` | NVARCHAR(512) NULL | Object-storage URL |
+| `role` | NVARCHAR(20) NOT NULL | `nurse` / `customer` / `admin` |
+| `is_active` | BIT NOT NULL DEFAULT 1 | False = account suspended (not deleted) |
+| `email_verified_at` | DATETIME2 NULL | |
+| `phone_verified_at` | DATETIME2 NULL | Set on first successful OTP |
+| `last_login_at` | DATETIME2 NULL | |
+| `last_login_ip` | NVARCHAR(45) NULL | IPv4 or IPv6 |
+| `preferred_language` | NVARCHAR(5) NOT NULL DEFAULT 'fa' | `fa` / `en` |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+| `deleted_at` | DATETIME2 NULL | Soft delete — NULL = active |
+
+---
+
+#### `user_sessions`
+
+Auth session records for refresh token management. Each login creates a session. Logging out or detecting a stolen token invalidates the session.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `user_id` | BIGINT FK → users NOT NULL | |
+| `refresh_token_hash` | NVARCHAR(64) NOT NULL | SHA-256 of the issued refresh token |
+| `device_info` | NVARCHAR(500) NULL | User-agent string |
+| `ip_address` | NVARCHAR(45) NULL | |
+| `is_revoked` | BIT NOT NULL DEFAULT 0 | |
+| `revoked_at` | DATETIME2 NULL | |
+| `expires_at` | DATETIME2 NOT NULL | |
+| `created_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `roles`
+
+RBAC roles for admin staff. Nurses and customers do not use this table — their permissions are determined by the `users.role` field.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `name` | NVARCHAR(50) UNIQUE NOT NULL | `super_admin` / `admin` / `support` / `finance` / `moderator` |
+| `description` | NVARCHAR(500) NULL | |
+| `created_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `user_roles`
+
+Assignment of admin roles to admin users. A user may hold multiple roles. Revoked roles retain history.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `user_id` | BIGINT FK → users NOT NULL | Must be a user with role=admin |
+| `role_id` | BIGINT FK → roles NOT NULL | |
+| `granted_by_user_id` | BIGINT FK → users NULL | |
+| `granted_at` | DATETIME2 NOT NULL | |
+| `revoked_at` | DATETIME2 NULL | NULL = still active |
+
+---
+
+#### `nurse_profiles`
+
+Extended data for users with `role = nurse`. Separated from `users` to avoid a bloated base table. Denormalized aggregates (`average_rating`, `total_completed_bookings`) are maintained on every review publication and booking completion — never calculated on-the-fly in search queries.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `user_id` | BIGINT FK → users UNIQUE NOT NULL | 1:1 |
+| `bio` | NVARCHAR(2000) NULL | Displayed on nurse profile page |
+| `years_of_experience` | SMALLINT NULL | |
+| `education_level` | NVARCHAR(50) NULL | `bachelor` / `master` / `phd` / `associate` |
+| `education_field` | NVARCHAR(200) NULL | e.g., "پرستاری — دانشگاه تهران" |
+| `specializations_json` | NVARCHAR(MAX) NULL | JSON array of specialization tag strings |
+| `is_verified` | BIT NOT NULL DEFAULT 0 | True only when all required verification steps pass |
+| `verification_status` | NVARCHAR(30) NOT NULL DEFAULT 'not_started' | `not_started` / `pending` / `in_review` / `approved` / `rejected` / `suspended` |
+| `is_accepting_bookings` | BIT NOT NULL DEFAULT 0 | Nurse can toggle without losing verified status |
+| `average_rating` | DECIMAL(3,2) NULL | Denormalized; recalculated on each published review |
+| `total_reviews` | INT NOT NULL DEFAULT 0 | Denormalized count of published reviews |
+| `total_completed_bookings` | INT NOT NULL DEFAULT 0 | Denormalized |
+| `response_rate` | DECIMAL(5,2) NULL | % of booking requests responded to before expiry |
+| `avg_response_time_hours` | DECIMAL(5,2) NULL | Rolling average for display on profile |
+| `profile_completion_score` | SMALLINT NOT NULL DEFAULT 0 | 0–100, shown in backoffice to surface incomplete profiles |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+| `deleted_at` | DATETIME2 NULL | Soft delete |
+
+---
+
+#### `customer_profiles`
+
+Extended profile for users with `role = customer`. Intentionally lightweight — most customer data lives in their bookings and patients.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `user_id` | BIGINT FK → users UNIQUE NOT NULL | 1:1 |
+| `national_id_verified_at` | DATETIME2 NULL | Anti-fraud KYC for high-value customers (optional at launch) |
+| `default_emergency_contact_name` | NVARCHAR(200) NULL | **(encrypted)** — overridable per booking |
+| `default_emergency_contact_phone` | NVARCHAR(20) NULL | **(encrypted)** |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `patients`
+
+The person receiving care. Fully separated from the customer because the payer (adult child, spouse) is often not the patient (elderly parent, newborn, post-surgical adult). A customer may register multiple patients. Patient medical data is encrypted at rest.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `customer_id` | BIGINT FK → customer_profiles NOT NULL | Record owner |
+| `display_name` | NVARCHAR(200) NOT NULL | e.g., "پدر", "مادر بزرگ", "نوزاد" |
+| `first_name` | NVARCHAR(100) NULL | |
+| `last_name` | NVARCHAR(100) NULL | |
+| `birth_date` | DATE NULL | |
+| `gender` | NVARCHAR(10) NULL | `male` / `female` |
+| `blood_type` | NVARCHAR(5) NULL | A+, A-, B+, B-, O+, O-, AB+, AB- |
+| `initial_medical_notes` | NVARCHAR(MAX) NULL | **(encrypted)** — baseline context set by the family |
+| `is_active` | BIT NOT NULL DEFAULT 1 | Soft-archivable |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `customer_addresses`
+
+Saved service locations for a customer. Used in booking requests to tell the nurse where to go. The full address is encrypted. Coordinates are stored for EVV distance matching at check-in.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `customer_id` | BIGINT FK → customer_profiles NOT NULL | |
+| `title` | NVARCHAR(100) NOT NULL | e.g., "خانه", "خانه‌ی پدری" |
+| `address_line1` | NVARCHAR(500) NOT NULL | **(encrypted)** |
+| `address_line2` | NVARCHAR(500) NULL | **(encrypted)** |
+| `city_id` | BIGINT FK → cities NOT NULL | |
+| `district_id` | BIGINT FK → districts NULL | |
+| `postal_code` | NVARCHAR(20) NULL | |
+| `latitude` | DECIMAL(10,7) NULL | For EVV match tolerance check |
+| `longitude` | DECIMAL(10,7) NULL | |
+| `access_notes` | NVARCHAR(500) NULL | **(encrypted)** — door code, building instructions, unit number |
+| `is_primary` | BIT NOT NULL DEFAULT 0 | One primary per customer |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `nurse_bank_accounts`
+
+Banking details for nurse payout. IBAN (Sheba) is encrypted. Multiple accounts allowed; exactly one marked primary receives weekly payouts. Verified by admin before first payout.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `nurse_id` | BIGINT FK → nurse_profiles NOT NULL | |
+| `bank_name` | NVARCHAR(100) NOT NULL | |
+| `account_holder_name` | NVARCHAR(200) NOT NULL | **(encrypted)** |
+| `iban` | NVARCHAR(34) NOT NULL | **(encrypted)** — IR + 24 digits (Sheba) |
+| `is_primary` | BIT NOT NULL DEFAULT 0 | |
+| `is_verified` | BIT NOT NULL DEFAULT 0 | Admin confirmed the account exists and matches nurse identity |
+| `verified_by_admin_id` | BIGINT FK → users NULL | |
+| `verified_at` | DATETIME2 NULL | |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+### Domain 2 — Geographic Data
+
+---
+
+#### `provinces`
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `name_fa` | NVARCHAR(100) NOT NULL | |
+| `name_en` | NVARCHAR(100) NOT NULL | |
+| `is_active` | BIT NOT NULL DEFAULT 1 | |
+
+---
+
+#### `cities`
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `province_id` | BIGINT FK → provinces NOT NULL | |
+| `name_fa` | NVARCHAR(100) NOT NULL | |
+| `name_en` | NVARCHAR(100) NOT NULL | |
+| `is_active` | BIT NOT NULL DEFAULT 1 | |
+| `sort_order` | SMALLINT NOT NULL DEFAULT 0 | For ordered dropdowns |
+
+---
+
+#### `districts`
+
+Sub-city units (محله / منطقه). Granularity varies: in Tehran these map to the 22 official municipal districts; in smaller cities they may be major neighborhoods. Districts are optional — nurses can cover a whole city without specifying districts.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `city_id` | BIGINT FK → cities NOT NULL | |
+| `name_fa` | NVARCHAR(200) NOT NULL | |
+| `name_en` | NVARCHAR(200) NULL | |
+| `is_active` | BIT NOT NULL DEFAULT 1 | |
+
+---
+
+#### `nurse_service_areas`
+
+Defines where a nurse is willing to travel. A nurse can cover multiple cities and optionally specific districts within each. A row with `district_id = NULL` means the nurse covers the entire city. This table drives the geographic filter in nurse search.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `nurse_id` | BIGINT FK → nurse_profiles NOT NULL | |
+| `city_id` | BIGINT FK → cities NOT NULL | |
+| `district_id` | BIGINT FK → districts NULL | NULL = entire city |
+| `created_at` | DATETIME2 NOT NULL | |
+
+**Index:** `(nurse_id, city_id, district_id)` UNIQUE — prevents duplicate area declarations.
+
+---
+
+### Domain 3 — Nurse Services & Pricing
+
+The service model has three admin-defined layers (category → option groups → option values) and two nurse-defined layers (variant → variant options). This design lets admins add new configurable dimensions (e.g., "shift length", "number of patients") without schema changes, and lets each nurse price every combination they choose to offer independently.
+
+---
+
+#### `service_categories`
+
+Admin-managed top-level care types. These are the primary search dimension for customers.
+
+Examples: *مراقبت از سالمند* (Elderly Care), *مراقبت پس از جراحی* (Post-Surgery Recovery), *مراقبت از نوزاد* (Infant/Newborn Care), *مدیریت بیماری مزمن* (Chronic Illness Management), *همراهی و کمک روزمره* (Companionship/Daily Living — future tier).
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `name_fa` | NVARCHAR(200) NOT NULL | |
+| `name_en` | NVARCHAR(200) NOT NULL | |
+| `description_fa` | NVARCHAR(1000) NULL | Shown to customers in search |
+| `icon_url` | NVARCHAR(512) NULL | |
+| `is_active` | BIT NOT NULL DEFAULT 1 | |
+| `sort_order` | SMALLINT NOT NULL DEFAULT 0 | |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `service_option_groups`
+
+Admin-defined configurable dimensions per category. Each group represents one axis the nurse can configure. A NULL `service_category_id` means the option group applies across all categories (e.g., shift type).
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `service_category_id` | BIGINT FK → service_categories NULL | NULL = cross-category |
+| `name_fa` | NVARCHAR(200) NOT NULL | e.g., "تعداد بیمار", "نوع شیفت" |
+| `name_en` | NVARCHAR(200) NOT NULL | |
+| `description_fa` | NVARCHAR(500) NULL | Instructions shown to nurse when setting up a listing |
+| `is_required` | BIT NOT NULL DEFAULT 1 | If true, nurse must select a value from this group per variant |
+| `sort_order` | SMALLINT NOT NULL DEFAULT 0 | |
+| `is_active` | BIT NOT NULL DEFAULT 1 | |
+
+---
+
+#### `service_option_values`
+
+Concrete choices within an option group. The nurse selects from these when creating a variant.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `option_group_id` | BIGINT FK → service_option_groups NOT NULL | |
+| `label_fa` | NVARCHAR(200) NOT NULL | e.g., "۱ نفر", "۲ نفر", "شبانه‌روزی" |
+| `label_en` | NVARCHAR(200) NULL | |
+| `sort_order` | SMALLINT NOT NULL DEFAULT 0 | |
+| `is_active` | BIT NOT NULL DEFAULT 1 | |
+
+---
+
+#### `nurse_service_variants`
+
+The atomic bookable unit on the platform. Each variant is a specific offering by a nurse: a service category with a particular combination of option values, at a specific price. These rows are indexed for search and displayed on the nurse's public profile. A nurse may have many variants per category (one per combination they choose to offer).
+
+Example: *Nurse A → Elderly Care → 2 patients → Full-day shift → 3,200,000 IRR per day*
+
+The `display_name` is auto-generated from the selected option labels but can be customized by the nurse. The `price_unit` determines how the price is shown (per hour, per session, per day, etc.). For hourly variants, `estimated_duration_hours` gives the minimum or typical commitment so customers can estimate total cost.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `nurse_id` | BIGINT FK → nurse_profiles NOT NULL | |
+| `service_category_id` | BIGINT FK → service_categories NOT NULL | |
+| `display_name` | NVARCHAR(300) NOT NULL | Shown on profile and search results |
+| `price` | BIGINT NOT NULL | In IRR. Never null — every variant must have a price. |
+| `price_unit` | NVARCHAR(20) NOT NULL | `per_hour` / `per_session` / `per_half_day` / `per_day` / `per_24h` |
+| `estimated_duration_hours` | DECIMAL(5,2) NULL | For hourly variants, helps customer estimate total cost |
+| `description` | NVARCHAR(1000) NULL | Nurse's optional notes about this specific variant |
+| `is_active` | BIT NOT NULL DEFAULT 1 | Nurse can deactivate without deleting; deactivated variants cannot be booked |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `nurse_service_variant_options`
+
+Records which option values apply to a variant. Together, these rows define the full configuration of a variant. A variant covering two option groups (e.g., patient count + shift type) will have two rows here.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `variant_id` | BIGINT FK → nurse_service_variants NOT NULL | |
+| `option_group_id` | BIGINT FK → service_option_groups NOT NULL | |
+| `option_value_id` | BIGINT FK → service_option_values NOT NULL | |
+
+**Constraint:** `(variant_id, option_group_id)` UNIQUE — one value per dimension per variant.
+
+---
+
+#### `nurse_availability_slots`
+
+Recurring weekly availability windows declared by the nurse. These inform the customer's search (e.g., "available Saturdays 8am–6pm") but are **soft constraints** — the nurse still accepts or rejects each individual booking request. They do not block booking requests for times outside these slots; they are guidance only.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `nurse_id` | BIGINT FK → nurse_profiles NOT NULL | |
+| `day_of_week` | TINYINT NOT NULL | 0=Saturday, 1=Sunday, 2=Monday, 3=Tuesday, 4=Wednesday, 5=Thursday, 6=Friday (Shamsi week) |
+| `start_time` | TIME NOT NULL | |
+| `end_time` | TIME NOT NULL | |
+| `is_active` | BIT NOT NULL DEFAULT 1 | |
+| `created_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `nurse_availability_exceptions`
+
+Date-specific overrides to the recurring weekly schedule. Used for vacations, public holidays the nurse wants to block, or one-time extra availability on a normally-off day.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `nurse_id` | BIGINT FK → nurse_profiles NOT NULL | |
+| `exception_date` | DATE NOT NULL | |
+| `is_available` | BIT NOT NULL | False = day blocked; True = day open (even if absent from weekly slots) |
+| `reason` | NVARCHAR(200) NULL | e.g., "تعطیلات عید نوروز" |
+
+**Constraint:** `(nurse_id, exception_date)` UNIQUE.
+
+---
+
+### Domain 4 — Nurse Verification
+
+The verification pipeline is a sequence of steps. Each step type is admin-configurable (new steps can be added as rows, no code change). Steps can be automated (KYC API call) or manual (admin reviews uploaded document). The overall `nurse_verifications` record aggregates the step outcomes into a single status.
+
+---
+
+#### `nurse_verifications`
+
+Master verification record for a nurse — one row per nurse, created when the nurse first submits for verification. Every status transition here is captured in `audit_logs`. When all required `verification_steps` reach `passed`, this record's status moves to `approved` and `nurse_profiles.is_verified` flips to true.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `nurse_id` | BIGINT FK → nurse_profiles UNIQUE NOT NULL | 1:1 |
+| `status` | NVARCHAR(30) NOT NULL DEFAULT 'not_started' | `not_started` / `pending` / `in_review` / `approved` / `rejected` / `suspended` |
+| `submitted_at` | DATETIME2 NULL | First submission timestamp |
+| `approved_at` | DATETIME2 NULL | |
+| `rejected_at` | DATETIME2 NULL | |
+| `suspended_at` | DATETIME2 NULL | |
+| `rejection_reason` | NVARCHAR(1000) NULL | Shown to the nurse in the app |
+| `reviewed_by_admin_id` | BIGINT FK → users NULL | Last admin to act on this record |
+| `internal_notes` | NVARCHAR(2000) NULL | Admin-only; not shown to nurse |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `verification_step_types`
+
+Admin-configurable catalog of what steps exist in the pipeline. Adding a new step type (e.g., "professional liability insurance") requires only inserting a row here — no code change needed. The `code` is a stable machine key referenced by application logic for automated steps.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `code` | NVARCHAR(100) UNIQUE NOT NULL | e.g., `identity_kyc`, `moh_license`, `ino_membership`, `criminal_record`, `bank_account_verification` |
+| `name_fa` | NVARCHAR(200) NOT NULL | Shown in backoffice |
+| `name_en` | NVARCHAR(200) NOT NULL | |
+| `description_fa` | NVARCHAR(500) NULL | Instructions shown to nurse for this step |
+| `is_required` | BIT NOT NULL DEFAULT 1 | Non-required steps are advisory; they don't block approval |
+| `is_automated` | BIT NOT NULL DEFAULT 0 | If true, platform calls an external API for this step |
+| `automation_provider` | NVARCHAR(100) NULL | e.g., `finnotech`, `u_id`, `jibbit`, `manual` |
+| `requires_document_upload` | BIT NOT NULL DEFAULT 0 | If true, nurse must upload at least one document |
+| `sort_order` | SMALLINT NOT NULL DEFAULT 0 | Processing order shown to nurse |
+| `is_active` | BIT NOT NULL DEFAULT 1 | |
+| `created_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `verification_steps`
+
+One row per step per nurse. Tracks individual step status as the nurse moves through the pipeline. The `external_response_json` stores the raw API response for automated steps — critical for dispute and compliance audit. For manual steps, `reviewed_by_admin_id` and `review_notes` capture who reviewed and what they decided.
+
+`expires_at` supports time-limited steps: the criminal record certificate (گواهی عدم سوء پیشینه) is valid for a limited period; when it expires, the step reverts to `pending` and a support alert is raised.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `nurse_verification_id` | BIGINT FK → nurse_verifications NOT NULL | |
+| `step_type_id` | BIGINT FK → verification_step_types NOT NULL | |
+| `status` | NVARCHAR(30) NOT NULL DEFAULT 'pending' | `pending` / `submitted` / `processing` / `passed` / `failed` / `expired` |
+| `is_automated` | BIT NOT NULL | Snapshot from step_type at creation; stored so historical records survive step_type edits |
+| `external_provider` | NVARCHAR(100) NULL | KYC vendor that processed this step |
+| `external_reference_id` | NVARCHAR(200) NULL | Provider's session/transaction ID |
+| `external_response_json` | NVARCHAR(MAX) NULL | Full API response for audit |
+| `reviewed_by_admin_id` | BIGINT FK → users NULL | NULL for automated steps |
+| `review_notes` | NVARCHAR(1000) NULL | Admin rationale for pass/fail decision |
+| `submitted_at` | DATETIME2 NULL | When nurse submitted this step |
+| `completed_at` | DATETIME2 NULL | When step reached terminal state |
+| `expires_at` | DATETIME2 NULL | For time-limited steps (e.g., criminal record cert) |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+**Constraint:** `(nurse_verification_id, step_type_id)` UNIQUE.
+
+---
+
+#### `verification_documents`
+
+Documents uploaded as evidence for a verification step. File contents live in object storage (S3-compatible). This table holds the metadata, reference key, and integrity hash. Access to the actual file must be through signed/time-limited URLs — never a direct public URL.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `verification_step_id` | BIGINT FK → verification_steps NOT NULL | |
+| `document_type` | NVARCHAR(50) NOT NULL | `national_id_front` / `national_id_back` / `moh_license` / `ino_certificate` / `criminal_record` / `selfie` / `liveness_video` |
+| `storage_key` | NVARCHAR(512) NOT NULL | Object-storage path — access-controlled, no public URL |
+| `file_hash` | NVARCHAR(64) NOT NULL | SHA-256 of raw file bytes for integrity verification |
+| `file_size_bytes` | INT NULL | |
+| `mime_type` | NVARCHAR(100) NULL | |
+| `is_valid` | BIT NULL | NULL = pending review; True/False after admin assessment |
+| `uploaded_at` | DATETIME2 NOT NULL | |
+
+---
+
+### Domain 5 — Booking & Scheduling
+
+The booking lifecycle has two distinct phases: the **request phase** (before payment) and the **booking phase** (after payment). Separating them into two tables keeps each table focused and makes lifecycle transitions explicit. A booking only exists if payment succeeded.
+
+**Request lifecycle:**
+`pending_nurse_response` → nurse accepts → `accepted_awaiting_payment` → payment received → `converted` (Booking created)
+`pending_nurse_response` → nurse rejects → `rejected_by_nurse`
+`pending_nurse_response` → deadline passes → `expired_no_response`
+`accepted_awaiting_payment` → 30-min payment window passes → `payment_deadline_expired`
+Any pre-payment state → customer cancels → `cancelled_by_customer`
+
+**Booking lifecycle:**
+`pending_payment` → payment captured → `confirmed`
+`confirmed` → nurse checks in → `in_progress`
+`in_progress` → nurse checks out → `completed`
+`confirmed` → cancelled before service → `cancelled`
+`completed` → disputed → `disputed`
+`disputed` → resolved → `closed`
+
+---
+
+#### `booking_requests`
+
+A customer's intent to book a nurse for a specific service, date, and time slot. Created when the customer submits a request. Multiple requests can exist for the same customer/nurse pair (e.g., first one rejected, a new one submitted later). No money is involved at this stage.
+
+The `nurse_response_deadline_at` is computed from `platform_configs.nurse_response_deadline_hours` at creation time and stored so it is immune to config changes. Similarly, `payment_deadline_at` is set when the nurse accepts and reflects the 30-minute window from that moment.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `customer_id` | BIGINT FK → customer_profiles NOT NULL | |
+| `nurse_id` | BIGINT FK → nurse_profiles NOT NULL | |
+| `patient_id` | BIGINT FK → patients NOT NULL | |
+| `variant_id` | BIGINT FK → nurse_service_variants NOT NULL | The specific service + options the customer wants |
+| `customer_address_id` | BIGINT FK → customer_addresses NOT NULL | |
+| `requested_date` | DATE NOT NULL | |
+| `requested_time_start` | TIME NOT NULL | |
+| `requested_time_end` | TIME NOT NULL | |
+| `customer_notes` | NVARCHAR(1000) NULL | Additional context the customer sends with the request (visible to nurse) |
+| `status` | NVARCHAR(50) NOT NULL DEFAULT 'pending_nurse_response' | See lifecycle above |
+| `nurse_response_deadline_at` | DATETIME2 NOT NULL | After this, job transitions to `expired_no_response` automatically |
+| `payment_deadline_at` | DATETIME2 NULL | Set when nurse accepts; 30-minute countdown starts |
+| `nurse_rejection_reason` | NVARCHAR(500) NULL | Optional message from nurse on rejection |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `bookings`
+
+Confirmed service engagement. Created when nurse accepts AND payment is successfully captured within the deadline. This is the source of truth for the actual service event. The `variant_snapshot_json` and `address_snapshot_json` freeze the service details and address at booking time, protecting historical records from future edits to those referenced entities.
+
+The fee fields capture the exact split at the moment of booking: `gross_amount` (what the customer pays), `platform_fee_amount` (platform's share), and `nurse_payout_amount` (what the nurse will receive). The `platform_fee_rate` is stored so auditors can reconstruct how the split was calculated even after the fee schedule changes.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `booking_request_id` | BIGINT FK → booking_requests UNIQUE NOT NULL | 1:1 — the request that created this booking |
+| `customer_id` | BIGINT FK → customer_profiles NOT NULL | Denormalized for query performance |
+| `nurse_id` | BIGINT FK → nurse_profiles NOT NULL | |
+| `patient_id` | BIGINT FK → patients NOT NULL | |
+| `variant_id` | BIGINT FK → nurse_service_variants NOT NULL | Reference — see snapshot below for historical accuracy |
+| `variant_snapshot_json` | NVARCHAR(MAX) NOT NULL | Full JSON of variant + option labels at booking time |
+| `customer_address_id` | BIGINT FK → customer_addresses NOT NULL | |
+| `address_snapshot_json` | NVARCHAR(MAX) NOT NULL | **(encrypted)** — full address at booking time |
+| `scheduled_date` | DATE NOT NULL | |
+| `scheduled_time_start` | TIME NOT NULL | |
+| `scheduled_time_end` | TIME NOT NULL | |
+| `gross_amount` | BIGINT NOT NULL | Total charged to customer (IRR) |
+| `platform_fee_amount` | BIGINT NOT NULL | Platform's cut |
+| `platform_fee_rate` | DECIMAL(5,4) NOT NULL | e.g., 0.1500 = 15% — captured at booking time |
+| `nurse_payout_amount` | BIGINT NOT NULL | gross_amount - platform_fee_amount |
+| `status` | NVARCHAR(30) NOT NULL DEFAULT 'pending_payment' | See lifecycle above |
+| `confirmed_at` | DATETIME2 NULL | When payment was captured |
+| `cancelled_at` | DATETIME2 NULL | |
+| `cancellation_reason` | NVARCHAR(500) NULL | |
+| `cancelled_by` | NVARCHAR(20) NULL | `customer` / `nurse` / `admin` / `system` |
+| `completed_at` | DATETIME2 NULL | When booking status moved to completed |
+| `payout_released` | BIT NOT NULL DEFAULT 0 | True when this booking is included in a processed payout batch |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `booking_care_instructions`
+
+Clinical and logistical context provided by the family at booking time. Separated from `bookings` to keep the financial/scheduling table clean and because this data has stricter access controls (encrypted, visible only to the assigned nurse and admin). The nurse reads this before the visit.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `booking_id` | BIGINT FK → bookings UNIQUE NOT NULL | 1:1 |
+| `current_conditions` | NVARCHAR(MAX) NULL | **(encrypted)** — active diagnoses |
+| `current_medications` | NVARCHAR(MAX) NULL | **(encrypted)** — drug names, doses, schedule |
+| `allergies` | NVARCHAR(1000) NULL | **(encrypted)** |
+| `special_instructions` | NVARCHAR(2000) NULL | **(encrypted)** — care protocol, family preferences |
+| `emergency_contact_name` | NVARCHAR(200) NULL | **(encrypted)** |
+| `emergency_contact_phone` | NVARCHAR(20) NULL | **(encrypted)** |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `visit_verifications`
+
+Electronic Visit Verification (EVV). The nurse clocks in and out via the app; GPS coordinates and timestamps are recorded. This is the authoritative record of whether a visit occurred and for how long. It is required for payout release. If a nurse does not check in by a configurable threshold after the scheduled start time, a `support_alerts` record is created and the family is notified.
+
+`check_in_address_match` is a computed boolean: did the nurse's GPS at check-in fall within an acceptable radius of the booking address? This flag is advisory for admin — a mismatch triggers a review but does not automatically cancel the booking.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `booking_id` | BIGINT FK → bookings UNIQUE NOT NULL | 1:1 |
+| `check_in_at` | DATETIME2 NULL | |
+| `check_in_latitude` | DECIMAL(10,7) NULL | |
+| `check_in_longitude` | DECIMAL(10,7) NULL | |
+| `check_in_address_match` | BIT NULL | Did GPS match booking address within tolerance? |
+| `check_out_at` | DATETIME2 NULL | |
+| `check_out_latitude` | DECIMAL(10,7) NULL | |
+| `check_out_longitude` | DECIMAL(10,7) NULL | |
+| `actual_duration_minutes` | INT NULL | Computed: check_out_at - check_in_at |
+| `status` | NVARCHAR(20) NOT NULL DEFAULT 'pending' | `pending` / `checked_in` / `completed` / `missed` / `disputed` |
+| `nurse_checkout_notes` | NVARCHAR(500) NULL | Optional note from nurse at checkout |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+### Domain 6 — Payments
+
+---
+
+#### `payment_gateways`
+
+Configuration for each PSP connected to the platform. Credentials are encrypted. Multiple gateways may be active simultaneously (e.g., standard IPG for direct payment, a BNPL gateway for installments, a failover gateway). The `type` field determines which payment flow applies.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `code` | NVARCHAR(50) UNIQUE NOT NULL | e.g., `zarinpal`, `idpay`, `payping`, `bnpl_hamrah`, `bnpl_toranj` |
+| `name` | NVARCHAR(100) NOT NULL | Display name |
+| `type` | NVARCHAR(30) NOT NULL | `standard` / `bnpl` |
+| `is_active` | BIT NOT NULL DEFAULT 1 | |
+| `config_json` | NVARCHAR(MAX) NULL | **(encrypted)** — merchant ID, API keys, webhook secret, callback URLs |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `payment_transactions`
+
+Records every payment attempt against a booking. A booking may have multiple rows here (failed first attempt, successful retry). The row where `status = 'succeeded'` is the one that triggers booking confirmation. The `gateway_response_json` stores the full PSP response — essential for dispute, chargebacks, and Shaparak reconciliation.
+
+`ip_address` and `user_agent` at payment time are retained for fraud detection and dispute evidence.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `booking_id` | BIGINT FK → bookings NOT NULL | |
+| `customer_id` | BIGINT FK → customer_profiles NOT NULL | |
+| `gateway_id` | BIGINT FK → payment_gateways NOT NULL | |
+| `amount` | BIGINT NOT NULL | Amount charged in this transaction (IRR) |
+| `currency` | NVARCHAR(5) NOT NULL DEFAULT 'IRR' | |
+| `status` | NVARCHAR(30) NOT NULL DEFAULT 'initiated' | `initiated` / `pending` / `succeeded` / `failed` / `cancelled` / `refunded` / `partially_refunded` |
+| `gateway_transaction_id` | NVARCHAR(200) NULL | PSP's transaction identifier |
+| `gateway_reference_code` | NVARCHAR(200) NULL | Shaparak reference code — the definitive payment proof |
+| `gateway_response_code` | NVARCHAR(50) NULL | PSP result code |
+| `gateway_response_json` | NVARCHAR(MAX) NULL | Full PSP response |
+| `is_installment` | BIT NOT NULL DEFAULT 0 | True if funded via a BNPL plan |
+| `initiated_at` | DATETIME2 NOT NULL | When the payment flow was started |
+| `paid_at` | DATETIME2 NULL | When PSP confirmed success |
+| `failed_at` | DATETIME2 NULL | |
+| `failure_reason` | NVARCHAR(500) NULL | Human-readable from PSP |
+| `ip_address` | NVARCHAR(45) NULL | Customer's IP at payment time |
+| `user_agent` | NVARCHAR(500) NULL | |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `refunds`
+
+Refund requests and their resolution. Refunds are always admin-initiated — there is no customer self-service refund. They are typically triggered by a family request communicated through a support ticket. Default refund is 100% of the payment; admin may set a partial amount (e.g., cancellation fee deducted).
+
+The `ticket_id` links to the support conversation where the refund was discussed, providing full context for dispute evidence.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `payment_transaction_id` | BIGINT FK → payment_transactions NOT NULL | The original successful payment being refunded |
+| `booking_id` | BIGINT FK → bookings NOT NULL | |
+| `requested_by_customer_id` | BIGINT FK → customer_profiles NOT NULL | |
+| `ticket_id` | BIGINT FK → tickets NULL | Support conversation that led to this refund |
+| `amount` | BIGINT NOT NULL | Refund amount (IRR). Default = full gross_amount. |
+| `refund_percentage` | DECIMAL(5,2) NOT NULL | For audit display (e.g., 100.00, 50.00) |
+| `reason_category` | NVARCHAR(50) NOT NULL | `nurse_no_show` / `quality_complaint` / `scheduling_error` / `customer_cancellation` / `platform_error` / `other` |
+| `reason_notes` | NVARCHAR(1000) NULL | |
+| `status` | NVARCHAR(30) NOT NULL DEFAULT 'pending' | `pending` / `approved` / `rejected` / `processing` / `completed` / `failed` |
+| `approved_by_admin_id` | BIGINT FK → users NULL | |
+| `approved_at` | DATETIME2 NULL | |
+| `rejected_by_admin_id` | BIGINT FK → users NULL | |
+| `rejected_at` | DATETIME2 NULL | |
+| `rejection_reason` | NVARCHAR(500) NULL | Communicated to customer |
+| `gateway_refund_reference` | NVARCHAR(200) NULL | PSP's refund transaction ID |
+| `processed_at` | DATETIME2 NULL | When PSP confirmed refund success |
+| `admin_notes` | NVARCHAR(1000) NULL | Internal only — not shown to customer |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `nurse_payout_batches`
+
+Weekly aggregation of all amounts owed to nurses for completed, unpaid bookings. Admin initiates a batch (manually or via a scheduled job). Each batch covers a specific period and produces one `nurse_payouts` row per nurse with earnings in that window.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `period_start` | DATE NOT NULL | |
+| `period_end` | DATE NOT NULL | |
+| `total_amount` | BIGINT NOT NULL | Sum of all nurse_payout_amount in this batch |
+| `payout_count` | INT NOT NULL | Number of individual nurse payouts in this batch |
+| `status` | NVARCHAR(30) NOT NULL DEFAULT 'draft' | `draft` / `processing` / `completed` / `partially_failed` / `failed` |
+| `initiated_by_admin_id` | BIGINT FK → users NULL | |
+| `processed_at` | DATETIME2 NULL | |
+| `failure_notes` | NVARCHAR(1000) NULL | |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `nurse_payouts`
+
+One row per nurse per batch. Records the exact amount transferred, which bank account was used (snapshot, not FK, because account may change), and the transfer reference for bank reconciliation.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `batch_id` | BIGINT FK → nurse_payout_batches NOT NULL | |
+| `nurse_id` | BIGINT FK → nurse_profiles NOT NULL | |
+| `bank_account_id` | BIGINT FK → nurse_bank_accounts NOT NULL | Primary account at time of payout |
+| `iban_snapshot` | NVARCHAR(34) NOT NULL | **(encrypted)** — IBAN at time of payout; in case account is later changed |
+| `amount` | BIGINT NOT NULL | Total paid to nurse in this batch (IRR) |
+| `booking_count` | INT NOT NULL | How many bookings this covers |
+| `status` | NVARCHAR(30) NOT NULL DEFAULT 'pending' | `pending` / `processing` / `paid` / `failed` |
+| `transfer_reference` | NVARCHAR(200) NULL | Bank/ACH reference for reconciliation |
+| `paid_at` | DATETIME2 NULL | |
+| `failure_reason` | NVARCHAR(500) NULL | |
+| `created_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `nurse_payout_booking_links`
+
+Join table linking each payout to the specific bookings it covers. Enables per-booking reconciliation and prevents double-paying the same booking in a future batch.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `payout_id` | BIGINT FK → nurse_payouts NOT NULL | |
+| `booking_id` | BIGINT FK → bookings UNIQUE NOT NULL | UNIQUE ensures a booking can only appear in one payout |
+| `amount` | BIGINT NOT NULL | nurse_payout_amount for this booking |
+
+---
+
+### Domain 7 — BNPL / Installments
+
+When a customer pays via BNPL, the third-party provider approves the installment plan and pays the platform. The customer repays the BNPL provider directly. From the platform's perspective, the `payment_transactions` row is `succeeded` with `is_installment = true`. The tables below track the BNPL plan details for reconciliation, reporting, and potential future collections escalation.
+
+> **⚠️ Open decision before implementation:** Two BNPL settlement models exist and the choice affects this schema:
+>
+> - **Immediate full settlement** — the provider pays the platform the full booking amount (possibly net of their own fee) in one transfer at approval time. In this case `payment_transactions.amount` is the booking's `gross_amount`, and `installment_plans.total_amount` may be *higher* (the provider charges the customer more than the booking price to cover their financing fee). The current schema handles this correctly — the two amounts live in separate fields on separate tables.
+>
+> - **Tranched settlement** — the provider pays the platform in installments as the customer pays them. In this case a single `payment_transactions` row is insufficient; you would need either multiple rows in `payment_transactions` (one per provider settlement) or a dedicated `bnpl_settlement_entries` table linked to `installment_plans`. The current schema does **not** handle this — it would require an additive migration.
+>
+> Confirm which model your chosen BNPL provider uses before building the payment integration.
+
+---
+
+#### `installment_plans`
+
+Metadata about a BNPL approval linked to a specific payment transaction.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `payment_transaction_id` | BIGINT FK → payment_transactions UNIQUE NOT NULL | 1:1 |
+| `bnpl_provider_code` | NVARCHAR(50) NOT NULL | Matches `payment_gateways.code` |
+| `external_plan_id` | NVARCHAR(200) NOT NULL | Provider's plan identifier |
+| `total_amount` | BIGINT NOT NULL | Total the customer owes the provider (IRR), may include provider fee |
+| `installment_count` | TINYINT NOT NULL | Number of installments |
+| `monthly_fee_rate` | DECIMAL(5,4) NULL | Provider's monthly fee rate |
+| `plan_start_date` | DATE NOT NULL | |
+| `plan_end_date` | DATE NOT NULL | |
+| `status` | NVARCHAR(30) NOT NULL DEFAULT 'pending_approval' | `pending_approval` / `approved` / `rejected` / `active` / `completed` / `defaulted` |
+| `approved_at` | DATETIME2 NULL | |
+| `last_webhook_at` | DATETIME2 NULL | When last webhook was received from provider |
+| `webhook_payload_json` | NVARCHAR(MAX) NULL | Last webhook payload |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `installment_entries`
+
+Individual installment records. Updated via webhook from the BNPL provider when a payment occurs or is missed.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `plan_id` | BIGINT FK → installment_plans NOT NULL | |
+| `installment_number` | TINYINT NOT NULL | 1-based |
+| `amount` | BIGINT NOT NULL | Amount due for this installment (IRR) |
+| `due_date` | DATE NOT NULL | |
+| `paid_at` | DATETIME2 NULL | NULL = not yet paid |
+| `status` | NVARCHAR(20) NOT NULL DEFAULT 'upcoming' | `upcoming` / `due` / `paid` / `overdue` / `defaulted` |
+| `external_reference` | NVARCHAR(200) NULL | Provider's reference for this specific installment |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+### Domain 8 — Messaging (Ticket System)
+
+There is no live chat and no direct messaging between nurse and customer. All post-booking communication runs through a structured ticket system where admin can read every message. This is intentional: it protects vulnerable patients, creates a paper trail for disputes, and prevents disintermediation. Tickets can also be used by customers or nurses to contact support for any reason.
+
+---
+
+#### `tickets`
+
+A support or communication thread. May be linked to a booking, refund, or stand alone. Admin assigns, responds, and resolves tickets. Customers and nurses communicate through messages on their assigned ticket.
+
+The `reference_code` is a human-readable identifier (e.g., `TKT-2025-001234`) communicated to users for support follow-up.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `reference_code` | NVARCHAR(30) UNIQUE NOT NULL | Human-readable code for support communication |
+| `subject` | NVARCHAR(300) NOT NULL | |
+| `type` | NVARCHAR(50) NOT NULL | `booking_coordination` / `booking_issue` / `refund_request` / `nurse_complaint` / `review_dispute` / `verification_question` / `general` |
+| `status` | NVARCHAR(30) NOT NULL DEFAULT 'open' | `open` / `pending_customer` / `pending_nurse` / `pending_admin` / `resolved` / `closed` |
+| `priority` | NVARCHAR(20) NOT NULL DEFAULT 'medium' | `low` / `medium` / `high` / `urgent` |
+| `booking_id` | BIGINT FK → bookings NULL | Context link — not required |
+| `refund_id` | BIGINT FK → refunds NULL | |
+| `created_by_user_id` | BIGINT FK → users NOT NULL | Who opened the ticket |
+| `assigned_to_admin_id` | BIGINT FK → users NULL | Current admin owner |
+| `resolved_at` | DATETIME2 NULL | |
+| `closed_at` | DATETIME2 NULL | |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `ticket_participants`
+
+Controls who has access to a ticket. Every ticket has at minimum its creator and an admin. Post-booking tickets may include both the customer and the nurse.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `ticket_id` | BIGINT FK → tickets NOT NULL | |
+| `user_id` | BIGINT FK → users NOT NULL | |
+| `participant_role` | NVARCHAR(20) NOT NULL | `customer` / `nurse` / `admin` / `support` |
+| `added_at` | DATETIME2 NOT NULL | |
+| `removed_at` | DATETIME2 NULL | NULL = still active participant |
+
+**Constraint:** `(ticket_id, user_id)` UNIQUE.
+
+---
+
+#### `ticket_messages`
+
+Messages within a ticket. `is_internal = true` messages are admin-only notes — they are never shown to the customer or nurse. This allows admins to coordinate internally without leaving the ticket context.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `ticket_id` | BIGINT FK → tickets NOT NULL | |
+| `sender_user_id` | BIGINT FK → users NOT NULL | |
+| `body` | NVARCHAR(MAX) NOT NULL | |
+| `is_internal` | BIT NOT NULL DEFAULT 0 | True = admin-only note |
+| `attachments_json` | NVARCHAR(MAX) NULL | JSON array of {storage_key, filename, mime_type} |
+| `created_at` | DATETIME2 NOT NULL | |
+
+---
+
+### Domain 9 — Reviews & Patient Records
+
+---
+
+#### `review_tags_master`
+
+Admin-managed standardized tags for reviews. Allows quantitative aggregation of qualitative feedback (e.g., "% of reviews tagged 'punctual'"). Nurses can later see their most common tags on their profile.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `name_fa` | NVARCHAR(100) NOT NULL | e.g., "وقت‌شناس", "مهربان", "متخصص", "غیرحرفه‌ای" |
+| `name_en` | NVARCHAR(100) NULL | |
+| `sentiment` | NVARCHAR(10) NOT NULL | `positive` / `negative` / `neutral` |
+| `is_active` | BIT NOT NULL DEFAULT 1 | |
+| `sort_order` | SMALLINT NOT NULL DEFAULT 0 | |
+
+---
+
+#### `reviews`
+
+Post-booking review by the customer about the nurse. Only one review per booking. Submitted reviews enter `pending_moderation` and are not shown publicly until an admin (or AI moderator) approves them. A rating of 1 or 2 with negative content automatically triggers a `support_alerts` row so the support team can investigate.
+
+When a review is published, `nurse_profiles.average_rating` and `total_reviews` are updated.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `booking_id` | BIGINT FK → bookings UNIQUE NOT NULL | One review per booking |
+| `customer_id` | BIGINT FK → customer_profiles NOT NULL | |
+| `nurse_id` | BIGINT FK → nurse_profiles NOT NULL | Denormalized for query performance |
+| `rating` | TINYINT NOT NULL | 1–5 |
+| `body` | NVARCHAR(2000) NULL | Free-text content |
+| `status` | NVARCHAR(30) NOT NULL DEFAULT 'pending_moderation' | `pending_moderation` / `published` / `rejected` / `hidden` |
+| `moderated_by_admin_id` | BIGINT FK → users NULL | Admin or AI agent that approved/rejected |
+| `moderation_notes` | NVARCHAR(500) NULL | Internal reason for rejection or hiding |
+| `published_at` | DATETIME2 NULL | |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `review_tag_links`
+
+Tags applied to a specific review.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `review_id` | BIGINT FK → reviews NOT NULL | |
+| `tag_id` | BIGINT FK → review_tags_master NOT NULL | |
+
+**Constraint:** `(review_id, tag_id)` UNIQUE.
+
+---
+
+#### `patient_care_records`
+
+Nurse-authored clinical notes written after completing a booking. These accumulate over time and form a longitudinal care history for the patient. When a new nurse receives a booking request for the same patient, they can read this history to understand prior care, medications, and observations — enabling continuity of care across multiple nurses.
+
+Access to these records is strictly controlled: only the patient's owning customer, nurses with a confirmed upcoming or in-progress booking for that patient, and admin may read them. All fields are encrypted.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `patient_id` | BIGINT FK → patients NOT NULL | |
+| `booking_id` | BIGINT FK → bookings NOT NULL | The specific visit that generated this record |
+| `nurse_id` | BIGINT FK → nurse_profiles NOT NULL | Who authored the record |
+| `observations` | NVARCHAR(MAX) NULL | **(encrypted)** — general notes on patient state during the visit |
+| `vitals_json` | NVARCHAR(MAX) NULL | **(encrypted)** — structured: {blood_pressure, temperature, pulse, oxygen_saturation, ...} |
+| `medications_json` | NVARCHAR(MAX) NULL | **(encrypted)** — medications administered or observed |
+| `conditions_note` | NVARCHAR(MAX) NULL | **(encrypted)** — new or changed conditions noted by the nurse |
+| `recorded_at` | DATETIME2 NOT NULL | When nurse submitted this record |
+| `created_at` | DATETIME2 NOT NULL | |
+
+---
+
+### Domain 10 — Notifications
+
+---
+
+#### `notifications`
+
+In-app notification records for all user types. No push notifications at launch — these are polled on page load or explicitly fetched. The `data_json` carries a typed payload that the front-end uses to navigate to the relevant entity (e.g., open a specific booking, ticket, or payout screen).
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `user_id` | BIGINT FK → users NOT NULL | Recipient |
+| `type` | NVARCHAR(80) NOT NULL | e.g., `booking_request_received`, `booking_accepted`, `booking_rejected`, `booking_request_expired`, `payment_succeeded`, `payment_failed`, `booking_confirmed`, `review_published`, `review_rejected`, `payout_processed`, `ticket_new_message`, `verification_update`, `nurse_no_show_alert` |
+| `title_fa` | NVARCHAR(300) NOT NULL | |
+| `body_fa` | NVARCHAR(500) NULL | |
+| `data_json` | NVARCHAR(MAX) NULL | e.g., {"entity_type": "booking", "entity_id": 1234} |
+| `is_read` | BIT NOT NULL DEFAULT 0 | |
+| `read_at` | DATETIME2 NULL | |
+| `created_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `support_alerts`
+
+Internal alerts visible only to the support and admin team. Not shown to customers or nurses. Automatically generated by platform rules (low review ratings, EVV no-shows, payment anomalies) or manually by admin. Each alert has an owner and a resolution trail.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `alert_type` | NVARCHAR(50) NOT NULL | `low_rating_review` / `nurse_no_show` / `payment_anomaly` / `verification_step_expired` / `evv_location_mismatch` / `fraud_signal` |
+| `severity` | NVARCHAR(20) NOT NULL | `info` / `warning` / `critical` |
+| `entity_type` | NVARCHAR(50) NOT NULL | e.g., `review`, `booking`, `payment_transaction`, `verification_step` |
+| `entity_id` | BIGINT NOT NULL | |
+| `description` | NVARCHAR(500) NOT NULL | Human-readable summary |
+| `status` | NVARCHAR(20) NOT NULL DEFAULT 'open' | `open` / `acknowledged` / `resolved` / `dismissed` |
+| `assigned_to_admin_id` | BIGINT FK → users NULL | NULL = unassigned |
+| `resolved_at` | DATETIME2 NULL | |
+| `resolved_by_admin_id` | BIGINT FK → users NULL | |
+| `resolution_notes` | NVARCHAR(500) NULL | |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+### Domain 11 — Audit & Logging
+
+---
+
+#### `audit_logs`
+
+Immutable, append-only record of all state-changing operations on sensitive entities. Every insert, update, or status change on bookings, payments, refunds, verifications, reviews, and user accounts produces a row here. This table must never be updated or deleted — archive to cold storage after a retention period.
+
+`changed_fields_json` stores just the names of fields that changed, enabling fast filtering ("show me all booking status changes") without parsing full old/new value diffs.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `entity_type` | NVARCHAR(100) NOT NULL | Table name: `bookings`, `payment_transactions`, `refunds`, `nurse_verifications`, `verification_steps`, `reviews`, `users`, `nurse_profiles` |
+| `entity_id` | BIGINT NOT NULL | PK of the affected row |
+| `action` | NVARCHAR(20) NOT NULL | `created` / `updated` / `status_changed` / `deleted` |
+| `old_values_json` | NVARCHAR(MAX) NULL | Full row snapshot before change (NULL for creates) |
+| `new_values_json` | NVARCHAR(MAX) NULL | Full row snapshot after change (NULL for deletes) |
+| `changed_fields_json` | NVARCHAR(MAX) NULL | JSON array of field names that changed |
+| `performed_by_user_id` | BIGINT FK → users NULL | NULL for system/background jobs |
+| `performed_by_role` | NVARCHAR(50) NULL | Captured at action time |
+| `ip_address` | NVARCHAR(45) NULL | |
+| `user_agent` | NVARCHAR(500) NULL | |
+| `request_id` | NVARCHAR(100) NULL | Correlation ID from API request for distributed tracing |
+| `created_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `system_events`
+
+Higher-volume behavioral event log for analytics, funnel analysis, and future fraud detection feature engineering. Distinct from `audit_logs` — audit is for compliance and accountability; system_events is for product analytics and monitoring. May be partitioned by month or archived to a data warehouse.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `event_type` | NVARCHAR(100) NOT NULL | e.g., `nurse_search_performed`, `nurse_profile_viewed`, `booking_request_submitted`, `payment_initiated`, `verification_step_started` |
+| `user_id` | BIGINT FK → users NULL | NULL for anonymous or system events |
+| `session_id` | NVARCHAR(100) NULL | App session identifier |
+| `payload_json` | NVARCHAR(MAX) NULL | Event-specific properties (search filters, variant viewed, etc.) |
+| `source` | NVARCHAR(30) NOT NULL | `api` / `background_job` / `admin_panel` / `webhook` |
+| `ip_address` | NVARCHAR(45) NULL | |
+| `created_at` | DATETIME2 NOT NULL | |
+
+---
+
+### Domain 12 — Platform Configuration
+
+---
+
+#### `platform_configs`
+
+Key-value store for runtime-tunable business parameters. Changing a parameter (e.g., raising the platform fee, adjusting the nurse response deadline) does not require a deployment — admin edits a row and the application picks it up. Values are stored as strings; the `data_type` field tells the application how to parse them.
+
+Representative keys and their purpose:
+
+| Key | Description |
+|---|---|
+| `platform_fee_rate` | Decimal — e.g., `0.1500` (15%). Used for new bookings only. |
+| `booking_payment_deadline_minutes` | Integer — how long the customer has to pay after nurse accepts. Default 30. |
+| `nurse_response_deadline_hours` | Integer — how long before a booking request auto-expires. |
+| `nurse_payout_interval_days` | Integer — how many days after period_end before a batch is created. |
+| `default_refund_percentage` | Decimal — default % refunded when admin approves. Default 100. |
+| `min_rating_for_support_alert` | Integer — reviews with rating ≤ this value trigger a support_alert. Default 2. |
+| `evv_location_tolerance_meters` | Integer — GPS match tolerance for check-in address verification. |
+| `review_requires_admin_approval` | Boolean — whether all reviews need moderation before publish. |
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `key` | NVARCHAR(100) UNIQUE NOT NULL | |
+| `value` | NVARCHAR(500) NOT NULL | |
+| `data_type` | NVARCHAR(20) NOT NULL | `integer` / `decimal` / `boolean` / `string` / `json` |
+| `description` | NVARCHAR(500) NULL | |
+| `updated_by_admin_id` | BIGINT FK → users NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+| `created_at` | DATETIME2 NOT NULL | |
+
+---
+
+### Domain 13 — Future Extensions (modeled now, inactive at launch)
+
+These tables are defined now to avoid a painful migration when the features ship. They carry no data at launch but the FK relationships are already established so the rest of the schema doesn't need to change.
+
+---
+
+#### `organizations`
+
+Nursing companies that may register on the platform and add their employed nurses. Each nurse remains individually verified and responsible. The organization acts as a sponsor/guarantor for its nurses and may have a separate dashboard.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `name` | NVARCHAR(300) NOT NULL | |
+| `type` | NVARCHAR(30) NOT NULL | `nursing_company` / `staffing_agency` |
+| `moh_license_number` | NVARCHAR(100) NULL | MoH establishment permit (پروانه تأسیس) |
+| `admin_user_id` | BIGINT FK → users NOT NULL | Organization's admin account |
+| `is_verified` | BIT NOT NULL DEFAULT 0 | Platform-verified |
+| `verified_at` | DATETIME2 NULL | |
+| `is_active` | BIT NOT NULL DEFAULT 1 | |
+| `created_at` | DATETIME2 NOT NULL | |
+| `updated_at` | DATETIME2 NOT NULL | |
+
+---
+
+#### `organization_nurses`
+
+Membership link between a nurse and an organization. A nurse can belong to at most one active organization at a time (enforced by checking `left_at IS NULL`).
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `organization_id` | BIGINT FK → organizations NOT NULL | |
+| `nurse_id` | BIGINT FK → nurse_profiles NOT NULL | |
+| `joined_at` | DATETIME2 NOT NULL | |
+| `left_at` | DATETIME2 NULL | NULL = current member |
+| `status` | NVARCHAR(20) NOT NULL | `active` / `suspended` / `left` |
+
+---
+
+#### `fraud_flags`
+
+Signals from a future fraud detection service. Modeled now so the schema is ready to receive data when the detection layer is built, requiring no migration. The `confidence_score` field anticipates an ML model output.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `entity_type` | NVARCHAR(50) NOT NULL | `user` / `payment_transaction` / `booking` |
+| `entity_id` | BIGINT NOT NULL | |
+| `flag_type` | NVARCHAR(100) NOT NULL | e.g., `identity_mismatch`, `unusual_payment_velocity`, `address_anomaly`, `kyc_response_inconsistency` |
+| `severity` | NVARCHAR(20) NOT NULL | `low` / `medium` / `high` |
+| `confidence_score` | DECIMAL(5,4) NULL | 0.0000–1.0000 from detection model |
+| `details_json` | NVARCHAR(MAX) NULL | Evidence from the detection model |
+| `status` | NVARCHAR(30) NOT NULL DEFAULT 'open' | `open` / `investigating` / `confirmed_fraud` / `false_positive` / `resolved` |
+| `assigned_to_admin_id` | BIGINT FK → users NULL | |
+| `created_at` | DATETIME2 NOT NULL | |
+| `resolved_at` | DATETIME2 NULL | |
+
+---
+
+#### `recurring_booking_schedules`
+
+Future feature: allows families to establish a repeating care pattern (e.g., every Monday and Thursday morning with the same nurse). At launch, all bookings are one-off. The `rrule` field uses the RFC 5545 recurrence rule format, which is widely supported by scheduling libraries.
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | BIGINT PK IDENTITY | |
+| `customer_id` | BIGINT FK → customer_profiles NOT NULL | |
+| `nurse_id` | BIGINT FK → nurse_profiles NOT NULL | |
+| `variant_id` | BIGINT FK → nurse_service_variants NOT NULL | |
+| `patient_id` | BIGINT FK → patients NOT NULL | |
+| `customer_address_id` | BIGINT FK → customer_addresses NOT NULL | |
+| `rrule` | NVARCHAR(500) NOT NULL | RFC 5545 recurrence rule, e.g., `FREQ=WEEKLY;BYDAY=MO,TH` |
+| `scheduled_time_start` | TIME NOT NULL | |
+| `scheduled_time_end` | TIME NOT NULL | |
+| `effective_from` | DATE NOT NULL | |
+| `effective_until` | DATE NULL | NULL = indefinite |
+| `is_active` | BIT NOT NULL DEFAULT 1 | |
+| `created_at` | DATETIME2 NOT NULL | |
+
+---
+
+## Relationship Summary
+
+| Relationship | Type | Notes |
+|---|---|---|
+| `users` → `nurse_profiles` | 1:1 | role = nurse |
+| `users` → `customer_profiles` | 1:1 | role = customer |
+| `customer_profiles` → `patients` | 1:N | One family, many patients |
+| `customer_profiles` → `customer_addresses` | 1:N | |
+| `nurse_profiles` → `nurse_bank_accounts` | 1:N | One primary at a time |
+| `nurse_profiles` → `nurse_service_variants` | 1:N | Each variant is one bookable offering |
+| `nurse_service_variants` → `nurse_service_variant_options` | 1:N | Defines the option combination |
+| `service_option_groups` → `service_option_values` | 1:N | |
+| `nurse_profiles` → `nurse_service_areas` | 1:N | Many city/district pairs |
+| `nurse_profiles` → `nurse_verifications` | 1:1 | |
+| `nurse_verifications` → `verification_steps` | 1:N | One per step type |
+| `verification_steps` → `verification_documents` | 1:N | |
+| `booking_requests` → `bookings` | 1:1 | Created on nurse accept + payment |
+| `bookings` → `booking_care_instructions` | 1:1 | |
+| `bookings` → `visit_verifications` | 1:1 | EVV record |
+| `bookings` → `payment_transactions` | 1:N | Multiple attempts allowed |
+| `payment_transactions` → `refunds` | 1:1 | One refund per transaction |
+| `payment_transactions` → `installment_plans` | 1:1 | Only if is_installment = true |
+| `installment_plans` → `installment_entries` | 1:N | One per installment |
+| `nurse_payout_batches` → `nurse_payouts` | 1:N | One per nurse per batch |
+| `nurse_payouts` → `nurse_payout_booking_links` | 1:N | Detailed booking breakdown |
+| `nurse_payout_booking_links` → `bookings` | N:1 | Each booking in exactly one payout |
+| `bookings` → `reviews` | 1:1 | One review per booking |
+| `reviews` → `review_tag_links` | 1:N | |
+| `patients` → `patient_care_records` | 1:N | Grows with every visit |
+| `tickets` → `ticket_participants` | 1:N | |
+| `tickets` → `ticket_messages` | 1:N | |
+| `tickets` ↔ `refunds` | 1:1 (optional) | Refund conversation |
+| Sensitive entities → `audit_logs` | *:N | Append-only change log |
+
+---
+
+## Key Design Decisions
+
+**Why `booking_requests` and `bookings` are separate tables**
+A booking request may be rejected, expire, or have its payment deadline lapse without a booking ever being created. Merging these would require many nullable fields and complex status logic. Keeping them separate makes each table's invariants clear: a `bookings` row always has a successful payment.
+
+**Why `variant_snapshot_json` exists on `bookings`**
+If a nurse later edits or deletes a variant, historical bookings must still display what the customer paid for. The FK to `nurse_service_variants` is kept for joins but `variant_snapshot_json` is the authoritative record for display and dispute.
+
+**Why monetary amounts are stored as BIGINT (IRR)**
+Rials are the smallest unit; there are no decimal subdivisions in practice. Storing as BIGINT eliminates floating-point precision issues. All division (for fee calculation) is done in application code with explicit rounding rules.
+
+**Why `platform_fee_rate` is stored per booking**
+The platform's fee schedule will change over time. Deriving the split from `platform_configs` would corrupt historical reporting. Every booking stores the rate that was in effect at the moment of confirmation.
+
+**Why the verification pipeline is data-driven**
+`verification_step_types` rows define what steps exist and whether they're automated. Adding a new regulatory requirement (e.g., professional liability insurance in year 2) requires one INSERT, not a schema migration and code deploy.
+
+**Why there is no direct nurse ↔ customer messaging**
+Platform safety design: all communication is ticket-based and admin-readable. This protects vulnerable patients, provides dispute evidence, and prevents disintermediation. Post-booking coordination (nurse asking about the patient's room location, customer asking about arrival time) happens through a ticket of type `booking_coordination`.
+
+**Why `patient_care_records` are nurse-authored and patient-scoped**
+Clinical notes build a longitudinal record for the patient, not the booking. When a different nurse takes over care, they read the history before accepting the booking request, making care continuity possible without the family having to repeat everything.
+
+
+# Advices 
+Several things stand out after sitting with the full model:
+
+1. The nurse search query will be expensive from day one
+
+Finding nurses requires joining nurse_profiles (verified + accepting) → nurse_service_variants (category + price range) → nurse_service_variant_options → nurse_service_areas (city/district). That's already 4 joins before any sorting by rating or availability. At even modest scale this becomes slow.
+
+Advice: build a denormalized nurse_search_index table that is updated on writes (when a nurse edits a variant, changes their area, or gets a new review). This table stores one row per variant with all search-relevant fields flat. Read path hits one table; write path maintains it. Much cheaper than adding Elasticsearch to the stack at your current stage.
+
+2. The two-stage clinical disclosure is implicit — make it explicit
+
+Right now booking_requests.customer_notes (1000 chars, unencrypted) is what the nurse sees when deciding to accept. The full booking_care_instructions (encrypted, medications, conditions, etc.) only exists after the booking is confirmed. This boundary is correct and security-smart, but it's nowhere stated in the model.
+
+If you don't document this explicitly in the API contract, a developer will one day accidentally expose the full clinical record to a nurse at the request stage — before any commitment. Write this rule into the model comments and enforce it at the application layer, not just by convention.
+
+3. Dispute window vs payout timing can overlap
+
+A booking can be disputed after the weekly payout batch already ran and the nurse was paid. The current model has no clawback mechanism — nurse_payouts has no way to record that money needs to come back. Consider adding clawback_amount and clawback_status to nurse_payouts, or simply enforce a policy that payout only runs for bookings where the dispute window has closed (e.g., 72 hours post-completion). Either way, document the rule.
+
+4. The ticket system has an urgent on-site gap
+
+The ticket system is async. If a nurse arrives and the patient doesn't answer the door, or there's a medical emergency, there is no real-time channel in the model. The only outlet is the emergency contact phone number buried in booking_care_instructions. This is probably acceptable for v1 — but be intentional about it. The operational playbook for nurses should explicitly say "in an emergency, call the emergency contact number from the app, then open a ticket." Otherwise nurses will try to find the family's phone number by other means, which breaks the platform's communication control.
+
+5. Three tables will eat your disk quietly
+
+audit_logs, system_events, and notifications grow without any natural bound. Before you hit production, decide:
+
+audit_logs — partition by month, archive after 2–3 years to cold storage
+system_events — same, or pipe directly to a data warehouse and don't keep them in SQL Server at all
+notifications — add a job that hard-deletes read notifications older than 90 days
+If you don't plan this before launch, you'll be doing emergency archiving under pressure later.
+
+6. is_verified on nurse_profiles is a derived value — protect it
+
+This flag is true when all required verification steps pass. But it lives as a column that could theoretically be set independently. If a bug or a rogue admin sets is_verified = 1 without the steps passing, an unvetted nurse becomes bookable. Enforce this transactionally: the only code path that sets is_verified = true should be the one that also checks all required verification_steps.status = 'passed', inside the same transaction. Never expose a direct update API for this field.
\ No newline at end of file
diff --git a/product/todo.md b/product/todo.md
index bab1b46..7baa375 100644
--- a/product/todo.md
+++ b/product/todo.md
@@ -1,15 +1,12 @@
 
-# fix issue with locale detection 
 # cleanup layout
 # add rules and conventions and structure again for both projects 
 
-# inspect the authorization flow and check both for client and server checking in the client project 
+ 
+
 
-# make sure there is a proper central service for all server and client ( one for server and one for client) fetchs which handles headers based on the browser cookies or cookies api in next.js 
 
-# ensure there is react query configured  for server state management in the client project
 
-# ensure proper error handling and toast for api errors in the client project
 
 
 
diff --git a/product/whatsInYourMind.txt b/product/whatsInYourMind.txt
index b8b1826..a9599ff 100644
--- a/product/whatsInYourMind.txt
+++ b/product/whatsInYourMind.txt
@@ -2,4 +2,7 @@ ticket page,
 backoffice,
 verify the registration code
 rate limit
-workbox for cache ( maybe )
\ No newline at end of file
+workbox for cache ( maybe )
+
+اگر پرداخت قسطی داشته باشیم و طرف اون وسط بخواد کنسل کنه چی میشه ؟ 
+bnpl اگر باشه خب پول پرستار رو کی میده ؟ 
\ No newline at end of file
diff --git a/product/فلوی-احراز-هویت-پرستار.html b/product/فلوی-احراز-هویت-پرستار.html
new file mode 100644
index 0000000..cd4bff1
--- /dev/null
+++ b/product/فلوی-احراز-هویت-پرستار.html
@@ -0,0 +1,420 @@
+<!DOCTYPE html>
+<html lang="fa" dir="rtl">
+<head>
+<meta charset="UTF-8">
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+<title>فلوی احراز هویت و صلاحیت پرستار — راهنمای پیاده‌سازی</title>
+<link rel="preconnect" href="https://fonts.googleapis.com">
+<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
+<link href="https://fonts.googleapis.com/css2?family=Vazirmatn:wght@400;500;700;800&display=swap" rel="stylesheet">
+<style>
+  :root {
+    --ink: #1f2933; --muted: #52606d; --accent: #0d6e6e; --accent-dark: #0a5252;
+    --line: #d9e2e6; --bg: #f7f9fa; --card: #ffffff;
+    --warn-bg: #fff7e6; --warn-border: #f0b429;
+    --note-bg: #eef6f6;
+    --auto: #0a7d3c; --auto-bg: #e6f4ea;
+    --consent: #b45309; --consent-bg: #fdf0dd;
+    --manual: #475569; --manual-bg: #eef1f4;
+    --bad: #b42318; --bad-bg: #fdeceb;
+  }
+  * { box-sizing: border-box; }
+  html { scroll-behavior: smooth; }
+  body {
+    font-family: 'Vazirmatn','Tahoma','IRANSans','Segoe UI',sans-serif;
+    direction: rtl; text-align: right; line-height: 2; color: var(--ink);
+    background: var(--bg); margin: 0; padding: 0; font-size: 16.5px; -webkit-font-smoothing: antialiased;
+  }
+  .wrap { max-width: 1000px; margin: 0 auto; padding: 44px 24px 80px; }
+  .doc { background: var(--card); border: 1px solid var(--line); border-radius: 16px;
+    padding: 42px clamp(20px,5vw,52px); box-shadow: 0 4px 24px rgba(15,40,50,.05); }
+  h1 { font-size: 1.95rem; font-weight: 800; line-height: 1.6; color: var(--accent-dark);
+    margin: 0 0 6px; border-bottom: 3px solid var(--accent); padding-bottom: 16px; }
+  h2 { font-size: 1.5rem; font-weight: 800; color: var(--accent-dark); margin: 50px 0 12px;
+    padding: 10px 16px; background: linear-gradient(90deg,var(--note-bg),transparent);
+    border-right: 5px solid var(--accent); border-radius: 6px; }
+  h3 { font-size: 1.2rem; font-weight: 700; color: var(--accent-dark); margin: 30px 0 8px; }
+  h4 { font-size: 1.02rem; font-weight: 700; color: var(--muted); margin: 20px 0 6px; }
+  p { margin: 12px 0; }
+  a { color: var(--accent); text-decoration: none; border-bottom: 1px dotted var(--accent); word-break: break-all; }
+  a:hover { color: var(--accent-dark); border-bottom-style: solid; }
+  strong { font-weight: 700; color: #102a30; }
+  ul, ol { padding-right: 24px; margin: 12px 0; }
+  li { margin: 6px 0; }
+  hr { border: none; border-top: 1px solid var(--line); margin: 38px 0; }
+  code, .ltr { direction: ltr; unicode-bidi: embed; font-family: 'Consolas','Menlo',monospace;
+    background: #eef2f3; padding: 1px 6px; border-radius: 5px; font-size: .86em; color: #0a5252; }
+
+  blockquote { margin: 18px 0; padding: 14px 20px; background: var(--note-bg);
+    border-right: 5px solid var(--accent); border-radius: 8px; color: var(--muted); }
+  blockquote.warn { background: var(--warn-bg); border-right-color: var(--warn-border); color: #7a5b00; }
+  blockquote.bad { background: var(--bad-bg); border-right-color: var(--bad); color: #7a1d16; }
+  blockquote p { margin: 6px 0; }
+
+  .meta { color: var(--muted); font-size: .95rem; margin: 4px 0 20px; }
+  .sourcing { font-size: .9rem; background: #f0f4f5; border: 1px dashed var(--line);
+    border-radius: 10px; padding: 14px 20px; color: var(--muted); }
+
+  /* badges */
+  .badge { display: inline-block; border-radius: 20px; padding: 1px 11px; font-size: .8em; font-weight: 700; white-space: nowrap; }
+  .b-auto { background: var(--auto-bg); color: var(--auto); }
+  .b-consent { background: var(--consent-bg); color: var(--consent); }
+  .b-manual { background: var(--manual-bg); color: var(--manual); }
+  .b-bad { background: var(--bad-bg); color: var(--bad); }
+
+  /* tables */
+  .tablewrap { overflow-x: auto; margin: 20px 0; border-radius: 10px; border: 1px solid var(--line); }
+  table { border-collapse: collapse; width: 100%; min-width: 680px; font-size: .9rem; background: #fff; }
+  th, td { border: 1px solid var(--line); padding: 9px 12px; text-align: right; vertical-align: top; line-height: 1.7; }
+  thead th { background: var(--accent); color: #fff; font-weight: 700; }
+  tbody tr:nth-child(even) { background: #f6fafa; }
+  tbody tr:hover { background: #eef6f6; }
+  td:first-child, th:first-child { font-weight: 600; }
+
+  /* TOC */
+  nav.toc { background: #f0f6f6; border: 1px solid var(--line); border-radius: 12px; padding: 16px 26px; margin: 24px 0 8px; }
+  nav.toc h2 { margin: 0 0 8px; font-size: 1.12rem; background: none; border: none; padding: 0; }
+  nav.toc ol { margin: 0; } nav.toc a { border-bottom: none; }
+
+  /* stepper */
+  .stepper { margin: 24px 0; border-right: 3px solid var(--line); padding-right: 4px; }
+  .step { position: relative; padding: 0 34px 22px 0; }
+  .step::before { content: attr(data-n); position: absolute; right: -19px; top: 0;
+    width: 34px; height: 34px; border-radius: 50%; background: var(--accent); color: #fff;
+    font-weight: 800; display: flex; align-items: center; justify-content: center; font-size: .95rem;
+    box-shadow: 0 0 0 4px var(--bg); }
+  .step .st-title { font-weight: 800; color: var(--accent-dark); font-size: 1.08rem; margin-bottom: 2px; }
+  .step .st-sub { color: var(--muted); font-size: .9rem; }
+
+  /* step cards (detailed) */
+  .card { border: 1px solid var(--line); border-radius: 12px; margin: 16px 0; overflow: hidden; }
+  .card > .head { background: #f3f8f8; padding: 12px 18px; display: flex; align-items: center;
+    gap: 10px; flex-wrap: wrap; border-bottom: 1px solid var(--line); }
+  .card > .head .num { background: var(--accent); color: #fff; width: 28px; height: 28px; border-radius: 50%;
+    display: inline-flex; align-items: center; justify-content: center; font-weight: 800; font-size: .85rem; flex: none; }
+  .card > .head .ttl { font-weight: 800; color: var(--accent-dark); font-size: 1.05rem; }
+  .card > .body { padding: 6px 18px 14px; }
+  .kv { display: grid; grid-template-columns: 140px 1fr; gap: 4px 14px; margin: 10px 0; }
+  .kv dt { font-weight: 700; color: var(--muted); }
+  .kv dd { margin: 0; }
+  @media (max-width: 560px) { .kv { grid-template-columns: 1fr; } .kv dt { margin-top: 8px; } }
+
+  .legend { display: flex; gap: 16px; flex-wrap: wrap; margin: 14px 0 4px; font-size: .9rem; }
+  .legend span { display: inline-flex; align-items: center; gap: 6px; }
+
+  @media print {
+    body { background: #fff; font-size: 12px; }
+    .doc { border: none; box-shadow: none; padding: 0; }
+    h2 { background: none; } a { color: #000; border: none; }
+  }
+</style>
+</head>
+<body>
+<div class="wrap">
+<article class="doc">
+
+<h1>فلوی احراز هویت و صلاحیت پرستار<br>راهنمای پیاده‌سازی برای ثبت‌نام در پلتفرم</h1>
+
+<p class="meta"><strong>سناریو:</strong> پرستار برای ثبت‌نام مراجعه می‌کند و این داده‌ها را می‌دهد: شمارهٔ موبایل، کد ملی، شمارهٔ نظام (پرستاری)، و در صورت نیاز چند داده دیگر. هدف: <strong>اثبات اینکه او واقعاً همان کسی است که می‌گوید</strong>، <strong>راستی‌آزماییِ صلاحیت حرفه‌ای او</strong>، و <strong>استخراج خودکارِ حداکثر اطلاعات معتبر</strong> از منابع آنلاین (API پولی شخص ثالث بلامانع است).</p>
+
+<blockquote class="warn">
+<p>⚠️ <strong>یک تصحیح مهم از همان ابتدا:</strong> در ایران <strong>پرستاران</strong> عضو <strong>سازمان نظام پرستاری</strong> هستند و «<strong>شمارهٔ نظام پرستاری</strong>» دارند؛ «<strong>کد نظام پزشکی</strong>» مخصوص <strong>پزشکان</strong> (سازمان نظام پزشکی) است. این دو سامانهٔ کاملاً جدا هستند. در این سند هر دو پوشش داده شده‌اند، اما برای پرستار، منبع درست <strong>نظام پرستاری</strong> است (و جالب اینکه برخلاف نظام پزشکی، استعلام نظام پرستاری <em>API ندارد</em> — به بخش‌های ۴ و ۷ نگاه کنید).</p>
+</blockquote>
+
+<nav class="toc">
+<h2>فهرست</h2>
+<ol>
+  <li><a href="#principles">اصول طراحی (پیش از کدنویسی بخوانید)</a></li>
+  <li><a href="#inputs">داده‌های ورودی که از پرستار می‌گیریم</a></li>
+  <li><a href="#overview">نقشهٔ کلی فلو (نمای پرنده)</a></li>
+  <li><a href="#steps">فلوی مرحله‌به‌مرحله (با ورودی/خروجی/منطق هر گام)</a></li>
+  <li><a href="#crosscheck">ماتریس تطبیق متقابل (قلبِ ضدِ تقلب)</a></li>
+  <li><a href="#fieldmap">جدول «داده موردنیاز ← منبع/سرویس»</a></li>
+  <li><a href="#scoring">جمع‌بندیِ تصمیم و امتیاز اعتماد</a></li>
+  <li><a href="#legal">نکات حقوقی، حریم خصوصی و دسترسی</a></li>
+  <li><a href="#sources">منابع</a></li>
+</ol>
+</nav>
+
+<hr>
+
+<h2 id="principles">۱. اصول طراحی (پیش از کدنویسی بخوانید)</h2>
+<ol>
+  <li><strong>تفاوت «اظهار» و «دادهٔ رسمی».</strong> هر چیزی که پرستار <em>تایپ می‌کند</em> (نام، سابقه، شماره نظام) صرفاً ادعاست. ارزش واقعی وقتی ساخته می‌شود که آن ادعا را با یک <strong>منبع رسمی مستقل</strong> (ثبت احوال، نظام پرستاری، تأمین اجتماعی) تطبیق دهید.</li>
+  <li><strong>سه نوع منبع از نظر دسترسی:</strong>
+    <div class="legend">
+      <span><span class="badge b-auto">خودکار</span> با API و فقط ورودی‌هایی که پرستار داده، بی‌نیاز از اقدام او</span>
+      <span><span class="badge b-consent">رضایتی / OTP</span> نیازمند ورود یا تأیید پیامکیِ خودِ فرد</span>
+      <span><span class="badge b-manual">دستی / آپلود</span> فرم وب بدون API، یا آپلود مدرک، یا استعلام سازمانی</span>
+    </div>
+  </li>
+  <li><strong>هویت را «گره بزنید»، نه اینکه فقط چک کنید.</strong> سخت‌ترین تقلب این حوزه، استفاده از یک <strong>شمارهٔ نظامِ واقعی ولی دزدیده‌شده</strong> است (سناریوی «پرستار قلابی»). پادزهر: نام و <strong>عکسِ</strong> روی رکورد نظام پرستاری را با هویت ثبت احوال <em>و</em> سلفیِ زندهٔ همان لحظه تطبیق دهید (بخش ۵).</li>
+  <li><strong>ارزان به گران.</strong> اول استعلام‌های ارزان و قطعی (شاهکار) را اجرا کنید؛ اگر رد شد، اصلاً سراغ مراحل گران (احراز ویدیویی) نروید. این هم هزینه را پایین می‌آورد هم تجربهٔ کاربر را.</li>
+  <li><strong>همهٔ این APIها فقط B2B هستند.</strong> برای استفاده باید شرکت ثبت‌شده، احراز کسب‌وکار و <code>client credential</code> داشته باشید؛ و طبق رگولاتوری باید از کاربر <strong>رضایت صریح</strong> برای استعلام و نگه‌داری داده بگیرید.</li>
+  <li><strong>«سال سابقه» را نمی‌توان بی‌رضایت و خودکار کشید.</strong> هیچ API عمومی‌ای با کد ملی، سال‌های تجربهٔ بالینی را برنمی‌گرداند؛ این داده یا با <em>رضایت/OTP خود فرد</em> از تأمین اجتماعی می‌آید یا با <em>آپلود گواهی سابقه</em> (بخش ۴، گام ۶).</li>
+</ol>
+
+<hr>
+
+<h2 id="inputs">۲. داده‌های ورودی که از پرستار می‌گیریم</h2>
+<p>برای اجرای کاملِ فلو، در فرم ثبت‌نام این فیلدها را جمع کنید (بعضی برای استعلام‌های رسمی <strong>الزامی</strong>اند):</p>
+<div class="tablewrap">
+<table>
+<thead><tr><th>فیلد</th><th>چرا لازم است</th><th>وضعیت</th></tr></thead>
+<tbody>
+<tr><td>شمارهٔ موبایل</td><td>تطبیق با کد ملی در شاهکار؛ ارسال OTP</td><td>الزامی</td></tr>
+<tr><td>کد ملی</td><td>کلید همهٔ استعلام‌های هویتی و حرفه‌ای</td><td>الزامی</td></tr>
+<tr><td><strong>تاریخ تولد</strong></td><td><strong>برای استعلام هویت ثبت احوال و احراز ویدیویی الزامی است</strong> (بدون آن دادهٔ کامل ثبت احوال برنمی‌گردد)</td><td>الزامی</td></tr>
+<tr><td>شمارهٔ نظام پرستاری</td><td>راستی‌آزمایی صلاحیت در <code>estelam.ino1.ir</code></td><td>الزامی</td></tr>
+<tr><td>سریال پشت کارت ملی</td><td>ورودیِ احراز هویت ویدیوییِ (eKYC)</td><td>برای eKYC</td></tr>
+<tr><td>ویدیوی سلفی (≈۵ ثانیه)</td><td>زنده‌سنجی + تطبیق چهره با عکس ثبت احوال</td><td>برای eKYC</td></tr>
+<tr><td>کد پستی محل سکونت</td><td>تنها راه گرفتن آدرس رسمی (مسیر کد ملی→آدرس وجود ندارد)</td><td>اختیاری</td></tr>
+<tr><td>شمارهٔ کارت یا شبای بانکی</td><td>تطبیق مالکیت حساب واریز با کد ملی</td><td>هنگام تسویه</td></tr>
+<tr><td>گواهی سابقهٔ کار / مدرک تحصیلی (آپلود)</td><td>اثبات سابقه و کارشناسی پرستاری (که API ندارند)</td><td>آپلود</td></tr>
+</tbody>
+</table>
+</div>
+
+<hr>
+
+<h2 id="overview">۳. نقشهٔ کلی فلو (نمای پرنده)</h2>
+<div class="stepper">
+  <div class="step" data-n="۱"><div class="st-title">تطبیق موبایل ↔ کد ملی <span class="badge b-auto">خودکار</span></div><div class="st-sub">شاهکار — ارزان‌ترین و اولین دروازه. اگر رد شد، همین‌جا توقف.</div></div>
+  <div class="step" data-n="۲"><div class="st-title">تأیید مالکیت موبایل با OTP <span class="badge b-consent">OTP</span></div><div class="st-sub">پیامک کد یک‌بارمصرف؛ هم رضایت می‌گیرد هم شماره را قفل می‌کند.</div></div>
+  <div class="step" data-n="۳"><div class="st-title">استعلام هویت ثبت احوال <span class="badge b-auto">خودکار</span></div><div class="st-sub">کد ملی + تاریخ تولد → نام، نام پدر، شناسنامه، جنسیت، وضعیت حیات. پر کردن خودکار پروفایل.</div></div>
+  <div class="step" data-n="۴"><div class="st-title">احراز هویت ویدیویی (تطبیق چهره) <span class="badge b-consent">رضایتی</span></div><div class="st-sub">سلفی زنده ↔ عکس ثبت احوال. اثبات «حضور فیزیکیِ صاحب کد ملی».</div></div>
+  <div class="step" data-n="۵"><div class="st-title">راستی‌آزمایی صلاحیت پرستاری <span class="badge b-manual">دستی/Scrape</span></div><div class="st-sub"><code>estelam.ino1.ir</code> → نام، مقطع، رشته، شهر، <strong>عکس</strong>. تطبیق متقابل با گام ۳ و ۴.</div></div>
+  <div class="step" data-n="۶"><div class="st-title">سابقهٔ کار + مدرک تحصیلی <span class="badge b-consent">رضایتی</span> <span class="badge b-manual">آپلود</span></div><div class="st-sub">تأمین اجتماعی با OTP خود فرد، یا آپلود گواهی سابقه و دانشنامه.</div></div>
+  <div class="step" data-n="۷"><div class="st-title">پروانهٔ صلاحیت حرفه‌ای + عدم سوء پیشینه <span class="badge b-consent">رضایتی</span></div><div class="st-sub">پروانهٔ وزارت بهداشت (شاملِ غربالگری سوء‌پیشینه است) + آپلود گواهی عدم سوء پیشینه.</div></div>
+  <div class="step" data-n="۸"><div class="st-title">تطبیق حساب بانکیِ واریز <span class="badge b-auto">خودکار</span></div><div class="st-sub">شبا/کارت ↔ کد ملی. هنگام تنظیم تسویه‌حساب.</div></div>
+  <div class="step" data-n="۹"><div class="st-title">امتیاز اعتماد و تصمیم نهایی <span class="badge b-manual">منطق داخلی</span></div><div class="st-sub">جمع‌بندی نتایج، رفع مغایرت، تأیید/رد/بازبینی انسانی.</div></div>
+</div>
+
+<hr>
+
+<h2 id="steps">۴. فلوی مرحله‌به‌مرحله</h2>
+<p class="meta">برای هر گام: <strong>ورودی</strong> (چه می‌فرستیم)، <strong>منبع/API</strong>، <strong>خروجی</strong> (چه فیلدهایی برمی‌گردد)، و <strong>منطق تطبیق و تصمیم</strong>.</p>
+
+<!-- STEP 1 -->
+<div class="card">
+  <div class="head"><span class="num">۱</span><span class="ttl">تطبیق موبایل ↔ کد ملی (شاهکار)</span><span class="badge b-auto">خودکار</span></div>
+  <div class="body">
+    <dl class="kv">
+      <dt>ورودی</dt><dd><code>mobileNumber</code> + <code>nationalId</code> (همان دو فیلدی که پرستار داده)</dd>
+      <dt>منبع / API</dt><dd>سرویس <strong>شاهکار</strong> از طریق یکی از resellerها: Finnotech، U-ID/یوآیدی، api.ir، Shabanic، Zohal و … (همگی روی همان backend دولتی رگولاتوری مخابرات).</dd>
+      <dt>خروجی</dt><dd>فقط یک بولینِ <code>isMatched: true/false</code> (به‌همراه کد/پیام وضعیت). <strong>هیچ دادهٔ هویتی دیگری نمی‌دهد.</strong></dd>
+      <dt>منطق تصمیم</dt><dd>اگر <code>false</code> → یعنی سیم‌کارت به‌نام این کد ملی نیست؛ ثبت‌نام را همین‌جا متوقف یا به بازبینی دستی بفرستید. اگر <code>true</code> → ادامه. <em>(ارزان‌ترین استعلام؛ همیشه اول اجرا شود.)</em></dd>
+    </dl>
+  </div>
+</div>
+
+<!-- STEP 2 -->
+<div class="card">
+  <div class="head"><span class="num">۲</span><span class="ttl">تأیید مالکیت شماره با OTP</span><span class="badge b-consent">OTP</span></div>
+  <div class="body">
+    <dl class="kv">
+      <dt>ورودی</dt><dd>شمارهٔ موبایل (همان شمارهٔ تأییدشده در گام ۱)</dd>
+      <dt>منبع / API</dt><dd>هر سرویس پیامک (Kavenegar، ملی‌پیامک، IPPanel، …)</dd>
+      <dt>خروجی</dt><dd>تأیید اینکه کاربر همان لحظه به سیم‌کارت دسترسی دارد + ثبت <strong>رضایت</strong> قانونی برای استعلام‌ها.</dd>
+      <dt>منطق تصمیم</dt><dd>شاهکار می‌گوید «سیم به‌نام این کد ملی است»؛ OTP می‌گوید «کاربر همین حالا سیم را در دست دارد». ترکیب این دو، جعل شماره را بسیار سخت می‌کند.</dd>
+    </dl>
+  </div>
+</div>
+
+<!-- STEP 3 -->
+<div class="card">
+  <div class="head"><span class="num">۳</span><span class="ttl">استعلام هویت ثبت احوال (استخراج خودکار اطلاعات)</span><span class="badge b-auto">خودکار</span></div>
+  <div class="body">
+    <dl class="kv">
+      <dt>ورودی</dt><dd><code>nationalCode</code> + <code>birthDate</code> (تاریخ تولد الزامی است)</dd>
+      <dt>منبع / API</dt><dd><strong>استعلام هویت ثبت احوال</strong> از Shabanic یا U-ID. <span class="badge b-manual">توجه</span> «صحت‌سنجی کد ملیِ» Finnotech فقط <em>درصد تطبیق</em> می‌دهد، نه خودِ داده — برای پر کردن پروفایل از سرویس «استعلام هویت» استفاده کنید.</dd>
+      <dt>خروجی (فیلدها)</dt><dd><code>firstName</code>، <code>lastName</code>، <code>fatherName</code> (نام پدر)، <code>gender</code> (جنسیت)، <code>birthDate</code>، <code>deathStatus</code> (<strong>وضعیت حیات</strong> — زنده/فوت)، <code>idNo</code> (شماره شناسنامه)، <code>idSerial</code>/<code>idSerie</code> (سری و سریال شناسنامه). <em>شهر محل تولد به‌صورت فیلد صریح برنمی‌گردد.</em></dd>
+      <dt>منطق تصمیم</dt><dd><strong>پروفایل را خودکار پر کنید</strong> و نامِ اظهارشدهٔ پرستار را با <code>firstName/lastName</code>ِ رسمی تطبیق دهید. اگر <code>deathStatus</code> = فوت‌شده → پرچم قرمز و توقف. این گام، «نام واقعیِ گره‌خورده به کد ملی» را به دست می‌دهد که در گام ۵ به‌کار می‌آید.</dd>
+    </dl>
+  </div>
+</div>
+
+<!-- STEP 4 -->
+<div class="card">
+  <div class="head"><span class="num">۴</span><span class="ttl">احراز هویت ویدیویی و تطبیق چهره (eKYC)</span><span class="badge b-consent">رضایتی</span></div>
+  <div class="body">
+    <dl class="kv">
+      <dt>ورودی</dt><dd>ویدیوی سلفی (≈۵ ثانیه) + <code>nationalId</code> + <code>nationalIdSerial</code> (سریال پشت کارت ملی) + <code>birthDate</code> + <code>gender</code></dd>
+      <dt>منبع / API</dt><dd><strong>احراز هویت ویدیوییِ</strong> U-ID، api.ir یا VIDA/ویدا. (زنده‌سنجی ~۹۸٪، تطبیق چهره >۹۹٪ طبق اعلام ارائه‌دهنده.)</dd>
+      <dt>خروجی</dt><dd>یک enum وضعیت: <code>state</code> = <code>ACCEPTED</code>/<code>REJECTED</code> به‌همراه <code>reason</code> (مثلاً <code>FACE_NOT_MATCH_ID</code> یا تأیید). <em>خروجی عددِ درصد نیست، بلکه قبول/رد است.</em></dd>
+      <dt>منطق تصمیم</dt><dd>این گام اثبات می‌کند فردِ زندهٔ پشت دوربین <strong>همان صاحب عکسِ ثبت احوالِ آن کد ملی است</strong> — یعنی صرفاً کسی نیست که کد ملیِ دیگری را تایپ کرده. اگر <code>REJECTED</code> → بازبینی دستی یا توقف.</dd>
+    </dl>
+  </div>
+</div>
+
+<!-- STEP 5 -->
+<div class="card">
+  <div class="head"><span class="num">۵</span><span class="ttl">راستی‌آزمایی صلاحیت پرستاری (نظام پرستاری)</span><span class="badge b-manual">دستی / Scrape</span></div>
+  <div class="body">
+    <dl class="kv">
+      <dt>ورودی</dt><dd>شمارهٔ نظام پرستاری <em>یا</em> نام و نام خانوادگی (تطبیق <strong>دقیق</strong> است؛ ورودیِ کد ملی ندارد)</dd>
+      <dt>منبع</dt><dd>سامانهٔ عمومی <code>estelam.ino1.ir</code> («استعلام پرستاران کشور») — بدون لاگین، بدون کپچا. <strong>API رسمی یا واسطه‌ای ندارد</strong>؛ یا بررسی دستی است یا scrape شکنندهٔ صفحه (با CSRF token).</dd>
+      <dt>خروجی (فیلدها)</dt><dd>نام، نام خانوادگی، شمارهٔ نظام، <strong>مقطع تحصیلی</strong> (مثلاً «کارشناس»)، <strong>رشتهٔ تحصیلی</strong> (مثلاً «پرستاری»)، <strong>شهر هیئت‌مدیره</strong> (شعبه/استان)، و <strong>عکس پرسنلی</strong>.</dd>
+      <dt>چه چیزی نمی‌دهد</dt><dd><span class="badge b-bad">مهم</span> وضعیت فعال/منقضی، تاریخ ثبت/عضویت، تخصص و محل خدمت را نمی‌دهد. ⟶ یعنی <strong>«فعال بودن» و «سال سابقه» از این استعلام درنمی‌آید</strong> (برای آن‌ها به گام ۶ و ۷ بروید).</dd>
+      <dt>منطق تصمیم</dt><dd>اینجاست که <strong>تطبیق متقابل</strong> انجام می‌شود: نامِ روی رکورد نظام پرستاری باید با نامِ ثبت احوال (گام ۳) بخواند، و <strong>عکسِ</strong> این رکورد باید با چهرهٔ سلفی (گام ۴) و عکس ثبت احوال هم‌خوان باشد. این کار، شمارهٔ نظامِ «واقعی ولی دزدیده‌شده» را لو می‌دهد.</dd>
+    </dl>
+  </div>
+</div>
+
+<!-- STEP 6 -->
+<div class="card">
+  <div class="head"><span class="num">۶</span><span class="ttl">سابقهٔ کار و مدرک تحصیلی</span><span class="badge b-consent">رضایتی</span><span class="badge b-manual">آپلود</span></div>
+  <div class="body">
+    <dl class="kv">
+      <dt>سابقهٔ کار</dt><dd><strong>تأمین اجتماعی</strong> (<code>eservices.tamin.ir</code> / اپ «تأمین من»). با کد ملیِ تنها قابل استخراج <em>نیست</em>؛ نیازمند <strong>لاگین یا OTP رویِ سیم‌کارتِ خود فرد</strong> است. خروجی: روزهای بیمه، دستمزد مبنا، سوابق تلفیقی، و مدت اشتغال نزد هر کارفرما. <strong>گزینهٔ عملی:</strong> یا API استعلام بیمهٔ مبتنی‌بر رضایت (کاربر OTP می‌زند)، یا از پرستار بخواهید «خروجی سابقه/گواهی سابقهٔ کار» را خودش بگیرد و آپلود کند.</dd>
+      <dt>مدرک تحصیلی</dt><dd>مدرک پرستاری زیر نظر <strong>وزارت بهداشت</strong> است، نه وزارت علوم ⟶ سامانهٔ سجاد آن را تأیید نمی‌کند. منبع درست: <code>eg.behdasht.gov.ir</code> (سامانهٔ دانش‌آموختگان). استعلامِ تأییدیه <strong>سازمان‌محور</strong> است (شرکت شما درخواست رسمی می‌دهد، پاسخ به شما برمی‌گردد) و API عمومی ندارد. <strong>گزینهٔ عملی اولیه:</strong> آپلود دانشنامه/مدرک کارشناسی + بررسی بصری.</dd>
+      <dt>منطق تصمیم</dt><dd>«سال سابقه» و «کارشناسی پرستاری» را به‌عنوان دادهٔ <em>اظهاری-با-مدرک</em> ثبت کنید و در صورت نیاز با تأییدیهٔ رسمی ارتقا دهید. تاریخِ نبودِ این داده‌ها در APIهای ارزان را به‌عنوان محدودیت بپذیرید.</dd>
+    </dl>
+  </div>
+</div>
+
+<!-- STEP 7 -->
+<div class="card">
+  <div class="head"><span class="num">۷</span><span class="ttl">پروانهٔ صلاحیت حرفه‌ای + گواهی عدم سوء پیشینه</span><span class="badge b-consent">رضایتی</span></div>
+  <div class="body">
+    <dl class="kv">
+      <dt>پروانهٔ صلاحیت حرفه‌ای</dt><dd>مدرک وزارت بهداشت (سامانه‌های <code>Rn.behdasht.gov.ir</code> و <code>op.salamat.gov.ir</code>) که صدورش <strong>مشروط به گزینش و گواهی عدم سوء پیشینه</strong> است. صدور <strong>self-service</strong> (لاگین خود فرد با کد ملی + OTP) است و API عمومی ندارد. ⟶ معتبر بودنِ این پروانه یعنی «سوء‌پیشینه و گزینش <em>هنگام صدور</em> بررسی شده‌اند».</dd>
+      <dt>عدم سوء پیشینه</dt><dd>گواهی رسمی که <strong>فقط خودِ فرد</strong> از <code>adliran.ir</code> با رمز ثنا می‌گیرد؛ <strong>هیچ API شخص‌ثالثی برای کشیدن آن وجود ندارد.</strong> ⟶ از پرستار بخواهید گواهی را بگیرد و آپلود کند، و دوره‌ای تمدید کنید.</dd>
+      <dt>منطق تصمیم</dt><dd>چون این دو سند برای کارِ مراقبت از افراد آسیب‌پذیر حیاتی‌اند، آن‌ها را <strong>الزامی</strong> کنید (آپلود + بازبینی)، حتی اگر خودکار نیستند.</dd>
+    </dl>
+  </div>
+</div>
+
+<!-- STEP 8 -->
+<div class="card">
+  <div class="head"><span class="num">۸</span><span class="ttl">تطبیق حساب بانکیِ واریز</span><span class="badge b-auto">خودکار</span></div>
+  <div class="body">
+    <dl class="kv">
+      <dt>ورودی</dt><dd>شمارهٔ کارت یا شبا + <code>nationalCode</code> (+ تاریخ تولد)</dd>
+      <dt>منبع / API</dt><dd><strong>تطبیق شبا/کارت با کد ملی</strong> (Shabanic / U-ID). یا «کارت به شبا»ی Shabanic که <code>IBAN</code>، شماره حساب، <code>depositOwners</code> (نام صاحب حساب) و نام بانک را می‌دهد (~۵٬۰۰۰ تومان).</dd>
+      <dt>خروجی</dt><dd>وضعیت تطبیق + نام صاحب حساب + نام بانک + وضعیت حساب (فعال/مسدود).</dd>
+      <dt>منطق تصمیم</dt><dd>اطمینان از اینکه پولِ پرستار به حسابِ <strong>خودِ او</strong> واریز می‌شود (نه واسطه). معمولاً هنگام اولین تسویه اجرا می‌شود، نه لزوماً در ثبت‌نام.</dd>
+    </dl>
+  </div>
+</div>
+
+<!-- STEP 9 -->
+<div class="card">
+  <div class="head"><span class="num">۹</span><span class="ttl">امتیاز اعتماد و تصمیم نهایی</span><span class="badge b-manual">منطق داخلی</span></div>
+  <div class="body">
+    <p>نتایج همهٔ گام‌ها را در یک «کارت اعتماد» جمع کنید و بر اساس آن تأیید/رد/بازبینی انسانی را تصمیم بگیرید (بخش ۷ این سند).</p>
+  </div>
+</div>
+
+<hr>
+
+<h2 id="crosscheck">۵. ماتریس تطبیق متقابل (قلبِ ضدِ تقلب)</h2>
+<p>ارزش فلو در تک‌تک استعلام‌ها نیست، بلکه در <strong>هم‌خوانیِ آن‌ها با یکدیگر</strong> است. این جدول نشان می‌دهد کدام فیلد باید با کدام منبع بخواند تا هویت «گره» بخورد:</p>
+<div class="tablewrap">
+<table>
+<thead><tr><th>چه چیزی باید با چه چیزی بخواند</th><th>منبع‌های درگیر</th><th>اگر نخواند یعنی…</th></tr></thead>
+<tbody>
+<tr><td>موبایل ↔ کد ملی</td><td>شاهکار (گام ۱)</td><td>سیم‌کارت به‌نام شخص دیگری است / جعل شماره</td></tr>
+<tr><td>نامِ اظهارشده ↔ نامِ ثبت احوال</td><td>فرم ثبت‌نام ↔ استعلام هویت (گام ۳)</td><td>کد ملیِ متعلق به فرد دیگری وارد شده</td></tr>
+<tr><td>چهرهٔ سلفیِ زنده ↔ عکس ثبت احوال</td><td>eKYC (گام ۴)</td><td>فرد، صاحب واقعیِ کد ملی نیست (هویت دزدیده)</td></tr>
+<tr><td><strong>نام و عکسِ نظام پرستاری ↔ هویت ثبت احوال + سلفی</strong></td><td>estelam.ino1.ir (گام ۵) ↔ گام‌های ۳ و ۴</td><td><strong>شمارهٔ نظامِ واقعی ولی دزدیده‌شده</strong> — خطرناک‌ترین حالت</td></tr>
+<tr><td>رشته/مقطعِ نظام پرستاری ↔ مدرک تحصیلی آپلودی</td><td>گام ۵ ↔ گام ۶</td><td>مدرک جعلی یا ناهماهنگ</td></tr>
+<tr><td>نام صاحب حساب ↔ کد ملی</td><td>تطبیق بانکی (گام ۸)</td><td>حساب واریز متعلق به شخص دیگری است</td></tr>
+</tbody>
+</table>
+</div>
+<blockquote class="bad"><p><strong>درس کلیدی:</strong> یک شمارهٔ نظام پرستاریِ معتبر به‌تنهایی چیزی را اثبات نمی‌کند، چون می‌تواند دزدیده شده باشد. آنچه اثبات می‌کند، <strong>زنجیرهٔ «کد ملی ← چهرهٔ زنده ← عکس ثبت احوال ← عکس نظام پرستاری ← نامِ یکسان در همه»</strong> است. این تنها سدّ واقعی در برابر سناریوی «پرستار قلابی» است.</p></blockquote>
+
+<hr>
+
+<h2 id="fieldmap">۶. جدول «داده موردنیاز ← منبع / سرویس»</h2>
+<div class="tablewrap">
+<table>
+<thead><tr><th>داده‌ای که می‌خواهید</th><th>منبع / API</th><th>ورودی لازم</th><th>دسترسی</th></tr></thead>
+<tbody>
+<tr><td>تطبیق موبایل ↔ کد ملی</td><td>شاهکار (Finnotech/U-ID/api.ir/…)</td><td>موبایل + کد ملی</td><td><span class="badge b-auto">خودکار</span></td></tr>
+<tr><td>نام، نام خانوادگی، نام پدر، جنسیت</td><td>استعلام هویت ثبت احوال (Shabanic/U-ID)</td><td>کد ملی + تاریخ تولد</td><td><span class="badge b-auto">خودکار</span></td></tr>
+<tr><td>شماره/سری/سریال شناسنامه</td><td>استعلام هویت ثبت احوال</td><td>کد ملی + تاریخ تولد</td><td><span class="badge b-auto">خودکار</span></td></tr>
+<tr><td>وضعیت حیات (زنده/فوت)</td><td>استعلام هویت ثبت احوال (<code>deathStatus</code>)</td><td>کد ملی + تاریخ تولد</td><td><span class="badge b-auto">خودکار</span></td></tr>
+<tr><td>تطبیق چهرهٔ زنده با عکس رسمی</td><td>eKYC ویدیویی (U-ID/api.ir/VIDA)</td><td>ویدیو + کد ملی + سریال کارت + تاریخ تولد + جنسیت</td><td><span class="badge b-consent">رضایتی</span></td></tr>
+<tr><td>صحت شمارهٔ نظام + مقطع/رشته/شهر + عکس</td><td>نظام پرستاری <code>estelam.ino1.ir</code></td><td>شماره نظام یا نام (تطبیق دقیق)</td><td><span class="badge b-manual">دستی/Scrape</span></td></tr>
+<tr><td>وضعیت فعال/منقضیِ عضویت نظام پرستاری</td><td>پورتال عضویت <code>membership.ino1.ir</code></td><td>لاگین + OTP خود فرد</td><td><span class="badge b-consent">رضایتی</span></td></tr>
+<tr><td>سال سابقه / سوابق بیمه</td><td>تأمین اجتماعی <code>eservices.tamin.ir</code></td><td>credential یا OTP خود فرد</td><td><span class="badge b-consent">رضایتی</span></td></tr>
+<tr><td>مدرک کارشناسی پرستاری</td><td>وزارت بهداشت <code>eg.behdasht.gov.ir</code> / آپلود</td><td>self-service فرد یا استعلام سازمانی</td><td><span class="badge b-manual">آپلود/دستی</span></td></tr>
+<tr><td>غربالگری سوء‌پیشینه (غیرمستقیم)</td><td>پروانهٔ صلاحیت حرفه‌ای + گواهی عدم سوء پیشینه</td><td>self-service فرد / آپلود گواهی</td><td><span class="badge b-consent">رضایتی</span></td></tr>
+<tr><td>تطبیق حساب واریز با کد ملی</td><td>تطبیق شبا/کارت با کد ملی (Shabanic/U-ID)</td><td>شبا یا کارت + کد ملی</td><td><span class="badge b-auto">خودکار</span></td></tr>
+<tr><td>آدرس رسمی</td><td>استعلام آدرس با کد پستی</td><td>کد پستی (از خود فرد)</td><td><span class="badge b-auto">خودکار</span></td></tr>
+<tr><td>کد نظام پزشکی (فقط اگر فرد پزشک باشد)</td><td>نظام پزشکی <code>membersearch.irimc.org</code> / API پادیوم</td><td>کد ملی یا شماره نظام</td><td><span class="badge b-auto">خودکار (B2B سلامت)</span></td></tr>
+<tr><td>موبایل از کد ملی / هویت از موبایل (معکوس)</td><td>—</td><td>—</td><td><span class="badge b-bad">غیرقابل‌دسترس</span></td></tr>
+</tbody>
+</table>
+</div>
+<blockquote><p>دو مسیر که <strong>برای شرکت خصوصی وجود ندارند</strong> و نباید رویشان حساب کنید: (۱) «کد ملی → شمارهٔ موبایل» یا «موبایل → هویت کامل» (فقط با دستور قضایی)، و (۲) «کد ملی → آدرس» (آدرس فقط با خودِ کد پستی به‌دست می‌آید).</p></blockquote>
+
+<hr>
+
+<h2 id="scoring">۷. جمع‌بندیِ تصمیم و امتیاز اعتماد</h2>
+<p>پیشنهاد می‌شود نتیجهٔ هر گام را به یک «کارت اعتماد» تبدیل کنید و سیاست تأیید را روی آن بنا کنید:</p>
+<div class="tablewrap">
+<table>
+<thead><tr><th>سطح</th><th>شرط</th><th>نتیجه</th></tr></thead>
+<tbody>
+<tr><td><strong>هویت پایه ✅</strong></td><td>شاهکار + OTP + استعلام ثبت احوال (نام می‌خواند، حیات تأیید) موفق</td><td>اجازهٔ تکمیل پروفایل؛ هنوز قابل‌رزرو نیست</td></tr>
+<tr><td><strong>هویت قوی ✅✅</strong></td><td>+ احراز ویدیوییِ <code>ACCEPTED</code> (تطبیق چهره)</td><td>هویت فرد قطعی است</td></tr>
+<tr><td><strong>صلاحیت حرفه‌ای ✅✅✅</strong></td><td>+ تطبیق نام/عکسِ نظام پرستاری با هویت + پروانهٔ صلاحیت + عدم سوء پیشینه</td><td><strong>قابل‌رزرو</strong> برای خانواده‌ها (نشانِ «احرازشده»)</td></tr>
+<tr><td><strong>بازبینی دستی ⚠️</strong></td><td>هر مغایرتی (نام نمی‌خواند، عکس مردد، شماره نظام یافت نشد)</td><td>صف بازبینی انسانی پیش از فعال‌سازی</td></tr>
+<tr><td><strong>رد ⛔</strong></td><td>شاهکار false، حیات=فوت، چهره REJECTED، یا سوء‌پیشینهٔ مشکل‌دار</td><td>عدم پذیرش</td></tr>
+</tbody>
+</table>
+</div>
+<p><strong>نکته‌های اجرایی:</strong> نتایج استعلام‌ها را با مهر زمانی ذخیره کنید (هم برای حسابرسی، هم دفاع حقوقی)؛ مدارک حساس (مجوز، سوء‌پیشینه) را <strong>دوره‌ای بازبینی/تمدید</strong> کنید نه فقط یک‌بار در ثبت‌نام؛ و هر استعلام را فقط با <strong>رضایت ثبت‌شدهٔ کاربر</strong> اجرا کنید.</p>
+
+<hr>
+
+<h2 id="legal">۸. نکات حقوقی، حریم خصوصی و دسترسی</h2>
+<ul>
+  <li><strong>پیش‌نیاز فنی:</strong> برای همهٔ APIها باید شرکت ثبت‌شده، احراز کسب‌وکار و <code>client credential</code> از ارائه‌دهنده داشته باشید. APIهای هویتی به اشخاص حقیقی داده نمی‌شوند.</li>
+  <li><strong>رضایت کاربر:</strong> طبق الزامات رگولاتوری، پیش از استعلام و نگه‌داری دادهٔ هویتی باید رضایت صریح بگیرید (متن رضایت‌نامه در فرم ثبت‌نام + لاگ OTP).</li>
+  <li><strong>کمینه‌سازی داده:</strong> فقط آنچه را که برای تصمیم لازم است ذخیره کنید؛ تصاویر سلفی و مدارک حساس را رمزنگاری و با دسترسی محدود نگه دارید.</li>
+  <li><strong>راهبردِ ارائه‌دهنده:</strong> ترجیحاً از یک ارائه‌دهندهٔ KYC جامع (مثل Finnotech یا U-ID) استفاده کنید تا اتصال به سرویس‌های دولتیِ گِی‌ت‌شده (شاهکار، ثبت احوال) را او مدیریت کند و بار انطباق روی دوش او باشد.</li>
+  <li><strong>محدودیت‌های واقعی را بپذیرید:</strong> نظام پرستاری API ندارد (دستی/Scrape)؛ سابقه و مدرک و سوء‌پیشینه رضایتی/آپلودی‌اند؛ مسیرهای معکوس موبایل/آدرس بسته‌اند. فلو را حول این واقعیت‌ها طراحی کنید، نه برخلافشان.</li>
+</ul>
+
+<blockquote class="warn"><p><strong>موارد با اطمینان پایین‌تر که پیش از کدنویسی باید با خودِ ارائه‌دهنده نهایی شوند:</strong> نام دقیق فیلدهای خروجی (مثل <code>idSerie</code>/<code>idSerial</code> و enumهای eKYC)؛ قیمت‌ها؛ امکان استعلامِ پروانهٔ صلاحیت حرفه‌ای توسط شخص ثالث؛ پوششِ مدارک وزارت بهداشت توسط APIهای reseller؛ و جزئیات API نظام پزشکیِ پادیوم. این‌ها از مستندات/منابع ثانویه استخراج شده‌اند و ممکن است در نسخهٔ قراردادی کمی فرق کنند.</p></blockquote>
+
+<hr>
+
+<h2 id="sources">۹. منابع</h2>
+<p class="sourcing">
+<strong>هویت و KYC:</strong>
+<a href="https://finnotech.ir/sub-service/%D8%AA%D8%B7%D8%A8%DB%8C%D9%82%20%DA%A9%D8%AF%D9%85%D9%84%DB%8C%20%D9%88%20%D9%85%D9%88%D8%A8%D8%A7%DB%8C%D9%84">Finnotech — شاهکار</a> ·
+<a href="https://finnotech.ir/sub-service/%D8%B5%D8%AD%D8%AA%E2%80%8C%20%D8%B3%D9%86%D8%AC%DB%8C%20%DA%A9%D8%AF%20%D9%85%D9%84%DB%8C">Finnotech — صحت‌سنجی کد ملی</a> ·
+<a href="https://u-id.net/api/">U-ID — API هویت</a> ·
+<a href="https://u-id.net/api-shahkar/">U-ID — شاهکار</a> ·
+<a href="https://u-id.net/api-ekyc-docs/">U-ID — eKYC docs</a> ·
+<a href="https://shabanic.ir/nid_api_doc">Shabanic — استعلام ثبت احوال</a> ·
+<a href="https://shabanic.ir/card_to_shaba_api_doc">Shabanic — کارت به شبا</a> ·
+<a href="https://shabanic.ir/p_iban_owner_verification">Shabanic — تطبیق شبا با کد ملی</a> ·
+<a href="https://www.api.ir/web-service/%D8%A7%D8%AD%D8%B1%D8%A7%D8%B2-%D9%87%D9%88%DB%8C%D8%AA-%D8%B2%D9%86%D8%AF%D9%87%E2%80%8C%D8%B3%D9%86%D8%AC%DB%8C-%D9%88%DB%8C%D8%AF%DB%8C%D9%88%DB%8C%DB%8C/">api.ir — زنده‌سنجی</a> ·
+<a href="https://vidaverify.ir/">VIDA</a> ·
+<a href="https://www.melipayamak.com/blog/posts/how-to-request-mobile-number-with-national-code/">ملی‌پیامک — استعلام موبایل با کد ملی</a>
+<br><br>
+<strong>صلاحیت حرفه‌ای و سابقه:</strong>
+<a href="https://estelam.ino1.ir/">نظام پرستاری — استعلام</a> ·
+<a href="https://membership.ino1.ir/">نظام پرستاری — عضویت</a> ·
+<a href="https://www.heyvagroup.com/shownews/11343/">heyvagroup — نظام پرستاری</a> ·
+<a href="https://op.salamat.gov.ir/">صلاحیت حرفه‌ای — اپراتور سلامت</a> ·
+<a href="https://www.heyvagroup.com/shownews/12145/">heyvagroup — صلاحیت حرفه‌ای</a> ·
+<a href="https://membersearch.irimc.org/">نظام پزشکی — جستجو</a> ·
+<a href="https://blog.podium.ir/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-api%D9%87%D8%A7%DB%8C-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86-%D9%86%D8%B8%D8%A7%D9%85-%D9%BE%D8%B2%D8%B4%DA%A9%DB%8C-%DA%A9%D8%B4%D9%88%D8%B1/">Podium — API نظام پزشکی</a> ·
+<a href="https://eservices.tamin.ir">تأمین اجتماعی</a> ·
+<a href="https://eg.behdasht.gov.ir/">وزارت بهداشت — دانش‌آموختگان</a> ·
+<a href="https://apieco.ir/api/ghabzino-social-security-records/">Ghabzino — سوابق بیمه</a>
+</p>
+
+<p class="meta"><em>این سند بر پایهٔ استعلام مستقیم مستندات ارائه‌دهندگان (Finnotech، U-ID، Shabanic، api.ir) و سامانه‌های رسمی (estelam.ino1.ir، membersearch.irimc.org، behdasht.gov.ir، tamin.ir) تهیه شده است. پیش از پیاده‌سازی، فیلدها و قیمت‌ها را با واحد فروش ارائه‌دهنده‌ای که با او قرارداد می‌بندید نهایی کنید.</em></p>
+
+</article>
+</div>
+</body>
+</html>
diff --git a/product/گزارش-پلتفرم-پرستاری.html b/product/گزارش-پلتفرم-پرستاری.html
new file mode 100644
index 0000000..d1911af
--- /dev/null
+++ b/product/گزارش-پلتفرم-پرستاری.html
@@ -0,0 +1,590 @@
+<!DOCTYPE html>
+<html lang="fa" dir="rtl">
+<head>
+<meta charset="UTF-8">
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+<title>گزارش پلتفرم پرستاری در منزل — ایران</title>
+<link rel="preconnect" href="https://fonts.googleapis.com">
+<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
+<link href="https://fonts.googleapis.com/css2?family=Vazirmatn:wght@400;500;700;800&display=swap" rel="stylesheet">
+<style>
+  :root {
+    --ink: #1f2933;
+    --muted: #52606d;
+    --accent: #0d6e6e;
+    --accent-dark: #0a5252;
+    --line: #d9e2e6;
+    --bg: #f7f9fa;
+    --card: #ffffff;
+    --warn-bg: #fff7e6;
+    --warn-border: #f0b429;
+    --note-bg: #eef6f6;
+    --ok: #0a7d3c;
+    --bad: #b42318;
+  }
+  * { box-sizing: border-box; }
+  html { scroll-behavior: smooth; }
+  body {
+    font-family: 'Vazirmatn', 'Tahoma', 'IRANSans', 'Segoe UI', sans-serif;
+    direction: rtl;
+    text-align: right;
+    line-height: 2;
+    color: var(--ink);
+    background: var(--bg);
+    margin: 0;
+    padding: 0;
+    font-size: 17px;
+    -webkit-font-smoothing: antialiased;
+  }
+  .wrap {
+    max-width: 940px;
+    margin: 0 auto;
+    padding: 48px 28px 80px;
+  }
+  .doc {
+    background: var(--card);
+    border: 1px solid var(--line);
+    border-radius: 16px;
+    padding: 44px clamp(20px, 5vw, 56px);
+    box-shadow: 0 4px 24px rgba(15, 40, 50, 0.05);
+  }
+  h1 {
+    font-size: 2.05rem;
+    font-weight: 800;
+    line-height: 1.6;
+    color: var(--accent-dark);
+    margin: 0 0 6px;
+    border-bottom: 3px solid var(--accent);
+    padding-bottom: 16px;
+  }
+  h2 {
+    font-size: 1.55rem;
+    font-weight: 800;
+    color: var(--accent-dark);
+    margin: 52px 0 12px;
+    padding: 10px 16px;
+    background: linear-gradient(90deg, var(--note-bg), transparent);
+    border-right: 5px solid var(--accent);
+    border-radius: 6px;
+  }
+  h3 {
+    font-size: 1.22rem;
+    font-weight: 700;
+    color: var(--accent-dark);
+    margin: 32px 0 8px;
+  }
+  h4 {
+    font-size: 1.05rem;
+    font-weight: 700;
+    color: var(--muted);
+    margin: 22px 0 6px;
+  }
+  p { margin: 12px 0; }
+  a { color: var(--accent); text-decoration: none; border-bottom: 1px dotted var(--accent); word-break: break-all; }
+  a:hover { color: var(--accent-dark); border-bottom-style: solid; }
+  strong { font-weight: 700; color: #102a30; }
+  ul, ol { padding-right: 26px; margin: 12px 0; }
+  li { margin: 7px 0; }
+  hr { border: none; border-top: 1px solid var(--line); margin: 40px 0; }
+
+  /* Inline code / Latin terms / URLs — keep them LTR so they read correctly */
+  code, .ltr {
+    direction: ltr;
+    unicode-bidi: embed;
+    font-family: 'Consolas', 'Menlo', monospace;
+    background: #eef2f3;
+    padding: 1px 6px;
+    border-radius: 5px;
+    font-size: 0.88em;
+    color: #0a5252;
+  }
+
+  /* The lead / summary block */
+  blockquote {
+    margin: 18px 0;
+    padding: 14px 20px;
+    background: var(--note-bg);
+    border-right: 5px solid var(--accent);
+    border-radius: 8px;
+    color: var(--muted);
+  }
+  blockquote.warn {
+    background: var(--warn-bg);
+    border-right-color: var(--warn-border);
+    color: #7a5b00;
+  }
+  blockquote p { margin: 6px 0; }
+
+  .meta {
+    color: var(--muted);
+    font-size: 0.95rem;
+    margin: 4px 0 20px;
+  }
+  .sourcing {
+    font-size: 0.92rem;
+    background: #f0f4f5;
+    border: 1px dashed var(--line);
+    border-radius: 10px;
+    padding: 14px 20px;
+    color: var(--muted);
+  }
+
+  /* Tables */
+  .tablewrap { overflow-x: auto; margin: 20px 0; border-radius: 10px; border: 1px solid var(--line); }
+  table {
+    border-collapse: collapse;
+    width: 100%;
+    min-width: 640px;
+    font-size: 0.92rem;
+    background: #fff;
+  }
+  th, td {
+    border: 1px solid var(--line);
+    padding: 10px 12px;
+    text-align: right;
+    vertical-align: top;
+    line-height: 1.75;
+  }
+  thead th {
+    background: var(--accent);
+    color: #fff;
+    font-weight: 700;
+    position: sticky;
+    top: 0;
+  }
+  tbody tr:nth-child(even) { background: #f6fafa; }
+  tbody tr:hover { background: #eef6f6; }
+  td:first-child, th:first-child { font-weight: 600; }
+
+  /* Tags */
+  .ok { color: var(--ok); font-weight: 700; white-space: nowrap; }
+  .bad { color: var(--bad); font-weight: 700; }
+  .pill {
+    display: inline-block;
+    background: #e6f4ea;
+    color: var(--ok);
+    border-radius: 20px;
+    padding: 1px 10px;
+    font-size: 0.82em;
+    font-weight: 700;
+  }
+
+  /* Table of contents */
+  nav.toc {
+    background: #f0f6f6;
+    border: 1px solid var(--line);
+    border-radius: 12px;
+    padding: 18px 26px;
+    margin: 24px 0 8px;
+  }
+  nav.toc h2 {
+    margin: 0 0 8px;
+    font-size: 1.15rem;
+    background: none;
+    border: none;
+    padding: 0;
+  }
+  nav.toc ol { margin: 0; }
+  nav.toc a { border-bottom: none; }
+
+  @media print {
+    body { background: #fff; font-size: 12px; }
+    .doc { border: none; box-shadow: none; padding: 0; }
+    h2 { background: none; }
+    a { color: #000; border: none; }
+  }
+</style>
+</head>
+<body>
+<div class="wrap">
+<article class="doc">
+
+<h1>ساخت پلتفرم پرستاری خصوصی در منزل در ایران<br>گزارش تحقیق و استراتژی</h1>
+
+<blockquote>
+<p><strong>ایده:</strong> پلتفرمی که به خانواده‌ها در ایران کمک می‌کند به‌سادگی پرستار خصوصی و احرازهویت‌شده برای عزیزانشان پیدا و استخدام کنند — مراقبت از سالمند، دورهٔ نقاهت پس از جراحی، مراقبت از نوزاد، و مدیریت بیماری‌های مزمن.</p>
+</blockquote>
+
+<p class="meta"><strong>تاریخ تهیه:</strong> ۱۴۰۵/۰۳/۲۶ (2026-06-16) &nbsp;·&nbsp; <strong>دامنه:</strong> (۱) تحلیل بازار و رقبا، (۲) مشکلات و ریسک‌ها، (۳) احراز هویت و اعتبارسنجی صلاحیت پرستار، (۴) چارچوب حقوقی ایران، به‌علاوهٔ توصیه‌های عملی.</p>
+
+<p class="sourcing"><strong>یادداشتی دربارهٔ منابع.</strong> این گزارش ترکیبی است از: (الف) یک مرحلهٔ تحقیق با راستی‌آزمایی متخاصمانه دربارهٔ <strong>چارچوب حقوقی ایران و رقبای داخلی</strong> (ادعاهایی که از فرایند رأی‌گیری سه‌گانه عبور کرده‌اند با <span class="ok">✅ تأییدشده</span> علامت خورده‌اند؛ ادعاهای <em>ردشده</em> صریحاً مشخص شده‌اند)، و (ب) تحقیق هدفمند وب دربارهٔ <strong>پلتفرم‌های خارجی، نمونه‌های شکست/ریسک، و ابزارهای احراز هویت</strong>. هرجا واقعیتی از صفحهٔ تبلیغاتی خودِ یک شرکت آمده باشد به‌عنوان «خوداظهاری/حسابرسی‌نشده» علامت خورده؛ و هرجا بر دانش مدل تکیه دارد با <strong>[تأییدنشده — پیش از اتکا راستی‌آزمایی شود]</strong> علامت خورده است. ارقام سرمایه‌گذاری و مقررات قدیمی را پیش از انتشار راستی‌آزمایی کنید.</p>
+
+<nav class="toc">
+<h2>فهرست</h2>
+<ol>
+  <li><a href="#summary">خلاصهٔ مدیریتی</a></li>
+  <li><a href="#market">۱. تحلیل بازار و رقبا</a></li>
+  <li><a href="#risks">۲. مشکلات و ریسک‌ها</a></li>
+  <li><a href="#verify">۳. احراز هویت و اعتبارسنجی صلاحیت پرستار</a></li>
+  <li><a href="#legal">۴. چارچوب حقوقی در ایران</a></li>
+  <li><a href="#gtm">۵. توصیه‌های عملی و راهبرد ورود به بازار</a></li>
+</ol>
+</nav>
+
+<hr>
+
+<h2 id="summary">خلاصهٔ مدیریتی</h2>
+
+<p><strong>می‌توانید این کسب‌وکار را قانوناً در ایران بسازید — اما این یک <em>فعالیت درمانی دارای مجوز</em> است، نه یک مارکت‌پلیس آزاد برای راه‌اندازی.</strong> اعتبار اصلی عبارت است از <strong>پروانهٔ تأسیس</strong> به‌علاوهٔ <strong>پروانهٔ مسئول فنی</strong> از وزارت بهداشت، که از طریق <strong>معاونت درمان</strong> و پس از تصویب <strong>کمیسیون قانونی تشخیص امور پزشکی (موضوع مادهٔ ۲۰)</strong> صادر می‌شود. <span class="ok">✅ تأییدشده</span></p>
+
+<p><strong>دو مسیر قانونی وجود دارد و انتخاب میان آن‌ها تعیین‌کننده است:</strong></p>
+<ul>
+  <li><strong>مرکز خدمات پرستاری در منزل</strong> (مرکز مشاوره و ارائه مراقبت‌های پرستاری در منزل) — تحت نظر سازمان نظام پرستاری؛ یک <strong>پرستار</strong> (کارشناسی + ۵ سال سابقهٔ بالینی) می‌تواند مؤسس و مسئول فنی باشد. <strong>این گزینهٔ درست برای ایدهٔ شماست.</strong> <span class="ok">✅ تأییدشده</span></li>
+  <li><strong>مرکز خدمات و مراقبت‌های بالینی در منزل</strong> — <strong>هم مؤسس و هم مسئول فنی باید پزشک باشند.</strong> مگر اینکه شریک پزشک داشته باشید، از این مسیر پرهیز کنید. <span class="ok">✅ تأییدشده</span></li>
+</ul>
+
+<p><strong>بازار واقعی و از پیش رقابتی است</strong> — آسانیسم، اسنپ دکتر، سلامت اول و هیراد همگی امروز فعال‌اند — <strong>اما عمدتاً در تهران/کرج متمرکزند و بیشتر به‌صورت اعزام مستقیم نیرو کار می‌کنند، نه به‌عنوان مارکت‌پلیس مبتنی بر اعتماد.</strong> این، شکاف بازار شماست. <span class="ok">✅ تأییدشده</span></p>
+
+<p><strong>سخت‌ترین مسئله، اعتماد و ایمنی است، نه فناوری.</strong> هر داستان عبرت‌آموز در خارج (جریمه‌های نظارتی Care.com، پروندهٔ کلاهبرداری هویتیِ «پرستار قلابی»، احکام طبقه‌بندی نادرست نیروی کار) به یک قاعده می‌رسد: <strong>مالک فرایند احراز صلاحیت خودتان باشید؛ هرگز آن را به خانواده‌ها واگذار نکنید، و هرگز بررسی ایمنی‌ای که واقعاً انجام نمی‌دهید را تبلیغ نکنید.</strong></p>
+
+<p><strong>خبر خوب دربارهٔ احراز هویت:</strong> ایران یک بازار رقابتی از APIهای آمادهٔ احراز هویت (KYC) دارد (تطبیق شمارهٔ موبایل با کد ملی از طریق <strong>شاهکار</strong>، تطبیق چهره/زنده‌بودن با کارت ملی) که احراز هویت را به ساده‌ترین لایه تبدیل می‌کند. لایهٔ مجوز سخت‌تر است (API عمومی B2B وجود ندارد)، اما <strong>پروانهٔ صلاحیت حرفه‌ای</strong> پرستار از وزارت بهداشت همان اعتباری است که باید مطالبه کنید — چون از پیش شامل بررسی سوء‌پیشینه است.</p>
+
+<p><strong>جمع‌بندی استراتژیک:</strong> به‌عنوان <strong>مرکز خدمات پرستاری در منزل</strong> ثبت کنید، از همان ابتدا با مراکز دارای مجوز همکاری کنید (مدل آسانیسم) تا سریع حرکت کنید، <strong>اعتماد احرازشده را به کل برند خود تبدیل کنید</strong>، <strong>شهرهای کم‌تر پوشش‌داده‌شده خارج از تهران</strong> را هدف بگیرید، و روی درآمد B2B/نهادی (مسیرهای ترخیص بیمارستانی، بیمه‌گرها، مزایای کارکنان شرکت‌ها) علاوه بر پرداخت مستقیم خانواده‌ها بسازید.</p>
+
+<hr>
+
+<h2 id="market">۱. تحلیل بازار و رقبا</h2>
+
+<h3>۱.۱ بازیگران ایرانی (کسانی که واقعاً با آن‌ها رقابت می‌کنید) <span class="ok">✅ تأییدشده</span></h3>
+
+<p>بازار داخلی <strong>فعال و در حال رشد</strong> است — تا سال ۱۳۹۸ حدود <strong>۷۰۰ شرکت خدمات درمانی در منزل</strong> ثبت شده بودند، با تلاش رسمی برای رساندن آن به حدود ۱٬۰۰۰ (که اکنون تقریباً مطمئناً بیشتر است). <span class="ok">✅ تأییدشده</span> (منبع واحد سال ۱۳۹۸؛ آن را یک کفِ تاریخی بدانید). رهبران بازار:</p>
+
+<div class="tablewrap">
+<table>
+<thead>
+<tr><th>بازیگر</th><th>مدل</th><th>بخش‌های هدف</th><th>نکات قابل‌توجه</th><th>قیمت‌گذاری</th></tr>
+</thead>
+<tbody>
+<tr>
+  <td>آسانیسم</td>
+  <td>مارکت‌پلیس/تطبیق که نیرو را از طریق مراکز دارای مجوزِ همکار تأمین می‌کند (مدل واسطه‌ای)</td>
+  <td>سالمند، کودک، پس از جراحی، مزمن، بالینی (تزریقات، پانسمان، تعویض سوند، خون‌گیری در منزل)</td>
+  <td>احراز هویت مراقبین، رعایت پروتکل بهداشتی، سفتهٔ تضمین ~۴۰ میلیون تومان، دورهٔ آزمایشی ۲۴–۴۸ ساعته. <strong>تمرکز ~۹۹٪ در تهران/کرج</strong>، ~۱٬۶۵۰ مراقب فعال در ۴ مرکز همکار (خوداظهاری)</td>
+  <td>فعلی (۱۴۰۴/۱۴۰۵)</td>
+</tr>
+<tr>
+  <td>اسنپ دکتر</td>
+  <td>عمودیِ سلامتِ اسنپ (بزرگ‌ترین سوپراَپ ایران)؛ اعزام مدیریت‌شده</td>
+  <td>سالمند، پس از جراحی (زخم، کشیدن بخیه)، نوزاد/کودک، مزمن (سکته، سرطان، پارکینسون، MS، آلزایمر)</td>
+  <td>فعال در تهران، کرج، قم، شیراز، کرمانشاه، اصفهان، مشهد. دارای <strong>مجوز عمومی واسطه‌گری پزشکی آنلاین («پل ارتباطی»)</strong> — <strong>نه</strong> مجوز اختصاصی پرستاری در منزل (این ادعا رد شد)</td>
+  <td>—</td>
+</tr>
+<tr>
+  <td>سلامت اول</td>
+  <td><strong>اعزام مستقیم پرستارهای خودش</strong> (نه مارکت‌پلیس باز) — شرکت پرستار را انتخاب می‌کند</td>
+  <td>مراقبت از سالمند (ساعتی / روزانه / شبانه‌روزی)</td>
+  <td><strong>۳٬۰۰۰+ نیروی فعال</strong>، مرکز تماس ۲۴/۷ (۱۵۲۷)، تهران + حومه (کرج، پردیس). دارای <strong>پروانهٔ رسمی وزارت بهداشت شمارهٔ ۳-۳۸۸۱۸۰</strong></td>
+  <td>«توافقی»؛ شیفت شبانه‌روزی به‌ازای هر ساعت ارزان‌تر</td>
+</tr>
+<tr>
+  <td>هیراد</td>
+  <td>اپ‌محور (کافه‌بازار، مایکت)؛ اعزام/کاریابی مدیریت‌شده</td>
+  <td>سالمند، کودک/نوزاد، پس از جراحی/نقاهت، تزریقات در منزل، آزمایش در منزل</td>
+  <td>هر دو سمت را نشان می‌دهد (خانواده درخواست می‌دهد؛ پرستار «کارهای موجود» را می‌بیند)؛ «استخدام بدون هزینه». اعلام می‌کند تحت مجوز وزارت بهداشت فعالیت می‌کند. اقبال محدود</td>
+  <td>—</td>
+</tr>
+</tbody>
+</table>
+</div>
+
+<p><strong>نتیجه‌گیری برای شما:</strong></p>
+<ol>
+  <li><strong>مدل غالب، اعزام مستقیم/مدیریت‌شده است، نه مارکت‌پلیس دوطرفهٔ واقعیِ مبتنی بر اعتماد.</strong> حتی بازیگران «شبه‌مارکت‌پلیس» (آسانیسم، هیراد) عملاً مثل آژانس‌های نیروی مدیریت‌شده کار می‌کنند. یک تجربهٔ واقعاً شفاف و مبتنی بر نظرات کاربران که در آن خانواده پرستار را انتخاب می‌کند، هنوز نسبتاً باز است.</li>
+  <li><strong>تمرکز جغرافیایی شدید است.</strong> تهران/کرج غالب‌اند؛ شهرهای ردهٔ دوم (مشهد، اصفهان، شیراز، تبریز، اهواز، قم) کم‌پوشش‌اند. <strong>این روشن‌ترین فضای خالی بازار است.</strong></li>
+  <li><strong>قیمت‌گذاری مبهم و توافقی است.</strong> قیمت‌گذاری شفاف و از پیش‌اعلام‌شده یک تمایز ارزشمند است.</li>
+  <li><strong>«دارای مجوز» یک سیگنال اعتماد واقعی است</strong> — سلامت اول شمارهٔ پروانهٔ وزارت بهداشت خود را برجسته نمایش می‌دهد. شما هم باید این کار را بکنید.</li>
+</ol>
+
+<blockquote class="warn">
+<p>⚠️ <strong>ادعاهای ردشده که نباید تکرار شوند:</strong> اسنپ دکتر مجوز اختصاصی پرستاری در منزل از وزارت بهداشت <strong>ندارد</strong> (فقط مجوز عمومی واسطه‌گری)؛ یک نمونهٔ قیمت‌گذاری به‌تفکیک شهر که به آن نسبت داده شده بود نیز رد شد. اعداد نیروی انسانی رقبا (۱٬۶۵۰ / ۳٬۰۰۰) ارقام تبلیغاتی خوداظهاری‌اند.</p>
+</blockquote>
+
+<h3>۱.۲ پلتفرم‌های خارجی (مدل‌هایی برای یادگیری)</h3>
+
+<p>پلتفرم‌های خارجی در <strong>چهار مدل ساختاری</strong> دسته‌بندی می‌شوند — دانستن اینکه از کدام مدل تقلید می‌کنید، از هر ویژگی منفرد مهم‌تر است:</p>
+<ol>
+  <li><strong>مارکت‌پلیس مصرف‌کنندهٔ خالص</strong> — خانواده‌ها را مستقیم به مراقبینِ <em>خوداشتغال</em> وصل می‌کند؛ پلتفرم هیچ‌کس را استخدام نمی‌کند (Care.com، Curam). ارزان، اما کنترل کیفیت ضعیف و ریسک حقوقی جدی بابت طبقه‌بندی نادرست نیروی کار.</li>
+  <li><strong>مدیریت‌شده / «تمام‌پشته» (full-stack)</strong> — شرکت نیروهای خودش را استخدام، آموزش، احراز و اعزام می‌کند و فناوری را روی آن سوار می‌کند (Honor، Cera، Homage، Portea). کیفیت و دفاع‌پذیری بالاتر؛ سرمایه‌بَر.</li>
+  <li><strong>پلتفرم تأمین نیرو برای مراکز</strong> — شیفت بیمارستان/خانهٔ سالمندان را پر می‌کند، نه مصرف‌کننده (Florence، Vivian Health).</li>
+  <li><strong>تجمیع تقاضا + ادغام با بیمه</strong> — مدل‌های جذب سرنخ / همراهی / بیمه (Papa، Pflege.de).</li>
+</ol>
+
+<p><strong>روشن‌ترین درس از داده‌ها: سرمایه و قراردادهای پایدار به‌سمت مدل‌های مدیریت‌شده/تمام‌پشته و ادغام‌شده با بیمه جریان دارند، در حالی که مارکت‌پلیس‌های خالصِ پیمانکار مستقل مدام به سقف قانون کار برمی‌خورند.</strong></p>
+
+<h4>جدول مقایسه (منتخب؛ ارقام سرمایه تقریبی — پیش از اتکا راستی‌آزمایی شود)</h4>
+<div class="tablewrap">
+<table>
+<thead>
+<tr><th>پلتفرم</th><th>کشور</th><th>مدل</th><th>ویژگی شاخص</th><th>کسب درآمد</th><th>تمایز / دستاورد</th></tr>
+</thead>
+<tbody>
+<tr><td>Care.com</td><td>آمریکا</td><td>مارکت‌پلیس اشتراکی خالص</td><td>پروفایل، نظرات، بررسی پیشینهٔ اختیاریِ پولی</td><td>اشتراک خانواده + مراقب؛ بدون سهم از دستمزد</td><td>بزرگ‌ترین. <span class="bad">داستان عبرت</span> — تسویهٔ ۸٫۵M دلار FTC (۲۰۲۴)، ۱M دلار Marin DA (۲۰۲۰)</td></tr>
+<tr><td>Honor</td><td>آمریکا</td><td>تمام‌پشتهٔ مدیریت‌شده + فرنچایز</td><td>پلتفرم فناوری+عملیات؛ جذب شبکهٔ جهانی Home Instead</td><td>B2B + فرنچایز؛ مراقبت ساعتی</td><td>یونیکورن (~۱٫۲۵B دلار+)؛ ~۲٫۱B دلار با Home Instead؛ ۱۰۰هزار+ مراقب</td></tr>
+<tr><td>Papa</td><td>آمریکا</td><td>همراهی + مراقبتِ پرداخت‌شده توسط بیمه</td><td>«Papa Pals» همراهی برای تنهایی؛ راهبری مراقبت</td><td>قرارداد B2B با Medicare Advantage / Medicaid / کارفرما</td><td>تنهایی را به نیاز سلامتیِ قابل‌صورت‌حساب تبدیل کرد؛ ۱۵۰M دلار Series D</td></tr>
+<tr><td>Cera</td><td>بریتانیا</td><td>تمام‌پشتهٔ مدیریت‌شده + هوش مصنوعی پیش‌بین</td><td>پیش‌بینی زمین‌خوردن/بستری روزها قبل؛ ثبت علائم حیاتی</td><td>B2B با NHS و ۱۵۰+ شهرداری</td><td>مالکیت هم‌زمان نیرو و داده؛ یونیکورن ~۱B دلار (۲۰۲۵)</td></tr>
+<tr><td>Florence</td><td>بریتانیا</td><td>مارکت‌پلیس تأمین نیرو برای مراکز</td><td>رزرو فوری شیفت؛ برنامه/حقوق/آموزش؛ بررسی DBS</td><td>کمیسیون به‌ازای شیفت + SaaS</td><td>حذف واسطه‌های گران آژانس پرستاری</td></tr>
+<tr><td>Curam</td><td>بریتانیا</td><td>مارکت‌پلیس خالص (خوداشتغال)</td><td>بررسی DBS + احراز بیومتریک؛ بیمهٔ همراه</td><td>کمیسیون ۱۲٫۵٪ + مالیات (مراقب ~۸۵٪ نگه می‌دارد)</td><td>مدل کم‌کارمزدِ خوداشتغال</td></tr>
+<tr><td>Homage</td><td>سنگاپور (+مالزی/استرالیا)</td><td><strong>مارکت‌پلیس گزینش‌شده + تطبیق انسانی</strong></td><td>الگوریتم نامزدها را پیشنهاد می‌دهد، کارکنان تطبیق نهایی را انجام می‌دهند؛ تله‌مدیسین؛ ادغام با یارانهٔ دولتی</td><td>حاشیهٔ ساعتی + بسته‌ها + B2B</td><td>شبکهٔ گزینش‌شدهٔ توانمند بالینی؛ ۳۰M دلار Series C (Temasek). <strong>بهترین تناسب مدل برای ایران</strong></td></tr>
+<tr><td>Portea Medical</td><td>هند</td><td>ارائه‌دهندهٔ بالینی مدیریت‌شده</td><td>فیزیوتراپی، پرستاری، ویزیت پزشک، آزمایش، اجارهٔ تجهیزات؛ بستهٔ «NRI» برای مهاجران</td><td>اشتراک + به‌ازای ویزیت + اجاره</td><td>بزرگ‌ترین در هند؛ ~۱۱۴M دلار جذب کرده</td></tr>
+<tr><td>Nightingales / Care24 / HCAH</td><td>هند</td><td>ارائه‌دهندگان بالینی مدیریت‌شده</td><td>برنامه‌های مزمن/تخصصی؛ صورت‌حساب بیمه‌ایِ بدون پرداخت نقدی (HCAH، ۴۰+ بیمه‌گر)</td><td>اشتراک + به‌ازای ویزیت + B2B</td><td>بازار به‌سرعت در حال تجمیع (هر دو خریداری شدند)</td></tr>
+<tr><td>Manzil / NMC Homecare</td><td>امارات</td><td>سلامت خانگی بالینی دارای مجوز</td><td>اعتباربخشی JCI؛ یکپارچه با بیمارستان؛ تزریق وریدی، فیزیوتراپی، مادر و نوزاد</td><td>حق‌الزحمه‌محور، صورت‌حساب بیمه‌ای</td><td>اعتبار بالینی درجه‌یک</td></tr>
+<tr><td>Veteranpoolen</td><td>سوئد</td><td>تأمین نیرو با استخدام بازنشستگان</td><td>قیمت‌گذاری متناسب با کسر مالیاتی RUT (۵۰٪) سوئد</td><td>کارمزد یارانه‌ای RUT + فرنچایز</td><td>تأمین نیروی منحصربه‌فرد (بازنشستگان فعال)</td></tr>
+<tr><td>Bakıcıburada</td><td>ترکیه</td><td>آگهی‌های طبقه‌بندی‌شدهٔ مراقب</td><td>تأیید هویت + سوءپیشینه؛ کشف روی نقشه</td><td>کارمزد آگهی/اشتراک</td><td>بدون سرمایهٔ ریسک‌پذیر؛ <strong>نزدیک‌ترین آنالوگ به بازار واقع‌بینانهٔ مرحلهٔ اولیهٔ ایران</strong></td></tr>
+</tbody>
+</table>
+</div>
+
+<h4>مهم‌ترین سیگنال‌های منطقه‌ای</h4>
+<ul>
+  <li><strong>هند نزدیک‌ترین آنالوگ است</strong> (جمعیت زیاد، پوشش عمومیِ کم، پرداخت از جیب خانواده). نکتهٔ گویا: <strong>هیچ مارکت‌پلیس خالصِ خانواده‌به‌مراقب در آنجا غالب نیست</strong> — همهٔ رهبران مدلِ بالینیِ مدیریت‌شده/استخدامی دارند، چون کشور فاقد آموزش ساختاریافتهٔ پیراپزشکی است، پس <strong>احراز و کنترل کیفیت خودِ محصول است.</strong></li>
+  <li>در <strong>آلمان</strong> تنها تلاش برای تطبیق مراقبِ مدیریت‌شده (Careship) <strong>ورشکست شد</strong>؛ بازماندگان مدل‌های کم‌سرمایهٔ جذب‌سرنخ/آگهی + کالای مصرفیِ یارانه‌ایِ بیمه‌اند.</li>
+  <li><strong>ترکیه</strong> عمدتاً آگهی‌های طبقه‌بندی‌شدهٔ خوداتکا و آژانس‌های کوچک است — تصویری واقع‌بینانه از آیندهٔ نزدیک ایران.</li>
+</ul>
+
+<h4>پنج ایدهٔ قابل‌انتقال برای یک بنیان‌گذار ایرانی</h4>
+<ol>
+  <li><strong>یک «اوبر برای پرستارها»ی خالص از پیمانکاران مستقل نسازید.</strong> روشن‌ترین شکست‌ها (ورشکستگی Careship؛ بازطبقه‌بندی نظافتچیان گیگِ Helpling به‌عنوان کارمند؛ رسوایی‌های کیفیت Care.com) همگی مدل‌های گیگ خالص‌اند. برای مراقبت، نقطهٔ بهینهٔ اثبات‌شده یک <strong>مارکت‌پلیس گزینش‌شده + احراز انسانی</strong> است (مدل Homage: الگوریتم نامزدها را رو می‌کند، تیم شما تطبیق نهایی را انجام می‌دهد و مالک احراز/آموزش است).</li>
+  <li><strong>احراز و آموزش را به محصول اصلی تبدیل کنید، نه افزونهٔ پولی.</strong> در ایران، <strong>زیرساخت اعتماد، کلِ ارزش پیشنهادی است</strong> — آن را پیش‌فرض بسته‌بندی کنید؛ مثل Care.com آپ‌سل نکنید.</li>
+  <li><strong>زود به‌سمت پرداخت‌کنندگان نهادی B2B حرکت کنید.</strong> ارزشمندترین خروجی‌ها از طریق نهادها کسب درآمد می‌کنند: Cera (NHS)، Papa (Medicare Advantage)، HCAH (بیمه‌گرها). آنالوگ‌های ایران: <strong>سازمان تأمین اجتماعی، بیمهٔ سلامت، ارجاع‌های ترخیص بیمارستانی، و مزایای کارکنان شرکت‌ها.</strong> ترخیص پس از جراحی/سکته یک کانال جذب با نیت بالاست.</li>
+  <li><strong>دو موتور درآمدی را روی هم سوار کنید و دنبال یک قلابِ یارانه باشید.</strong> (الف) کارمزد/حاشیهٔ ساعتی، به‌علاوهٔ (ب) اشتراک/جذب‌سرنخ. جعبهٔ کالای مصرفیِ بیمه‌ایِ آلمان و کسر مالیاتی ۵۰٪ سوئد قدرت <strong>اتصال به یک یارانهٔ موجود</strong> را نشان می‌دهند — بررسی کنید آیا بیمه‌گر، خیریه یا موقوفهٔ سالمندان ایرانی می‌تواند ویزیت‌ها را یارانه دهد.</li>
+  <li><strong>یک ردهٔ سبک‌ترِ «همراهی / کمک در امور روزمره» را جداگانه محصول‌سازی کنید.</strong> Papa کسب‌وکاری در مسیر یونیکورن را نه روی پرستاری ماهر بلکه روی همراهی سالمندانِ منزوی ساخت — مهارت کمتر، تأمین نیروی آسان‌تر، بازار وسیع‌تر. با توجه به دیاسپورای بزرگ ایران، زاویهٔ <strong>«فرزندان دور که هزینهٔ مراقبت از والدینشان در وطن را می‌پردازند»</strong> مستقیماً مرتبط است.</li>
+</ol>
+
+<blockquote>
+<p><strong>کم‌ریسک‌ترین نقطهٔ ورود:</strong> رویکرد «SaaS برای ارائه‌دهندگان» شرکت Birdie — فروش نرم‌افزار زمان‌بندی/انطباق/داشبورد خانواده <em>به</em> آژانس‌های موجود مراقبت در منزل ایران به‌جای رقابت مستقیم — اگر صدور مجوز/طبقه‌بندی نیروی کار در ابتدا مانعی جدی شد، ارزش نگه‌داشتن در آستین را دارد.</p>
+</blockquote>
+
+<hr>
+
+<h2 id="risks">۲. مشکلات و ریسک‌ها</h2>
+
+<p>این حوزه دو ویژگی غیرعادی و خطرناک را با هم دارد: خریداران <strong>افراد آسیب‌پذیرند</strong> (سالمند، پس از جراحی، نوزاد، بیمار مزمن) و خدمت <strong>بدون نظارت، داخل خانهٔ خصوصی</strong> انجام می‌شود. این ترکیب هر ریسک معمول مارکت‌پلیس را تشدید می‌کند و ابعاد مرگ‌وزندگی به آن می‌افزاید.</p>
+
+<blockquote class="warn"><p><strong>مهم‌ترین درس استراتژیک:</strong> پلتفرمی که ایمنی را تبلیغ کند ولی احراز واقعی را به خانواده‌ها واگذار کند، سرانجام با فاجعهٔ نظارتی، حقوقی و اعتباری روبه‌رو خواهد شد.</p></blockquote>
+
+<h3>۲.۱ شکست‌های اعتماد و ایمنی</h3>
+<p><strong>ریسک:</strong> اتصال غریبه‌ها به افراد آسیب‌پذیر بدون احراز دقیقِ <em>تحت‌مالکیت پلتفرم</em>، راه را برای سرقت، سوءاستفاده، کلاهبرداری و آسیب مرگبار باز می‌کند — و افکار عمومی <em>پلتفرم</em> را مقصر می‌داند.</p>
+<p><strong>نمونه‌های واقعی:</strong></p>
+<ul>
+  <li><strong>Care.com / تحقیق وال‌استریت‌ژورنال (۲۰۱۹):</strong> طی ~۶ سال، ۹ مراقب فهرست‌شده در Care.com که سابقهٔ پلیسی داشتند، بعداً به جرایمی متهم شدند که هنگام مراقبت از کودک یا سالمند رخ داد — از جمله سرقت، کودک‌آزاری، تجاوز جنسی و قتل. (<a href="https://www.thedailybeast.com/wsj-kids-assaulted-died-in-hands-of-carecom-caregivers/">Daily Beast/WSJ</a>)</li>
+  <li><strong>پاک‌سازی انبوه آگهی‌ها:</strong> Care.com حدود ۴۶٬۵۹۴ آگهی مهدکودک (~۴۵٪ آن پایگاه داده) را پس از کشف جعلی/ناموجود بودن حذف کرد. (<a href="https://www.engadget.com/2019-03-31-care-com-pulls-47000-daycare-listings.html">Engadget</a>)</li>
+  <li><strong>«پرستار قلابی» (Shannon Womack، ۲۰۲۵):</strong> ادعا می‌شود با ۲۰+ نام مستعار و ۷ شمارهٔ تأمین اجتماعی، با سرقت مدارک چهار پرستار واقعی، با ارائهٔ مدارک جعلی از طریق آژانس‌های تأمین نیرو در ۹+ مرکز کار کرده. متهم به ۴۳ فقره اتهام، از جمله سرقت دارو از سالمندان. (<a href="https://nurse.org/news/fake-nurse-arrested-shannon-womack-nursing-fraud/">Nurse.org</a>) — <em>درس کلیدی: حتی آژانس‌هایی که فکر می‌کردند احراز می‌کنند، با هویت سرقتی + مدارک جعلی شکست خوردند.</em></li>
+</ul>
+<p><strong>راهکارهای کاهش ریسک:</strong></p>
+<ul>
+  <li><strong>مالک احراز خودتان باشید؛ هرگز به خانواده‌ها واگذار نکنید.</strong> احراز هویت + سوءپیشینه + اعتبارسنجی مجوز را به‌عنوان یک دروازهٔ اجباریِ تحت‌مالکیت پلتفرم پیش از قابل‌رزرو شدن هر پرستار قرار دهید.</li>
+  <li><strong>اعتبار را در منبع رسمی راستی‌آزمایی کنید</strong>، نه با فایل آپلودی (که دقیقاً همان چیزی است که جعل می‌شود). در ایران: سامانهٔ سازمان نظام پرستاری و پروانهٔ صلاحیت حرفه‌ای وزارت بهداشت (بخش ۳).</li>
+  <li><strong>هر پروفایل را به کد ملی + سلفی زنده گره بزنید</strong> تا الگوی نام‌های مستعار/هویت سرقتی خنثی شود.</li>
+  <li><strong>به‌صورت دوره‌ای بازبینی کنید</strong> (انقضای مجوز، تعلیق، سوابق جدید).</li>
+</ul>
+
+<h3>۲.۲ مسئولیت حقوقی و قرار گرفتن در معرض دعوا</h3>
+<p><strong>ریسک:</strong> سه نوع قرارگیری در معرض ریسک روی هم انباشته می‌شوند — <strong>(الف) طبقه‌بندی نادرست نیروی کار</strong> (نامیدن پرستارها به‌عنوان «پیمانکار» در حالی که قانون آن‌ها را کارمند می‌داند)، <strong>(ب) مسئولیت نیابتی / استخدام سهل‌انگارانه</strong>، و <strong>(ج) شکاف‌های بیمه‌ای</strong>. دفاعِ «ما فقط یک پلتفرم فناوری بی‌طرفیم» در حال فرسایش است.</p>
+<p><strong>نمونه‌های واقعی:</strong></p>
+<ul>
+  <li><strong>حکم ۱۰ میلیون دلاری کالیفرنیا علیه TLC Home Care</strong> بابت طبقه‌بندی نادرست نیروهای منزل به‌عنوان پیمانکار (۲۰۲۳). (<a href="https://www.hrmorning.com/news/worker-misclassification-tlc-home-care/">HRMorning</a>)</li>
+  <li>دادگاه‌های فدرال مکرراً مراقبینِ منزل را <strong>کارمند، نه پیمانکار</strong> تشخیص می‌دهند — <em>هرچه مراقبت را برای کیفیت بیشتر استانداردسازی و نظارت کنید، بیشتر شبیه کارفرما به‌نظر می‌رسید.</em> (<a href="https://ogletree.com/insights-resources/blog-posts/federal-court-finds-in-home-caregivers-were-employees-not-independent-contractors-under-economic-realities-control-test/">Ogletree Deakins</a>)</li>
+</ul>
+<p><strong>راهکارهای کاهش ریسک:</strong></p>
+<ul>
+  <li><strong>مدل را آگاهانه انتخاب کنید:</strong> یا یک مارکت‌پلیس بی‌طرف واقعی (کنترل حداقلی؛ خانواده کارفرماست) یا یک مدل کامل آژانس/کارفرما (حقوق، نظارت، بیمه). <strong>میانهٔ خطرناک — کنترل زیاد برای «کیفیت» اما طبقه‌بندی پیمانکار برای «هزینه» — دقیقاً همان چیزی است که احکام طبقه‌بندی نادرست را فعال می‌کند.</strong></li>
+  <li><strong>[تأییدنشده — با وکیل محلی بررسی شود]</strong> تعهدات قانون کار و تأمین اجتماعی ایران به رابطهٔ استخدامی تعلق می‌گیرند؛ پیش از راه‌اندازی، طبقه‌بندی را درست انجام دهید. (شکاف قانون کار برای پرستاران منزل در بخش ۴.۵ دوسویه است: هزینهٔ الزامیِ کمتر، اما وضعیت حل‌نشده.)</li>
+  <li><strong>بیمهٔ مسئولیت عمومی + حرفه‌ای در سطح پلتفرم داشته باشید</strong>، و از پرستارها هم بخواهید بیمهٔ خود را داشته باشند.</li>
+  <li><strong>هر مرحلهٔ احراز را مستند کنید</strong> — هم پیشگیری است و هم دفاع حقوقی شما در برابر دعاوی استخدام سهل‌انگارانه.</li>
+</ul>
+
+<h3>۲.۳ مشکلات عملیاتی و کنترل کیفیت</h3>
+<p><strong>ریسک:</strong> جابه‌جایی شدید مراقب، غیبت‌هایی که بیمار آسیب‌پذیر را بی‌سرپرست می‌گذارند، تنوع گستردهٔ کیفیت، نظارت از راه دور تقریباً غیرممکن، و <strong>حذف واسطه (disintermediation)</strong> (جفت‌شدن خانواده + پرستار خارج از پلتفرم برای فرار از کارمزد).</p>
+<p><strong>داده‌های واقعی:</strong></p>
+<ul>
+  <li>جابه‌جایی مراقب در ۲۰۲۴ به ~۷۹٪ رسید، با ~۷۰٪ ترک کار طی ۱۰۰ روز اول؛ هر خروج ۲٬۶۰۰ تا ۵٬۰۰۰ دلار هزینه دارد و مشتری اغلب همراه مراقب می‌رود. (<a href="https://shiftcare.com/us/blog/caregiver-retention-in-2026-what-the-data-tells-us-about-turnover">ShiftCare</a>)</li>
+  <li><strong>حذف واسطه، حالت شکستِ قابل‌پیش‌بینی</strong> برای خدمات تکراری و مبتنی بر رابطه است. تاکتیک‌های تنبیهی معمولاً نتیجهٔ معکوس می‌دهند. (<a href="https://www.sharetribe.com/academy/how-to-discourage-people-from-going-around-your-payment-system/">Sharetribe</a>)</li>
+</ul>
+<p><strong>راهکارهای کاهش ریسک:</strong></p>
+<ul>
+  <li><strong>تأیید الکترونیکی ویزیت (EVV):</strong> ورود/خروج با GPS و مهر زمانی، با هشدار خودکار ویزیت ازدست‌رفته، تا غیبت‌ها فوری اعزام جایگزین را فعال کنند.</li>
+  <li><strong>تضمین پوشش/جایگزین:</strong> یک ذخیرهٔ پرستار آماده و وعدهٔ پرکردن سریع غیبت — دلیل اصلی استفاده از شما به‌جای استخدام خصوصی.</li>
+  <li><strong>با ارزش‌آفرینیِ ماندگار بر حذف واسطه غلبه کنید، نه با قفل‌کردن:</strong> زمان‌بندی/پرداخت یکپارچه، تضمین جایگزین، بیمه‌ای که فقط روی رزروهای داخل پلتفرم اعمال می‌شود، و حمایت در اختلافات که با خروج از پلتفرم از بین می‌رود.</li>
+  <li><strong>تطبیق مبتنی بر تداوم:</strong> یک پرستار اصلی + جایگزین مشخص برای هر بیمار؛ تداوم را به‌عنوان KPI ردیابی کنید.</li>
+</ul>
+
+<h3>۲.۴ ریسک‌های پرداخت و کلاهبرداری</h3>
+<p><strong>ریسک:</strong> پرداخت خارج از پلتفرم، نظرات جعلی، کلاهبرداری هویتی، جعل مدرک، و <strong>سوءاستفادهٔ مالی از سالمند.</strong></p>
+<p><strong>داده‌های واقعی:</strong></p>
+<ul>
+  <li>کلاهبرداری در مارکت‌پلیس‌های گیگ حدود ۲ برابر سایر جاهاست؛ یک گزارش ۲۰۲۵ افزایش ۲۱٪ سالانه را گزارش کرد که >۹۰٪ آن جعل هویت بود. (<a href="https://securityboulevard.com/2024/05/when-the-gig-is-fraud-building-trust-for-online-marketplaces-with-identity-verification/">Security Boulevard</a>)</li>
+  <li><strong>سوءاستفادهٔ مالی از سالمند:</strong> بررسی CFPB نشان داد جایی که قربانی مرتکب را می‌شناخت، ۱ نفر از هر ۹ نفر یک مراقب غیرخانوادگی بود، با میانگین خسارت ۵۷٬۸۰۰ دلار. (<a href="https://www.aarp.org/money/scams-fraud/financial-abuse-home-care-aide/">AARP</a>)</li>
+  <li><strong>جریمه‌های Care.com:</strong> ۲۰۲۰ — ۱M دلار Marin County DA (ادعای دروغین جست‌وجوی رجیستری متخلفان جنسی؛ تمدید خودکار نادرست)؛ ۲۰۲۴ — ۸٫۵M دلار FTC (تورم تعداد مشاغل موجود + الگوی فریبندهٔ لغو اشتراک). (<a href="https://www.cnbc.com/2024/08/26/carecom-reaches-8point5-million-us-ftc-settlement-over-job-listings-renewals-.html">CNBC</a>)</li>
+</ul>
+<p><strong>راهکارهای کاهش ریسک:</strong></p>
+<ul>
+  <li><strong>احراز هویت قوی هنگام ثبت‌نام</strong> (گره به کد ملی + تشخیص زنده‌بودن) برای هم پرستار و هم خانوادهٔ پرداخت‌کننده.</li>
+  <li><strong>نظرات را به رزروهای کامل‌شده و احرازشده داخل پلتفرم گره بزنید.</strong></li>
+  <li><strong>پرداخت امانی (escrow) داخل پلتفرم با حل اختلاف</strong> — هم کلاهبرداری را کم می‌کند و هم قوی‌ترین اهرم ضدِ حذف واسطه است.</li>
+  <li><strong>از دارایی مالی مشتریان محافظت کنید</strong> (دسترسی فقط‌خواندنی، مراقب تغییرات ناگهانی وکالت/وصیت)؛ ضمانت پرستار در برابر سرقت را در نظر بگیرید.</li>
+  <li><strong>هرگز تضمین یا بررسی‌ای که انجام نمی‌دهید را تبلیغ نکنید، و لغو اشتراک را واقعاً آسان کنید.</strong></li>
+</ul>
+
+<h3>۲.۵ پویایی‌های اعتماد ویژهٔ مراقبت از افراد آسیب‌پذیر در منزل</h3>
+<p>خدمت به‌تنهایی، بدون مشاهده، داخل خانه و به افرادی ارائه می‌شود که اغلب نمی‌توانند به‌طور قابل‌اتکا گزارش دهند چه رخ داده (نوزاد؛ بیماران دمانس، پس از بیهوشی، دارای اختلال شناختی). عدم تقارن اطلاعات شدید است و یک حادثهٔ منفرد می‌تواند یک برند شکننده را نابود کند.</p>
+<p><strong>راهکارها:</strong> جبران عدم‌مشاهده با <strong>نظارت ساختاریافته</strong> — EVV، تماس‌های نظارتیِ دوره‌ای توسط پرستار ارشد، گزارش‌های مراقبتیِ قابل‌رؤیت برای خانواده، دوربین‌های داخل منزل با رضایت در فضاهای مشترک؛ یک <strong>حلقهٔ بازخورد دوطرفه</strong> که بیمار تنها منبع آن نباشد؛ <strong>پروتکل‌های واکنش سریع به حادثه</strong> با تعلیق فوری در صورت شکایت معتبر؛ و <strong>تطبیق صلاحیت با حدّت بیماری</strong> (موارد پرحدّت پس از جراحی/تنفسی فقط به پرستارهای احرازشده).</p>
+
+<hr>
+
+<h2 id="verify">۳. احراز هویت و اعتبارسنجی صلاحیت پرستار</h2>
+
+<p><strong>پرسش «آیا این پرستار واقعاً همان است که می‌گوید و واقعاً دارای مجوز است؟» به دو بررسی تقسیم می‌شود که باید مراحل جداگانهٔ خط لوله باشند:</strong></p>
+<ul>
+  <li><strong>بررسی مجوز</strong> — آیا پرستار رسمی است؟ (سامانهٔ ثبت حرفه‌ای)</li>
+  <li><strong>بررسی هویت + پیشینه</strong> — آیا همان است که ادعا می‌کند، بدون سابقهٔ ردکننده؟ (KYC + سوءپیشینه)</li>
+</ul>
+
+<h3>۳.۱ مدل‌های مرجع جهانی (بهترین رویه‌ها برای الگوبرداری)</h3>
+<ul>
+  <li><strong>آمریکا — Nursys / e-Notify (استاندارد طلایی):</strong> تنها پایگاه دادهٔ ملی مجوز، تغذیه‌شده توسط هیئت‌های ایالتی پرستاری؛ e-Notify تغییرات وضعیت مجوز/انضباطی را از طریق یک API <em>پوش</em> می‌کند. <em>درس: نظارت پیوسته، نه احراز یک‌باره.</em></li>
+  <li><strong>بریتانیا — سامانهٔ NMC + DBS:</strong> سامانهٔ آنلاین NMC (رایگان، به‌روزرسانی روزانه) به «آیا دارای مجوز است؟» پاسخ می‌دهد؛ بررسی جداگانهٔ سوءپیشینهٔ DBS به «آیا ایمن است؟». <em>درس: دو بررسی را مجزا نگه دارید.</em></li>
+  <li><strong>شرکت‌های بررسی پیشینه (Checkr، Sterling):</strong> API-محور، ساخته‌شده برای جاسازی در جریان‌های گیگ/مارکت‌پلیس؛ یک بررسی شامل سابقهٔ کیفری، اعتبارسنجی مجوز، تحریم‌های درمانی، رجیستری سوءاستفاده، اشتغال/تحصیلات، و بازبینی مجدد.</li>
+</ul>
+<p><strong>یک خط لولهٔ مستحکم = رضایت ← احراز هویت ← اعتبارسنجی مجوز (منبع اصلی) ← بررسی سوءپیشینه + رجیستری سوءاستفاده ← اشتغال/تحصیلات ← نظارت پیوسته.</strong></p>
+
+<h3>۳.۲ ابزارهای مخصوص ایران (بخش عملیاتی)</h3>
+<p>ایران یک پشتهٔ قابل‌استفاده دارد، اما <strong>میان نهادهای ناظر پراکنده است</strong>، و حساس‌ترین بررسی (سوءپیشینه) <strong>محدود به رضایت فرد</strong> است، نه قابل‌استخراج آزاد توسط یک شرکت.</p>
+
+<h4>الف) مجوز حرفه‌ای — «آیا این یک پرستار واقعی است؟» (دو مرجع، هر دو را بررسی کنید)</h4>
+<ul>
+  <li><strong>پروانهٔ صلاحیت حرفه‌ای وزارت بهداشت</strong> در <code>Rn.behdasht.gov.ir</code> — اعتبارِ جدیدتر و <strong>معتبرتر</strong>. صدور آن از پیش وضعیت علمی، اخلاقی، سلامت، و سوءپیشینهٔ پرستار را بررسی می‌کند، و وزارت بهداشت اعلام کرده این پروانه <strong>حتی برای پرستاری خصوصی در منزل لازم است.</strong> <strong>[مهم‌ترین اعتبار برای مطالبه — چون شامل بررسی سوءپیشینه است]</strong> (<a href="https://behdasht.gov.ir/">behdasht.gov.ir</a>)</li>
+  <li><strong>شمارهٔ نظام پرستاریِ سازمان نظام پرستاری</strong> از طریق <code>ino.ir</code> / <code>membership.ino1.ir</code>. طبق گزارش‌ها امکان استعلام شمارهٔ عضویت توسط شخص ثالث وجود دارد؛ به‌عنوان <strong>بررسی متقاطع</strong> استفاده کنید. (<a href="https://www.heyvagroup.com/shownews/11343/">heyvagroup</a>)</li>
+  <li><strong>برای هیچ‌کدام یک API عمومی B2B یافت نشد</strong> — استفادهٔ واقع‌بینانهٔ امروزی <strong>مطالبهٔ آپلود + راستی‌آزمایی دستی</strong> است. <strong>[نبود API «یافت نشد» است، نه قطعاً تأییدشده]</strong></li>
+</ul>
+
+<h4>ب) احراز هویت — لایهٔ آسان (APIهای آماده وجود دارند)</h4>
+<p>یک بازار رقابتی از فروشندگان e-KYC ایرانی APIهای آماده می‌فروشند — <strong>این را بخرید، نسازید:</strong></p>
+<ul>
+  <li><strong>شاهکار:</strong> سرویس دولتی تطبیق شمارهٔ موبایل ↔ کد ملی؛ توسط سازمان تنظیم مقررات (CRA). نتیجه در <۱ ثانیه. <strong>دسترسی محدود است</strong> (تأیید + قرارداد + اتصال غیرمستقیم از طریق پلتفرم «سرو»)، پس <strong>آن را از طریق یک فروشنده مصرف کنید</strong>، نه مستقیم. (<a href="https://fa.wikipedia.org/wiki/%D8%B3%D8%A7%D9%85%D8%A7%D9%86%D9%87_%D8%B4%D8%A7%D9%87%DA%A9%D8%A7%D8%B1">ویکی‌پدیا</a>)</li>
+  <li><strong>صحت‌سنجی کد ملی:</strong> نام + نام خانوادگی + کد ملی ← تطبیق.</li>
+  <li><strong>تطبیق چهره/زنده‌بودن با عکس کارت ملی یا ثبت احوال:</strong> ارائه‌شده توسط فینوتک، یوآیدی، جیبیت، فراشناسا، ونیفای، کاوشک و دیگران — زنده‌بودن + تطبیق چهره + OCR. (<a href="https://asretarakonesh.ir/index.php/2024/01/02/%D9%86%DA%AF%D8%A7%D9%87%DB%8C-%D8%A8%D9%87-%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%DB%B8-%D8%B4%D8%B1%DA%A9%D8%AA-%D8%A7%DB%8C%D8%B1%D8%A7%D9%86%DB%8C-%D9%81%D8%B9%D8%A7%D9%84-%D8%AF%D8%B1-%D8%AD%D9%88%D8%B2/">عصر تراکنش: ۸ شرکت ایرانی KYC</a>)</li>
+  <li>این فروشندگان اتصالات بالادستیِ محدودشده توسط ناظر را برای شما مدیریت می‌کنند؛ یک شرکت ثبت‌شده ثبت‌نام و APIهای REST را مصرف می‌کند.</li>
+</ul>
+
+<h4>ج) سوءپیشینه — گواهی عدم سوء پیشینه (محدود به رضایت، بدون API شرکتی)</h4>
+<ul>
+  <li>گواهی رسمی «عدم سوءپیشینه»، که توسط خودِ فرد به‌صورت آنلاین از طریق <code>adliran.ir</code> با رمز شخصی ثنا یا حضوری از طریق پلیس +۱۰ دریافت می‌شود. (<a href="https://www.heyvalaw.com/web/articles/view/1865/">heyvalaw</a>)</li>
+  <li><strong>یک پلتفرم نمی‌تواند آن را استخراج کند</strong> — هیچ API شخص‌ثالث/کارفرما وجود ندارد؛ صدور به رمز شخصی ثنای فرد گره خورده است. <strong>طراحی واقع‌بینانه: از پرستار بخواهید گواهی خود را دریافت و آپلود کند، سپس دوره‌ای دوباره درخواست شود</strong> — و توجه کنید این بررسی از پیش در پروانهٔ صلاحیت حرفه‌ای گنجانده شده.</li>
+</ul>
+
+<h4>د) ریل‌های پشتیبان</h4>
+<ul>
+  <li><strong>ثنا:</strong> سامانهٔ هویت/ابلاغ الکترونیک قوهٔ قضائیه — عمدتاً به‌عنوان دروازهٔ دریافت گواهی عدم سوء پیشینه مرتبط است.</li>
+  <li><strong>سجام:</strong> KYC بازار سرمایه — عمدتاً نامرتبط، جز به‌عنوان گواهی بر اینکه ریل‌های قویِ e-KYC غیرحضوری در ایران وجود دارند.</li>
+</ul>
+
+<h3>۳.۳ خط لولهٔ پیشنهادیِ احراز برای پلتفرم شما</h3>
+<div class="tablewrap">
+<table>
+<thead>
+<tr><th>مرحله</th><th>هدف</th><th>ابزار ایران / روش</th><th>برنامه‌پذیر؟</th></tr>
+</thead>
+<tbody>
+<tr><td>۰. رضایت</td><td>مبنای قانونی برای احراز + ذخیرهٔ داده</td><td>رضایت صریح داخل اپ هنگام ثبت‌نام</td><td>—</td></tr>
+<tr><td>۱. هویت</td><td>تطبیق فرد ↔ کد ملی ↔ موبایل ↔ چهره</td><td>شاهکار + صحت‌سنجی کد ملی + تطبیق زنده‌بودن ویدیو/عکس با کارت ملی، از طریق یک فروشندهٔ KYC</td><td><span class="pill">بله — API آماده</span></td></tr>
+<tr><td>۲. مجوز</td><td>اعتبارسنجی صلاحیت پرستاری در منبع</td><td>پروانهٔ صلاحیت حرفه‌ای وزارت بهداشت (اصلی) + شمارهٔ نظام پرستاری (بررسی متقاطع)</td><td>دستی (API عمومی یافت نشد)</td></tr>
+<tr><td>۳. سوءپیشینه</td><td>بدون سابقهٔ ردکننده</td><td>عدم سوء پیشینه — پرستار خودش از adliran.ir/ثنا درخواست و آپلود می‌کند</td><td>بدون API شرکتی</td></tr>
+<tr><td>۴. نظارت پیوسته</td><td>کشف لغو/انقضا</td><td>راستی‌آزمایی دوره‌ای اعتبار مجوز + درخواست مجدد عدم سوء پیشینه؛ اجرای مجدد شاهکار هنگام تغییر موبایل</td><td>نیمه‌دستی</td></tr>
+</tbody>
+</table>
+</div>
+<p><strong>قواعد عملی:</strong> (۱) <strong>احراز هویت را بخرید</strong> از طریق یک ارائه‌دهندهٔ KYC. (۲) <strong>بررسی مجوز را روی پروانهٔ صلاحیت حرفه‌ای لنگر کنید</strong> (الزامی دولتی و شامل بررسی سوءپیشینه). (۳) <strong>گواهی سوءپیشینه را خوداظهاری بدانید.</strong> (۴) <strong>نظارت پیوسته بسازید</strong>، نه یک‌باره. (۵) <strong>مراقب حفاظت داده باشید</strong> — مسیریابی از طریق واسط KYC دارای مجوز شما را منطبق نگه می‌دارد.</p>
+
+<hr>
+
+<h2 id="legal">۴. چارچوب حقوقی در ایران</h2>
+
+<blockquote class="warn"><p><strong>پاسخ کوتاه: هیچ قانونی علیه این ایده وجود ندارد — اما این یک فعالیت درمانی نظارت‌شده است که نیازمند مجوز وزارت بهداشت است. فعالیتِ بدون پروانه همان چیزی است که غیرقانونی است، و جریمه‌ها تا لغو دائم و ارجاع قضایی تشدید می‌شوند.</strong> <span class="ok">✅ تأییدشده</span></p></blockquote>
+
+<h3>۴.۱ چارچوب حاکم <span class="ok">✅ تأییدشده</span></h3>
+<ul>
+  <li>صدور مجوز از طریق <strong>معاونت درمان وزارت بهداشت</strong>، پس از تصویب <strong>کمیسیون قانونی تشخیص امور پزشکی (موضوع مادهٔ ۲۰)</strong>، تحت <strong>قانون امور پزشکی مصوب ۱۳۳۴ (اصلاحیهٔ ۱۳۶۷)</strong> و <strong>آیین‌نامهٔ مراقبت در منزل مصوب ۱۳۷۸/۷/۱۷</strong> (۲۱ ماده، ۶ تبصره) جریان دارد.</li>
+  <li><strong>به هر مرکز یک پروانهٔ تأسیس و یک پروانهٔ مسئول فنی اعطا می‌شود.</strong></li>
+  <li>منابع: <a href="https://arakmu.ac.ir/vct/fa/regulation/1063/">arakmu.ac.ir</a> · <a href="https://www.mcls.gov.ir/fa/law/61">mcls.gov.ir/fa/law/61</a> · <a href="https://qavanin.ir/Law/TreeText/83385">qavanin.ir (مادهٔ ۲۰)</a></li>
+</ul>
+
+<h3>۴.۲ دو مسیر — مسیر پرستاری را انتخاب کنید <span class="ok">✅ تأییدشده</span></h3>
+<div class="tablewrap">
+<table>
+<thead>
+<tr><th></th><th>مرکز خدمات پرستاری در منزل (گزینهٔ شما)</th><th>مرکز خدمات و مراقبت‌های بالینی در منزل</th></tr>
+</thead>
+<tbody>
+<tr><td>نام</td><td>مرکز مشاوره و ارائه مراقبت‌های پرستاری در منزل</td><td>مرکز خدمات و مراقبت‌های بالینی در منزل</td></tr>
+<tr><td>تحت نظر</td><td>سازمان نظام پرستاری</td><td>مستقیماً وزارت بهداشت</td></tr>
+<tr><td>چه کسی مؤسس/مسئول فنی شود</td><td><strong>یک پرستار</strong> — کارشناسی پرستاری + ۵ سال سابقهٔ بالینی (می‌تواند هم مؤسس و هم مسئول فنی باشد)</td><td><strong>هم مؤسس و هم مسئول فنی باید پزشک باشند</strong></td></tr>
+<tr><td>تناسب با ایدهٔ شما</td><td><span class="ok">✅ پرستاری در منزل: سالمند / پس از جراحی / نوزاد / مزمن</span></td><td>فقط اگر شریک پزشک داشته باشید</td></tr>
+</tbody>
+</table>
+</div>
+<blockquote class="warn"><p>⚠️ ادعای «مؤسس/مسئول فنی برای همهٔ مراقبت‌های منزل باید پزشک باشند» <strong>رد شد</strong> — این قاعده فقط برای مسیر بالینی است. مسیر خدمات پرستاری یک پرستار واجد شرایط را مجاز می‌داند. منابع: <a href="https://www.mcls.gov.ir/fa/law/61">mcls.gov.ir/fa/law/61</a> · <a href="https://irannurse.ir">irannurse.ir</a> · <a href="https://vct.iums.ac.ir">vct.iums.ac.ir</a></p></blockquote>
+
+<h3>۴.۳ نحوهٔ عملکرد الزامیِ مدل <span class="ok">✅ تأییدشده</span></h3>
+<ul>
+  <li><strong>مراقبت باید در منزل بیمار ارائه شود؛ انجام خدمات (تزریقات، پانسمان، واکسیناسیون، ویزیت) در محل ستادی مرکز ممنوع است.</strong> بنابراین مرکز دارای مجوز یک نهاد اعزام/هماهنگی است، نه درمانگاه مراجعه‌حضوری — که از نظر ساختاری با یک پلتفرم تطبیق/اعزام سازگار است.</li>
+  <li>پس از موافقت اصولی، مؤسس حداکثر یک سال فرصت دارد مرکز را برای بازدید نهایی آماده کند.</li>
+</ul>
+
+<h3>۴.۴ الزام تجارت آنلاین — نماد اعتماد الکترونیکی (e-namad) <span class="ok">✅ تأییدشده</span></h3>
+<ul>
+  <li>یک <strong>نماد اعتماد الکترونیکی</strong> برای سایت ایرانی‌ای که خدمات/فروش آنلاین ارائه می‌دهد لازم است. تنها توسط <strong>مرکز توسعه تجارت الکترونیکی</strong> زیر نظر وزارت صنعت، معدن و تجارت صادر می‌شود.</li>
+  <li>برای یک سایت درآمدزا عملاً الزامی است چون قواعد PSP/شاپرک برای دریافت درگاه پرداخت اینترنتی (IPG) نیاز به نماد دارند. منابع: <a href="https://ecommerce.gov.ir">ecommerce.gov.ir</a> · <a href="https://www.netafraz.com/blog/getting-enamad-complete-guide/">راهنمای نت‌افراز</a></li>
+</ul>
+
+<h3>۴.۵ شکاف قانون کار و به‌رسمیت‌شناختن بازار (⚠️ اطمینان متوسط)</h3>
+<ul>
+  <li>پرستاران منزل خارج از شمول رژیم «مشاغل سخت و زیان‌آور»اند، چون قانون به‌طور خاص از کارکنان شرکت‌های مراقبت در منزل نام نبرده. تا سال ۱۳۹۸، ~۷۰۰ شرکت خدمات درمانی در منزل ثبت شده بودند (هدف ~۱٬۰۰۰)؛ این شکاف طبق گزارش‌ها تا ۱۴۰۲–۱۴۰۴ بدون قانونگذاری حل‌کننده ادامه داشت. منبع: <a href="https://www.ilna.ir/%D8%A8%D8%AE%D8%B4-%DA%A9%D8%A7%D8%B1%DA%AF%D8%B1%DB%8C-9/797233">مصاحبهٔ ایلنا با عضو شورای‌عالی نظام پرستاری</a>. <em>(منبع واحد ۱۳۹۸؛ ارقام کفِ تاریخی‌اند.)</em></li>
+</ul>
+
+<h3>۴.۶ سایر تعهداتی که باید برنامه‌ریزی کنید</h3>
+<ul>
+  <li><strong>مالیات و ثبت شرکت</strong> (ثبت شرکت، پروندهٔ مالیاتی، ارزش افزوده) — استاندارد برای هر کسب‌وکار ایرانی. <strong>[جزئیات با حسابدار بررسی شود]</strong></li>
+  <li><strong>بیمه/تأمین اجتماعی</strong> پرستارها بسته به طبقه‌بندی کارمند یا پیمانکار متفاوت است (بخش ۲.۲). <strong>[مشاورهٔ قانون کار بگیرید — مهم‌ترین تصمیم ساختاری]</strong></li>
+  <li><strong>نردبان جریمهٔ عدم انطباق:</strong> تذکر شفاهی/کتبی ← تعطیلی ۱–۳ ماه ← تعطیلی ۳ ماه–۱ سال ← <strong>لغو دائم پروانه + ارجاع به مراجع قضایی.</strong> فعالیتِ بدون مجوز ریسک حقوقی واقعی است. <span class="ok">✅ تأییدشده</span></li>
+</ul>
+
+<hr>
+
+<h2 id="gtm">۵. توصیه‌های عملی و راهبرد ورود به بازار</h2>
+<ol>
+  <li><strong>اکنون قالب قانونی را انتخاب کنید: یک «مرکز خدمات پرستاری در منزل» ثبت کنید.</strong> یا خودتان (اگر پرستار با کارشناسی + ۵ سال سابقه هستید) یا یک هم‌بنیان‌گذار پرستار به‌عنوان مؤسس/مسئول فنی. برای خدمات بالینیِ زیرنظر پزشک، بعداً یک شریک پزشک و مسیر بالینی را جداگانه اضافه کنید.</li>
+  <li><strong>سریع وارد بازار شوید با مدل آسانیسم — با مراکز دارای مجوز همکاری کنید</strong> در حالی که پروانهٔ خودتان در فرایند است. این به شما اجازه می‌دهد لایهٔ فناوری/برند/مارکت‌پلیس را قانونی و سریع راه‌اندازی کنید.</li>
+  <li><strong>اعتماد احرازشده را به کلِ برند خود تبدیل کنید.</strong> یک نشان احرازِ قابل‌رؤیت را بسته‌بندی کنید: ✓ هویت احرازشده (شاهکار + تطبیق چهره)، ✓ پروانهٔ صلاحیت حرفه‌ای، ✓ شمارهٔ نظام پرستاری، ✓ عدم سوء پیشینه، ✓ دورهٔ آزمایشی + تضمین. شمارهٔ پروانه را مثل سلامت اول نمایش دهید.</li>
+  <li><strong>جغرافیایی را ببرید که دیگران نادیده می‌گیرند.</strong> تهران/کرج اشباع‌اند؛ شهرهای ردهٔ دوم (مشهد، اصفهان، شیراز، تبریز، اهواز، قم) را هدف بگیرید.</li>
+  <li><strong>احراز را بخرید، نسازید.</strong> یک فروشندهٔ KYC (فینوتک یا یوآیدی) را برای شاهکار + کد ملی + تشخیص زنده‌بودن یکپارچه کنید؛ پروانهٔ صلاحیت حرفه‌ای + شمارهٔ نظام پرستاری را برای لایهٔ مجوز مطالبه کنید.</li>
+  <li><strong>مدل استخدام را پیش از مقیاس‌دهی با وکیل تصمیم بگیرید</strong> — مارکت‌پلیس بی‌طرف در برابر کارفرما/آژانس. از دام «کنترل برای کیفیت + پیمانکار برای هزینه» پرهیز کنید. صرف‌نظر از انتخاب، بیمهٔ مسئولیت پلتفرم داشته باشید.</li>
+  <li><strong>از روز اول علیه حذف واسطه مهندسی کنید:</strong> پرداخت امانی + حل اختلاف، تضمین پوشش پرستار جایگزین، EVV ورود/خروج، و حمایت‌هایی که فقط داخل پلتفرم اعمال می‌شوند.</li>
+  <li><strong>زود چرخهٔ نهادی را بسازید:</strong> مشارکت‌های ارجاع ترخیص بیمارستانی (پس از جراحی، پس از سکته)، و قراردادهای آزمایشی B2B با بیمه‌گرها (سلامت / تأمین اجتماعی)، خیریه‌ها یا کارفرمایان برای یارانه‌دادن ویزیت‌ها.</li>
+  <li><strong>یک ردهٔ سبک‌ترِ «همراهی / کمک روزمره» اضافه کنید</strong> (مدل Papa) — محدودیت تأمین نیروی کمتر، بازار وسیع‌تر. <strong>دیاسپورا</strong> را هدف بگیرید («برای مراقبت از والدینت در وطن هزینه کن»).</li>
+  <li><strong>هرگز ایمنی را بیش از حد تبلیغ نکنید.</strong> هر جریمهٔ Care.com به ادعای بررسی‌ای که انجام نشده برمی‌گردد. کمتر وعده دهید، بیشتر احراز کنید، لغو را آسان کنید.</li>
+</ol>
+
+<h3>پرسش‌های باز / مواردی که باید پیش از راه‌اندازی راستی‌آزمایی شوند</h3>
+<ol>
+  <li>تعداد فعلی (۱۴۰۴–۱۴۰۵) شرکت‌های ثبت‌شده و وضعیت کنونی شکاف قانون کارِ سخت و زیان‌آور برای پرستاران منزل.</li>
+  <li>الزامات کامل سرمایه، مکان، نیروی انسانی و بیمه برای مسیر مرکز خدمات پرستاری، و اینکه آیا یک مارکت‌پلیس فناوری‌محور می‌تواند با پیمانکاری فقط به مراکز دارای مجوزِ همکار (مدل آسانیسم) فعالیت کند بدون داشتن پروانهٔ خودش در ابتدا.</li>
+  <li>آیا نظام پرستاری / وزارت بهداشت هیچ API اعتبارسنجی B2B پشت یک پورتال ارائه می‌دهند.</li>
+  <li>جزئیات مالیات، ارزش افزوده و ساختار شرکت با یک حسابدار محلی؛ طبقه‌بندی استخدام با یک وکیل قانون کار.</li>
+</ol>
+
+<hr>
+
+<h3>منابع (منتخب)</h3>
+<p class="sourcing">
+<strong>ایران — حقوقی و بازار داخلی (تأییدشده):</strong> arakmu.ac.ir/vct/fa/regulation/1063 · mcls.gov.ir/fa/law/61 · qavanin.ir/Law/TreeText/83385 · irannurse.ir · vct.iums.ac.ir · ilna.ir · ecommerce.gov.ir · netafraz.com · asanism.com · snapp.doctor/home-nursing · salamateaval.com · myket.ir/app/hirad.sc.com<br><br>
+<strong>پلتفرم‌های خارجی:</strong> techcrunch.com (Honor، Cera، Vivian، Birdie، Portea) · ftc.gov و cnbc.com (Care.com FTC) · mobihealthnews.com (Papa) · florence.co.uk · technode.global (Homage) · tvmcapitalhealthcare.com (Manzil) · quartr.com (Veteranpoolen)<br><br>
+<strong>ریسک‌ها و شکست‌ها:</strong> thedailybeast.com (Care.com/WSJ) · engadget.com · nurse.org و washingtonpost.com (پرستار قلابی Womack) · hrmorning.com و ogletree.com (طبقه‌بندی نادرست) · shiftcare.com (جابه‌جایی نیرو) · sharetribe.com (حذف واسطه) · aarp.org (سوءاستفادهٔ مالی) · pymnts.com<br><br>
+<strong>ابزار احراز:</strong> ncsbn.org و nursys.com · nmc.org.uk · checkr.com و sterlingcheck.app · behdasht.gov.ir و heyvagroup.com · fa.wikipedia.org (شاهکار) · finnotech.ir · asretarakonesh.ir (۸ شرکت ایرانی KYC) · heyvalaw.com (عدم سوء پیشینه)
+</p>
+
+<p class="meta"><em>این گزارش از یک مرحلهٔ تحقیقِ راستی‌آزمایی‌شدهٔ متخاصمانه (چارچوب حقوقی ایران + رقبای داخلی) به‌علاوهٔ سه عامل تحقیقاتی هدفمند (رقبای خارجی، نمونه‌های ریسک/شکست، ابزار احراز) تدوین شده است. مقررات قدیمی، آمار خوداظهاریِ رقبا و ارقام سرمایه را پیش از تصمیم‌گیری یا انتشار با منابع اولیهٔ روز راستی‌آزمایی کنید.</em></p>
+
+</article>
+</div>
+</body>
+</html>