تنها وبسایت رسمی شرکت نوآوران سلامت گستر شریف noavaran-sharif.ir و noavaran-sharif.com

راه ارتباطی ما با شما سامانه پیامکی 50002210801

تنها لوگو رسمی ثبت شده شرکت نو آوران سلامت گستر شریف نوآوران شریف میباشد.

مقاله
مدیریت امنیت پایگاه داده برای نرم افزار به عنوان خدمتِ بهداشت و درمان در ابر AWS آمازون
بهمن ۲, ۱۳۹۵
مقاله
یک پیشینه‌ی پژوهش اصولی از رایانش ابری در بهداشت و درمان الکترونیکی
بهمن ۲, ۱۳۹۵

MedCloud: سیستم رایانش ابری بهداشت و درمان

مقاله

چکیده– با توجه به تعداد روبه‌افزایش بیماران و کاربردها، سیستم‌های موجود برای ذخیره‌ی داده‌های بیماران به میزان کافی مقیاس‌پذیر نیستند. رایانش ابری خبر از هزینه‌های پایین، مقیاس‌پذیری بالا، دسترس‌پذیری و قابلیت بازگشت پس از سانحه می‌دهد که می‌تواند راه‌حلی طبیعی برای بسیاری از مشکلات در ذخیره‌سازی و تحلیل سوابق پزشکی بیماران باشد. در این مقاله اثر رایانش ابری در بهبود خدمات بهداشت و درمان بررسی می‌شود. به طور خاص‌تر، این پژوهش طراحی معماری یک سیستم سوابق سلامت شخصی به نام “MedCloud” را به تفصیل شرح می‌دهد که از خدمات اکوسیستم Hadoop’s [1] استفاده و آن‌ها را با قوانین محرمانگی و امنیت HIPAA ادغام می‌کند. [۲] یک سکو[۱]ی مقیاس‌پذیر به توسعه‌دهندگان برای استفاده در توسعه‌ی کاربردها ارائه و Restlet [3]، یک پورتال وب، برای دسترسی به سیستم MedCloud در اختیار کاربران قرار داده شده است. پس از آن، توسعه‌ی مدل MedCloud نیز با استفاده از تحلیل مسائل نمایش داده شده و سپس، یک ارزیابی کامل از عملکرد آن آمده است.

اصطلاحات شاخص– رایانش ابری، Hadoop، Hbase، Restlet، HIPAA.

۱٫ مقدمه

بهداشت و درمان همواره مسئله‌ای عمده برای اجتماع و “به سمت فناوری اطلاعات هوشمندتر” نیز از ابتدا شعار اصلی یک مؤسسه‌ی بهداشت و درمان موفق بوده است. به منظور کاهش هزینه‌های بهداشت و درمان و افزایش کیفیت خدمات، نیاز شدیدی به استراتژی‌های جدید وجود دارد. علاوه بر آن، فناوری اطلاعات به طور مثبتی بخش بهداشت و درمان را تحت تأثیر قرار داده و اطلاعات دقیق‌تر و بهنگام‌تری از سرپرستی بیمار فراهم می‌آورد.[۴]

