ترجمه مقاله طراحی دانش محور سیستم های پشتیبان تصمیم

طراحی دانش محور سیستم های پشتیبان تصمیم برای مدیریت اورژانس

Knowledge-centered design of decision support systems for emergency management

 

چکیده

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

 

کلمات کلیدی: سیستم های پشتیبان تصمیم، طراحی دانش محور، مهندسی دانش، مدیریت اورژانس

سفارش ترجمه تخصصی مهندسی کامپیوتر

 

 

1. مقدمه

مدیریت اورژانس، فعالیت های مختلفی را در بر می گیرد از جمله آموزش و آماده سازی، شناسایی سیگنال اولیه، برنامه ریزی، کاهش، پاسخ و بازیابی که معمولا برای مقابله با وقایع احتمالا فاجعه انگیز ناشی از خطرات طبیعی یا رفتار انسان انجام می شوند ]18[. در واقع، یک موقعیت اورژانسی ممکن است تاثیر بسیار زیادی بر روی هز کسب و کار، تامین کننده ی خدمات، جامعه و خانواده در یک کشور داشته باشد، نه فقط به دلیل بیماری یا جان باختن، بلکه برای تاثیرات منفی که بر روی نیروی کار، موجوریت کالاها و خدمات و شرایط کلی اقتصادی و اجتماعی دارد. یک مدیریت ساختاری و هماهنگ شده باید مهیا شده و پیامدهایی که یک موقعیت اورژانسی ممکن است از آن ناشی شود را به حداقل برساند. رویکردهای مختلف در مورد مدیریت اورژانس می تواند در ادبیات و تحقیقات جاری یافت شود. می توان آنها را به سه دسته تقسیم کرد: 1) راه حل های مبتنی بر رسانه اجتماعی ]8، 21، 39[، که هدف آن بهبود مبادله و مشارکت اطلاعات و مشارکت شهروندان می باشد 2) سیستم های اطلاعات مدیریت اورژانس ]2، 9، 42[ که برای بیان مشکل ایجاد ارتباطات و هماهنگ سازی در میان نهادهای مستقل می باشد که ممکن است اهداف مختلف و رقابتی داشته باشد که در آن یک کنترل مرکزی غایب است و 3) سیستم های پشتیبان تصمیم ]6، 15، 45[ که برای تامین مدیران اورژانس با شاخص هایی برای انتخاب در میان دوره های جایگزین اقدامات در موقعیت های پیچیده و غیر مطلق پیشنهاد شذه است.

با بررسی دقیق تر سومین طبقه از رویکردها، می توانیم مشاهده کنیم که سیستم های پشتیبان تصمیم (DSS) معمولا در موقعیت های اورژانس خاص بکار گرفته می شود – برای مثال، موقعیت های اضطراری رادیولوژیکی ]34[، زلزله ها ]12[، اورژانس های بهداشتی درمانی ]20[ - یا برای بیان جنبه های خاصی از مدیریت اورژانس مانند آگاهی از موقعیت ]35[، تعبیه (ابتکار) ]24[ و آگاهی از زمینه ]25[. اصولی که طراحی این سیستم ها مبتنی بر آنها هستند غالبا وابسته به دامنه هستند، تنها رویکردهای سیستماتیک و به ندرت کلی درمورد طراحی و توسعه ی DSSها در ادبیات پیشنهاد شده اند. در میان نمونه های اندک، چارچوب دانش محور پیشنهاد شده در ]10[ را ذکر کرده ایم که از فناوری های وب معنایی برای مدلسازی دامنه کاربرد و نقشه های شناختی فازی در جهت ارائه برنامه های اورژانس استفاده می کند؛ احمد و همکاران ]3[ یک مولد DSS فرآیند و سناریو محور را ارائه می دهد؛ سرانجام، این کار در ]25[ توصیف می شود، اگرچه متمرکز بر آگاهی نسبت به زمین است، یک نظریه طراحی سطح بالا را برای کنترل تصادف زمان واقعی پیشنهاد می دهد.

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

با عمیق تر شدن در مسئله ی طراحی، پارادایم طراحی کاربر محور در ادبیات اخیر در مورد مدیریت اورژانس به عنوان یکی از با دوام ترین رویکردها در طراحی DSS می باشد (برای مثال، مراجعه کنید به ]5، 7، 29[). طراحی کاربر محور باید کاربران را در فرآیند طراحی دخیل کند، از نیاز و تجزیه و تحلیل وطیفه گرفته تا آزمایش کاربردپذیری؛ از این طریق، کاربران می توانند به طور مستقیم در چگونگی شکل گیری سیستم ها تاثیرگذار باشند ]1، 28[. با تازگی، دونالد نورمن اخطار داد که برآورده ساختن نیازهای کاربر نباید بیشتر از حد تخمین زده شود؛ "گوش کردن به مشتریان همیشه عاقلانه است، اما تن در دادن به نیازهای آنها می تواند به طراحی های بسیار پیچیده منجر شود" ]27[. کاربران لزوماً نمی دانند که چه چیزی برای آنها خوب است. در ضمن، کاربران مختلف ممکن است نیازهای گوناگونی را بیان کنند و در نتیجه برآورده ساختن نیازهای یک کاربر ممکن است به مفهوم غفلت از نیازهای کاربر دیگر باشد. طراحی کاربر محور، اگرچه مهم است، ممکن است کافی نباشد و در برخی موارد حتی ممکن است مضر نیز باشد. بنابراین، نورمن بر این باور است که طراحی فعالیت محور نسبت به رویکرد کاربر محور صرف برتری دارد و باید در اغلب موارد ارجح باشد ]27[. در واقع، هنگامیکه طراحی کاربر محور بر روی آنچه یک کاربر برای خودش خوب در نظر می گیرد متمرکز است، طراحی فعالیت محور از نیاز به در نظر گرفتن آنچه واقعا برای یک کاربر که فعالیت خاصی را انجام می دهد پشتیبانی می کند. تفاوت بین این موضع بسیار واضح است: زمانیکه موضع اول درونی تر و ذهنی تر است و مسئولیت طراحی را به دوش کاربر می گذارد، موضع دوم، برونی تر و عینی تر است و طراح را در نقش اصلی خود حفظ می کند.

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

هدف دوم از کار ما، ارائه ی یک رویکرد جدید برای طراحی DSS می باشد که نه فقط بر کاربران و فعالیت آنها، بلکه بر دانش مربوط به محیطی که کاربران در آن عمل می کنند و DSS بکار گرفته خواهد شد نیز تمرکز دارد. موضع ما این است که اگر کاربران بتوانند نیازها و اولویت های خود را بیان کنند، و تجزیه و تحلیل فعالیت آنها بتواند وظیفه های واقعی زیادی را که آنها مسئولشان هستند را نشان دهد، تنها بررسی محیط بزرگتر می تواند امکان شناسایی اهداف واقعی، محدودیت ها، فرآیندها و قواعد فعالیت تصمیم گیری را فراهم سازد. ما این رویکرد جدید را "طراحی دانش محور" می نامیم، زیرا محور آن بر دانش است: دانش در مورد کاربران DSS، فعالیت هایی که آنها باید با پشتیبانی از DSS انجام دهند و محیطی که در آن DSS بکار گرفته خواهد شد. طراحی دانش محور مبتنی بر یک مفهوم تکاملی می باشد که در آن یک طراحی می تواند مرحله به مرحله از طریق یک فرآیند پیشرفتی از اتخاذ دوگانه تا یک طراحی بهتر پیش رود که در آن، هر گروه دخیل – کاربر، سیستم و محیط – می تواند چیزی را بر دیگران تحمیل کرده و تحمیل های ورودی را قبول و یا رد کند. هدف روش طراحی دانش محور ما، تعویض طراحی کاربر محور یا فعالیت محور نیست، بلکه این مفاهیم را در یک چارچوب بزرگتر قرار می دهد و در نتیجه کل فرآیند طراحی را تقویت می کند. علاوه بر آن، به قدرت بیشتری یک رویکرد مشارکتی طراحی را ارتقاء می بخشد ]36[ که در آن، موضوعات مختلف – مدیران، فرآیند و متخصصان سازمان، متخصصان دامنه و پرسنل عملیاتی – در فرآیند طراحی دخیل هستند و دانش و تجربه ی ویژه ی خود را به ارمغان می آورند.

این مقاله به صورت زیر تنظیم شده است: بخش 2، یک نگاه کلی در مورد روش طراحی دانش محور را ارائه می دهد؛ بخش 3، یک مطالعه ی موردی HEALTHREATS را نشان می دهد؛ بخش 4 تا 7، در مراحل فردی روش شناختی متمرکز بوده و آنها را به صورت مفصل با رجوع به مطالعه ی موردی بررسی شده بیان می دارد؛ بخش 8، ویژگی های اصلی نمونه اولیه DSS بکارگرفته شده را توصیف می کند و بخش 9، در مورد نتایج اصلی ارزیابی DSS گزارش می دهد و در نهایت، بخش 10، در مورد نتایج بدست آمده صحبت کرده و مسائل مربوط به تحقیقات آینده را بیان می کند.

 

2. طراحی دانش محور: روش در یک نگاه

2-1 مراحل

هسته ی طراحی دانش محور، بررسی انواع مختلف دانش می باشد که در طراحی یک DSS دخیل هستند: 1) دانش در مورد محیط هدف که DSS در آن بکار گرفته خواهد شد، 2) دانش در مورد وظایف کاربر و 3) دانش در مورد ویژگی های کاربر و الگوهای تعامل. برای برطرف کردن این نیاز در یک روش ساختاری و موثر، یک روش طراحی دانش محورف همانطور که در شکل پایین (شکل 1) نشان داده شده است، در چهار مرحله تعریف شد:

