شاید اصطلاح DICOMWeb را شنیده باشید و از خود بپرسید که این چیست و چگونه ممکن است بر محیط تصویربرداری شما تأثیر بگذارد. این گزارش جامع هم یک معرفی سطح بالایی از DICOMWeb و عملکرد آن ارائه می‌دهد و هم نحوه استفاده از آن را توضیح می‌دهد. DICOMWeb نسخه جدیدی از پروتکل DICOM است. یک سرویس تحت وب را برای دسترسی و ارائه اشیاء DICOM (به عنوان مثال تصاویر، اندازه گیری‌ها و تا حدی گزارش‌های تصویربرداری پزشکی) مشخص می‌کند. در درجه اول برای توزیع نتایج و تصاویر به متخصصان مراقبت‌های بهداشتی در نظر گرفته شده است و قرار نیست جایگزین اتصالاتی که  بین مودالیتی‌هایی مانندCT، MR، اشعه ایکس دیجیتال و سایر دستگاه‌های گردآوری با PACS وجود دارد باشند زیرا این فرایند بر اساس استاندارد ارتباطی موجود DICOM  که استانداردهای تکامل یافته و سنتی هستند می‌باشد. DICOMWeb مکانیسم ساده‌ای برای دسترسی به یک شیء DICOM با استفاده از پروتکل‌های وب متداول، یعنی پروتکل HTTP / HTTPS فراهم می‌کند.

[vc_row][vc_column][vc_column_text] توجه داشته باشید که از امکانات جستجوی گسترده تصاویر DICOM در وب پشتیبانی نمی‌کند، با این وجود امکان استعلام از یک پایگاه داده کاملاً مشخص را فراهم می‌کند مثلا یک PACS، VNA (بایگانی فروشنده – خنثی)، یا رجیستری تصاویر مانند یک مرکز تبادل اطلاعات بهداشتی خصوصی یا عمومی (HIE) برای مطالعات تصویربرداری و اطلاعات مربوطه بیمار.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_single_image image=”16114″ img_size=”full” alignment=”center” onclick=”custom_link” link=”#Book” el_id=”Book”][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]

DICOMWeb نه تنها می‌تواند به اطلاعات بومی تصویر DICOM دسترسی پیدا کند بلکه به شما امکان می‌دهد از ارائه دهنده شیء درخواست کنید تا داده‌ها را به یک قالب که آماده ارائه می‌باشد مانند نمود JPEG تصویر DICOM تبدیل کند. با این حال، باید توجه داشت که DICOMWeb فقط مربوط به اشیاء بومی DICOM است، یعنی به اشیایی که بطور طبیعی در قالب غیر DICOM مانند JPEG، اسناد PDF و غیره ذخیره می‌شوند مرتبط نیست.

پروتکل استفاده شده در DICOMWEB چیست؟

پروتکل مورد استفاده DICOMWeb جدید نیست. برعکس، توسط بسیاری از شرکت‌های ارائه دهنده دسترسی وب مانند آمازون، گوگل و بسیاری دیگر به طور گسترده‌ای استفاده می‌شود. یک مزیت عمده نیز وجود دارد و آن این است که پروتکل سنتی DICOM هنوز تا حدودی یک پروتکل تک مخاطبی است که فقط برای پزشکی و در درجه کمتری برای تصویربرداری صنعتی استفاده می‌شود. در نتیجه، DICOMweb دسترسی به ابزار، تخصص و منابع بیشتری را فراهم می‌کند که مقادیر بسیار بیشتری از آنچه در حوزه تصویربرداری پزشکی در دسترس داریم، می‌باشد. علاوه بر این، ما یک هدیه دیگر نیز دریافت می‌کنیم. سرویس‌های وب که برای استفاده در دستگاه‌های تلفن همراه مانند تبلت، فبلت، تلفن و غیره بسیار مناسب هستند. DICOMWeb امکان “مخلوط کردن” آسان برنامه‌های مختلف در یک صفحه را فراهم می‌کند. به عنوان مثال، یک پرونده پزشکی الکترونیکی (EMR) می‌تواند منبعی را برای نمایش یک تصویر با استفاده از یک تماس ساده که توسط DICOMWeb API تعریف شده (رابط برنامه نویسی برنامه) در کنار نتیجه آزمایشگاه یا سایر اطلاعات بازیابی شده با استفاده از خدمات وب راه اندازی کند.