تعدادی از فراهم‌آورندگان بهداشت و درمان و شرکت‌های بیمه داده‌های پزشکی بیماران را به شکل سوابق پزشکی الکترونیکی[۲] و در پایگاه داده‌های متمرکز ذخیره می‌کنند.[۵] از گذشته، EMRها روشی پایه‌ای برای ذخیره‌ی سوابق پزشکی بیماران به صورت الکترونیکی بوده است. [۶] مشکل آن‌جا است که، هر بیماری فراهم‌آورندگان بهداشت و درمان متفاوتی دارد که شامل پزشکان، متخصصان، تراپیست‌ها، و دیگر شاغلین حیطه‌ی پزشکی می‌شوند. علاوه بر این، بیمار ممکن است بیمه‌هایی از شرکت‌های مختلف داشته باشد. فراهم‌آورندگان بهداشت و درمان، برای تشخیص مناسب بیماری بر اساس مجموع تمامی سوابق پزشکی بیمار، به دیدی کامل از وضعیت سلامت او نیاز دارند. متداول است که هر فراهم‌آورنده دارای پایگاه داده‌ی خود باشد. به همین دلیل، یک فراهم‌آورنده‌ی بهداشت و درمان ممکن است EMR یک بیمار را از دیگر فراهم‌آورندگان درخواست کند. عملیات درونی و به اشتراک‌گذاری داده میان EMRهای مختلف از سرعت بسیار پایینی برخوردار است. در نتیجه، برای تسریع به اشتراک‌گذاری EMRها، به مکانی مشترک برای ذخیره‌ی نیاز داریم.[۷] برای غلبه بر مشکل تأخیر انتقال EMRها میان فراهم‌آورندگان مختلف بهداشت و درمان، این مکان مشترک باید این فرآیند را به طرزی مؤثر تسهیل کند و بهبود بخشد.

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

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

در سال ۲۰۰۳، اعلامیه‌ی مسئولیت و قابلیت حمل بیمه‌های درمانی[۳] فدرال، استانداردی ملی برای محرمانگی اطلاعات پزشکی ایجاد کرد. موجودیت‌های HIPAA شامل فراهم‌آورندگان بهداشت و درمان، طرح‌های سلامت و شرکت‌های تسویه‌ی وجوه بهداشت و درمان هستند. بر اساس HIPAA، سوابق داده‌ها به شکل رکوردهای الکتریکی نگه‌داری می‌شوند و انتقال می‌یابند. هدف اصلی قانون محرمانگی HIPAA، ضمانت حفاظت کامل از اطلاعات سلامت افراد بدون هیچ‌گونه نقضی در جریان اطلاعات سلامت است. علاوه بر این، کیفیت بهداشت و درمان را افزایش می‌دهد و ضامنی برای سلامتی مردم است.[۲]

در این مقاله، یک سیستم رایانش ابری به نام “MedCloud” برای ذخیره‌ی EMRها ارائه شده است. هدف اصلی، تشکیل سکویی برای استفاده‌ی توسعه‌دهندگان است تا سکویی برای افراد. و این کمک بزرگی در ساده‌سازی مرحله‌ی توسعه است. سیستم MedCloud برای کاربران خدمات پایه‌ای به منظور ساختن یک کاربرد مؤثر بهداشت و درمان فراهم می‌آورد. سیستم ارائه‌شده از اکوسیستم Hadoop برای پیاده‌سازی سرور استفاده می‌کند. پایگاه داده‌های ستون‌گرا بر روی سیستم‌فایل‌های توزیع‌شده برای ذخیره و تحلیل داده‌ها مناسب هستند. کاربران از طریق چارچوب وب شناخته‌شده‌ی Restlet به سیستم دسترسی دارند. از آن‌جایی که در مدل پیشنهادشده محرمانگی و امنیت مبتنی بر HIPAA در نظر گرفته شده‌اند، شرح کاملی از معماری سیستم نیز ارائه شده است که در آن بخش‌هایی عملکردی از سیستم پیاده‌سازی شده‌اند. سرانجام، مقادیر موجه کارایی سیستم شرح داده شده‌اند. این مقاله به چهار بخش تقسیم شده است: بخش ۲ فعالیت‌های مرتبط را در بر دارد، در بخش ۳ شرح کاملی از معماری پیشنهادشده ارائه شده است. بخش ۴ نیز پیاده‌سازی و ارزیابی کارایی مدل پیشنهادشده را نشان می‌دهد و سرانجام در بخش ۵، نتیجه‌گیری مقاله آمده است.

۲٫ فعالیت‌های مرتبط