1- شناسایی محیط هدف. هدفس این مرحله توسعه ی یک درک عمیق از بخشی از جهان واقعی است که DSS در آن بکار گرفته می شود، از جمله تمامی سهامداران که بطور مستقیم یا غیر مستقیم تحت تاثیر سیستم، اعمال کاری آنها، ابزار مورد استفاده برای تعامل و همچنین شرایط اجتماعی و فیزیکی که در آن عمل می کنند قرار خواهند گرفت.

2- درک دامنه. هدف از درک دامنه، شناسایی، جمع آوری و ارائه تمامی دانش های مربوط به دامنه ای خاص از DSS          می باشد از جمله نهادها و فرآیندهای پایه که دامنه را مشخص می سازند، کارهای انجام شده توسط مدیران اورژانس و دانش لازم برای انجام کار به صورت درست و موثر.

3- توصیف صفات اختصاصی کاربر. این مرحله مربوط به تمامی جنبه های طراحی می باشد که بر روی کیفیت تعامل و قبل از همه بر روی کیفیت تاثیر می گذارد. بنابراین، طبقات مختلف کاربران که انتظار می رود با DSS کار کنند شناسایی می شود و نیازها، اهداف، اولویت ها، سابقه و ویژگی های اجتماعی آنها روشن می شوند. در نتیجه، الزامات تعامل تعریف می گردند.

4- تجزیه و تحلیل عملکردی. در نهایت، عملکردهای خاصی که انتظار می رود DSS تامین کند مورد تجزیه و تحلیل قرار می گیرند و ویژگی های رفتار سیستم به تفصیل بیان می گردد

همانطور که می توان اشاره کرد، مراحل (1) تا (4) دارای یک طیف باریک تر می باشد و بر انواع مختلف دانش متمرکز است. با شروع از هدف محیط که در آن DSS به کار گرفته می شود، به نوبه ی خود دامنه ی کاربرد، کاربران مورد نظر و در نهایت عملکردهایی که سیستم باید آنها را تامین کند را در نظر می گیرند. سپس، طراحی DSS با مرحله ی توسعه پیگیری            می شود و زمانی که نمونه اولیه DSS  تبیین شد، مرحله ی ارزیابی لازم است تا عملکرد آن را هم در تنظیمات و شرایط تجربی و هم محیط هدف ارزیابی کند.

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

 

2-2 تکنیک ها

