DICOM ( D igital I mage and C ommunications In M edicine protocol suite ).

1. DICOM(Digital Image and Communications In Medicine protocol suite ).

2. DICOM (Digital Image and Communications In Medicine protocol suite ). DICOM představuje digitální zobrazování a komunikaci v medicíně. Jedná se o veřejný standard vyvíjený spojeným úsilím American College of Radiology ( ACR ), Americké radiologické společnosti a National Electrical Manufactures Association ( NEMA ) - Federální asociace výrobců elektrotechniky. Standard je vyvíjen ve spojení s dalšími standardizačními organizacemi zahrnující CEN TC251 v Evropě a JIRA v Japonsku, a dalšími organizacemi zahrnujícími IEEE, HL7 a ANSI v USA.

3. Historie: • Digitalizace obrazové dokumentace sahá do sedmdesátých let minulého století příchodem počítačové tomografie (CT – computer tomography) a dalších diagnostických obrazových metod. Hlavním motorem bylo zvyšující využívání výpočetní techniky v klinických aplikacích a potřeba standardizace metod pro přenos obrazu a přidružených informací mezi zařízením vyráběnými různými výrobci. • ACR a NEMA vytvořili spojenou komisi v roce 1983, která vytvořila standardy k : • podpoře komunikace digitální obrazové informace, bez ohledu na výrobce zařízení • napomáhání rozvoje a rozmachu PACS systémů, včetně rozhraní do nemocničních informačních systému • umožnit vytvářet databáze diagnostických informací, které mohou být využity geograficky distribuovanými zdravotnickými zařízeními

4. DICOM standard: • DICOM podporuje operace v síťovém prostředí a používá standardní síťový protokol TCP/IP. • DICOM podporuje operace s off-line medii používající průmyslový standard medií jako je CD-R a MOD a logické file-systémy jako jsou ISO 9660 a PC file-systém (FAT 16). • DICOM specifikuje, napříč systémem servisních tříd, sémantiku příkazů a asociovaných dat. • Specifikuje úrovně shody. DICOM výslovně deklaruje, jak implementátor Standardu musí strukturovat dokument o shodě „Conformance Statement“ včetně specifikace jednotlivých aplikovaných funkcí a vlastností objektů • DICOM standard je strukturován jako vícesložkový dokument. • Představuje jednoznačné informační objekty, ne pouze pro obrázky a grafiku, ale také pro křivky, reporty, tisk atd. • Specifikuje jednoznačnou identifikaci informačních objektů, a definuje jejich vzájemné vazby v síťovém prostředí

5. PS 3.2 Shoda • DICOM Standard definuje principy, které musí implementace (konstrukce zařízení nebo informačního systému), mající ambice dosáhnout shody se Standardem, splňovat: • Požadavky na shodu. Část Standardu PS 3.2. specifikuje obecné požadavky, které musí být v procesu implementace dosaženo. Konkretizace požadavků pro jednotlivé funkce, data a příkazy je pak uvedena ve specifických kapitolách Standardu. • Prohlášení o shodě. Část Standardu PS 3.2. definuje strukturu dokumentu Prohlášení o shodě. Specifikuje informaci, která musí být v dokumentu obsažena včetně vazeb na konkrétní požadavky uvedené v ostatních kapitolách Standardu.

6. PS 3.3 Definice informačních objektů Tato část Standardu specifikuje velký počet tříd informačních objektů (Information Object Classes), které umožňují realizovat abstraktní definici entit reálného světa aplikovatelnou při komunikaci a přenosu medicínských obrazů a dalších relevantních informací (křivky, strukturalizované nálezy, dávky radiační terapie, atd.). Každá definice třídy informačních objektů je tvořena popisem jejího určení a atributů, pomocí kterých je definice realizována.

7. PS 3.3 Definice informačních objektů (pokračování) • Standard rozlišuje dva typy tříd informačních objektů: • Normalizované třídy informačních objektů obsahuje jen ty atributy, které jsou vlastní reprezentované entitě reálného světa. • Kompozitní třídy informačních objektů naopak mohou obsahovat nevlastní (cizorodé) atributy související s entitou reálného světa. Kompozitní třídy informačních objektů dávají strukturalizovaný rámec pro realizaci komunikačních požadavků pro zajištění úzké vazby mezi obrazovou informací a ostatními relevantními informacemi.

8. PS 3.4 Specifikace servisních tříd • Kapitola PS 3.4 definuje řadu servisních tříd. Servisní třída spojuje jeden nebo více informačních objektů s jedním nebo více příkazy, které nad těmito informačními objekty mají být vykonány. • Příkladem servisních tříd mohou být: • Uložení informací • Dotaz/odpověď • Základní management Worklistu • Management tisku

