چرا مراکز درمانی آینده به سیستم مدیریت فرایندهای کسب‌وکار (BPMS) نیاز دارند، نه صرفاً سیستم اطلاعات کلینیک (CIS)؟

1. مقدمه

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

با این حال، بسیاری از نرم‌افزارهای مورد استفاده در مراکز درمانی هنوز بر پایه ثبت و نگهداری اطلاعات طراحی شده‌اند. این سامانه‌ها که معمولاً در دسته سیستم‌های اطلاعات کلینیک (Clinic Information System - CIS) قرار می‌گیرند، وظایفی مانند مدیریت پرونده بیمار، نوبت‌دهی، صدور قبض، نسخه‌نویسی و گزارش‌گیری را به‌خوبی انجام می‌دهند؛ اما در اغلب موارد، مسئولیت هماهنگی میان این فعالیت‌ها همچنان بر عهده کاربران است. به بیان دیگر، نرم‌افزار اطلاعات را مدیریت می‌کند، اما فرآیند را مدیریت نمی‌کند.

این تفاوت زمانی آشکارتر می‌شود که یک مرکز درمانی رشد می‌کند، تعداد واحدهای آن افزایش می‌یابد یا قوانین و رویه‌های کاری آن تغییر می‌کنند. در چنین شرایطی، هماهنگی میان پذیرش، پزشک، پرستار، آزمایشگاه، صندوق، بیمه و سایر واحدها بیش از آنکه به قابلیت ثبت اطلاعات وابسته باشد، به توانایی سیستم در مدیریت گردش کار (Workflow)، اعمال قوانین کسب‌وکار (Business Rules) و هدایت خودکار فرآیندها وابسته است. اگر این هماهنگی صرفاً بر دانش و پیگیری کارکنان متکی باشد، احتمال بروز تأخیر، دوباره‌کاری، ناهماهنگی و خطا به‌طور قابل توجهی افزایش می‌یابد.

در سال‌های اخیر، مفهوم مدیریت فرایندهای کسب‌وکار (Business Process Management - BPM) به‌عنوان رویکردی برای طراحی و اجرای فرآیندهای سازمانی، جایگاه ویژه‌ای در صنایع مختلف پیدا کرده است. در این رویکرد، تمرکز از «مدیریت اطلاعات» به «مدیریت جریان انجام کار» تغییر می‌کند و سامانه‌های Business Process Management System (BPMS) با استفاده از موتورهای گردش کار، قوانین قابل پیکربندی، فرم‌های پویا و سازوکارهای خودکار، اجرای فرآیندها را به‌صورت یکپارچه مدیریت می‌کنند. با وجود گسترش این رویکرد در بسیاری از صنایع، بهره‌گیری از معماری فرآیندمحور (Process-Oriented Architecture) در نرم‌افزارهای مراکز درمانی هنوز به اندازه ظرفیت‌های آن مورد توجه قرار نگرفته است.

این مقاله با تکیه بر همین دیدگاه، به بررسی تفاوت میان سیستم‌های اطلاعات کلینیک (CIS) و سیستم‌های مدیریت فرایندهای کسب‌وکار (BPMS) در حوزه سلامت می‌پردازد و نشان می‌دهد که نیاز امروز و آینده مراکز درمانی، صرفاً ثبت و نگهداری اطلاعات نیست، بلکه مدیریت هوشمند و یکپارچه جریان ارائه خدمات درمانی است. در ادامه، ضمن تبیین مفاهیم و تفاوت‌های این دو رویکرد، یک مطالعه موردی از سامانه جامع هوشمند مدیریت مراکز درمانی «پارسیزطب» ارائه می‌شود تا نشان داده شود چگونه می‌توان با اتخاذ معماری فرآیندمحور، هماهنگی میان واحدهای مختلف، انعطاف‌پذیری در تغییر فرآیندها و اتوماسیون گردش کار را در محیط‌های درمانی محقق ساخت.

 

۲. نرم‌افزار درمانی دقیقاً چه کاری انجام می‌دهد؟

