در حال بارگذاری

CASE STUDYپاسارPasar

پرونده‌ای که با بیمار می‌ماند.

پلتفرم پرونده‌ی سلامت دیجیتال و خدمات درمانی در منزل — پزشک، پرستار، فیزیوتراپی، آزمایش و همراه — که از هفده سند مشخصات محصول به یک وب‌اپلیکیشن قابل نصب تبدیل شد. فاز اول: استان همدان.

مشتری
پاسار
حوزه
سلامت دیجیتال
دامنه‌ی کار
PWA پرونده‌ی سلامت و خدمات در منزل
سال
۱۴۰۵
کار ما
تحلیل محصولمعماریتوسعه وب‌اپلیکیشن
پاسار — پرونده‌ای که با بیمار می‌ماند.
01 / NEED

نیاز

پرونده‌ی سلامت دیجیتال و خدمات درمانی در منزل، با هفده سند مشخصات و یک فاز اول محدود به همدان. مسئله، تبدیل آن حجم سند به محصولی بود که بیمار و ارائه‌دهنده هر دو بتوانند استفاده کنند.

  • هفده سند مشخصات، یک محصول قابل استفاده
  • دو مخاطب: بیمار و ارائه‌دهنده‌ی خدمت
  • پرونده‌ای که با بیمار بماند، نه با مرکز
  • قابل نصب روی موبایل، بدون فروشگاه اپلیکیشن
02 / SOLUTION

راهکار

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

  • پرونده‌ی سلامت متصل به خود بیمار
  • مسیر درخواست خدمت در منزل
  • داشبورد ارائه‌دهنده و پیگیری درخواست‌ها
  • قابل نصب (PWA) برای فاز اول همدان
صفحه‌ی فرود پاسار با تصویر قلب و خانه و معرفی خدمات درمانی در منزل
صفحه‌ی فرود — خدمات در منزل، با پرونده‌ای که همراه بیمار می‌ماند.

01کشف

هفده سند، ده تناقض.

محصول در قالب هفده سند مشخصات رسید: ثبت‌نام و احراز هویت، پرونده، علائم حیاتی، آزمایش‌ها، امتیاز سلامت، درخواست خدمت، اعلان‌ها، باشگاه معرف و بقیه. خواندن همه‌ی اسناد در برابر هم، ده تناقض مستقیم و پنج شکاف را آشکار کرد که اگر مستقیم به کد می‌رفتند، باگ می‌شدند.

پس اول همین را نوشتیم: فهرست سؤال‌های باز، قبل از اولین خط کد.

  • ۱۷ سند مشخصات محصول
  • ۱۰ تناقض مستقیم و ۵ شکاف، مستند و قابل تصمیم
  • هر ماژول به سند مرجعش ارجاع دارد؛ کسی مجبور نیست دوباره PDF بخواند
02تصمیم

لایه‌ی دامنه، قبل از صفحه‌ها.

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

و چهار قانون غیرقابل مذاکره که در کد هم قابل مذاکره نیستند.

  • هرگز تشخیص قطعی داده نمی‌شود؛ سیستم وضعیت داده‌های ثبت‌شده را گزارش می‌کند، نه سلامت فرد
  • «اطلاعات کافی نیست» یک وضعیت واقعی است؛ با یک شاخص، اطمینان کاذب داده نمی‌شود
  • هیچ اطلاعاتی حذف نمی‌شود؛ هر ثبت یک رکورد جدید با تاریخ و ثبت‌کننده است
  • محدوده‌ی مرجع آزمایشگاه بر جداول پیش‌فرض اولویت دارد
03طراحی

سمت عمومی؛ خدمات و پزشکان.

صفحه‌ی فرود پنج خدمت در منزل را با یک زبان بصری واحد معرفی می‌کند: پزشک، پرستار، فیزیوتراپی، آزمایش، همراه. صفحه‌ی پزشکان قابل ایندکس است تا جست‌وجوی «پزشک در منزل همدان» به همین‌جا برسد.

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

اپ؛ پرونده، درخواست، وضعیت.

بعد از ورود با OTP، کاربر وارد پوسته‌ی اپ می‌شود: هدر، منوی پایین، داشبورد. پرونده‌ی سلامت علائم حیاتی و آزمایش‌ها را با تاریخچه نگه می‌دارد و وضعیت — پایدار، مناسب، نیاز به توجه، نیاز به پیگیری، نیازمند ارزیابی پزشکی، یا اطلاعات کافی نیست — را با سلب مسئولیت همیشگی نشان می‌دهد.

هر درخواست خدمت یک خط زمانی دارد: ثبت شده، در حال بررسی، منتظر پرداخت، پرداخت شده، هماهنگ شده، در حال انجام، انجام شده. و ثبت درخواست بدون تکمیل پرونده ممکن نیست؛ این گیت در دامنه است، نه در فرم.

  • PWA قابل نصب با منیفست و آیکن‌ها
  • تاریخ جلالی با Intl و تقویم fa-IR-u-ca-persian؛ بدون وابستگی خارجی
  • فونت وزیرمتن از پکیج محلی؛ بیلد به هیچ سرویس فونت خارجی وابسته نیست
داشبورد اپ پاسار با وضعیت سلامت، آخرین ثبت‌ها و دسترسی سریع به خدمات
داشبورد — وضعیت پرونده و دسترسی سریع.
صفحه‌ی پرونده‌ی سلامت پاسار با علائم حیاتی و آزمایش‌ها
پرونده‌ی سلامت — تاریخچه‌ای که هیچ‌وقت حذف نمی‌شود.
صفحه‌ی درخواست‌های پاسار با خط زمانی وضعیت هر درخواست
درخواست‌ها — ده وضعیت، یک خط زمانی.
تحویل

فاز اول، همدان.

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

این پروژه در حال توسعه است؛ اعداد زیر مشخصات نسخه‌ی فعلی‌اند.

۱۷
سند مشخصات، به یک لایه‌ی دامنه
۵ / ۱۰
وضعیت سلامت / وضعیت درخواست
۵
خدمت درمانی در منزل
۱
استان در فاز اول