9. PS 3.5 Datové struktury Tato kapitola specifikuje vytváření a kódování datových souborů (Data set) DICOM aplikací vycházejících z užití Informačních objektů a servisních tříd. Kapitola dále obsahuje specifikaci řady standardních kompresních technik.

10. PS 3.6 Datový slovník • Tato část Standardu představuje centrální registr DICOM datových elementů a jejich definic. Datové elementy představují základní entitu reprezentované informace včetně jejich unikátní identifikace v rámci Standardu DICOM. • Každý datový element je specifikován: • Jednoznačným návěštím (tagem), tvořeným číslem skupiny a číslem elementu • Jménem • Typem hodnoty (řetězec znaků, integer číslo,..) • Hodnotovou multiplicitou (počet hodnot charakterizující atribut) • Případným příznakem opsolentní

11. PS 3.6 Datový slovník • Každý unikátní identifikátor je specifikován: • Unikátní numerickou hodnotou, přičemž jednotlivé komponenty jsou odděleny desetinou tečkou. Maximální délka identifikátoru je 64 znaků. • Jménem • Typem, určujícím zda jde i třídu informačních objektů, definici kódování dat nebo obecně známý informační objekt • Indikací relevantní části Standardu

12. PS 3.7 Výměna zpráv • Kapitola definuje služby a protokoly používané aplikacemi medicínských zobrazovacích metod při výměně zpráv v rámci DICOM komunikace.Zprávy jsou složeny z posloupnosti příkazů a případně navazující posloupností dat (Data streem). • PS 3.7 specifikuje: • Operace a informace o stavu (nebo změně stavu) entity (DIMSE služby), které jsou k dispozici jednotlivým třídám služeb definovaných v kapitole 3.4 • Pravidla pro navázání a ukončení spojení zajišťovaného komunikačními službami • Pravidla pro ovládání příkazů realizujících komunikaci na principu požadavek-odezva • Kódovací pravidla nezbytná pro tvorbu posloupností příkazů a zpráv

13. PS 3.8 Podpora síťové komunikace pro výměnu zpráv V této části DICOM Standard specifikuje komunikační služby a protokoly nejvyšší komunikační vrstvy nezbytné pro komunikaci mezi DICOM aplikacemi. Tyto komunikační služby a protokoly zajišťují, že komunikace mezi DICOM aplikacemi je prováděna efektivně a koordinovaně v daném síťovém prostředí. Uvedená specifikace služeb vrchní komunikační vrstvy (Upper Layer Service) je podmnožinou služeb zajišťovaných sedmivrstvovým komunikačním modelem OSI (Open System Interconnection). Její definice specifikuje použití protokolu DICOM vrchní vrstvy ve spojení s TCP/IP transportním protokolem.

14. PS 3.10 Paměťová media a formáty filů. Kapitola 3.10 Standardu DICOM specifikuje obecný model ukládání medicínských obrazových informací na výměnných mediích. Účelem této části je poskytnout rámec umožňující vzájemnou výměnu různých typů medicínských obrazů a s nimi souvisejících informací na široké škále paměťových médií

15. PS 3.11 Aplikační profily paměťových médií Kapitola 3.11 specifikuje specifickou aplikační podmnožinu DICOM Standardu pro kterou implementace může dosáhnout shody. Takové prohlášení shody je aplikováno na funkčnost procesu výměny medicínských obrazů a relevantních informací na paměťových mediích pro specifické klinické využití.

16. PS 3.12 Paměťové funkce a formáty medií pro výměnu dat • Tato část Standardu usnadňuje a podporuje výměnu informací mezi medicínskými aplikacemi a specifikuje: • Strukturu pro popis vzájemných vztahů mezi obecným modelem paměťových medií a specifickými fyzickými medii a jejich formátem • Charakteristiku specifických fyzických medií a jejich formátů

17. PS 3.14 Zobrazovací funkce standardní stupnice šedi Kapitola 3.14 specifikuje standardizované zobrazovací funkce nezbytné pro konzistentní zobrazování obrazové informace založené na stupnici šedi. Tyto funkce poskytují metody kalibrace konkrétních zobrazovacích systémů umožňující zajistit konzistentní prezentaci obrazů na různých mediích (displeje, tiskárny apod.) Zobrazovací funkce jsou založeny na lidském vizuálním vnímání (Bartenův model).