بکارگیری روش اشاره شده در بخش قبلی نیاز به در دسترس بودن تکنیک های سالم دارد. این چهار مرحله از طراحی بر اساس یک فعالیت مشترک و اساسی به نام کسب و مدلسازی دانش می باشد ]17[. برای این هدف، یک روش کسب دانش اتخاذ گردید که می تواند با شخصی سازی های مربوطه برای هر یک از چهار مرحله ی بالا بکار گرفته شود. این روش در پنج مرحله همانطور که در شکل زیر نشان داده شده (شکل 2) تنظیم شده است.

(1) استنباط، ذهن اصلی و نقطه نظرات مدیران، متخصصان دامنه و کاربران را با هدف آشکار ساختن دانش، نیازها و انتظارات آنان جمع آوری کرده و تجزیه و تحلیل می کند. این مرحله هم بر دانش سطح که می تواند از طریق مصاحبه های ساده بدست آید و هم دانش عمیق ]31[ که نیاز به درونگرایی و تجزیه و تحلیل بیشتر دارد تا با عبارات کلامی بیان گردد تمرکز دارد. تمامی تکنیک های جدید برای کسب دانش از جمله پرسشنامه، مصاحبه های فردی و گروهی و مشاهدات طبیعی ممکن است بکار گرفته شوند. اطلاعات مهم ممکن است از طریق اسناد موجود در مورد موضوعات خاص در دسترس و منابع اطلاعاتی تر غیر رسمی تر مانند یادداشت هی شخصیریال اسناد فنی و به ویژه کتاب سوابق اورژانس های قبلی بدست آیند.

(2) مدلسازی، دانش بدست آمده از طریق استنباط را ترکیب کرده و یک طرح سند را ایجاد می کند به شکلی که تمامی افراد حاضر در فرآیند طراحی می توانند آن را به سادگی و بدون ابهام متوجه شوند. این امر، هم بر دانش واقعی شامل نهادها، ویژگی ها و روابط دامنه و هم بر دانش رویه ای (فرآیندی) در مورد اقدامات، فعالیت ها و فرآیندها تمرکز دارد.

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

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

(5) معتبرسازی، طراحی توسعه یافته برای دستیابی به تایید نهایی ازتمامی گروه های درگیر را بررسی می کند. معتبرسازی، آخرین ولی شاید مهمترین مرحله ی کسب دانش باشد، زیرا کمبود ارزیابی نهایی و یک ستایید رسمی طرح ممکن استباعث ایجاد مشکلات جدی درباره ی کیفیت DSS در حال توسعه باشد.

کسب دانش یک فرآیند تکرار شونده ی معمولی می باشد و برای رسیدن به یک نتیجه ی سالم، باید از چندین چرخه عبور کند.

 

3. آزمایش طراحی دانش محور

روش طراحی دانش محور که در بخش 2 معرفی شده است، نسخه ی اولیه ی آن اولین بار در قالب یک پروژه ی یک ساله ]32[ در مورد پشتیبانی تصمیم در مدیریت اورژانس پیشنهاد شده که بودجه ی آن توسط رجیون لومباردیا از ایتالیا در سال های 2004-2005 تامین گردید. در این زمینه، ویژگی های اساسی این روش شناسایی گردید و در طراحی یک DSS برای کمک به مدیران اورژانس در مورد زمین لرزه به صورت عملی مورد آزمایش قرار گرفت. دو سال بعد، پروژه HEALTHREATS ]33[، که تامین بودجه ی آن توسط اتحادیه اروپا در سال های 2007-2010 نیز انجام شد، موقعیت واقعی را برای توسعه ی روش طراحی دانش محور برای پتانسیل کامل خود و برای آزمایش آن در یک مورد وسیع تر در مورد مسئله ی اورژانس آنفولانزای همه گیر پیشنهاد داد. پروژه HEALTHREATS شامل یازده شریک از پنج کشور ایتالیا، رومانی، اسلونی، پرتغال و اسپانیا بود. هدف اصلی آن، توسعه ی یک DSS ابتکاری برای کمک به نهادهای مسئول بهداشت و درمان عمومی در جهت تصمیم گیری در مورد راه اندازی و مدیریت مداخلات عملیاتی در پاسخ به آنفولانزای همه گیر بود. به عنوان نقطه ی شروع در پروژه ما، نسخه های مربوطه در سازمان بهداشت جهانی مورد فرض قرار گرفتند، همانطور که در "برنامه آمادگی آنفولانزای جهانی سازمان بهداشت جهانی" مشخص شده بود ]44[، که اهداف اولیه و توصیه های مربوط به توسعه ی برنامه های آمادگی را برای مقامات بهداشت کشوری مهیا می سازد، تصمیم گرفته شد بر روی مراحل 4، 5 و 6 متمرکز شوند که در مورد دوره ی هوشیاری همه گیر و دوره ی همه گیر می باشد (جدول 1). فعالیت پروژه به صورت اولیه بر روی مورد ایتالیایی به نام ASL Brascia (یک مقام بهداشت محلی مهم) تمرکز کرده بود که زمینه ی مناسب را برای کسب دانش، طراحی DSS و ارزیابی پیشنهاد داده بود. بعد از آن، نمونه اولیه DSS به دیگر شرکای پروژه HEALTHREATS منتقل شد و در موارد عملی گوناگونی سمورد بررسی قرار گرفت. در بخش های 4 تا 7، به صورت مفصل سمراحل روش طراحی دانش محور بکار گرفته شده برای طراحی نمونه اولیه DSS توسعه یافته در چارچوب پروژه HEALTHREATS را توضیح می دهیم.

جدول 1. مراحل و دوره های زمانی همه گیر سازمان بهداشت جهانی

 

4. شناسایی محیط هدف

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

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

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

نتایج اصلی بدست آمده در این مرحله در بخش های بعدی توضیح داده شده اند.

 

4-1 سناریوی اورژانس

یک اورژانس، موقعیتی است که مستقل از قابل پیش بینی بودن و سطح آمادگی، باعث تغییرات ناگهانی و قوی در زمینه ای خاص با تاثیرات گسترده بر روی محیط و جامعه می شود و به یک مداخله ی سریع و جامع از سوی تمامی گروه های دخیل، از نهادهای دولتی گرفته تا خود شهروندان نیاز دارد. به عبارت کلی، در یک اورژانس، پنج طبقه ی اصلی از سهامداران دخیل می باشند: 1) جمعیت تاثیر، از جمله کسانی که به صورت مستقیم تحت تاثیر وقایع که حالت اورژانس را مشخص می کنند قرار می گیرند؛ 2) جمعیت زمینه، مربوط به افرادی که به هر نحوی به جمعیت تاثیر مربوط می شوند، اما به صورت مستقیم تحت تاثیر وقایع قرار نمی گیرند، از خویشاوندان و دوستان افرادی که متعلق به جمعیت تاثیر می باشند گرفته تا افرادی که به صورت ساده از طریق روزنامه، رادیو، تلویزیون و اینترنت از وقایع مطلع می شوند؛ 3) کارکنان دخیل، شامل تمامی         افراد حرفه ای و داوطلبان که در مدیریت اورزانس دخیل هستند؛ 4) واحد مدیریت اورژانس، که مسئول برنامه ریزی، هماهنگی و کنترل اقدامات انجام شده توسط کارکنان دخیلی می باشند، و 5) نهادها (موسسات) دخیلی در مدیریت اورژانس در سطوح محلی، دولتی و جهانی.

در این زمینه، تعاملات متعددی اتفاق می افتند، هم به صورت داخلی در هر طبقه از سهامداران و هم در میان آنها. بر اساس این تعاملات، محیط اورژانس می تواند به چهار سطح تقسیم شود:

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

این سناریو در شکل 3 نشان داده شده است.