در حال حاضر، ابر کشسان محاسبه‌ی آمازون[۴][۹] یکی از محبوب‌ترین سکوهای ابری است و یک محیط مجازی محاسباتی برای کاربران به منظور اجرای کاربردهایشان فراهم می‌آورد که منجر به بهبود کارایی می‌شود اما در به اشتراک‌گذاری داده انعطاف‌پذیر نیست. هم‌چنین، مدل پرداخت به ازای هر نوبت[۵] را پیاده‌سازی کرده است. موتور کاربردی گوگل[۶][۱۰] نیز سکوی ابری دیگری است که به کاربران اجازه‌ی اجرای یک کاربرد وب نوشته‌شده با زبان‌های برنامه‌نویسی پایتون و جاوا می‌دهد اما تنها مؤلفه‌های عملکردی محدودی را فراهم می‌آورد. هم‌چنین، یک کنسول مدیریت مبتنی بر وب برای مدیریت اجرای کاربردهای وب کاربر ارائه می‌دهد اما برای کاربردهای توزیع‌شده با کارایی بالا مناسب نیست.[۱۱]

در زمینه‌ی پزشکی، برای بهبود بهداشت و درمان، سیستم‌های نرم‌افزاری مختلفی در سراسر جهان ایجاد شده‌اند. Care2X یک سیستم اطلاعاتی متن‌باز بیمارستانی است که معماری سرویس‌گیرنده-سرویس‌دهنده را پیاده‌سازی کرده است. مزیت‌های Care2X شامل انعطاف‌پذیری، مدیریت آسان، ساخت ابزارهای توسعه‌دهنده توسط خودش، انتخاب آسان بخش‌ها و ایستگاه‌ها و کمک‌های اجتماع Care2X است. اشکال عمده آن است که هیچ استاندارد واقعی‌ای میان مؤلفه‌ها وجود ندارد و هنوز در حال توسعه است و به نوآوری‌های زیادی نیاز دارد. علاوه بر این‌، مستندسازی ضعیف و تدابیر امنیتی ناکارایی دارد. [۱۲] در [۱۳]، نویسندگان یک راه‌حل از ابر خصوصی متن‌باز برای بهداشت و درمان روستایی در هند ارائه و Care2X را بر روی ابر خصوصی توسعه داده‌اند. آن‌ها کاربرد خود را فقط به خدمت‌دهی در مناطق روستایی و در موارد اضطراری منحصر کرده‌اند. با این وجود، اگر بر روی تمامی بیمارستان‌ها یا بیماران یک کشور اِعمال می‌شد، منجر به حفظ جان بیماران در هر مکان و هر زمانی می‌شد. علاوه بر این، بسیاری از آمارها در مورد متداول‌ترین بیماری‌ها در یافتن روش‌های جدیدی برای حداقل ساختن آسیب‌پذیری در برابر آن‌ها یاری‌دهنده هستند.

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

۳٫ MedCloud: یک سیستم محاسباتی ابری

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

الف. نیازمندی‌های سیستم

در این بخش، به نیازمندی‌های سیستم با توجه به قوانین محرمانگی و امنیت HIPAA اشاره می‌شود.[۲] اگرچه HIPAA یک استاندارد آمریکایی است، اما می‌تواند به سادگی در کشورهای مختلفی به کار گرفته شود. ویژگی‌های سیستم با توجه به آن کشور، موجودیت‌های پوشش داده شده و کاربران، قابل تنظیم است.

  1. نیازمندی‌ها:
  • کاربران بر اساس سطح امتیازاتشان، دسته‌بندی خواهند شد و سطح دسترسی در مرحله‌ی ثبت‌نام تعریف می‌شود.
  • بیمارستان یا مؤسسه‌ی پزشکی سطح دسترسی کاربرانش را از لیست تعریف‌شده‌ی طبقه‌بندی دسترسی‌ها که با توجه به قوانین محرمانگی و امنیت HIPAA تنظیم شده‌اند انتخاب می‌کند.[۲]
  • اطلاعیه‌ی محرمانگی مشاغل[۷] که شامل سیاست‌ها و قوانین قانون محرمانگی[۲] است باید در وب‌سایت سیستم پست شود.
  • شرکت‌کنندگان می‌توانند لیستی از افراد مجاز را برای سازمان اطلاعات سلامت[۸] و وابسته به کشور ثبت کنند.
  • هر مدرکی که نیازمند امضا باشد می‌تواند به صورت یک تصویر اسکن‌شده از مدرک امضاشده و به عنوان یک مدرک الکترونیکی به همراه یک امضای الکترونیکی ارائه شود.
  • بر اساس قوانین امنیتی HIPAA، موجودیت‌های پوشش داده‌شده باید تدابیر امنیتی محدودکننده‌ای را به کار برند.
  • سیستم اطلاعات پزشکی باید سیاست‌های فنی و رویه‌ها را اِعمال و سخت‌افزارها و نرم‌افزارهای مورد نیاز که تنها به افراد مجاز اجازه‌ی دسترسی به e-PHI می‌دهند را پیاده‌سازی کند.
  • انتقال داده باید امن باشد.

