مقاله Bill Siwicki در Healthcare IT News با عنوان Building an asynchronous telehealth model clinicians can use در 22 سپتامبر 2026، در ظاهر به موضوعی نسبتاً مشخص یعنی توسعه مدل مراقبت غیرهمزمان در تله‌هلث می‌پردازد، اما در واقع مسئله‌ای بسیار بنیادی‌تر را مطرح می‌کند: چگونه می‌توان یک قابلیت دیجیتال را از سطح فناوری و ارتباط با بیمار به سطح یک مدل عملیاتی پایدار برای ارائه خدمت بالینی ارتقا داد؟ این مقاله با استفاده از دیدگاه‌های Eric Poon، مدیر ارشد اطلاعات سلامت Duke Health و استاد پزشکی و انفورماتیک دانشگاه Duke، و Kathi Cox از Texas Health Resources، تأکید می‌کند که مشکل اصلی مراقبت غیرهمزمان، نبود فناوری نیست. فناوری ارسال پیام، دریافت اطلاعات، تبادل تصویر و سند، مشاهده سوابق بیمار و پاسخ‌گویی غیرهمزمان سال‌هاست وجود دارد. مسئله واقعی این است که وقتی این قابلیت در مقیاس وسیع وارد جریان کار نظام سلامت می‌شود، چه کسی باید درخواست را دریافت کند، چه کسی باید آن را بررسی کند، با چه اولویتی باید پردازش شود، حداکثر زمان پاسخ چقدر است، چه مواردی باید به تعامل همزمان تبدیل شوند، چه کسی مسئول Escalation است، فعالیت انجام‌شده چگونه در پرونده بیمار ثبت می‌شود و در نهایت هزینه این خدمت چگونه جبران خواهد شد.

از این منظر، پیام محوری مقاله را می‌توان در یک تمایز اساسی خلاصه کرد: مراقبت غیرهمزمان نباید به‌عنوان یک ابزار یا کانال ارتباطی جدید به زیرساخت موجود اضافه شود؛ بلکه باید به‌عنوان یک مدل جدید از سازمان‌دهی کار بالینی طراحی شود. این تمایز اهمیت زیادی دارد، زیرا تجربه بسیاری از سامانه‌های سلامت نشان داده است که افزودن یک قابلیت دیجیتال بدون بازطراحی فرآیند، معمولاً به جای حذف بار کاری، یک لایه جدید از کار را ایجاد می‌کند. بیمار تصور می‌کند که با ارسال یک پیام، فرآیند درمان ساده‌تر شده است؛ اما اگر همان پیام مستقیماً وارد Inbox پزشک شود و پزشک علاوه بر ویزیت‌های برنامه‌ریزی‌شده مجبور باشد پیام‌ها، درخواست تمدید دارو، پرسش درباره نتایج آزمایش، تصاویر ارسالی بیمار و سایر تعاملات غیرهمزمان را نیز بررسی کند، نتیجه می‌تواند افزایش بار کاری پنهان و کاهش پذیرش بالینی فناوری باشد. به همین دلیل مقاله تجربه پیام‌های الکترونیکی بیماران در Patient Portalهایی مانند MyChart را نمونه‌ای هشداردهنده می‌داند. پیام‌رسانی غیرهمزمان در اصل بخشی از مراقبت غیرهمزمان است، اما اگر برای آن ظرفیت اختصاصی، قواعد Routing، اولویت‌بندی، SLA و مسئولیت سازمانی تعریف نشده باشد، به یک صف اضافی بر دوش پزشک تبدیل می‌شود.