نیاز ویژه به DSS برای راهنمایی و پشتیانی واحد مدیریت اورژانس به صورت عمده شناسایی شده است ]6، 15، 42[. بنابراین، در ادامه، تنها بر سطح مدیریت تمرکز خواهیم داشت.

 

4-2 وظیفه ی مدیریت اورژانس

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

مدیران اورژانس تمامی این وظایف را در یک زمینه با ویژگی های خستگی، فشار، اضطراب و مسئولیت بیش از حد اجرا می کنند. در این کار، آنها باید با قواعد رسمی مطابقت داشته باشند و برنامه های اورژانس اعلام شده را بکار گرفته، راه حل هایی برای مسائل جدید یافته، به صورت پویا با این موقعیت متغیر سریع منطبق شوند و به سرعت به وقایع درون زمینه ی اورژانس و درخواست های رسیده از نهادها پاسخ دهند. این وظایف غالباً دانش زیادی را می طلبند و نیاز به مدیران اورژانس دارند تا همه ی مهارت ها و تجربیات خود را در جهت همکاری به کار گیرند. در واقع، مدیریت اورژانس، فعالیتی همکارانه است که در آن متخصصان متعددی باید اطلاعات را به اشتراک گذاشته و در یک فرآیند تصمیم گیری بسیار تعاملی شرکت کنند ]5[.

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

 

4-3 پارادایم پشتیبانی تصمیم

رویکردهای متعددی برای پشتیبانی از تصمیم وجود دارند ]15[، از رویکرد صرفاً اطلاعاتی گرفته تا پارادایم های اصولی قوی. هدف پشتیبانی اطلاعاتی، بهبود کیفیت تصمیمات انسان از طریق تامین اطلاعات بیشتر برای تصمیم گیرندگان می باشد که می تواند در تجزیه و تحلیل موقعیت جاری و ارزیابی جایگزین ها کمک کند. در هر حال، در مورد اورژانس با مقیاس بزرگ، یک رویکرد صرفاً اطلاعاتی نمی تواند موثر باشد: پشتیبانی تصمیم نباید داده های بیشتری را در اختیار مدیران قرار دهد، اما می تواند اطلاعات متمرکز کمتری را فراهم سازد. هدف پشتیبانی هنجاری، از سوی دیگر، کمک مستقیم به تصمیم گیرندگان از طریق یک پیشنهاد نهایی، شاید بهترین پیشنهاد موجود و آماده ی استفاده می باشد. در یک معنا، هدف آن تعویض تصمیم گیرندگان در تمامی موارد ممکن و حل مسئله ی تصمیم در ریشه می باشد. به سختی می توان یک رویکرد هنجاری قوی را در مدیریت اورژانس بکار گرفت، زیرا به صورت عملی، پیش بینی تمامی موارد ممکن که احتمال دارد اتفاق بیفتد و شناسایی یک استراتژی دخالتی مناسب برای هر یک از آنها در هر زمینه ای غیر ممکن است. علاوه بر آن، یک پشتیبانی هنجاری بسیار قوی ممکن است مسائل پذیرشی را ایجاد کند زیرا بدون توجیه، مدیران اورژانس ممکن است به پایبندی به پیشنهادات اعلام شده توسط DSS علاقه ای نداشته باشند.

یک تجزیه و تحلیل دقیق تر در مورد رفتار مدیران اورژانس نشان می دهد که اغلب تصمیماتی که آنها می گیرند ساده است: در جلوی این مسئله، فقط یک راه حل ممکن وجود دارد، که برای متخصصان مدیریت اورژانس شناخته شده است. تمامی این تصمیمات را می توان بر پایه دانش دامنه موجود اتخاذ کرد و به صورت عمده بر قواعد رسمی و پروتکل های پاسخ اثبات شده اتکا کرد. از سوی دیگر، تنها تعداد اندکی از تصمیمات واقعا موفق و به صورت ذاتی پیچیده هستند و نیاز با توجه بسیار از سوی مدیران اورژانس دارند. اکثر آنها شامل سه جنبه می باشند: (1) انتخاب از میان برنامه های دخالتی مناسب برای رویارویی یا یک موقعیت خاص؛ (2) تعریف یک برنامه ی جدید در مقابل وقایع نادر و خاص که عملیات استانداردی برای آنها وجود ندارد و (3) جاسازی و تعبیه ی منابع که عموماً برای فعالیت هایی که باید انجام شوند کافی نیستند. بر اساس این مشاهدات، یک پارادایم پشتیبان تصمیم بر اساس دو فرضیه اصلی زیر تایید شده اند:

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

بنابراین، رویکرد حاصله در مورد پشتیبانی تصمیم یک مورد ترکیبی است که بر پایه دو پارادایم متفاوت می باشد که         زمینه های تصمیم گیری متفاوتی را بر اساس پیچیدگی آنها همانطور که در ]37[ پیشنهاد شد می باشد.

5. درک دامنه

هدف از درک دامنه کسب تمامی دانش مربوط به دامنه صلاحیت خاص از DSS می باشد که برای موارد زیر ضروری است:

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

دوباره روش کسی دانش که در بخش 2-2 نمایش داده شده با پشتیبانی دو مهندس دانش بکار گرفته شد. در مرحله ی استدلال، هفت متخصص دامنه حضور داشتند، که جامعه ای ناهمگن از افراد حرفه ای که مسئول مدیریت یک اورژانس آنفولانزای همه گیر از دامپزشکی و پیشگیری ها پزشکی تا مراقبت های بهداشتی اولیه و کمک های اورژانسی، مراقبت های خانگی و خدمات پرستاری، فعالیت های اجتمعای بهداشتی و امنیت عمومی بودند را ارائه داد. در وهله ی اول، دو پرسشنامه به متخصصان دامنه داده شد، پرسشنامه ی اول بر نیازها و اهداف متخصصان دامنه و سازمان واحد مدیریت اورژانس تمرکز داشت و پرسشنامه ی دوم، اطلاعات مربوط به پایگاه ها داده و اسنادی که مدیران اورژانس معمولا در کارشان استفاده می کنند را جمع آوری کرد. در ادامه، مهندسان دانش بر دانش عمیق متمرکز شدند }31[؛ گروه های مشاهده ی طبیعی و تمرکز کمک زیادی به این فعالیت کردند.

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

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

 

5-1 ساختار سازمانی

از تجزیه و تحلیل دامنه ی انجام شده مشخص شد که یک سازمان سلسله مراتبی برای مدیریت اورژانس موفق لازم است. چهار مسئله از نیاز به یک سلسله مراتب پشتیبانی می کنند:

• یک اختصاص منطقی از نقش ها و وظایف برای اجزای مختلف واحد مدیریت اورژانس
• یک جداسازی شفاف از مسئولیت ها
• یک تعریف دقیق از جریان اطلاعات
• یک زنجیره دستور کارآمد بین نقش های مختلف، به ویژه، بین واحد مدیریت اورژانس و کارکنان دخیل

تجزیه و تحلیل دامنه نشان می دهد که مدیریت اورژانس بهداشت شامل سطوح زیر می باشد:

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

 

5-2 موضوعات پشتیبانی تصمیم

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

 

5-2-1 وقایع

یک واقعه (رخداد) واقعیتی است که در زمانی خاص و در مکانی خاص در زمینه ی اورژانس اتفاق می افتد که برای فرآیند مدیریت بسیار مهم است. این مفهوم نه فقط شامل وقایع خاص می باشد که از اورژانس نشات می گیرد (زمین لرزه، عفونت ویروسی مسری، حمله ی تروریستی و ...)، بلکه پیامدهای آنها (آسیب های وارده به کارخانه ی پر خطر، آلودگی آب، عدم دسترسی به شبکه های ارتباطی و ...) و تاثیرات اقدامات انجام شده توسط کارکنان دخیل برای رویارویی به اورژانس (بازیابی یک وسیله ی برقی، فعالسازی کمک به افراد مجروح، اجرای بررسی های ایمنی برای ساختمان های صدمه دیده و ...) را نیز شامل می شود. در مطالعه ی موردی ما، 14 نوع واقعه ی اولیه شناسایی شدند که نشان دهنده ی وقایع اصلی می باشند که در یک اورژانس همه گیر (مسری) اتفاق می افتد و باید مدیریت شود. نمونه های وقایع اولیه عبارتند از: شیوع مشکوک آنفولانزاری مرغی در یک مرغداری، خطر سرایت به انسان، مورد انسانی مشکوک، حضور خوشه های انسانی مشکوک و نیاز به واکسیناسیون گسترده.

 

5-2-2 برنامه ها

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

 

5-2-3 منابع

هر اقدام از یک برنامه نیاز دارد که موجودیت منابع اجرا شوند. به طور کلی، یک منبع ممکن است توسط یک نوع، یک مکانی که در آن موجود است، و یک کمیت شناسایی شود. علاوه بر آن، منابع می توانند قابل مصرف (یک کمیت مشخص از منبع مصرف می شود) یا قابل استفاده مجدد باشند (منبع ممکن است به محض موجود شدن پس از استفاده، قابل استفاده مجدد باشد). سرانجام، منابع را می توان به منابع انسانی، منابع مادی و منابع اطلاعاتی طبقه بندی کرد. در پروژه HEALTHREATS، منابع انسانی اصلی زیر شناسایی شده اند: کارکنان مقامات بهداشتی، پزشکان، دکرتان، پرستاران و کارگران اجتماعی. منابع مادی به چند دسته طبقه بندی شده اند: تخت ها در بیمارستان ها و دیگر ساختارهای مراقبتی، داروهای ضد ویروسی، واکسن ها، تجهیزات محافظت فردی، ابزار شناسایی، مواد ضد عفونی و دیگر داروها. سرانجام، منابع اطلاعاتی شامل دو طبقه از موضوعات هستند: اسناد مرجع و فرم هایی که باید پر شوند. اسناد مرجع برای تامین پشتیبانی اطلاعاتی از کاربران در نظر گرفته شده اند و مثلا شامل قواعد، توصیه های رسمی و روندهای عملیاتی می باشند. هدف این فرم ها تولید گزارش های فنی لازم برای تضمین یک ارتباط درست و به موقع با نهادهای دخیل می باشد. این فرم ها باید اعمال گزارشگری محلی دامنه ی خاص را انعکاس دهند و می توانند در زمان لزوم توسط مدیران اورژانس دانلود و تکمیل شوند. هم اسناد مرجع و هم فرم ها با موقعیت های خاصی که باید در آنها استفاده شوند در ارتباطند به شکلی که در لحظه ی درست و در موقعیت درست به کاربران عرضه شوند.

 

6. توصیف کاربران

هدف از سومین مرحله ی روش دانش محور، شناسایی و توصیف طبقات کاربر می باشد که از DSS استفاده و نیازهای تعاملی آنها را استدلال خواهد کرد. در پروژه HEALTHREATS، یک تیم شامل دو مهندس دانش، دو متخصص تعامل انسان-رایانه، هشت کاربر نماینده و هفت متخصص دامنه از این مرحله استفاده کرده اند.

اول از همه، همانطور که در جدول 2 نشان داده شده است، هفت طبقه از کاربران شناسایی شده اند. سپس، سناریوهای تعاملی بین کاربران متعلق به طبقات شناسایی شده و DSS شناسایی شده اند. هشت مورد استفاده، که به پنج مورد استفاده هنجاری و سه مورد استفاده اطلاعاتی تقسیم شده اند طراحی شده اند؛ در وهله ی اول، آنها در زبان طبیعی بر اساس         نمونه ی از قبل تعریف شده و سپس، پس از تکرار عملیات و پالایش با کاربران و متخصصان دامنه، از طریق نمودارهای UML رسمی مستند شدند ]14[. در نهایت، توجه بر روی نمونه های تعاملی بین کاربران و DSS متمرکز شد، این جنبه ها از طریق پنج نمودار فعالیت UML ارائه شدند.

 

7. تجزیه و تحلیل توابع (عملکردها)

در نهایت، چهارمین مرحله از روش دانش محور بر روی توصیف مفصل نیازهای عملکردی (تابعی) DSS که مرجع اساسی توسعه ی سیستم را تشکیل می دهد متمرکز می شود. این مرحله در دو گام سازماندهی شده است: گام اول، تجزیه و تحلیل نیازهای کلی و گام دوم، استدلال و مدلسازی دانش مربوط به برنامه های وقایع و دخالتی.

 

7-1 نیازهای کلی

دو طراح نرم افزار با همکاری با مدیران، متخصصان دامنه و کاربران، 77 نیاز عملکردی را شناسایی کردند که به 8 حوزه تقسیم می شوند: (1) مدیریت وقایع، برنامه ها و اقدامات، (2) اطلاعات مربوط به موقعیت اورژانس، (3) مدیریت منابع مادی، (4) مدیریت منابع انسانی، (5) مدیریت منابع اطلاعات، (6) نقشه جغرافیایی، (7) مدیریت دانش و پایگاه های داده و (8) مدیریت سیستم و کاربر. با توجه به تعداد بالای نیازهای شناسایی شده و منابع محدود پروژه، سه طبقه از اولویت ها تعریف شدند: "اجباری"، "پیشرفته" و "خوب".

 

7-2 مدلسازی وقایع و برنامه ها

سه مهندس دانش، هفت متخصص دامنه، دو مدیر و چهار کاربر برای استدلال و مدلسازی دانش مربوط به وقایع و              برنامه های از پیش شناسایی شده در مرحله ی درک دامنه با هم همکاری کردند (بخش های 5-2-1 و 5-2-2). در وهله ی اول، هفت مصاحیه ی فردی با متخصصان دامنه به مهندسان دانش این اجازه را داد که تمامی وقایع ممکن را تجزیه و تحلیل کرده و برنامه های دخالتی مربوطه را مدلسازی کنند. از آنجا که برنامه های دخالتی ممکن است به انواع مختلف اسناد (مانند، روندهای عملیاتی که باید دنبال شوند یا فرم های گزارشی که باید تکمیل شوند) یا منابع داده خارجی (به ویژه، پایگاه        داده های حاوی اطلاعات مربوط به سناریو اورژانس) اشاره داشته باشند؛ دانش مربوط به تمامی انواع اسن مراجع خارجی نیز استدلال شده است و به صورت مناسبی با برنامه های مربوطه مطابقت یافته است. در دومین تکرار چرخه ی کسب دانش، چهار مصاحبه ی فردی با هدف تعمیق دانش مربوط به برنامه ها و تکمیل ارائه ی آنها صورت گرفته است. در نهایت، و مصاحبه ی گروهی با متخصصان دامنه، مدیران و کاربران صرف پالایش و معتبرسازی کل مجموعه ی مقایع و برنامه های جمع آورش شده گردیده است.

 

 

 

جدول 2. طبقات کاربر و وظایف اصلی آنها

نقش کاربر	سطح سازمان	وظایف
مدیر واقعه	سطح عملیاتی	جمع آوری اطلاعات ورودی برای DSS از حوزه ی اورژانس و منابع خارجی
مدیر اورژانس مرکزی	سطح مرکزی	شناسایی و معرفی برنامه های دخالتی نیاز به اجرای یک برنامه جدید با یک مدیر اورژانس محلی پایش اجرای برنامه مدیریت درخواست ها برای اجرای یک برنامه جدید توسط مدیران اورژانس محلی
مدیر اورژانس محلی	سطح سرزمینی	اجرای برنامه های دخالتی نیاز به اجرای یک برنامه جدید یا توقف برنامه در حال اجرا مدیریت منابع موجود در شاخه ی سرزمینی مربوطه
اپراتور حوزه	سطح عملیاتی	اجرای اقدامات تجویزی در برنامه دخالتی در حال اجرا تامین نتایج اقدامات اجام شده برای مدیر اورژانس محلی
مدیر تعبیه منابع	سطح مرکزی سطح سرزمینی	بروزرسانی و پایش تعبیه منابع در شاخه های سرزمینی گوناگون
مدیر دانش	سطح مرکزی	مدیریت پایگاه های دانش DSS
مدیر سیستم	سطح مرکزی	مدیریت حساب ها و گروه های کاربر تامین پشتیبانی عملیاتی در طول عملیات DSS

 

برنامه ها در BPMN (توصیف مدلسازی فرآیند کسب و کار) ارائه شده است) ]43[ که اثبات شده است هم برای متخصصان دامنه و هم مهندسان دانش مناسب است، در نتیجه یک ابزار به اشتراک گذاری موثر ارتباط و دانش را تشکیل می دهد. BPMN شامل تمامی اقدامات اولیه لازم برای فرآیندهای پیچیده ی مدل می شود، از جمله، توالی، انتخاب، تکرار و اجرای موازی؛ علاوه بر این، می تواند در کد رایانه ای قابل اجرا انباشته شود و در نتیجه از DSS راحت تر استفاده کند. برای مثال، شکل 4 "برنامه برای نظارت بر انسان در معرض خطر ویروس همه گیر" را نشان می دهد که با واقعه ی اولیه "انسان در معرض خطر سرایت" در ارتباط است. شروع این برنامه از طریق یک دایره ی کوچک (در سمت چپ مثال) نشان داده شده می شود، در حالیکه هر مستطیل نشان دهنده ی یک اقدام برای اجرا یا یک برنامه برای فعال شدن می باشد (در این مثال، "برنامه برای مدیریت یک مورد انسانی مشکوک یا تایید شده". یک لوزی با یک ضربدر، یک دروازه انحصاری را نشان می دهد که یک گزینه در میان مجموعه ای از جایگزین های ممکن می باشد (در این مثال، چپ ترین دروازه انحصاری می خواهد که حضور در محیط اورژانس بچه هایی که در مدارس عمومی هستند را تایید کند؛ اگر این امر درست باشد، اقدام "اقدامات را انجام دهید تا حضور بچه ها را در محیط اورژانس محدود کنید" باید اجرا شود، وگرنه برنامه این کار را با اقدام بعدی ادامه می دهد. دیگر اقدامات اولیه (که در مثال ذکر نشده اند) امکان ارائه ی تصمیمات فراگیر و اجراهای موازی (با نمادهای چنگال و اتصال) را فراهم می سازد. اقدامات ممکن است به ساناد یا منابع داده های خارجی اشاره داشته باشد، برای رجوع به چنین اسنادی، از موضوعات (اشیاء) داده های رنگی استفاده می شود؛ به ویژه، موضوعات داده های قرمز (همانطور که در شکل نشان داده شده است) اشاره دارد به روندها، استانداردها یا مقررات رسمی که باید بکارگیری شده یا در طول اجرای یک اقدام در نظر گرفته شوند.

 

8. نمونه اولیه DSS

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

لایه ی کاربردی از چهار مدول تشکیل شده است. مدول دسترسی به داده ها و مدول دسترسی به سند که شامل اجزای منطقی مسئول بکارگیری پشتیبانی اطلاعاتی می باشند. مدول مدیریت، توابع و عملکردهای ضروری برای مدیریت تمام      داده ها، اسناد و پایگاه های دانش DSS را فراهم می کند. مدول هسته ی DSS قلب DSS می باشد و بر پایه ی یک موتور استدلال دانش محور می باشد. این مدول مسئول فراهم ساختن پشتیبانی هنجاری خاص لازم برای کمک به مدیران اورژانس در کارشان می باشد و اگر دقیق تر بگوییم در مقابل وقایعی که در حوزه ی اورژانس روی می دهند، این مدول نشان می دهد که اغلب برنامه ها و پیشنهادهای دخالتی پیشنهادی، از اجرای درست و موثر پشتیبانی می کنند (]13[ را برای جزئیات بیشتر ببینید)

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

از یک نقطه نظر فنی، DSS بر روی پلتفرم جاوا بکارگیری شده است. لایه ی تعامل کاربر بر اساس سرور وب Apache ساخته شده است که درخواست و تولید صفحات وب را مدیریت می کند. لایه ی برنامه کاربردی حاوی لاجیک (منطق) برنامه که در محفظه ی JBoss اجرا می شود می باشد. لایه ی دانش و داده ها از پایگاه داده های رابطه ای MySQL تشکیل شده است.

برای توسعه صفحات کاربر DSS، الگوهای طراحی تعامل انسان – رایانه برای برنامه های کاربردی وب که به صورت         گسترده ای پذیرفته شده است اتخاذ گردیده است ]41[ که هدف آن ارائه ی اطلاعات پشتیبانی – هم اطلاعاتی و هم هنجاری - به روشی شفاف و حتی الامکان کارآمد می باشد، در نتیجه باعث تسهیل تعامل و تقویت کاربرد می شود. در حالیکه صفحات مختلفی برای نقش ها و وظایف گوناگون کاریر لازم می باشند، یک ساختار پایه ای مشترک در تمامی صفحات کاربر ایجاد شد تا سازگاری را تضمین و از استفاده ی آسان پشتیبانی کند. یک صفحه ی عمومی شامل عناصر اساسی که در شکل 6 به آنها اشاره شده است می باشد که صفحه ی اصلی DSS را نشان می دهد: (1) سر صفحه با آرم DSS که یک لینک به صفحه ی اصلی را نیز تشکیل می دهد؛ (2) منو بار اصلی که برای هر نقش کاربر تفاوت دارد؛ (3) "ورود به عنوان" با رمز عبور کاربر وارد شده؛ (4) عنوان صفحه؛ (5) یک زیرنویس خلاصه که محتوای صفحه را توصیف      می کند؛ (6) یک پیام خوش آمد گویی (فقط برای صفحه ی اصلی)؛ (7) ناحیه ی اصلی که بستگی به نقش کاربر و حالت سیستم دارد؛ و (8) فوتر (نوشته ی پایین صفحه) با نسخه ی سیستم که لینک مربوط به وبسایت پروژه.

 

9. ارزیابی DSS

9-1 ویژگی های کیفیت

پس از توسعه ی DSS، ارزیابی با کاربران نهایی انجام گردید که بر روی کیفیت تعامل کاربر با DSS و توانایی DSS بر پشتیبانی بر همکاری در میان کاربران تمرکز دارد.

همانند ارزیابی تعامل کاربر –  DSS، توجه بر روی کارایی و قابلیت استفاده متمرکز شده است، که به صورت کلی نقاط قوت پذیرش سیستم ]26[ را با تاثیر مستقیم بر روی برطرف کردن نیازهای کاربر را در نظر می گیرد. کارایی یعنی اینکه آیا سیستم ها انتظارات کاربران را برآورده می سازند یا خیر. بطور ویژه، عملکردهای DSS بکارگیری شده را در برابر نیازهای مورد نظر کاربران ارزیابی می کدن. قابلیت استفاده در برابر اسن سوال قرار دارد که آیا کاربران می توانند وظایف خود را به آسانی و بطور کارآمد از طریق بکارگیری ابزارهای تعاملی پیشنهاد شده توسط DSS اجرا نمایند.

برای ارزیابی تعامل کاربر به کاربر از طریق DSS، فقط یک ویژگی جهانی به نام "کارایی همکاری" مورد نظر قرار گرفته است که میزان پشتیبانی موثر و کارآمد DSS از همکاری میان افراد دخیل در مدیریت اورژانس را نشان می دهد.

 

9-2 روش های ارزیابی

9-2-1 کارایی ارزیابی

روش زیر، یکی از مشتقات روش های مبتنی بر پرسشنامه ]23[، برای اجرای ارزیابی کارایی اتخاذ شده است:

1) اول یک تیم ارزیابی تعریف گردید که شامل مجموعه ای از کاربران واقعی مسئول ارزیابی توابع DSS بکارگیری شده      می باشد.

2) مجموعه ای از موارد آزمایش مربوط به نیازهای بکارگیری شده انتخاب و به عنوان مرجعی برای ارزیابی در نظر گرفته شدند.

 

شکل 6.. صفحه ی اصلی DSS

3) سپس یک شاخص برای کارایی به صورت یک شه گانه ی USF/nth> ، USF/adv ،USF/man USF = < تعریف گردید که در آن USF/man ، USF/adv و USF/nth ارزش های متوسط ارزشیابی بیان شده توسط گروه ارزیابی درباره نیازهای "اجباری"، "پیشرفته" و "خوب" را به ترتیب نشان می دهند. کاربران به شکلی تنظیم شدند که قضاوت خود را برای هر مورد آزمایش از طریق یک ارزش کیفی در مجموعه ای ترتیبی {غیرقابل قبول، نسبتاً قابل قبول، کافی، رضایتبخش، کاملاً رضایتبخش} با توجه به میزان برآورده شدن نیازهای موردنظر توابع DSS بیان دارند. این ارزش ها، سپس در یک مقیاس صحیح {1، 2، 3، 4، 5} طراحی شدند.