به عنوان یک نمونه تشبیه، این را در نظر بگیرید که چگونه Google Maps به روش استاندارد اکثر وب سایت‎‌ها جهت ارائه مسیرهای راهنما به سمت کسب و کارهای خودشان تبدیل شده است، به عنوان مثال یک رستوران یا هتل. یک کلیک روی یک نقشه ای کوچک، شما را به یک نقشه بزرگ با جهت‌های راهنمایی هدایت می‌کند. ما می توانیم با بازیابی یک تصویر پزشکی از پایگاه داده PACS، کار مشابهی را انجام دهیم، با یک کلیک ساده که به یک آدرس وب تبدیل می‌شود، تصویر تعبیه شده در یک صفحه EMR فراهم می‌شود.

بله حتی اگر بتوانیم قالب بومی DICOM را بازیابی کنیم، هنوز به یک مشاهده‌گر DICOM نیاز داریم، اما راه اندازی آن بسیار آسان‌تر می‌شود و اگر از ارائه دهنده خواسته شود که داده‌های پیکسل را به صورت یک قالب استاندارد و مطابق با رسانه مصرف کننده مثلا JPEG یا TIFF ارائه دهد یا در صورت گردآوری اطلاعات به صورت چند فریمی و دینامیک مانند موردی که در قلب و عروق یا بررسی‌های قلبی (اکوکاردیوگرافی) استفاده می‌شود، آن را به MPEG تبدیل کند، می‌تواند به راحتی در هر مرورگر استاندارد وب نمایش داده شود. همچنین قابلیت تبدیل گزارش ساختار یافته DICOM به یک متن، pdf یا html که باز هم نمایش ساده‌ای دارد و به نمایشگر ویژه DICOM نیاز ندارد، وجود دارد.

DICOMWeb قالب‌های واقعی داده DICOM را که معمولاً به عنوان “سربرگ DICOM” یا فراداده یا نحوه دسترسی به یک پایگاه داده DICOM نامیده می‌شود، تغییر نمی‌دهد. فقط پروتکل را تغییر می‌دهد، یعنی مکانیزم حمل و نقل مورد استفاده برای دسترسی به اطلاعات.

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

 با DICOMWeb، یک شناساگر منبع یکنواخت ساده (URI) که منبع را تعریف می‌کند کافی است در حالی که در پروتکل DICOM سنتی ما باید از شماره پورت خاصی استفاده کنیم که باید در رایانه با استفاده از یک آدرس IP ثابت پیکربندی شود، مسئله‌ای که  به خودی خود یک مشکل است زیرا امروزه بیشتر جهان از آدرس دهی IP داینامیک و آدرس سطح برنامه DICOM استفاده می‌کند که به آن عنوان AE (عنوان موجودیت برنامه) گفته می‌شود. پروتکل DICOMWeb آدرس منبع را فراهم می‌کند، ما از پورت استاندارد دسترسی به وب استفاده می‌کنیم و مسیریابی توسط زیرساخت آدرس‌دهی اینترنتی انجام می‌شود. دیگر نیازی به آدرس پیچیده IP، شماره پورت و آدرس دهی عنوان AE نیست.

 خبرهای خوب فقط همین‌ها نیستند. از پروتکل سنتی DICOM به پروتکل DICOMWeb نقشه دهی مستقیمی وجود دارد. در  همان مورد تشبیه اداره پست و FEDEX، این امکان برای FEDEX وجود دارد که نامه را بسته بندی کرده و از اداره پست برای ارسال آن به مرکز توزیع خود استفاده کند و از آنجا برای تحویل پاکت FEDEX از ون‌های FEDEX استفاده کند. . شاید به نظر کارآمد نرسد، اما به یاد داشته باشید که این فقط یک نرم‌افزار است و افزودن یک لایه پردازشی دیگر لزوماً آنقدرها هم دشوار نیست، حتی اگر انجام آن به صورت مستقیم کارایی بیشتری داشته باشد، بنابراین افزودن DICOMWeb به عنوان یک لایه اضافی نرم‌افزار به یک رابط نرم افزار PACS موجود کار دشواری نیست. اگر شما به نحوه بازیابی اطلاعات واقعاً علاقه‌مند هستید، این اطلاعات در تصویر نشان داده شده است. اشیاء DICOM که شامل تصاویر، شکل موج‌ها یا اسناد هستند، در یک بسته‌بندی DICOM محصور شده‌اند و توسط یک پایگاه داده تجاری مانند Oracle، Sybase، MySQL، سرور SQL و بسیاری دیگر مدیریت می‌شوند. بیشتر این پایگاه‌های داده حاوی جداولی هستند که می‌توان با استفاده از آن‌ها و زبان استعلام استاندارد ANSI به نام SQL به آن‌ها دسترسی پیدا کرد.