در مدل سنتی Telehealth، بخش قابل توجهی از عملیات بر اساس «قرار ملاقات» سازمان‌دهی می‌شود. بیمار زمان مشخصی دارد، پزشک در آن زمان ظرفیت مشخصی اختصاص داده است و Encounter در یک بازه زمانی معلوم شکل می‌گیرد. به همین دلیل ظرفیت منابع انسانی را می‌توان تا حد زیادی بر مبنای تقویم برنامه‌ریزی کرد. اما در مراقبت غیرهمزمان، واحد سازمان‌دهنده کار دیگر Appointment نیست؛ بلکه Request و Queue است. بیمار ممکن است در هر ساعت از شبانه‌روز درخواست خود را ارسال کند، در حالی که حجم و پیچیدگی درخواست‌ها در روزهای مختلف تغییر می‌کند. حتی دو درخواست با تعداد کلمات مشابه می‌توانند بار بالینی کاملاً متفاوتی داشته باشند. یک درخواست ممکن است صرفاً مربوط به تمدید یک داروی قبلی باشد، در حالی که درخواست دیگری ممکن است حاوی نشانه‌هایی از یک وضعیت بالقوه پرخطر باشد که نیازمند تماس فوری یا ارجاع به مراقبت حضوری است. بنابراین ظرفیت مورد نیاز برای مراقبت غیرهمزمان را نمی‌توان صرفاً با شمارش تعداد پیام‌ها یا درخواست‌ها محاسبه کرد؛ ظرفیت تابعی از حجم، پیچیدگی، ریسک، زمان پاسخ مورد انتظار و احتمال تبدیل درخواست به یک Encounter دیگر است.

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

۱. از تله‌مدیسین نوبت‌محور به مراقبت غیرهمزمان و مدیریت جریان کار بالینی

یکی از مهم‌ترین نکاتی که از مقاله می‌توان دریافت، تغییر ماهیت واحد اصلی خدمت در گذار از Telemedicine متعارف به Async Care است. در مدل نوبت‌محور، «جلسه» واحد اصلی خدمت است؛ در مدل غیرهمزمان، «پرونده درخواست» یا Clinical Request به واحد اصلی تبدیل می‌شود. این تغییر از نظر عملیاتی بسیار مهم است، زیرا در یک جلسه همزمان، زمان، ارائه‌دهنده و بیمار از پیش به یکدیگر متصل شده‌اند، در حالی که در یک تعامل غیرهمزمان این اتصال باید توسط خود سیستم ایجاد و مدیریت شود.

در نتیجه، سکو باید بتواند به‌صورت مداوم به این پرسش پاسخ دهد که «این درخواست چیست، چقدر اهمیت دارد، چه کسی باید آن را بررسی کند و تا چه زمانی باید پاسخ داده شود؟» این سؤال‌ها در سیستم‌های سنتی Scheduling کمتر به چشم می‌آیند، زیرا بسیاری از آنها پیشاپیش در زمان‌بندی و نوع Appointment نهفته‌اند. اما در Async Care این تصمیم‌ها باید در لحظه ورود درخواست اتخاذ شوند. به همین دلیل مقاله بر وجود یک مدل Tiered Operating Model تأکید دارد؛ مدلی که درخواست‌ها را بر اساس ریسک و نیاز به مداخله بالینی تفکیک می‌کند.

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

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

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

در نتیجه، یکی از دستاوردهای مفهومی مقاله این است که Async Care را باید با منطق Queue Management و Worklist Management طراحی کرد، نه صرفاً با منطق Messaging. پیام نقطه شروع تعامل است؛ اما ارزش واقعی زمانی ایجاد می‌شود که پیام به یک Case قابل مدیریت تبدیل شود. این Case باید مالک داشته باشد، وضعیت داشته باشد، اولویت داشته باشد، SLA داشته باشد، مسیر Escalation داشته باشد و در نهایت بسته شود.

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

۲. ادغام مراقبت غیرهمزمان با EHR و پرونده طولی بیمار

دومین پیام بسیار مهم مقاله، ضرورت ادغام مراقبت غیرهمزمان با EHR و Workflow موجود است. Poon این اصل را به‌صورت بسیار روشنی بیان می‌کند: طراحی باید بر مبنای Consolidation, not Addition باشد؛ یعنی هدف نباید اضافه کردن یک سیستم دیگر به محیط کاری پزشک باشد، بلکه باید اطلاعات و فعالیت‌های غیرهمزمان در همان جریان کاری موجود قرار گیرند.

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

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

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

در چنین مدلی، Async Care باید با عناصر اصلی پرونده بیمار پیوند بخورد؛ از جمله:

• Patient Identity و MPI؛
• ارائه‌دهنده و سازمان مسئول؛
• Encounterهای قبلی و جاری؛
• داروها و Medication History؛
• نتایج آزمایش و سایر Observations؛
• درخواست‌های تشخیصی و Service Requestها؛
• ارجاع‌ها و Care Pathwayها؛
• برنامه مراقبت و Follow-up؛
• و در صورت نیاز تصاویر، اسناد و داده‌های ارسالی بیمار.

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