18. PS 3.15 Bezpečnost a profily managementu systému V této kapitole specifikuje DICOM Standard bezpečnost systémů a pravidla řízení přístupu k informacím, která musí být dodržena pro dosažení shody aplikace se Standardem. Bezpečnostní pravidla a management systému se odkazují na obecně uznávané standardní protokoly jako jsou DHCP, LDAP, TLS a další.

19. PS 3.16 Mapování obsahových zdrojů • Tato kapitola DICOM Standardu specifikuje: • Návrhy formátu strukturovaných dokumentů DICOM informačních objektů • Množinu kódovaných termínů využívaných informačními objekty • Lexikon výrazů definovaných a aktualizovaných DICOM • Překlady kódovaných termínů specifických pro jednotlivé země

20. PS 3.18. Webovský přístup k DICOM objektům (WADO) Tato poslední část DICOM Standardu specifikuje prostředky jimiž je umožněno realizovat požadavek na povolené DICOM objekty ve formátu http URL/URI. Požadavek musí obsahovat směrník na příslušný známý a definovaný DICOM objekt ve formě konkrétního UID.

21. PS 3.1 Úvod a přehled PS 3.2 S h o d a PS 3.4 Specifikace tříd služeb PS 3.6 Datový slovník PS 3.3 Definice datových objektů PS 3.5 Datová struktura a sémantika PS 3.7 Výměna zpráv PS 3.8 Komunikační podpora výměny zpráv TCP/IP OSI PS 3.9 Komunikační podpora Výměny zpráv mezi porty Logika uspořádání Standardu DICOM

22. DICOM komunikace Nejdůležitější částí Standardu DICOM je formalizace a zajištění síťové komunikace mezi entitami se zajištěnou shodou se Standardem DICOM (medicínské zobrazovací přístroje – modality, informační moduly a aplikace –RIS, NIS, PACS,..) spolu s definicí typů a datového formátu pro ukládání obrazové a pacientské dokumentace na výměnných paměťových médiích. Za základ modelu vzájemného komunikačního propojení DICOM entit byl vzat sedmivrstvý základní referenční model OSI (Open Systems Interconnection).

24. Rozhraní Vrchní vrstvy DICOM a aplikační vrstvy OSI

25. Struktura aplikační vrstvy DICOM • Aplikační entity DICOM a třídy služeb v nich obsažených představují jádro aplikační vrstvy. Aplikační entity DICOM využívají služeb zajišťovaných modulem DIMSE (DICOM Message Service Elements). • DIMSE podporuje komunikaci mezi odpovídajícími uživateli služeb DIMSE. Uživatelé DIMSE služeb mohou vystupovat v roli: • iniciátor • prováděcí

26. Základní elementy DIMSE služeb požadavek (žádost) indikace požadavku odezva potvrzení akceptace požadavku

27. Zpráva ( ) Žádost Příkaz Žádost Indikace a přidružená data Zpráva Odezva ( ) Příkaz odezva a přidruženádata Potvrzení Iniciační Vykonavatel DIMSE služby Provádějící uživatel DIMSE služby uživatel DIMSE služby Komunikace mezi uživateli DIMSE služby

29. Služby DIMSE • DIMSE zajišťuje dva typy služeb souvisejících s přenosem informací: • služba oznamovací (notifikační) • služba operační (výkonná) • Oznamovací (notifikační) služba umožňuje informovat inicializačního uživatele o výskytu události nebo změně stavu na straně provádějícího uživatele objektového páru služeb DIMSE (SOP). • Operační služba umožní předat druhému uživateli SOP požadavek na činnost zajišťovanou tímto uživatelem.

30. Operace DIMSE DIMSE specifikuje dvě skupiny služeb a to DIMSE-C, která podporuje operace kompozitní třídy objektových párů a DIMSE-N pro SOP normalizované třídy. Obě skupiny DIMSE služeb jsou podporovány DIMSE komunikačním protokolem, který používá specifický proces DICOM formátování a kódování zpráv. Způsob aplikace DIMSE služeb se liší u kompozitního a normalizovaného SOP a tedy byly vytvořeny dvě skupiny DIMSE operací.

31. DIMSE operace NázevSkupinaTyp C-STOREDIMSE-Cprováděcí C-GETDIMSE-Cprováděcí C-MOVEDIMSE-Cprováděcí C-FINDDIMSE-Cprováděcí C-ECHODIMSE-Cprováděcí N-EVENT-REPORTDIMSE-Ninformační N-GETDIMSE-Nprováděcí N-SETDIMSE-Nprováděcí N-ACTIONDIMSE-Nprováděcí N-CREATEDIMSE-Nprováděcí N-DELETEDIMSE-Nprováděcí