مشکلی که در اینجا وجود دارد این است که شما باید ساختار جدول پایگاه داده را بشناسید، که در بسیاری از موارد اطلاعات اختصاصی فروشنده برای انجام یک استعلام است. اگر فروشنده‌ای از طریق ایستگاه کاری خود با PACS خود صحبت کند، این مشکلی نیست، اما این مسئله برای یک “خارجی” مشکل محسوب می‌شود، به عنوان مثال اگر می‌خواهید از ایستگاه کاری فروشنده دیگری استفاده کنید، یا می‌خواهید تصاویر PACS مثلا CT یا MR را برای مقایسه بازیابی کنید. حتی اگر فروشنده به اصطلاح طرح پایگاه داده خود را به اشتراک بگذارد، برای هر فروشنده PACS متفاوت است، بنابراین برای دیدن لیست کار مطالعاتی که در PACS شما ذخیره شده است، باید برای هر سیستم PACS درخواست متفاوتی بنویسید. این همان جایی است که استاندارد DICOM نقش مهمی ایفا می‌کند زیرا یک مدل دسترسی اطلاعات استاندارد متشکل از بیمار، مطالعه، سری و تصویر را با کلیدهای جستجو مورد نیاز تعیین می‌کند که جهت دسترسی و بازگشت اطلاعات به ایستگاه کاری یا مودالیتی در یک قالب لیست کار استاندارد لازم می‌باشند. بنابراین، یک استعلام SQL “SELECT… FROM… WHERE” در برابر جداول پایگاه داده اختصاصی با نگاشتن آن در یک درخواست استاندارد DICOM FIND ایجاد می‌شود، که از سلسله مراتب تصویرـ مجموعه ـ مطالعه ـ بیمار برای جستجوی بیمار و سوابق مطالعه و نمایش لیست کار آن استفاده می‌کند. این روشی است که DICOM سنتی عمل می‌کند. برای ایجاد رابط مبتنی بر وب، مرحله بعدی تبدیل استاندارد‌های وب (GET، POST و غیره) که به اصطلاح به آن‌ها دستورات گفته میشود، می‌باشد. داده‌های خروجی با استفاده از XML یا قالب اسکریپت جاوا به نام JSON قالب‌بندی می‌شوند. شما مطمئنا می‌دانید که ایجاد یک رابط کاربری چقدر می‌تواند آسان باشد زیرا توسعه دهندگان JAVA می‌دانند چگونه با استفاده از این زبان‌های متداول اسکریپت نویس، برنامه‌های خاصی برای برای نرم‌افزار خود بنویسند. این دنیای تصویربرداری پزشکی را به دنیای کاملاً جدیدی از برنامه‌ها باز می‌کند که می‌توانند در تلفن یا سایر رسانه‌های تلفن همراه شما تعبیه شوند.

 در مورد بازیابی اطلاعات، کمیته DICOM نیز از این فرصت استفاده کرد و تغییر قابل توجهی در نحوه بازیابی اطلاعات ایجاد کرد. پروتکل سنتی، یک شیء DICOM مانند تصویر را به عنوان یک BLOB مستقل حاوی داده باینری که یک فراداده، یا همان سربرگ به همراه دارد در نظر می‌گیرد. راهی برای جدا کردن این شی وجود نداشت.

 DICOMWeb این امکان را فراهم می‌کند که فرا‌داده‌ها به خودی خود و  بدون داده‌های پیکسل واقعی، یا فقط از طریق داده‌های پیکسل که به آن‌ها “توده داده” می‌گویند بازیابی شوند. برگردیم به تشبیه خود مربوط به نامه‌ها، به جای اینکه چندین پاکت نامه را که همه شان باید در جهت پیدا کردن جزئیات کل اطلاعات رد و بدل شده باز شوند، این امکان را فراهم می‌کند که نامه‌ها در یک جعبه بزرگ قرار داده شوند، که به عنوان “انتقال توده‌ای” از آن یاد می‌شود و همچنین امکان تفسیر محتوای آن با مشاهده بارنامه (فراداده)، که می‌تواند به طور جداگانه بازیابی شود را نیز فراهم می‌کند. تا این جا مشکلی وجود ندارد هر چند، ممکن است نگران مسائل امنیتی باشید، زیرا در حال حاضر، اکثر برنامه‌های پزشکی با استفاده از یک شبکه بسته در بخش رادیولوژی قفل شده‌اند، که توسط فایروال، نرم افزار تشخیص نفوذ و سایر سیستم‌های حفاظتی در برابر نرم افزارهای مخرب محافظت می‌شود. اگر یک پزشک نیاز به دسترسی به تصاویر از طریق یک شبکه عمومی داشته باشد، اغلب با استفاده از VPN یا شبکه خصوصی مجازی این امکان فراهم می‌شود، یک “تونل” امن از طریق زیرساخت اینترنت عمومی ایجاد می‌شود و به شما امکان می‌دهد اطلاعات رمزگذاری شده را به همان روشی که تجارت الکترونیک اجازه می‌دهد خرید بلیط هواپیما یا هر خرید آنلاین دیگری را با استفاده از پرداخت کارت اعتباری انجام می‌دهید مبادله کنید. که ما را به این نکته می‌رساند: از همان مکانیزم امنیتی استفاده شده برای خرید مثلا بلیط هواپیما یا خرید آنلاین کتاب جدید، یعنی احراز هویت کاربر و رمز عبور و همچنین رمز‌گذاری امن شماره کارت اعتباری شما، برای دسترسی به اطلاعات از طریق DICOMWeb استفاده می‌شود. بله، خرید بلیط برای یک کنسرت آنلاین ممکن است با HIPAA سازگار نباشد، اما ضمانت‌های اضافی مانند مسیرهای ممیزی و مدیریت رضایت با رعایت استانداردهای همراه و جزئیات آن در بخش به اصطلاح ITI (زیرساخت IT)  IHE( ادغام مشخصات بهداشت و درمان) انجام می‌شود .