از منظر معماری اطلاعات، می‌توان این زنجیره را چنین دید:

Patient Request → Clinical Context → Triage → Clinical Review → Decision/Action → Documentation → Longitudinal Record

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

این موضوع در معماری ملی سلامت اهمیت بیشتری پیدا می‌کند. اگر سکوهای سطح اول، HISهای بیمارستانی، سامانه‌های تخصصی و رجیستری‌ها هر کدام تعاملات غیرهمزمان خود را جداگانه نگهداری کنند، دوباره همان مسئله جزیره‌ای شدن داده‌ها تکرار می‌شود. بنابراین Async Care باید در سطح ملی نیز تابع اصول Interoperability و Longitudinal Record باشد.

در چنین معماری‌ای، ممکن است یک بیمار از طریق یک سیستم سطح اول درخواست خود را ثبت کند، اما بررسی نتیجه آزمایش به داده‌ای نیاز داشته باشد که از سکوی موضوعی آزمایشگاهی آمده است. پاسخ پزشک ممکن است به یک دارو یا Referral منجر شود و این رویداد نیز باید در معماری ملی قابل تبادل باشد. در نتیجه Async Care به‌طور طبیعی به لایه‌های FHIR، API، Identity، Consent، Terminology، Audit و Data Governance وابسته می‌شود.

مقاله همچنین بر مسئله مستندسازی تأکید ویژه دارد. اگر پزشک مجبور شود پس از هر تعامل غیرهمزمان، اطلاعات را دوباره در قالب یک Note وارد کند، بخش قابل توجهی از مزیت مدل از بین می‌رود. به همین دلیل مستندسازی باید از ابتدا بخشی از طراحی باشد. اطلاعات ارسالی بیمار، اقدامات انجام‌شده توسط پزشک و پاسخ نهایی باید بتوانند به شکل ساختاریافته وارد پرونده شوند و در صورت نیاز برای Billing، Quality Measurement و Audit نیز قابل استفاده باشند.

در این زمینه، AI می‌تواند نقش مهمی داشته باشد. سیستم می‌تواند محتوای درخواست بیمار و پاسخ پزشک را تحلیل و یک پیش‌نویس ساختاریافته از Clinical Note ایجاد کند. اما مقاله بر یک مرزبندی مهم تأکید دارد: AI می‌تواند مستندسازی را تسهیل کند، ولی مسئولیت بالینی را بر عهده نمی‌گیرد. پزشک یا تیم درمان باید مسئولیت تأیید نهایی و تصمیم بالینی را حفظ کند.

۳. هوش مصنوعی، مدیریت صف و بازطراحی نقش نیروی انسانی

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

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

برای نمونه، AI می‌تواند تشخیص دهد که یک درخواست احتمالاً مربوط به «Medication Refill» است، درخواست دیگری مربوط به «Lab Result Review» و مورد دیگری مربوط به «Symptom Assessment». همچنین می‌تواند بررسی کند که آیا اطلاعات ضروری برای رسیدگی وجود دارد یا خیر. اگر بیمار مثلاً برای ارزیابی یک وضعیت خاص اطلاعاتی را ارسال نکرده باشد، سیستم می‌تواند پیش از قرار گرفتن درخواست در Worklist پزشک، کمبود اطلاعات را مشخص کند.

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

کاربرد بعدی، Priority Recommendation است. AI می‌تواند بر اساس قواعد و مدل‌های معتبر، سطح ریسک احتمالی را پیشنهاد کند و مواردی را که احتمال نیاز به پاسخ سریع دارند بالاتر قرار دهد. اما اینجا نیز همان اصل حاکمیت انسانی که مقاله بر آن تأکید دارد اهمیت دارد: AI باید پیشنهاد دهد، اما مسئولیت نهایی طبقه‌بندی بالینی و اقدام باید در اختیار تیم درمان باقی بماند.

از این منظر، معماری مناسب می‌تواند چیزی شبیه این باشد:

AI-assisted Intake → Classification → Missing Information Detection → Summarization → Priority Recommendation → Human Validation → Routing

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