32. DIMSE protokol Stroj DIMSE protokol definuje procedury a pravidla kódování nezbytná pro tvorbu zpráv využívaných pro výměny příkazů a odezev mezi dvojicí uživatelů DIMSE služeb, respektive dvěma DICOM aplikačními entitami. Stroj DIMSE protokol akceptuje zprávy a předává je uživateli DIMSE služeb a to vždy dvojicí požadavek/odezva, respektive indikace/potvrzení. Procedury definují pravidla pro přenos zpráv odpovídajících požadavku a odezvě inicializačního a provádějícího uživatele tvořících SOP. Pravidla specifikovaná DIMSE protokolem definují způsob interpretace příkazové části zprávy, nedefinují však, co iniciační uživatel má dělat se získanou informací a jak má být provedena operace na straně provádějícího uživatele služby DIMSE.

33. Datový soubor Příkazovýsoubor Příkazový element Návěští Délka Hodnota Struktura DICOM zpráv

34. Podpora síťové komunikace pro výměnu DICOM zpráv Síťové komunikační služby DICOM tvoří množinu specifických komunikačních služeb určených pro komunikaci mezi DICOM aplikačními entitami. DICOM komunikační entity se označují jako SCU (Service Clase User) a SCP (Service Clase Provider). Z hlediska architekturu DICOM se jedná o dvě rovnocenné entity, respektive uzly. Komunikace na úrovni Vrchní vrstvy je realizována v režimu klient/server, přičemž zpravidla bývá SCU klientem a SCP serverem.

35. Služba navázání a ukončení propojení uživatelů není vykonávána DIMSE, ale nižší vrstvou OSI modelu reprezentovanou Relační a Presentační vrstvou. V síti DICOM se jedná o Vrchní vrstvu DICOM. Během fáze navázání spojení si uživatelé DIMSE služeb vymění iniciační informace a to prostřednictvím specifikace parametrů příkazu A-ASSOCIATE Vrchní vrstvy DICOM. Služba (příkaz) A-ASSOCIATE zajistí předání tří klíčových parametrů: • Aplikační kontext (unikátní nejvyšší vrstva spojení) • Prezentační kontext (nižší vrstva spojení) • Položka uživatelské informace • Příkazy A-RELEASE a A-ABORT jsou využity pro ukončení spojení. Služba vzájemného propojení uživatelů DICOM entit.

36. Základní služby Vrchní vrstvy SlužbaTyp A-ASSOCIATEPotvrzovaný příkaz A-RELEASEPotvrzovaný příkaz A-ABORTNepotvrzovsaný příkaz A-P-ABORTPotvrzovaný příkaz P-DATANepotvrzovsaný příkaz

37. Datové jednotky protokolu DICOM A‑ASSOCIATE‑RQ PDU – každé spojení DICOM entit začíná tímto příkazem. Součástí procesu inicializace asociace (spojení) sdělí požadující entita provádějící entitě o jaký požadavek v následující komunikaci půjde a jaké jsou požadovaní (navrhované) parametry spojení A‑ASSOCIATE‑AC PDU – provádějící element reaguje na předchozí příkaz akceptací návrhu, nebo navrhne své vlastní parametry spojení, případně zamítne některé z požadovaných služeb A‑ASSOCIATE‑RJ PDU – provádějící element tímto příkazem odmítne realizovat požadované operace (služby) a ukončí komunikaci P‑DATA‑TF PDU – příkaz realizuje vlastní přenos dat A‑RELEASE‑RQ PDU – příkaz regulérně ukončí spojení mezi požadujícím a provádějícím elementem A‑RELEASE‑RP PDU – provádějící element potvrzuje tímto příkazem akceptaci ukončení komunikace. Požadující element může, ale nemusí na toto potvrzení čekat. A‑ABORT PDU – příkaz ukončí spojení v situaci, kdy dojde k nenormální situaci při přenosu dat. Všechny původně požadované služby jsou tímto příkazem ukončeny.

38. Klíčové služby DICOM DICOM STORE DICOM STORAGE COMMITMENT (potvrzení o realizaci správného uložení obrazové informace) DICOM QUERY/RETRIEVE DICOM MODALITY WORKLIST (předání požadavků a dat na vyšetření a plánovaného pořadí vyšetření na jednotlivých modalitách) DICOM PERFORMED PROCEDURE STEP (odeslání informace o postupu a fázi vyšetření prováděného příslušnou modalitou) DICOM PRINT (realizace procesu tisku obrazové informace)

