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

Prezentace na téma: "DICOM (Digital Image and Communications In Medicine protocol suite )."— Transkript prezentace:

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

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).

23

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 Komunikace mezi uživateli DIMSE služby
Žádost Potvrzení Indikace Odezva Zpráva Příkaz Žádost a přidružená data Příkaz odezva ( ) Provádějící uživatel DIMSE služby Iniciační Vykonavatel DIMSE služby

28

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ázev Skupina Typ C-STORE DIMSE-C prováděcí
C-GET DIMSE-C prováděcí C-MOVE DIMSE-C prováděcí C-FIND DIMSE-C prováděcí C-ECHO DIMSE-C prováděcí N-EVENT-REPORT DIMSE-N informační N-GET DIMSE-N prováděcí N-SET DIMSE-N prováděcí N-ACTION DIMSE-N prováděcí N-CREATE DIMSE-N prováděcí N-DELETE DIMSE-N prová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 Struktura DICOM zpráv Příkazový soubor Datový soubor Příkazový element
Návěští Délka Hodnota

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 vzájemného propojení uživatelů DICOM entit.
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í.

36 Základní služby Vrchní vrstvy
Služba Typ A-ASSOCIATE Potvrzovaný příkaz A-RELEASE Potvrzovaný příkaz A-ABORT Nepotvrzovsaný příkaz A-P-ABORT Potvrzovaný příkaz P-DATA Nepotvrzovsaný 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 Uložiště potvrzení požadavek
RIS NIS P A C S Akviziční modalita Worklist dotaz Worklist odpověď PPS v řešení PPS hotové Uložiště Uložiště potvrzení požadavek Uložiště potvrzení odpověď dostupnost oznámení

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 Uložiště potvrzení požadavek
RIS NIS P A C S Akviziční modalita Worklist dotaz Worklist odpověď PPS v řešení PPS hotové Uložiště Uložiště potvrzení požadavek Uložiště potvrzení odpověď dostupnost oznámení