در عین حال، این مدل نیازمند Governance جدی است. اگر AI یک درخواست را اشتباه Low Risk تشخیص دهد و در نتیجه پاسخ آن به تأخیر بیفتد، مسئله صرفاً یک خطای نرم‌افزاری نیست؛ بلکه یک مسئله بالینی و حقوقی است. بنابراین سیستم باید امکان Audit تصمیمات، ثبت پیشنهاد AI، ثبت تصمیم نهایی انسان و تحلیل عملکرد مدل را فراهم کند.

از اینجا می‌توان به یک اصل مهم برای معماری AI در سلامت رسید: AI باید در جایگاهی قرار گیرد که ارزش عملیاتی ایجاد کند اما مسئولیت بالینی را به‌صورت نامرئی به الگوریتم منتقل نکند.

این مسئله به‌ویژه زمانی اهمیت پیدا می‌کند که مدل در مقیاس ملی پیاده شود. در یک مرکز کوچک، ممکن است پزشک شخصاً همه درخواست‌ها را ببیند؛ اما در مقیاس ملی، چنین مدلی امکان‌پذیر نیست. نیاز به طبقه‌بندی، Routing، Worklist و مدیریت ظرفیت اجتناب‌ناپذیر است. در چنین محیطی، AI می‌تواند یکی از اجزای مهم National Clinical Workflow Intelligence Layer باشد.

۴. مقیاس‌پذیری واقعی؛ از طراحی فناوری تا اقتصاد و حاکمیت خدمت

در نهایت، مقاله نشان می‌دهد که حتی اگر فناوری، EHR Integration، Routing، AI و Workflow به‌درستی طراحی شوند، هنوز یک سؤال اساسی باقی می‌ماند: آیا سازمان واقعاً می‌تواند این مدل را در مقیاس بزرگ و در بلندمدت حفظ کند؟

Cox در مقاله تأکید می‌کند که مانع اصلی گسترش Async Care فناوری نیست، بلکه ایجاد مدلی است که از نظر بالینی صحیح، از نظر مالی پایدار و از نظر عملیاتی با کل تجربه مراقبت بیمار یکپارچه باشد. این نکته شاید مهم‌ترین پیام سیاستی مقاله باشد.

هر خدمت جدیدی در نظام سلامت هزینه ایجاد می‌کند. برای Async Care این هزینه ممکن است کمتر از یک ویزیت حضوری باشد، اما صفر نیست. باید زیرساخت فناوری، Integration، نیروی انسانی، نظارت، پشتیبانی، امنیت، مستندسازی و در برخی موارد ظرفیت On-call فراهم شود. بنابراین اگر نظام پرداخت هیچ ارزش اقتصادی برای این خدمت قائل نشود، سازمان‌های سلامت ممکن است انگیزه کافی برای توسعه آن نداشته باشند.

در اینجا باید بین Cost Reduction و Value Creation تفاوت گذاشت. هدف Async Care لزوماً این نیست که همه تعاملات را ارزان‌تر کند. هدف می‌تواند این باشد که برای نوع خاصی از نیازهای بالینی، مناسب‌ترین modality انتخاب شود. اگر یک موضوع را می‌توان بدون Video Visit و صرفاً با بررسی پرونده و پاسخ غیرهمزمان حل کرد، الزام بیمار به رزرو یک جلسه و اختصاص یک بازه زمانی کامل برای پزشک ممکن است ناکارآمد باشد. اما اگر یک موضوع نیازمند معاینه یا گفت‌وگوی همزمان باشد، Async Care نباید جایگزین آن شود.

بنابراین مدل بالغ، Async-First به معنای «همه‌چیز غیرهمزمان» نیست؛ بلکه به معنای استفاده از غیرهمزمانی در جایی است که از نظر بالینی مناسب است و تبدیل سریع به تعامل همزمان در جایی که لازم است.

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

از طرف دیگر، موفقیت Async Care به همکاری چند گروه وابسته است: ارائه‌دهندگان خدمت، مدیران سازمان، فروشندگان EHR و پرداخت‌کنندگان. هر یک از این گروه‌ها بخشی از مدل را کنترل می‌کنند. اگر EHR Integration ضعیف باشد، پزشک با یک سیستم موازی مواجه می‌شود. اگر Staffing درست طراحی نشود، Queue متراکم می‌شود. اگر Payment Model مناسب نباشد، سازمان انگیزه اقتصادی کافی ندارد. و اگر Governance مشخص نباشد، مرز مسئولیت‌ها مبهم خواهد شد.