در دهه‌های اخیر، استفاده از سیستم‌های اطلاعات کلینیک (Clinic Information System - CIS) به یکی از ارکان اصلی مدیریت مراکز درمانی تبدیل شده است. امروزه کمتر مرکز درمانی را می‌توان یافت که فرآیندهای روزمره خود را بدون استفاده از یک سامانه نرم‌افزاری انجام دهد. این سامانه‌ها نقش مهمی در دیجیتالی‌سازی اطلاعات، کاهش وابستگی به اسناد کاغذی و افزایش سرعت دسترسی به داده‌های پزشکی ایفا کرده‌اند و بدون تردید، یکی از مهم‌ترین عوامل تحول در مدیریت اطلاعات سلامت به شمار می‌روند.

یک سامانه اطلاعات کلینیک معمولاً مجموعه‌ای از قابلیت‌های کاربردی را در اختیار کاربران قرار می‌دهد؛ از جمله ثبت اطلاعات بیماران، تشکیل پرونده الکترونیکی، مدیریت نوبت‌دهی، ثبت خدمات پزشکی و پاراکلینیکی، نسخه‌نویسی، مدیریت صندوق و پرداخت، ارتباط با بیمه‌ها، گزارش‌گیری و مدیریت کاربران. هر یک از این قابلیت‌ها بخشی از نیازهای عملیاتی یک مرکز درمانی را پوشش می‌دهد و باعث می‌شود اطلاعات به‌صورت ساخت‌یافته و قابل بازیابی در اختیار کارکنان قرار گیرد.

با این حال، نکته قابل تأمل آن است که در بسیاری از این سامانه‌ها، تمرکز اصلی بر «چه اطلاعاتی باید ثبت شود؟» است، نه بر «این اطلاعات در چه فرآیندی و با چه ترتیبی باید جریان پیدا کنند؟». به بیان دیگر، معماری این نرم‌افزارها عموماً اطلاعات‌محور (Information-Oriented) است؛ یعنی هر ماژول وظیفه ثبت، نمایش یا ویرایش بخشی از اطلاعات را بر عهده دارد، اما مدیریت ارتباط پویا میان این ماژول‌ها و هدایت فرآیندهای سازمانی، معمولاً خارج از هسته اصلی سیستم قرار می‌گیرد.

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

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

بنابراین، اگرچه CIS ابزار ارزشمندی برای مدیریت اطلاعات محسوب می‌شود و وجود آن برای هر مرکز درمانی ضروری است، اما با پیچیده‌تر شدن فرآیندهای درمان، افزایش تعداد واحدهای سازمانی، تغییر مستمر قوانین و گسترش خدمات، صرفِ مدیریت اطلاعات دیگر پاسخگوی نیازهای مراکز درمانی نخواهد بود. آنچه در این مرحله اهمیت پیدا می‌کند، توانایی سیستم در مدیریت فرآیندها، هدایت گردش کار، اعمال قوانین کسب‌وکار و هماهنگ‌سازی خودکار میان واحدهای مختلف است؛ قابلیتی که زمینه‌ساز گذار از یک سیستم اطلاعاتی به یک سیستم مدیریت فرآیندهای کسب‌وکار (BPMS) خواهد بود.

 

 

۳. مشکل اصلی رویه‌های فعلی مراکز درمانی از کجاست؟

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

دلیل این مسئله را باید در تفاوت میان مدیریت اطلاعات و مدیریت فرآیند جستجو کرد.

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

• آیا مرحله قبلی به‌درستی تکمیل شده است؟
• مسئول انجام مرحله بعد چه کسی است؟
• آیا شرایط لازم برای ادامه فرآیند وجود دارد؟
• در صورت وجود یک استثناء، مسیر جایگزین چیست؟
• اگر انجام یک فعالیت بیش از زمان مجاز طول بکشد، چه اقدامی باید انجام شود؟

در بسیاری از سیستم‌های اطلاعات کلینیک (CIS)، پاسخ این پرسش‌ها بر عهده کاربران است. کارکنان با تکیه بر تجربه، دانش فردی یا هماهنگی‌های غیررسمی، فرآیند را پیش می‌برند و نرم‌افزار صرفاً وقایع را ثبت می‌کند.

