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
- سیستم نوبتدهی
اینها هست:
یک زیربنای هماهنگی بالینی تریاژمحور و آفلاینمحور که برای مراقبت درازمدت در محیطهای با منابع محدود طراحی شده—تکنالوژی در خدمت پیوستگی، نه جانشینِ آن.