در مورد پروتکل سنتی DICOM، مجموعه ابزارهای توسعه نرم‌افزاری موجود است، اما هیچ یک مانند پروتکل‌های وب نیست. همگام سازی بین دو دستگاهی که از پروتکل سنتی DICOM استفاده می‌کنند سربارغیربدیهی دارد زیرا هر برقراری ارتباطی شامل سه مرحله می‌باشد : نیاز به همگام سازی بین دو دستگاه در مورد نوع و رمزگذاری اطلاعاتی که باید رد و بدل شود وجود دارد و پس از تأیید، تبادل واقعی و سپس دوباره مذاکره برای انتشار انجام می‌شود. بنابراین سه مرحله به جای یک مرحله وجود دارد و همه از یک جعبه ابزار DICOM استفاده می‌کنند. تصور کنید که یک مدیر پروژه (دستگاه DICOM) می‌خواهد اطلاعات را تبادل کند. او با منشی (جعبه ابزار) تماس می‌گیرد، وی برای اطمینان از اینکه قادر به دریافت اطلاعات ارسال شده هستند، با مقصد تماس می‌گیرد. مقصد با استفاده از اطلاعات موجود در فهرست خود (شماره پورت، آدرس IP، عنوان AE)، پاسخ را تأیید یا رد می‌کند، در صورت تأیید، اطلاعات رد و بدل می‌شوند (تصویر را می‌فرستد) و با تماس دیگری آن را پیگیری می‌کند (اتصال را آزاد می‌کند). در عوض، در مورد نمونه تشبیه DICOMWeb، مدیر می‌تواند اطلاعات را در یک صندوق پستی عمومی رها کند و همین کافی است، یعنی یک مرحله به جای سه مرحله.