4) یک مقیاس برای USF سرانجام برای تجمیع سه جزء USF به نام های USF/man ، USF/adv و USF/nth در ارزیابی کیفی جهانی تعریف شد:

 

 

9-2-2 ارزیابی کارایی

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

1) یک تیم ارزیابی تعریف شدند که شامل یک مجموعه از کاربران واقعی مسئول ارزیابی کارایی DSS و یک مجموعه از کاربران مرجع بودند که به صورت کامل آموزش دیده و کاملا با DSS آشنا هستند.

2) مجموعه ای از وظایف آزمایشی که در آن، وظیفه به صورت یک مجموعه ی ساختاری از وظایف مورد نیاز برای رسیدن به یک هدف مورد نظر می باشد ]11[ به صورت یک مرجع برای ارزیابی انتخاب و در نظر گرفته شد.

3) سپس یک شاخص برای کارایی به صورت یک سه گانه ی USE = <USE/eff, USE/rob, USE/mem> تعریف شد که در آن USE/eff, USE/rob, USE/mem نسبت بین مقادیر متوسط ارزیابی نیرومدنی، کارایی و به یاد ماندنی بودن ثبت شده با کاربران واقعی گروه ارزیابی را نشان می دهند در حالیکه مجموعه وظایف آزمایش تعریف شده (مقادیر کاربر) و مقادیر بدست آمده با همان مجموعه از وظایف آزمایش توسط کاربران مرجع (مقادیر مرجع) را اجرا می نمایند. بطور خاص، در طی اجرای وظیفه ی آزمایش، زمان صرف شده برای اجرای وظیفه و تعداد خطاهای صورت گرفته شمرده شدند تا کارایی و نیرومندی را به ترتیب ارزیابی کنند؛ به یاد ماندنی بودن نیز سپس توسط تکرار اجرای همان وظایف پس از یک دوره ی عدم فعالیت با سیستم و توسط اندازه گیری تفاوت در کارایی مشاهده شده با توجه به اولین جلسه ی تجربی ارزیابی شد.