اما در یک سیستم مدیریت فرآیندهای کسب‌وکار (BPMS)، این مسئولیت به هسته سیستم منتقل می‌شود. موتور فرآیند، وضعیت فعلی هر بیمار را می‌شناسد، مرحله بعد را تعیین می‌کند، قوانین کسب‌وکار را اعمال می‌کند، وظایف را به نقش مناسب ارجاع می‌دهد، تأخیرها را پایش می‌کند و در صورت نیاز، اقدامات خودکار مانند ارسال اعلان یا ایجاد وظیفه را انجام می‌دهد.

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

 

۴. تفاوت CIS و BPMS؛ تفاوت در نگاه، نه فقط در قابلیت

تفاوت میان سیستم اطلاعات کلینیک (Clinic Information System - CIS) و سیستم مدیریت فرآیندهای کسب‌وکار (Business Process Management System - BPMS) صرفاً در تعداد امکانات یا ماژول‌های نرم‌افزاری نیست؛ بلکه تفاوت اصلی در نوع نگاه به مسئله مدیریت یک مرکز درمانی است.

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

به بیان ساده:

CIS پاسخ می‌دهد: چه اطلاعاتی در سیستم وجود دارد؟

BPMS پاسخ می‌دهد: چه کاری باید انجام شود، توسط چه کسی، در چه زمانی و تحت چه شرایطی؟

 

مقایسه این دو رویکرد را می‌توان به شکل زیر خلاصه کرد:

ویژگی	CIS (Clinic Information System)	BPMS (Business Process Management System)
تمرکز اصلی	مدیریت اطلاعات و داده‌های درمانی	مدیریت جریان کار و فرآیندهای سازمانی
نقطه شروع طراحی	موجودیت‌ها، فرم‌ها و ماژول‌ها	فرآیندها، مراحل و رویدادها
هسته اصلی سیستم	Database و ماژول‌های کاربردی	Workflow Engine و موتور اجرای فرآیند
نقش کاربر	پیگیری و هماهنگی مراحل کاری	انجام وظایف تعریف‌شده در مسیر فرآیند
هماهنگی بین واحدها	عمدتاً وابسته به کارکنان	مدیریت‌شده توسط موتور فرآیند
مدیریت قوانین کسب‌وکار	معمولاً نیازمند تغییرات نرم‌افزاری	قابل تعریف و تغییر از طریق Rule Engine
تغییر در فرآیندها	اغلب وابسته به توسعه نرم‌افزار	قابل انجام از طریق پیکربندی
توسعه سیستم	افزودن ماژول‌های جدید	توسعه و تغییر فرآیندها
مدیریت استثناها	معمولاً خارج از جریان اصلی سیستم	قابل تعریف در مسیر فرآیند
کنترل وضعیت بیمار	نمایش اطلاعات ثبت‌شده	مدیریت مرحله فعلی و مسیر بعدی

 

این تفاوت در محیط‌های درمانی اهمیت زیادی پیدا می‌کند. برای مثال، در یک CIS ممکن است اطلاعات یک بیمار شامل سوابق، خدمات انجام‌شده و پرداخت‌ها به‌طور کامل ثبت شده باشد؛ اما سیستم الزاماً نمی‌داند که بیمار در چه مرحله‌ای از دریافت خدمت قرار دارد، چه اقدامی باید بعد از آن انجام شود یا در صورت تأخیر چه کسی باید مطلع شود.

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

بنابراین، حرکت از CIS به BPMS به معنای کنار گذاشتن سیستم‌های اطلاعاتی نیست؛ بلکه به معنای تکامل آن‌هاست. اطلاعات همچنان پایه اصلی هر سامانه درمانی است، اما زمانی بیشترین ارزش را ایجاد می‌کند که در یک فرآیند هوشمند، قابل کنترل و قابل بهبود جریان پیدا کند.

 

۵. معماری یک سیستم فرآیندمحور در مراکز درمانی

