برنامهٔ آزمایشی افغانستان

05 — تز سکو

فناوری، در خدمت مأموریت

همان انتخاب‌های طراحی که به تداوم مراقبت اجازه می‌دهند در محیط‌هایی که بیشتر نرم‌افزارها بی‌سروصدا شکست می‌خورند، زنده بماند.

آخرین به‌روزرسانی June 18, 2026همهٔ بخش‌ها

1سکو چیست

Welnote یک سکوی توزیع‌شده‌ی هماهنگی مراقبتِ امن و آفلاین‌اول است. سه نقش را حول یک سابقه‌ی بیمارِ طولیِ واحد به هم پیوند می‌دهد: کارمندان سلامت میدانی که مراقبت را در جامعه ارائه می‌دهند، پزشکان از راه دور که پرونده‌ها را ناهم‌زمان بازبینی می‌کنند، و ناظران برنامه که برنامه را اداره می‌کنند.

این یک اپ پزشکی از راه دور یا جایگزین EMR نیست. زیرساختِ هماهنگیِ بالینیِ ذخیره‌وارسال است که یک تیم پراکنده را وامی‌دارد از همان سابقه‌ی بیمار کار کنند—حتی وقتی هیچ‌کس هم‌زمان آنلاین نیست.

جنبه‌ی بالینیِ این موضوع زیرِ مدل مراقبت و ایمنی بالینی شرح داده شده، و جنبه‌ی حریم خصوصی زیرِ اخلاق داده و حریم خصوصی. آنچه در پی می‌آید، استدلال مهندسی‌ای است که آن‌ها را در میدان کارآمد می‌کند.

2چرا آفلاین‌اول

در میدان، اتصال استثناست، نه قاعده. پس آفلاین یک حالتِ تنزل‌یافته نیست—پیش‌فرض است. همه‌ی کارکردهای بالینی باید بدون دسترسی به اینترنت کار کنند. یک کارمند می‌تواند بیماری را ثبت کند، مشاهدات را بگیرد، فوریت را دسته‌بندی کند و یک پیگیری را بدون هیچ سیگنالی ثبت کند؛ شبکه تنها بعداً، برای تطبیق، اهمیت می‌یابد.

3چرا معماری همگام‌سازی

چون تیم به‌ندرت هم‌زمان آنلاین است، سیستم بنا بر طراحی ناهم‌زمان است: ذخیره‌وارسال در هر دو جهت. مشاهدات میدانی به‌سوی پزشکان و ناظران حرکت می‌کنند، در حالی که طرح‌های مراقبت، توصیه‌های پیگیری و تغییرات وضعیت به‌سوی میدان بازمی‌گردند.

  • نوشتن‌های محلی‌اول، که به‌گونه‌ای ناهم‌زمان با تضمینِ تحویل نهایی ارائه می‌شوند
  • همگام‌سازی دوسویه — هل‌دادن به ابر، سپس کشیدن تغییرات پزشک و ناظر به میدان
  • نشانگرهای جداگانه برای هر موجودیت تا هر جدول مستقل همگام شود
  • تحویل خودتوان از طریق کلیدهای جهش — تلاش‌های مجدد هرگز سوابق را تکراری نمی‌کنند
  • هم‌روندیِ خوش‌بینانه از طریق نسخه‌های ردیف — سرور نوشتن‌های کهنه را رد و یک ادغام را دوباره صف می‌کند
  • اقتدار تعارض در سطح فیلد — هر کنشگر مالک فیلدهای مشخصی است؛ مشاهدات فقط افزودنی‌اند
موتور همگام‌سازی حیاتی‌ترین لایه‌ی قابلیت اطمینان در سیستم است. تداوم بالینی، یکپارچگی داده، کارایی میدانی و مقیاس‌پذیری را تعیین می‌کند.

4چرا معماری برنامه‌محور

برنامه همان مستأجر و مرز امنیتی است. هر سابقه به یک برنامه تعلق دارد؛ امنیت در سطح ردیف روی هر جدول ابری، عضویت در برنامه را به مرز مجوزدهی بدل می‌کند. این کار داده‌ی هر شریک را جدا نگه می‌دارد و تصمیم‌های دسترسی را ساده و قابل‌حسابرسی می‌سازد.

دسترسی (آنچه می‌توانید ببینید) برنامه‌محور است، در حالی که واگذاری (این‌که چه کسی مسئول یک پرونده است) جداگانه رهگیری می‌شود—پس دیده‌شدن و مسئولیت هرگز لازم نیست یک چیز باشند.

5چرا مالکیت محلی

این معماری فرض‌های استانداردِ SaaS را وارونه می‌کند تا اقتدار را آن‌جا که مراقبت رخ می‌دهد نگه دارد.

دستگاه همراه همان سیستم سابقه است. ابر یک لایه‌ی تطبیق است.