مقادیر در نظر گرفته شده برای USE/eff, USE/rob, USE/mem نیز سپس در یک مقیاس عدد صحیح از 1 تا 5 با معنای زیر طراحی شدند:

1. ارزش کاربر > 8/1 × ارزش مرجع

2. 4/1 × ارزش مرجع < ارزش کاربر ≤ 8/1 × ارزش مرجع

3. 2/1 × ارزش مرجع < ارزش کاربر ≤ 4/1 × ارزش مرجع

4. ارزش مرجع < ارزش کاربر ≤ 2/1 × ارزش مرجع

5. ارزش کاربر ≤ ارزش مرجع

 

4) یک مقیاس برای USE در نهایت برای تجمیع سه جزء USE به نام های USE/eff, USE/rob, USE/mem در یک ارزیابی کیفی جهانی تعریف گردید:

 

 

9-2-3 ارزیابی کارایی همکاری

مسئله ی ارزیابی کارایی همکاری یک سیستم رایانه محور با هدف پشتیبانی از تعامل وظیفه محور بین افراد درون یک محیط خاص، فقط به صورت ضعیف در ادبیات و تحقیقات کنونی مورد بررسی قرار گرفته است. برخی رویکردهای تنها بر روی کارایی سیستم های همکاری (برای مثال ]30 و 38[) متمرکز شده اند در حالیکه دیگر رویکردها حتی اگر کارایی را به صورت ویژه در نظر بگیرند، اقدامات هدفی را تامین نمی کنند و فقط نظرات و پیشنهادات کاربران را از طریق کارگاه ها یا گروه های تمرکز مهیا می سازند (برای مثال ]4[). بنابراین، یک رویکرد جدید ذهنی بر اساس سه بعد پیشنهاد شده است که این ابعاد عبارتند از: شایستگی، به عنوان ویژگی تعاملات کاربر به کاربر که باید در موضو ع با اجتناب از دیالوگ های خارج از حوزه و غیر مادی مورد توجه قرار گیرد؛ صحت، به عنوان ویژگی تعاملات شایسته و مناسب برای انتقال اطلاعات درست و اجتناب از گمراه کردن و یا حتی پیام های نادرست؛ و کاربردپذیری، به عنوان ویژگی تعاملات درست برای حضور در کارآمدی و کارایی وظیفه ی همکارانه.