ب. معماری پیشنهادشده

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

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

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

کاربردهایی، مانند تحلیل آماری EMRها و انتقال تصویربرداری‌های پزشکی نیازمند ذخیره‌ی ترابایت‌ها یا پتابایت‌هایی برای به انجام‌رسانی نیازمندی‌های محاسباتی و ذخیره‌ای خود هستند. پایگاه داده‌هایی مانند SQL محدود به توانایی‌های مشخصی هستند و قادر به مدیریت نیازهای ذخیره‌سازی‌های انبوه نیستند.[۱۴] این موضوع منجر به توسعه‌ی ذخیره‌سازی‌های افقی مقیاس‌پذیر، غیررابطه‌ای و توزیع‌پذیر به نام پایگاه داده‌های NoSQL شد. به دلیل خواندن‌ها و نوشتن‌های سریع، پشتیبانی از ذخیره‌ی انبوه، گسترش‌پذیری سریع و هزینه‌های پایین، ذخیره‌های NoSQL داده مناسب نیازمندی‌های امروزی هستند.[۱۵] این موارد به ذخیره‌ی مستندها، زوج‌هایی از کلید و مقدار و پایگاه داده‌های ستون‌گرا تقسیم شده‌اند. [۱۶] MedCloud از ذخیره‌سازی ستون‌گرای داده‌ها استفاده کرده است زیرا بهترین انتخاب برای سیستم است. ذخیره‌سازی داده‌ی NoSQL برای کاربردهای انبارسازی داده‌ها، کارایی بالای تحلیل داده و فرآیندهای هوش تجاری است. در MedCloud یک ابزار مؤثر انبارسازی داده مورد نیاز است و بنابراین، یک ذخیره‌ی داده‌ی ستون‌گرا بر روی فایل‌سیستم توزیع‌شده اجرا می‌شود و می‌تواند منجر به دست‌یابی به کارایی بالای موردنیاز گردد.

شکل ۱معماری MedCloud

به علاوه، پایگاه داده‌های ستون‌گرا از روش‌شناسی ستون خانواده‌ها[۹] استفاده می‌کند که در آن هر جدول به طور خاص توسط یک کلید اصلی شناسایی می‌شود و کلید خارجی ندارد. [۱۷] یک طراحی برای جدول بیمار و جدول ویزیت به ترتیب در جداول ۱ و ۲ تعریف شده‌اند. در جدول بیمار، یک ستون برای خانواده وجود دارد که شامل ضروری‌ترین اطلاعات بیمار است. اطلاعاتی اجباری مانند شماره‌ی شناسایی بیمار و نام کامل او در جدول بیمار و دیگر اطلاعات اختیاری برای انعطاف‌پذیری در جمع‌آوری اطلاعات( زیرا برخی از بیمارستان‌ها و درمانگاه‌ها ممکن است در نوع اطلاعات در دسترس با هم اختلاف داشته باشند) نیز در این جدول وجود دارند. در جدول ویزیت، ویزیت می‌تواند در بیمارستان یا درمانگاه باشد. دو خانواده‌ی ستون در این جدول وجود دارند: یکی برای اطلاعات ابتدایی ویزیت و دیگری برای اطلاعاتی در مورد تشخیص بیماری قلبی. اگر نیاز به اضافه کردن تشخیص‌های بیش‌تری به سیستم باشد، خانواده‌های ستون بیش‌تری می‌توانند اضافه شوند.