39. DICOM storage commitment Odeslání obrazové informace Požadavek na potvrzení Potvrzení o uložení dat

40. DICOM Storage Commitment • Poskytuje potvrzení z datových uložišť. • Provider – PACS, datové úložiště • Uživatel – obvykle modalita nebo pracovní stanice, další PACS nebo broker. • Požadavek / odpověď • Modality požadují data z PACSu (požadavky jsou specifikovány seznamem datových objektů) • PCAS odpovídá modalitě (odpovědi obsahují: seznam datových objektů, při selhání, poskytují důvod selhání, omezení zdroje, objekt nenalezen apod. • Použití • Ztráta síťového spojení • Ztráta připojení PACSu • Studie byly do PACSu zapsány pozdě

41. DICOM Instance Availability Notification: • Poskytuje oznámení o dostupnosti obrazových dat. • Provider – používá oznámení. Obvykle RIS / nebo reportovací systém. Může to být účetní systém. Pracovní stanice pro post-processing. • Uživatel – poskytuje oznámení. Obvykle PACS, další zařízení podporující Retrieve (získání dat). • Použití • PACS ukončí přijímání – ukládání obrázků studie • PACS oznámí reportovacímu systému připravenost k prohlížení • Celkově koordinuje plánování aktivit s přenosem obrazových dat mezi systémy • Napomáhá společnému implicitnímu a explicitnímu workflow • Přínosy • Dovolí včasné čtení workflow a rychlý reporting • Vyhnutí se „vlhkému“ čtení nekompletních studií • Vyhnutí se nadměrným dotazům na PACS kvůli zjištění, zda jsou obrázky připraveny

42. DICOM modality worklist Management obrazové informace RIS Požadavek na worklist NIS Seznam pacientů a dat

43. DICOM modality worklist: Zajišťuje komunikaci uživatelem a providerem. Provider - obvykle RIS (radiologický informační systém), NIS (nemocniční informační systém), může to být PACS, nebo další zařízení. Uživatel – obvykle modalita nebo obrazový systém. Může to být také router, proxy apod. pro externí modality. Query – dotaz. Modalita se dotazuje providera. Dotaz může obsahovat filtry : Datum/čas studie Jméno pacienta ID pacienta (rodné číslo, číslo pojištěnce, interní ID NIS/RIS) Počet přístupů Jméno systému Modalitu

44. DICOM modality worklist (pokr.): • Response – odpověď (RIS/NIS vrací výsledky modalitě. Výsledkem může být prázdný seznam, jedna položka worklistu, nebo více položek worklistu.) • Výsledky obsahují detaily : • Informace o pacientovi (ID, jméno, demografická data alergie,těhotenství, pokyny) • Informace o plánování (Datum a čas) • Informace o proceduře (Poznámky, kód vyšetření - lokální definice, každého radiologického pracoviště, kontrast, medikace) • Další informace (Počet přístupů, číslo studie žádající lékař/ oddělení)

45. DICOM modality worklist (příklad použití): • Dotaz/ odpověď modality od RIS • Modalita zobrazí worklist obsluze • Obsluha vybere položku worklistu • Modalita načte demografická data pacienta a nabídku detailů • Modalita vloží detaily do obrázků, zprávy o stavu procedury, atd.

46. dostupnostoznámení PPShotové PPShotové Worklistodpověď Uložištěpotvrzení odpověď P A C S Uložištěpotvrzenípožadavek RIS NIS Uložiště PPSv řešení Worklistdotaz Akviziční modalita

47. DICOM performed procedure step Management obrazové informace RIS Začátek vyšetření NIS PPS kompletní

48. DICOM Modality Performed Procedure Step (MPPS) • Provádí logování a sledování stavu procedur na modalitách. • Provider - obvykle RIS (radiologický informační systém), NIS (nemocniční informační systém), PACS. Jeden provider může přeposílat data dalším. • Uživatel – obvykle modalita nebo obrazový systém. Může to být také router, proxy, broker apod. pro externí modality. PACS jako proxy pro modality.

49. DICOM MPPS (příklad použití): • Indikuje jednotlivé kroky procedury. • Sledování atributů • Zprávy neplánovaných případů • Kompletace – dokončení • Přerušení • Selhání modality, špatně vybraná položka worklistu, apod. • Asistence při účtování a přeplánování

50. dostupnostoznámení PPShotové PPShotové Worklistodpověď Uložištěpotvrzení odpověď P A C S Uložištěpotvrzenípožadavek RIS NIS Uložiště PPSv řešení Worklistdotaz Akviziční modalita