روش زیر که برای مورد حاضر طراحی شده است، برای اجرای ارزیابی کارایی همکاری اتخاذ شده است:

1) اول یک تیم ارزیابی طراحی شد که شامل یک گروه از کاربران واقعی با نقش ارزیابی کارایی DSS بوده است.

2) یک سناریوی آزمایش (شبیه سازی شده اما واقع گرایانه) تعریف شد که در آن، از تیم ارزیابی خواسته شد که یک کار مدیریتی اورژانس کامل را انجام دهد.

3) سپس یک شاخص برای کارایی همکاری به صورت یک سه گانه ی CEF = <CEF/per, CEF /cor, CEF /uti> تعریف گردید که در آن CEF/per, CEF /cor, CEF /uti نشان دهنده ی مقادیر متوسط ارزیابی صلاحیت، درستی و کاربردپذیری بیان شده توسط کاربران تیم ارزیابی بودند در حالیکه در کار مدیریت اورژانس تعریف شده حضور داشتند. بطور خاص، در طی اجرای کار آنها، از کاربران خواسته شد تا تعداد کل تعاملات کاربر به کاربر روی داده را توسط تمایز بین تعاملاتی که شایسته، درست و کارآمد در نظر گرفته شده اند را ثبت کنند. CEF/per, CEF /cor, CEF /uti سپس در یک مقیاس عدد صحیح از 1 تا 5 با معناهای زیر ترسیم شدند:

 