به همین دلیل، Async Care را باید یک Operating Model چندلایه دانست که حداقل چهار حوزه را هم‌زمان در بر می‌گیرد:

• Clinical Governance: تعیین صلاحیت خدمات، ریسک، مسئولیت و قواعد Escalation؛
• Operational Governance: مدیریت Queue، Routing، SLA، Staffing و On-call؛
• Information Governance: پرونده طولی، Privacy، Consent، Audit، Provenance و مستندسازی؛
• Financial Governance: تعرفه، پرداخت، هزینه و مدل اقتصادی خدمت.

اگر یکی از این چهار حوزه نادیده گرفته شود، مدل ممکن است از نظر فناوری کار کند ولی از نظر نظام سلامت پایدار نباشد.

جمع‌بندی تحلیلی

مقاله Building an asynchronous telehealth model clinicians can use در واقع بیش از آنکه مقاله‌ای درباره یک فناوری خاص باشد، درباره بازطراحی سازمان‌دهی مراقبت در عصر دیجیتال است. نویسندگان نشان می‌دهند که Telehealth در مرحله اولیه عمدتاً حول Video Visit و Appointment شکل گرفته بود، اما مرحله بعدی بلوغ آن می‌تواند به سمت مدل‌هایی حرکت کند که در آنها تعامل بالینی لزوماً به حضور همزمان بیمار و پزشک وابسته نیست. تحقق این گذار، با افزودن یک قابلیت جدید به Portal یا EHR اتفاق نمی‌افتد؛ بلکه نیازمند طراحی یک زنجیره کامل از دریافت درخواست تا تصمیم بالینی، مستندسازی، Escalation و ثبت در پرونده طولی بیمار است.

مهم‌ترین نکته مقاله این است که کاهش مراجعه حضوری یا کاهش تعداد Video Visit به خودی خود به معنای موفقیت نیست. اگر این کاهش با انتقال پنهان کار به Inbox پزشکان همراه شود، در واقع بار نظام سلامت فقط از یک محل به محل دیگر منتقل شده است. بنابراین موفقیت باید بر اساس شاخص‌هایی مانند زمان پاسخ، کیفیت تصمیم، نرخ Escalation، بار کاری ارائه‌دهندگان، رضایت بیمار، تکمیل مستندسازی، هزینه خدمت و پیامدهای بالینی ارزیابی شود.

در چنین برداشتی، معماری Async Care را می‌توان به‌صورت یک چرخه کامل دید:

Patient Request → Intake → Risk/Triage → Routing → Clinical Review → Response/Action → Escalation if Needed → Documentation → Longitudinal Record → Measurement & Reimbursement

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

از منظر معماری ملی سلامت، این موضوع حتی یک گام فراتر می‌رود. مراقبت غیرهمزمان می‌تواند یکی از مصرف‌کنندگان و تولیدکنندگان اصلی خدمات سکوهای ملی سلامت باشد. یک درخواست غیرهمزمان ممکن است برای پاسخ به داده آزمایشگاهی نیاز داشته باشد؛ ممکن است به Medication Record، سابقه بیماری، Referral یا Encounter قبلی مراجعه کند؛ و پاسخ آن نیز می‌تواند یک ServiceRequest، Medication تغییر‌یافته، Referral یا Follow-up ایجاد کند. بنابراین Async Care در یک معماری ملی باید به‌صورت یک Clinical Interaction & Workflow Layer دیده شود که بر روی زیرساخت‌های هویت، FHIR، API Gateway، EHR، Terminology، Consent، Audit و Data Governance عمل می‌کند.

در این چارچوب، EHR دیگر صرفاً مخزن داده نیست و Telehealth نیز صرفاً یک کانال ارتباطی نیست. EHR باید زمینه بالینی را در اختیار Workflow قرار دهد و Telehealth باید بتواند این زمینه را به یک تعامل بالینی تبدیل و نتیجه آن را دوباره به پرونده بازگرداند. در چنین معماری‌ای، Async Care می‌تواند از یک «پیام بیمار به پزشک» به یک رویداد قابل مدیریت در چرخه مراقبت بیمار تبدیل شود.

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

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

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

این دقیقاً همان نقطه‌ای است که مقاله از یک بحث درباره Asynchronous Telehealth به یک بحث وسیع‌تر درباره معماری نسل بعدی ارائه خدمات دیجیتال سلامت تبدیل می‌شود.