جدول ۱جدول بیمار

کلید ردیف ستون خانواده‌ها
اطلاعات:
(شماره‌ی شناسایی بیمار) نام کوچک

میان‌نام

نام خانوادگی

تاریخ تولد

جنسیت

وضعیت تأهل

آدرس

شماره‌ی تلفن

گروه خونی

 

جدول ۲جدول ویزیت

کلید ردیف ستون خانواده‌ها
اطلاعات: بیماری قلبی
(شماره‌ی شناسایی ویزیت)

(شماره‌ی شناسایی بیمار)

تاریخ پذیرش

تاریخ مرخص کردن

شماره‌ی اتاق

شماره‌ی شناسایی پزشک

شماره‌ی شناسایی بیماری قلبی

شماره‌ی شناسایی آزمایش

شماره‌ی شناسایی علائم بیماری

شماره‌ی شناسایی امضا

شماره‌ی شناسایی فاکتور ریسک

 

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

جدول ۳جدول خدمات

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

 

  1. لایه‌ی مدیریت سرور: در معماری ارائه‌شده، معماری ارباب-برده پیاده‌سازی شده است. ارباب دو مؤلفه‌ی اصلی دارد:
    • مدیر پرسش‌ها: یک عنصر حیاتی در سیستم است که پرسش‌ها را از لایه‌ی کاربرد دریافت می‌کند و شامل فراداده‌هایی از فایل‌سیستم و مکان داده‌ها در پایگاه داده است که توسط هر پرسش مورد نیاز هستند. هم‌چنین، فعالیت‌های گسترده‌ی سیستم مانند زباله‌روبی[۱۰] تکه‌های بی‌استفاده و جابه‌جایی تکه‌ها میان برده‌ها را کنترل می‌کند.
    • مدیر همروندی: مسئول مدیریت و توزیع کارها و درخواست‌ها بر روی برده‌ها به‌وسیله‌ی هماهنگی با مدیر پرسش‌ها است. علاوه بر این، برای تکرار داده‌ها در میان برده‌ها استفاده می‌شود.

          در بخش برده، موارد زیر وجود دارند:

  • مدیر ذخیره‌ی داده: به عنوان عاملی برای مدیریت ذخیره‌ی داده و ذخیره‌سازی فایل‌های داده در سیستم‌فایل توزیع‌شده استفاده می‌کند.
  • مدیر وظایف: به عنوان برده‌ای برای مدیر همروندی عمل می‌کند زیرا مسئول مثال‌آوری و نظارت بر وظایف فردی درون یک کار است.