یک سیستم مدیریت فرآیندهای کسب‌وکار (BPMS) در محیط درمانی را نمی‌توان صرفاً مجموعه‌ای از فرم‌ها و ماژول‌های نرم‌افزاری در نظر گرفت. هسته اصلی چنین سیستمی، توانایی آن در تعریف، اجرا، کنترل و بهبود فرآیندهایی است که در طول ارائه خدمات درمانی اتفاق می‌افتند.

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

اجزای اصلی یک BPMS درمانی را می‌توان به صورت زیر تعریف کرد:

۵-۱. موتور فرآیند (Workflow Engine)

موتور فرآیند، هسته اجرایی یک BPMS است. این بخش مسئول مدیریت چرخه حیات فرآیند، کنترل وضعیت فعلی، هدایت مراحل و اجرای انتقال بین وضعیت‌ها است.

برای مثال، مسیر یک بیمار در یک مرکز درمانی می‌تواند شامل وضعیت‌هایی مانند:

پذیرش ← انتظار ← ارزیابی اولیه ← ویزیت پزشک ← خدمات درمانی ← پرداخت

باشد.

موتور فرآیند مشخص می‌کند:

• بیمار در چه مرحله‌ای قرار دارد؟
• مرحله بعدی چیست؟
• چه نقشی مسئول انجام آن مرحله است؟
• چه شرایطی برای انتقال به مرحله بعد وجود دارد؟

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

۵-۲. موتور قوانین کسب‌وکار (Rule Engine)

مراکز درمانی همواره با قوانین متغیر مواجه هستند؛ از تعرفه‌ها و قراردادهای بیمه گرفته تا شرایط خاص ارائه خدمات.

Rule Engine این امکان را فراهم می‌کند که تصمیم‌های فرآیندی بر اساس قوانین قابل تنظیم اجرا شوند.

برای مثال:

• اگر بیمار تحت پوشش بیمه خاصی باشد، مسیر مالی متفاوتی طی شود.
• اگر خدمت خاصی ثبت شود، مرحله جدیدی به فرآیند اضافه شود.
• اگر مبلغ صورتحساب از مقدار مشخصی بیشتر باشد، نیاز به تأیید مدیر داشته باشد.

در این رویکرد، تغییر قوانین الزاماً به معنی تغییر کد نرم‌افزار نیست، بلکه می‌تواند از طریق پیکربندی سیستم انجام شود.

۵-۳. فرم‌ساز پویا (Dynamic Form Builder)

با توجه به تنوع مراکز درمانی، یک سیستم فرآیندمحور باید بتواند فرم‌ها را متناسب با نیاز هر سازمان ایجاد و تغییر دهد.

فرم‌ها در BPMS صرفاً صفحات ورود اطلاعات نیستند؛ بلکه بخشی از یک مرحله فرآیندی محسوب می‌شوند.

برای مثال:

فرم پذیرش بیمار در مرحله ورود

• فرم علائم حیاتی در مرحله ارزیابی اولیه
• فرم شرح حال و درمان در مرحله ویزیت
• فرم تأیید بیمه در مرحله مالی

اتصال فرم‌ها به فرآیند باعث می‌شود اطلاعات دقیقاً در زمان و مکان مناسب ثبت شوند.

۵-۴. مدیریت نقش‌ها و وظایف (Role & Task Management)

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

یک BPMS باید بتواند:

• وظایف را به نقش مناسب تخصیص دهد.
• دسترسی‌ها را کنترل کند.
• مسئولیت هر مرحله را مشخص کند.
• وضعیت انجام وظایف را پایش کند.

در این حالت، فرآیند وابسته به حضور یا حافظه افراد نیست، بلکه سیستم مسئول هدایت کار است.

۵-۵. مدیریت رویدادها و اعلان‌ها (Event & Notification Management)

در فرآیندهای درمانی، بسیاری از اقدامات در پاسخ به یک رویداد اتفاق می‌افتند.

مانند:

• ثبت پذیرش بیمار
• پایان ویزیت
• ثبت نتیجه آزمایش
• تکمیل پرداخت

یک معماری Event-Driven می‌تواند این رویدادها را دریافت کرده و اقدامات مناسب را اجرا کند؛ مانند ایجاد مرحله جدید، ارسال پیام، ایجاد وظیفه یا اطلاع‌رسانی به کاربر مرتبط.