حالا بیایید کمی استاندارد DICOMWeb را عمیق تر بررسی کنیم، زیرا این مهم است که بدانید به چه نسخه‌ای از DICOMWeb نیاز دارید یا به دنبال آن می‌گردید. برای اینکه کارها تا حدی پیچیده باشد، سه نسخه مختلف از پروتکل وجود دارد. چرا سه تا ؟ خب، این به چگونگی تکامل فناوری مربوط می‌شود. این کار با یک اجرای ساده در سال ۲۰۰۳ آغاز شد اما با قابلیت‌های محدود، به دنبال آن برنامه‌هایی با استفاده از خدمات وب در سال ۲۰۱۱، و اخیراً در سال  ۲۰۱۴، ما خدمات RESTfull (نمایندگی انتقال دولت) را تعریف کردیم که در واقع فرایندی است که امروزه  بیشتر اینترنت از‌ طریق آن به هم متصل می‌شود. برای بررسی اجمالی و مقایسه این سه نسخه به جدول مراجعه کنید.

نام پروتکل	“سنتی”  DICOM	WADO-URI	WADO-WS	WADO-RS	QIDO-RS, STOW-RS, UPS- RS, capabilities-RS
استاندارد شده در	۱۹۹۳	۲۰۰۳	۲۰۱۱	۲۰۱۴	۲۰۱۴
مورد استفاده	مشاهده‌گر از زاه دور  DICOM	سرور وب / دسترسی به مرورگر	دسترسی به خدمات وب فراداده و تصویر	خدمات وب  و دسترسی متحرک	خدمات وب  و دسترسی متحرک
پروتکل	“DICOM” پروتکل	محور URI	خدمات وب	خدمات RESTfull	RESTfull خدمات
پارامترهای قالب بازگشتی	DICOM	ارائه شده ،DICOM,   متن، فشرده شده، ناشناس، زیرمجموعه	به عنوان URI اما همچنین فرا داده	به عنوان URI اماهمچنین فرا داده، توده داده	استعلام، ذخیره سازی، فهرست کار
آدرس دهی	IP، پورت, عنوانAE	پورت استاندارد, uri/url	پورت استادارد, uri/url, جامعه  ID	پورت استادارد, uri/url, جامعه  ID	پورت استادارد, uri/url, جامعه  ID
کپسوله شدن	فراسربرگ DICOM	پارت ۱۰ DICOM	SOAP (XML)	JSON (Java script)	JSON (Java script)
ویژگی	سربار,  نیمه اختصاصی	فشرده اما محدود	درازنویس	مناسب برای دسترسی وب	مناسب برای دسترسی وب

در ستون اول، مشخصات پروتکل سنتی DICOM را مشاهده خواهید کرد، که مربوط به سال ۱۹۹۳ است، زمانی از آن استفاده می‌شود  که یک مشاهده گر DICOM در حال دسترسی به یک پایگاه داده PACS یا VNA با پروتکل سه مرحله‌ای می‌باشد. شما فقط می‌توانید تصاویر قالب بندی شده DICOM یا اطلاعات مربوط به آن را پس بگیرید و از IP سنتی، شماره پورت و آدرس عنوان AE استفاده می‌شود. رمزگذاری از فراسربرگ DICOM در مقابل داده‌های پیکسل استفاده می‌کند. بنابراین، ویژگی آن این است که به طور قطع دارای سربار پروتکلی است و تخصصی است، یا حتی ممکن است آن را نیمه اختصاصی بنامید، یعنی فقط در دامنه تصویربرداری استفاده می‌شود.