مدیر هماهنگی: مؤلفه‌ی کلیدی در سیستم MedCloud است و درخواست‌ها و پاسخ‌ها را در موارد ارتباطات چندگانه‌ی ارباب-برده کنترل و مدیریت می‌کند.

  1. لایه‌ی کاربرد: عملکرد کل این لایه ارائه‌ی خدماتی به کاربران است. یک کاربرد مجموعه‌ای از مؤلفه‌های نرم‌افزاری( خدمات) است که با همکاری یکدیگر به هدف خاصی دست می‌یابند. یک کاربر می‌تواند خدمتی از طریق دسترسی شبکه درخواست کند. HTTP [18] که مخفف پروتکل انتقال ابرمتن[۱۱] است، پروتکل استاندارد شبکه در اینترنت می‌باشد. بنابراین، کاربران برای استفاده از فناوری HTTP به منظور درخواست خدمت، به یک چارچوب وب که از یک سرور HTTP برای انتقال خدمات استفاده می‌کند نیاز دارند. سرور کاربرد این درخواست را می‌پذیرد و با خدمات در دسترس مقایسه می‌کند و سپس مطابق با استراتژی‌های متفاوت پاسخ‌، به آن جواب می‌دهد. توجه شود که خدمات مبتنی بر شیوه‌ی معماری REST [19] منتشر می‎‌شوند. برای این لایه، تمامی مؤلفه‌های در دسترس بر روی چارچوب وب اجرا می‌شوند. در این بخش، عملکرد لایه‌ی کاربرد توسط تعدادی از عناصر معرفی شده است.
  • تأییدکننده‌ی هویت: مسئول اعتبارسنجی جزئیات ورود مشتری( به معنی ورود و خروج از سیستم) است. کارمندان فراهم‌آورندگان بهداشت و درمان کاربران اصلی یک سیستم بهداشت و درمان هستند. به طور طبیعی، کارمندان شامل کارکنان مدیریتی، کارکنان درمانگاهی، بخش مدیریت و کارکنان فناوری اطلاعات هستند که باید پیش از دسترسی به EMRها تأیید هویت شوند.
  • اجازه‌دهنده: از آن‌جایی که اطلاعات بیمار شخصی و حیاتی است، برای ضمانت معیارهای امنیتی و به دست‌آوردن اعتماد کاربر، قوانین محرمانگی و امنیت HIPAA در سیستم ما اِعمال شده‌اند. به علاوه، این یک بخش حیاتی برای تمایز اجازه‌های کاربر و نمایش خدمات مجاز به آن کاربر بر اساس قوانین محرمانگی HIPAA است. یک فراهم‌آورنده‌ی بهداشت و درمان باید یک فرد را برای اضافه و یا حذف کردن کاربران در سیستم تعیین کند.
  • دریافت‌کننده‌ی درخواست‌ها: با اجرای این استراتژی پیاده‌سازی خدمت، لایه‌ی سرور درخواست خدمت را پردازش می‌کند و پاسخ به سمت کاربر مسیریابی می‌شود.
  • تجمیع‌کننده‌ی داده‌ها: داده‌ی ورودی هر عملیاتی را بررسی و اعتبارسنجی می‌کند.
  • ثبت NPP: شامل سیاست‌ها و قوانین محرمانگی و امنیتی HIPAA است.
  • ثبت اجازه‌دهندگان: لیستی از تمامی کاربران مجاز را در بر دارد. زمانی که یک فراهم‌آورنده‌ی بهداشت و درمان یک کاربر را اضافه کرد، این کاربر به طور خودکار به سوابق ثبت‌شده اضافه می‌شود.
  • ثبت خدمات: تمامی خدمات ارائه‌شده توسط سیستم MedCloud را در بر دارد و به جدول ۳ نگاشت می‌شود. هر خدمت جدیدی به کل آن اضافه می‌شود.
  • ردیاب آشکارسازی: شامل تمامی کاربران یا فراهم‌آورندگان بهداشت و درمان است که به سوابق پزشکی هر بیمار دسترسی داشته‌اند.

ج. تحلیل مسائل