که در آن

•  
• Ntot تعداد کل تعاملات، Nper، Ncor و Nuti به ترتیب تعداد تعاملات شایسته، درست و کارآمد (مفید)           می باشند.

4) یک مقیاس برای CEF در نهایت برای تجمیع سه جزء CEF به نام های CEF/per, CEF /cor, CEF /uti در یک ارزیابی کیفی جهانی تعریف شدند.

 

9-3 تنظیمات تجربی و نتایج ارزیابی

برای ارزیابی کارآمدی و کارایی، دو متخصص تعاملات رایانه ایف آزمایشی را با پنج کاربر در اختیار گرفته شده از               ASL Brescia انجام دادند. مجموعه ای متشکل از 34 مورد، با پوشش اغلب نیازهای  DSS و در بر دارنده ی             فعالیت های اصلی که کاربران باید در طی یک موقعیت اورژانس انجام دهند، انتخاب شد و به صورت موارد آزمایش برای ارزیابی کارایی و ارزیابی کارآمدی مورد استفاده قرار گرفت. جلسات تجربی (آزمایشی) تحت شرایط آزمایشگاه انجام شد که در آن کاربران در یک محیط بدون مزاحمت کار می کردند.

برای ارزیابی کارایی همکاری، یک سناریوی پیشنهاد شده توسط ASL Brascia (منطقه شماره 4 – Valle Trompia) در نظر گرفته شد. تیم اورژانس که برای آزمایش DSS ایجاد شده بود شامل یک مدیر واقعه، دو مدیر اورژانس مرکزی، سه مدیر اورژانس محلی و چهار اوپراتور حوزه بود که اتاق های کار جداگانه ای برای شبیه سازی تنظیمات توزیعی برای آنها در نظر گرفته شد. این شبیه سازی برای یک روز کاری کامل در نظر گرفته شده بود. در این مدت، سه واقعه اتفاق افتاد – که عبارتند از: "نیاز به واکسیناسیون گسترده"، "مورد مشکوک انسانی" و "نیاز به واکسیناسیون اورژانس محلی" – که موجب ایجاد هفت برنامه ی دخالتی شد. در طول اجرای اورژانس شبیه سازی شده، یک متخصص تعامل انسان – رایانه، پشتیبانی لازم برای حمایت از اجرای درست آزمایش را فراهم ساخت، فعالیت های تیم را مشاهده و قضاوت های کاربر در مورد کارایی همکاری را جمع آوری کرد.

ارزیابی نهایی DSS نتایج ارائه شده در جدول 3 را ارائه کرده است.

علاوه بر ارزیابی ارائه شده در بالا، نظرات غیر رسمی نیز از کاربران در طول فعالیت های ارزیابی جمع آوری شد که نشان    می دهند:

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

 

10. بحث و نتیجه گیری

تحقیقات و تجربیات گزارش شده در این مقاله، مدیریت اورژانس و همکاری را را از سه دیدگاه بررسی می کند. اول از همه، از دیدگاه روش های طراحی، یک رویکرد جدید را در مورد طراحی DSS ارائه می دهد که یک گام رو به جلو با توجه به طراحی کاربر محور ارتقاء یافته در ادبیات مدیریت اورژانس ]7، 29[ و تحقیقات DSS ]22، 40[ و در مورد طراحی فعالیت محور پیشنهاد شده توسط نورمن ]27[ برای توسعه ی سیستم های تعاملی پیچیده می باشد. در مقایسه با دیگر رویکردهای مربوط به طراحی DSS اخیراً پیشنهاد شده در ادبیات، که عمدتاً در مورد توسعه ی چارچوب های کلی (برای مثال،             ]3، 10[) یا نظریه های طراحی سطح بالا (مثلاً ]25[) می باشد، روش ما مبتنی بر یک رویکرد منطقی و ساختاری می باشد که از روش های سالم مهندسی دانش برای اجرای تمامی مراحل و وظایف فرآیند طراحی استفاده می کند. علاوه بر مدیریت اورژانس، در هر زمینه ی پشتیبانی از تصمیم مربوط به وجود انواع مختلفی از منابع دانش و نیاز به تعادل بین پشتیبانی اطلاعاتی و هنجاری نیز قابلیت کاربرد دارد. کاربرد عملی این روش در مرجع (منبع) پروژه ی HEALTHREATS نشان داده شده است.

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

سوم، یک رویکرد چند وجهی در مورد ارزیابی یک DSS ارائه شده است که نه تنها کیفیت تعامل کاربر – DSS از جمله کارایی و کاربردپذیری، بلکه سطح تعامل کاربر به کاربر را از طریق DSS از جمله کارایی همکاری را نیز بررسی می کند. این امر، پیشرفت بزرگی را با توجه به ادبیات موجود ارائه می دهد که معمولا تنها بر روی کاربردپذیری تمرکز دارد ]19[ و بررسی میزان برآوردسازی نیازهای یک زمینه ی کاربردی را از دست می دهد. علاوه بر آن، این رویکرد پیشنهادی با تمامی جزئیات فنی لازم برای بکارگیری عملی را توسعه داده است و بطور واقعی در مطالعه موردی در نظر گرفته شده مورد بررسی قرار گرفته است.

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

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