هر کنشگر در برابر یک پایگاه‌داده‌ی محلی کار می‌کند؛ ابر آن پایگاه‌داده‌ها را با یکدیگر تطبیق می‌دهد. بیماران به‌صورت پیش‌فرض با نام مستعار هستند؛ یک برنامه می‌تواند همگام‌سازی نام واقعی را انتخاب کند که امنیت در سطح ردیف آن را تنها برای اعضای همان برنامه قابل مشاهده نگه می‌دارد—پس شریکان محلی و جوامع، مالکیتِ حساس‌ترین داده را بنا بر ساختار حفظ می‌کنند.

6چرا گردش‌کارهای یاری‌شده با هوش مصنوعی (و کجا متوقف می‌شوند)

هوش مصنوعی به‌صراحت از اقتدار تصمیم‌گیری بالینی جدا شده است. قابلیت‌های آینده روی داده‌ی ساختارمند عمل می‌کنند تا اصطکاک را بکاهند، نه آن‌که تصمیم‌های بالینی بگیرند.

  • خلاصه‌سازی پرونده
  • ترجمه
  • پیشنهادهای تریاژ
  • پیش‌نویس طرح‌های مراقبت برای بازبینی پزشک
  • بینش‌های جمعیتی

هوش مصنوعی روی داده‌ی ساختارمند عمل می‌کند، نه بر اقتدار خامِ تصمیم‌گیری. تصمیم‌گیرنده همیشه یک پزشکِ دارای پروانه است.

7معماری سیستم

7.1 معماری سطح‌بالا

دستگاه‌های میدانی (Flutter) — کارمندان و پزشکان

پایگاه‌داده‌ی محلی (SQLite / Drift) — سرچشمه‌ی حقیقت

موتور همگام‌سازی دوسویه (هل‌دادن + کشیدن)

لایه‌ی تطبیق ابری (Supabase)

پرتال وب (Next.js) — پزشکان، ناظران، مدیران

هوشمندیِ برنامه و جمعیت

7.2 جایی که مراقبت رخ می‌دهد در برابر جایی که مدیریت می‌شود

موبایل جایی است که مراقبت رخ می‌دهد؛ وب جایی است که برنامه مدیریت می‌شود. بازبینی پرونده توسط پزشک عامدانه روی هر دو در دسترس است—بسیاری از پزشکان میدانی تنها به تلفن دسترسیِ قابل‌اعتماد دارند.

8معماری داده

مدل داده کوچک، طولی و دوست‌دارِ افزودن است.

  • برنامه — مستأجر و مرز امنیتی
  • بیمار — موجودیتِ طولیِ نام‌مستعار
  • پرونده — دوره‌ی مراقبت، با یک واگذاری و چرخه‌ی عمر وضعیت
  • مشاهده — نقطه‌ی داده‌ی بالینیِ فقط‌افزودنی
  • پیوست — شواهد رسانه‌ای رمزگذاری‌شده (EXIF/GPS حذف‌شده، AES-256-GCM)
  • طرح مراقبت — برون‌دادِ پزشک
  • پیگیری — گره‌ی تداومِ زمانی
  • رویداد پرونده — سابقه‌ی فعالیت و حسابرسیِ تغییرناپذیر

واحدِ حقیقت، خط‌زمانی بیمار است، نه ویزیت منفرد.

9اصول امنیتی

لایهنوع هویت
دستگاهشناسه‌ی نام‌مستعار + هویت واقعیِ اختیاری
ابرشناسه‌ی نام‌مستعار + هویت واقعیِ اختیاری (RLS)
پزشکپیش‌فرض نام مستعار؛ نام در صورت فعال‌سازیِ برنامه
ناظر / سازمان مردم‌نهادتنها داده‌ی تجمیعی
  • چنداجاره‌ایِ برنامه‌محور با امنیت در سطح ردیف روی هر جدول ابری
  • دسترسی مبتنی بر نقش و کم‌ترین‌امتیاز (کارمند میدانی، پزشک، ناظر، مدیر)
  • به‌صورت پیش‌فرض شناسه‌های نام‌مستعار؛ نام واقعی تنها زمانی همگام می‌شود که برنامه آن را فعال کند و با امنیت در سطح ردیف محافظت می‌شود
  • سابقه‌ی حسابرسیِ سمتِ سرور که در همگام‌سازیِ موفق نوشته می‌شود
  • رمزگذاریِ پیوستِ برنامه‌محور تا بازبین‌های مجاز بتوانند عکس‌های میدانی را رمزگشایی کنند
  • پاک‌سازیِ از راه دورِ دستگاه در صورت گم‌شدن یا توقیف تلفن

استدلال کاملِ حریم خصوصی در صفحه‌ی اخلاق داده و حریم خصوصی است.

10بیانِ تز

این سیستم این‌ها نیست:

  • پزشکی از راه دور
  • جایگزینِ EMR
  • سیستم نوبت‌دهی

این‌ها هست:

یک زیرساختِ هماهنگیِ بالینیِ تریاژ‌محور و آفلاین‌اول که برای مراقبت طولی در محیط‌های محدود از منابع طراحی شده—فناوری در خدمت تداوم، نه جانشینِ آن.