چارچوب MedCloud مجموعه‌ای از خدمات را ارائه می‌دهد که با تمامی مدل‌های برنامه‌نویسی کار می‌کند و از ذخیره‌سازی، مدیریت فایل، نظارت و امنیت پشتیبانی می‌کند. توسعه‌دهندگان و کاربران نهایی، دو نوع کاربرِ این سیستم هستند. در نتیجه، هر یک از سیستم به روش متفاوتی استفاده خواهند کرد.

  1. گسترش کاربرد: سیستم MedCloud یک کیت توسعه‌ی نرم‌افزار[۱۲] خاص برای توسعه‌دهندگان به منظور ایجاد کاربردهایشان بدون داشتن آگاهی از بینش ارائه می‌دهد. پس از آن‌که یک توسعه‌دهنده کاربرد خود را کامل کرد، می‌تواند به سادگی آن را گسترش دهد. همان‌طور که پیش‌تر نیز اشاره شد، یک سکوی خاص برای توسعه‌دهندگان به منظور استفاده در طراحی کاربردهایشان ایجاد شده است. قیمت‌گذاری و قوانین مربوط به استفاده برای کاربردهای آتی فرمول‌بندی می‌شود.
  2. درخواست خدمت: شکل ۲ نمودار توالی فازهای مدیریت درخواست را برای خدمت بازیابی بیمار با شماره‌ی شناسایی‌اش نشان می‌دهد
  • مراحل ۱و ۲: مشتری به صورت امن و توسط سرور وب به سیستم دسترسی می‌یابد.
  • مراحل ۳و ۴: تأییدکننده جزئیاتِ ورود مشتری به سیستم را اعتبارسنجی می‌کند.
  • مراحل ۵و ۶: اگر این اطلاعات معتبر بودند، جزئیات ورود به کنترل‌کننده‌ی دسترسی‌ها فرستاده می‎‌شوند که لیستی از خدمات ارائه‌شده برای این مشتری را بر اساس قوانین محرمانگی HIPAA ارسال می‌کند.
  • مراحل ۷و ۸: مشتری درخواست بازیابی بیمار بر اساس شماره‌ی شناسایی را به مدیریت‌کننده‌ی درخواست خدمت می‌فرستد که درخواست ورودی را به منبع سرور بیمار ارسال می‌کند.
  • مرحله‌ی ۹: منبع سرور بیمار شامل تعاریفی از خدمات در دسترس است و یک نمونه از اچ‌بیسِ[۱۳] مشتری ایجاد می‌کند.
  • در مراحل بعدی، مانند مراحل ۱۰ و ۱۱، درخواست توسط ارتباطات میان اچ‌بیس مشتری و اچ‌بیس سرور مدیریت می‌شود.
  • مراحل ۱۲و ۱۳: اچ‌بیسِ مشتری، تابع فراخوانی ردیف بر اساس شماره‌ی شناسایی را که برای یافتن یک ردیف خاص درون ناحیه‌ی اچ‌بیس‌ها سرورها و توسط یک سرور اچ‌بیس ارباب، صدا می‌زند.
  • مراحل ۱۴و ۱۵: پاسخ که یا بیمار درخواست‌شده و یا پیام “یافت نشد” است به سوی مشتری فرستاده می‌شود.

شکل ۲ نمودار توالی برای یک درخواست خواندن

۴٫ پیاده‌سازی و ارزیابی کارایی

در این بخش، مؤلفه‌های فیزیکی سیستم شرح داده می‌شوند. شکل ۳ گسترش مدل سیستم MedCloud را نشان می‌دهد. معماری MedCloud، دو گره را به عنوان ارباب برای مدیریت خوشه‌ی Hadoop تعیین می‌کند. در بخش برده، سیستم قادر به اضافه کردن هر تعداد برده که مورد نیاز است می‌باشد، زیرا Hadoop به صورت خطی مقیاس می‌پذیرد. این خوشه با استفاده از نسخه‌ی سوم Cloudera و آپدیت ۵ (CHD3U5) آن پیاده‌سازی شده است. بسته‌ی Cloudera شامل Hadoop است که برای دست‌یابی به مقیاس‌پذیری و خدمات مورد نیازش استفاده می‌شود. در طراحی عملی، Hadoop بر روی ۲۳ سرور ابری از شرکت ابر باز RackSpace و شامل ۳ گره‌ی عمده برای مدیریت خوشه برپا شده است. اولین گره‌ی ارباب حامل Hmaster و Zookeeper است که بر روی Namenode [1] اجرا می‌شود و وظایف مدیران پرسش و همروندی را اجرا می‌کند. یک خوشه‌ی Zookeeper مورد نیاز است، که کار مدیر هماهنگی را انجام می‌دهد زیرا Zookeeper بر روی ۳ گره اجرا می‌شود. ارباب دوم شامل Namenode دوم یعنی ردیاب کارها و Zookeeper است. گره‌ی سوم تنها Zookeeper را اجرا می‌کند.

شکل ۳مدل گسترشMedCloud