ستون دوم اولین نسخه از DICOMWeb، WADO URI را نشان می‌دهد که یک URI یا منبع یاب ساده است که می‌تواند برای بازیابی یک شیء در قالب اصلی DICOM یا قالب ارائه شده (به عنوان مثال JPEG) استفاده شود. برای بازیابی اطلاعات از دستور http GET استفاده می‌کند. با این حال، برنامه نرم‌افزار باید دقیقاً بداند که شیء در کجا واقع شده است، به عنوان مثال در یک VNA و برای بازیابی اطلاعات، باید شناسه منحصر به فرد یا UID آن را بداند. یکی از  کاربردهای معمولی می‌تواند بازیابی تصویر از PACS هنگام کلیک روی EMR بر روی یک تصویر آیکون باشد، که مثلا یک درخواست برای نسخه ارائه شده JPEG از آن تصویر را ایجاد می‌کند. گزینه‌های پارامتری (با نام مستعار نوع رسانه) گسترده‌ای برای مشخص کردن نوع بازیابی تصویر وجود دارد، یعنی می‌توانید به سرور دستور دهید تا تصویر را شناسایی زدایی کند، حاشیه نویسی روی تصویر ارائه شده مانند نام بیمار را مشخص کنید، اندازه آن را با تعیین شماره ردیف‌ها و ستون‌ها تغییر دهید، دستور دهید تا منطقه تصویر مبادله شود، عرض و سطح پنجره خاصی را اعمال کنید، در صورت وجود تصویر چند فریمی، شماره فریم را انتخاب کنید و فشرده سازی را اعمال کنید. کپسوله سازی شیء  DICOM به عنوان یک پرونده به اصطلاح قسمت ۱۰ انجام می‌شود، که به قسمت ۱۰ استاندارد DICOM اشاره دارد، که یک فراسربرگ اضافی را با مشخص کردن منبع، سازنده و رمزگذاری مورد استفاده برای پرونده توصیف می‌کند.

 برای داشتن یک تصویر کلی از این که  یک فراخوانی WADO URI چگونه اجرا می‌شود، در اینجا مثالی آورده شده است:

 بازیابی یک ناحیه از یک تصویر  DICOM، در صورت امکان تبدیل شده  به  JPEG2000، با حاشیه نویسی‌هایی در تصویر حاوی نام بیمار و اطلاعات فنی، و نقشه دهی شده داخل یک اندازه تصویر تعریف شده:

https://aspradio/imageaccess.js?requestType=WADO &studyUID=1.2.250.1.59.40211.12345678.678910 &seriesUID=1.2.250.1.59.40211.789001276.14556172.67789 &objectUID=1.2.250.1.59.40211.2678810.87991027.899772.2 &contentType=image%2Fjp2;level=1,image%2Fjpeg;q=0.5 &annotation=patient,technique &columns=400 &rows=300 ®ion=0.3,0.4,0.5,0.5 &windowCenter=-1000 &windowWidth=2500

نسخه دوم DICOMWeb، پیاده سازی سرویس‌های وب یا WADO WS است. این پروتکل براساس عملکردی است که توسط WADO URI ارائه شده است، یعنی در انتخاب گزینه‌های مختلف از همان قابلیت‌ها برخوردار است، اما آن را گسترش می‌دهد تا بازیابی‌هایی را  از رجیستری‌هایی مانند رجیستری تعریف شده توسط پروفایل IHE XDS (تبادل اسناد سازمانی) فراهم کند.

برخلاف WADO URI که درخواست کننده برای بازیابی یک تصویر یا شئ، شناسه منحصر به فردی (UID)  را مشخص می‌کند، آدرس دهی آن امکان تعیین یک شناسه مخزن منحصر به فرد برای قرار دادن داده‌ها را فراهم می‌کند. در اصل همتای تصویربرداری تبادل اسناد IHE XDS  است. تفاوت دیگر با WADO URI رمزگذاری با استفاده از XML برای فراداده برای اشیا ء برگشتی است.

یک مورد می‌تواند این باشد که EMR بخواهد در قالب JPEG یک تصویر در هر سری با اطلاعاتی راجع به توصیف هر سری نشان دهد (به عنوان مثال شرح سری). در این حالت، EMR  لیستی از اشیاء را به سرور DICOM ارسال می‌کند (“انتخاب”) و محتوای شی را درخواست می کند. سرور DICOM تصاویر JPEG مربوط به اشیاء ذکر شده را پس می فرستد و EMR اطلاعات “انتخاب” را برای به دست آوردن اطلاعات مربوط به اشیاء بازیابی شده را به سرور DICOM ارسال می کند و سرور DICOM اطلاعات مربوطه را به صورت یک سند”فراداده”  که به XML تبدیل شده است پس می فرستد.