۵-۶. گزارش‌گیری و تحلیل فرآیند (Process Analytics)

در سیستم‌های اطلاعاتی سنتی، گزارش‌ها معمولاً بر داده‌های ثبت‌شده تمرکز دارند؛ مانند تعداد بیماران یا میزان درآمد.

اما در BPMS، علاوه بر داده، خود فرآیند نیز قابل تحلیل است:

• متوسط زمان هر مرحله چقدر است؟
• بیماران در کدام مرحله بیشترین انتظار را دارند؟
• کدام فرآیند بیشترین تأخیر را دارد؟
• کدام بخش نیاز به بهبود دارد؟

این قابلیت، زمینه حرکت از مدیریت واکنشی به مدیریت مبتنی بر تحلیل را فراهم می‌کند.

 

۶. مطالعه موردی: پیاده‌سازی معماری فرآیندمحور در سامانه پارسیزطب

۶-۱. رویکرد طراحی پارسیزطب

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

با این نگاه، مسئله اصلی در طراحی یک سامانه مدیریت کلینیک، صرفاً ایجاد ماژول‌هایی برای ثبت اطلاعات نبود؛ بلکه ایجاد بستری بود که بتواند جریان واقعی ارائه خدمت را مدیریت کند.

بر همین اساس، سامانه پارسیزطب با رویکرد فرآیندمحور (Process-Oriented) طراحی شد. در این رویکرد، فرآیند به عنوان عنصر اصلی طراحی سیستم در نظر گرفته می‌شود و ماژول‌های نرم‌افزاری در خدمت اجرای صحیح آن قرار می‌گیرند.

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

در معماری فرآیندمحور پارسیزطب، نقطه شروع طراحی این سؤال بوده است:

بیمار از لحظه ورود تا پایان دریافت خدمت چه مسیری را طی می‌کند و سیستم چگونه باید این مسیر را مدیریت کند؟

۶-۲. معماری کلی سیستم

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

• لایه کاربردی (Application Layer)
• موتور فرآیند (Workflow Engine)
• موتور قوانین کسب‌وکار (Rule Engine)
• فرم‌ساز پویا (Dynamic Form Builder)
• سیستم اعلان و رویداد (Notification & Event Engine)
• لایه گزارش‌گیری و تحلیل
• لایه ارتباطات و API

در این معماری، موتور فرآیند به عنوان هسته هماهنگ‌کننده سیستم عمل می‌کند و ارتباط میان بخش‌های مختلف را بر اساس مسیر تعریف‌شده فرآیند مدیریت می‌نماید.

۶-۳. موتور فرآیند پارسیزطب

یکی از مهم‌ترین اجزای معماری پارسیزطب، موتور فرآیند آن است که مسئول تعریف، اجرا و کنترل گردش کارهای درمانی و سازمانی است. در طراحی این بخش، به جای وابستگی کامل به یک مدل ثابت، از یک معماری ترکیبی (Hybrid Architecture) استفاده شده است تا ضمن حفظ انعطاف‌پذیری، کنترل دقیقی بر رفتار فرآیندها وجود داشته باشد.

هسته اصلی این موتور بر مبنای State Machine طراحی شده است.

در این مدل، هر فرآیند از مجموعه‌ای از:

• وضعیت‌ها (State)
• انتقال‌ها (Transition)

تشکیل می‌شود.

برای مثال، مسیر یک بیمار می‌تواند شامل وضعیت‌های زیر باشد:

رزرو نوبت

↓

پذیرش

↓

ارزیابی اولیه

↓

انتظار

↓

ویزیت پزشک

↓

ثبت طرح درمان

↓

پرداخت

↓

خروج

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

• وضعیت بیمار در هر لحظه قابل مشاهده است.
• مسیر حرکت فرآیند قابل کنترل است.
• امکان تعریف سناریوهای متفاوت وجود دارد.
• وابستگی به هماهنگی‌های دستی کاهش پیدا می‌کند.

۶-۴. معماری رویدادمحور (Event-Driven Architecture)