برای گره‌های داده یعنی برده‌ها، ۲۰ گره استفاده می‌شوند که هر یک شامل سرور ناحیه‌ای است که به همراه ردیاب وظایف بر روی گره‌ی داده اجرا می‌شود. گره‌های داده در مدیریت ذخیره‌سازی داده و انجام کارها کارآمد هستند. پس از تنظیم خوشه‌ی Hadoop، Thrift به عنوان رابط برنامه‌نویسی نرم‌افزار[۱۴] مشتری برای ساده‌سازی و مزیت‌های مورد توجه برای ارتباط با اچ‌بیس استفاده شد.[۲۰] پس از برپایی موفقیت‌آمیز با سرور Hbase، چارچوب Restlet، (restlet 2.1rc1) به عنوان سکوی وب استفاده می‌شود. مشخصات ماشین HP، Intel(R) Core (TM) 2Quad، پردازنده‌ی ۲٫۶۶GHz، دیسک ذخیره‌سازی ۳۲۰GB و RAM 8.00 GB برای ارباب‌ها است. برای برده‌ها نیز مشخصه‌ها همان هستند به جز دیسک ذخیره‌سازی ۱۶۰GB و حافظه‌ی فیزیکی RAM 8.00 GB.

آزمایش برای اندازه‌گیری مقیاس‌پذیری سیستم با درخواست تصادفی خواندن‌ها از محل ذخیره‌ی داده‌های Hbase انجام شده است. Apache bench  ابزار محک‌گذاری مناسبی برای اندازه‌گیری کارایی است. تعداد درخواست‌ها در ثانیه به همراه تعداد رو به افزایش گره‌های داده‌ها محاسبه شده است. پارامترهای آزمایش ۱۰۰۰ درخواست ورودی، نرخ همروندی ۱۰۰، و نرخ انتقال ۱۰۰ مگابیت در ثانیه است. هر بار ۵ گره‌ی داده به خوشه اضافه می‌شوند و ۲۰۰۰۰۰ رکورد به پایگاه داده اضافه می‌شوند. به عنوان مثال ۵ گره‌ی داده( ۲۵۰۰۰۰ رکورد)، ۱۰ گره‌ی داده(۴۵۰۰۰۰ رکورد)، ۱۵ گره‌ی داده( ۶۵۰۰۰۰ رکورد) و … . هر رکورد شامل ۸ ردیف با ۳ کپی است. همان‌طور که در شکل ۴ مشاهده می‌شود، تعداد درخواست‌ها در ثانیه حدود ۲۰۰ عدد است. اگرچه داده به تدریج بزرگ می‌شود، تعداد درخواست‌ها در ثانیه ثابت است. این بدان معنی است که با افزایش اندازه‌ی داده و گسترش گره‌های داده، سیستم MedCloud هنوز هم سطح کارایی خود را حفظ می‌کند. در نتیجه، مقیاس‌پذیری سیستم تضمین می‌شود.

شکل ۴نمودار درخواست‌ها در ثانیه بر اساس تعداد ماشین‌ها

۵٫ نتیجه‌گیری

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

منبع

Sobhy, Dalia, Yasser El-Sonbaty, and Mohamad Abou Elnasr. “MedCloud: healthcare cloud computing system.” Internet Technology And Secured Transactions, 2012 International Conference for. IEEE, 2012.

[۱] Platform

[۲] Electronic Medical Records (EMR)

[۳] Health Insurance Portability and Accountability Act (HIPAA)

[۴] Amazon Elastic Compute Cloud

[۵] pay-per-time

[۶] Google App Engine

[۷] The Notice of Privacy Practices (NPP)

[۸] Health Information Organization (HIO)

[۹] column-families methodology

[۱۰] Garbage Collection

[۱۱] Hypertext Transfer Protocol (HTTP)

[۱۲] crafted software development kit (SDK)

[۱۳] Hbase

[۱۴] Application programming interface (API)

دریافت مقاله

برای دریافت این مقاله برروی دکمه دانلود کلیک نمایید.