WADO WS  از پروتکل SOAP (پروتکل دسترسی ساده به اشیا) استفاده می‌کند. کپسوله سازی SOAP با استفاده از XML بسیار محبوب است و به طور گسترده توسط بسیاری از ارائه دهندگان خدمات اینترنت استفاده می‌شود. یکی از معایب SOAP این است که این پروتکل کاملاً زبانی است، همان درخواستی که در بالا ذکر شده با استفاده از URI   منجر به تراکنشی می‌شود که اندازه آن حدوداً پنج برابر است. باید توجه داشت که WADO WS برای تبادل تصاویر در شرکت‌های مختلف در زمینه فعالیت IHE XDS بسیار مفید بود، اما تمرکز کمیته استاندارد به جای گسترش و بهبود WADO WS، گسترش نسخه بعدی بوده است.

گزینه سوم برای DICOMWeb، WADO RS  استفاده از خدمات RESTful است. باز هم، با توجه به عملکرد آن، بسیار شبیه WADO URI و WADO WS است، از این جهت که می‌تواند تصویری را با حاشیه نویسی، پنجره دار، مقیاس دار، فشرده و غیره بازیابی کند اما در مورد بازیابی تصویر یک و چند فریمی و داده‌ها و فراداده‌های ارائه شده، استاندارد گزینه بازیابی داده‌های به اصطلاح انبوه، یعنی داده‌های پیکسلی را بدون سربرگ یا فراداده معمولی اضافه کرد.

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

پروتکل RS به نحوی گسرتش داده شده است تا نه تنها یک بازیابی (WADO RS)، بلکه یک فروشگاه (STOW RS) و استعلام (QIDO RS) را نیز ارائه دهد. این سرویس یک لیست کاری اضافه کرد که طبق مدل سنتی DICOM UPS یا

Unified Worklist and Procedure  گام برداشته و ویژگی بازیابی قابلیت‌های یک منبع خاص را دارد، یعنی خدمات و جزئیات آن سرویس‌هایی که می‌تواند ارائه دهد چیست.

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

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

تفاوت عمده بین WADO WS و WADO RS در این است که پروتکل Restful (RS) نسبت به پروتکل SOAP فشرده تر است زیرا از JSON استفاده می‌کند اما SOAP از XML استفاده می‌کند. خدمات RESTful مشابه استاندارد HL7 FHIR (منابع تعامل سریع بهداشت و درمان) است.

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

در نتیجه، چه چیزهایی باید در مورد DICOMWeb بدانید؟

• اول از همه، شما باید بدانید که چه کاربردی دارد، یعنی موارد استفاده معمول، مانند توزیع تصویر در وب، نه در روش‌هایی که یک مودالیتی معمول (CT، MR  و غیره) لیست‌های کار را با یک سیستم اطلاعاتی تبادل می‌‌کند یا تصاویر خود را در PACS ذخیره می‌کند.
• دوم، همچنین باید توجه داشته باشید که سه نسخه مختلف وجود دارد، هر یک بر روی یکدیگر کار می‌کنند و عملکرد آن را گسترش می‌دهند، یعنی از پیاده سازی یکURI تا وب سرویس (WS) تا Restful (RS). مشابه سرویس‌های سنتی DICOM، این سرویس‌ها با یکدیگر سازگار نیستند، بنابراین برای مطابقت با سرویس گیرنده‌ها و سرورها باید عبارات انطباق را بررسی کنید.

استفاده از DICOMWeb می‌تواند یک مزیت عمده در موارد خاص استفاده باشد زیرا یک رابط کاربری ساده را فراهم می‌کند که ایجاد آن آسان است و از بسیاری از منابع، ابزارها و تجربیات موجود استفاده می‌کند. علاوه بر این، با پیشرفت‌های موجود در فضای IT مراقبت‌های بهداشتی که FHIR نیز در آن اجرا می‌شود سازگار است. باز هم، این جایگزینی برای نحوه ارتباط سیستم‌ها و PACS در حال حاضر نیست، که بالغ و قوی هستند، به عنوان آخرین کاری که می‌خواهیم انجام دهیم گسترش IOT (اینترنت اشیا) با دستگاه‌های تشخیصی حاوی اطلاعات حساس است، می‌باشد.

با این حال، صحبت در مورد احتیاطات لازم ضروری است. این یک تکنولوژی جدید است، که خطرات خاصی را در رابطه با ادغام، در دسترس بودن و پایگاه دانش در بین ارائه دهندگان به همراه دارد. بنابراین، قبل از شروع به کار در DICOMWeb، اطلاعات و آموزش های لازم را کسب کنید.
منبع : DICOMWeb, what is it and how can it be used