در پارسیزطب، اجرای فرآیندها بر پایه رویدادها انجام می‌شود. به این معنا که هر اتفاق مهم در سیستم می‌تواند یک رویداد ایجاد کند:

• ثبت پذیرش بیمار
• پایان ویزیت
• ثبت درخواست خدمت
• تکمیل پرداخت
• لغو یک مرحله

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

۶-۵. مدیریت قوانین کسب‌وکار

یکی از چالش‌های مهم مراکز درمانی، تغییر مداوم قوانین و شرایط اجرایی است. تعرفه‌ها، قراردادهای بیمه، سیاست‌های داخلی مرکز و سناریوهای خدماتی ممکن است در طول زمان تغییر کنند. در یک معماری سنتی، چنین تغییراتی معمولاً نیازمند تغییر در کد نرم‌افزار است.

در پارسیزطب، با استفاده از Rule Engine، بخشی از منطق تصمیم‌گیری به صورت قابل تنظیم طراحی شده است.

برای مثال:

• مسیر مالی بیمار بر اساس نوع بیمه تعیین شود.
• برای خدمات خاص، مرحله تأیید اضافه شود.
• بر اساس شرایط تعریف‌شده، اعلان یا وظیفه جدید ایجاد شود.

این رویکرد باعث می‌شود سیستم بتواند با تغییرات سازمانی همراه شود، بدون اینکه هر تغییر کوچک نیازمند توسعه نرم‌افزاری باشد.

۶-۶. مدل تعریف فرآیند و ذخیره‌سازی

تعریف فرآیندها در پارسیزطب به صورت داده‌محور (Data Driven) انجام می‌شود.

اطلاعات مربوط به:

• وضعیت‌ها
• انتقال‌ها
• قوانین
• تنظیمات پویا

در پایگاه داده نگهداری می‌شوند و بخشی از تنظیمات انعطاف‌پذیر نیز با ساختارهای JSON مدیریت می‌شوند. این طراحی امکان تغییر و تکامل فرآیندها را بدون نیاز به Deploy مجدد بخش اصلی سیستم فراهم می‌کند.

 

۷. نتیجه‌گیری و چشم‌انداز آینده

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

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

در چنین شرایطی، رویکرد سیستم‌های مدیریت فرآیندهای کسب‌وکار (BPMS) می‌تواند مکمل نسل موجود سیستم‌های اطلاعات کلینیک (CIS) باشد. BPMS با انتقال تمرکز از «ثبت اتفاقات» به «مدیریت اتفاقات»، امکان کنترل گردش کار، اجرای قوانین کسب‌وکار، کاهش وابستگی به هماهنگی انسانی و ایجاد انعطاف‌پذیری در برابر تغییرات سازمانی را فراهم می‌کند.

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

با این حال، حرکت به سمت معماری‌های فرآیندمحور به معنای حذف سیستم‌های اطلاعاتی موجود نیست؛ بلکه مرحله‌ای تکاملی در مسیر بلوغ سامانه‌های سلامت محسوب می‌شود. مراکز درمانی همچنان به مدیریت اطلاعات دقیق نیاز دارند، اما این اطلاعات زمانی بیشترین ارزش را ایجاد می‌کنند که در یک جریان کاری هوشمند، قابل کنترل و قابل بهبود مورد استفاده قرار گیرند.

آینده سیستم‌های مدیریت درمان، احتمالاً به سمت ترکیب سه حوزه حرکت خواهد کرد:

• مدیریت فرآیند (Process Management) برای هدایت جریان کار
• هوش مصنوعی (Artificial Intelligence) برای پیش‌بینی و پیشنهاد تصمیم‌ها
• تحلیل فرآیند (Process Intelligence) برای شناسایی نقاط ضعف و بهبود مستمر

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

 

در نهایت، می‌توان گفت که مسیر آینده نرم‌افزارهای درمانی از «مدیریت پرونده بیمار» به سمت «مدیریت تجربه کامل بیمار در طول فرآیند درمان» حرکت خواهد کرد؛ جایی که سیستم نه فقط ثبت‌کننده اتفاقات، بلکه هدایت‌کننده هوشمند جریان ارائه خدمت خواهد بود