PACS je v podstatě systém uchovávající obrazové informace vzniklé na digitálních zařízeních (modalitách) používaných ve zdravotnických zařízeních a pracujících na principech různých zobrazovacích metod. Tato zařízení jsou schopna pracovat a komunikovat na základě standardu DICOM (Digital Imaging and Communications in Medicine). Výsledný systém je databázově orientovaný a je schopen pracovat s velkými objemy dat (řádově GB). Aby byl takový systém použitelný, pak musí mít určité vlastnosti, které nemají běžné databázové systémy, protože je nepotřebují. Na druhé straně se musí zbavit vlastností, které mohou v konečném důsledku, zejména při naplnění daty, databázový systém brzdit.

Proč tolik rozruchu, vždyť CT nebo MR představují jenom jednotlivé obrázky a angiografie zpravidla vytváří „slepenec obrázků“ (multiframe)?

Ano, je to pravda. U CT vyšetření jde o stovky až tisíce obrázků o rozlišení 512×512 nebo 1024×1024 bodů a bitové hloubce šedi někde mezi deseti a čtrnácti bity. U MR je používané rozlišení v současné době ještě menší (256×256 bodů), ale množství obrázků v jednom vyšetření mohou dosahovat desítek tisíc. Výsledný objem pak není zanedbatelný. Pokud jde o angioskopii, zde vznikají klasické filmy. Snímky jsou dynamické a v případě konverze klasického videosignálu do DICOM mohou jednotlivé obrázky představovat klasické video s patřičným HD rozlišením. Výsledný soubor může mít i několik gigabytů dat. Když se toto sečte, dojde k naplnění přísloví, kterak tisíckrát nic umořilo osla.

Co to je DICOM?

Správná otázka. Jde o standard, který popisuje, jak má být ukládána a přenášena informace vzniklá na modalitách. Tento standard popisuje i takové detaily, jak má být obrazová informace komprimována a jaké metody mají být použity na straně pracovní stanice nebo modality. Jednotlivé obrázky mají dvě základní části. Popis vlastní bitmapy a blok s tzv. DICOM tagy. DICOM tagy jsou textová pole nesoucí informaci o pacientu, modalitě, parametrech snímkování apod. V této hlavičce jsou také neseny jednoznačné identifikátory, které popisují jedinečnost každého snímku a jeho příslušnost ve strukturální hierarchii. Jednotlivé snímky (a to je jediné, co „reálně“ existuje) jsou sdružovány do sérií, série do vyšetření (nebo studií) a vyšetření do pacienta. Toto je základní čtyřúrovňová hierarchie informací ve vyšetřeních uložených v PACS systémech.

No dobře, máme soubory o velkém objemu dat, a jak to tedy souvisí s databázovými systémy? Je vůbec možné je používat tak, jak jsme zvyklí?

Databáze obecně znají pojem „blob“ (binary large object). Takový objekt jsou schopny uložit a ošetřit ve svých strukturách. Problém je, že různé databáze pracují se svými daty různě. A to je jádro potíží. Vybavovací doba, rychlost obměn dat apod. PACS systémy od jednotlivých výrobců se liší hlavně tímto přístupem. Takovým extrémem je totální rozebrání položek hlaviček DICOM souborů na jednotlivé položky a jejich uložení do databázových tabulek s odděleně uloženou bitmapovou částí. Tento přístup může být velice omezující, protože může dojít k odstranění položek, které databáze nezná. Například může dojít k odstranění privátních tagů, do kterých si specializované pracovní stanice ukládají informace potřebné k popisu specializovaných datových obrazovkových výstupů. Druhý extrém je uchovat celý obrázek v původním tvaru a v pomocné databázi uchovat jen informace nejnutnější k jeho vyhledání, případně k analýze dat nebo jiným pohnutkám.

Jak by měly PACS optimálně fungovat?

Každá databáze funguje dobře, dokud se do ní data vkládají. Pokud potřebujete získat data zpět, je třeba definovat kritéria délky odezvy na dotaz k vybavení nebo podání dat. To se velice jednoduše řekne, ale hůře vykonává zejména při požadavku na data o opravdu velkém objemu. Uvedu příklad. Naše firma se dlouhodobě zabývala informačními ERP systémy. I ti nejvýkonnější zákazníci neměli za deset let více než deset gigabytů databázových dat. Když jsme se začali zabývat PACS, vznikly požadavky ukládat data s roční produkcí od půlky do několika terabytů (!). Pro zajímavost, některá nejproduktivnější pracoviště denně dodávají do svých PACS archivů šedesát až osmdesát gigabytů dat. Na to by hodně „datově vyspělá“ továrna musela pracovat osmdesát i více let. PACS je obecný informační systém. Jeho realizace se liší od dodavatele k dodavateli. Jeden dodavatel holt hrne programovací kód do systému „lopatou“, a jiný dbá o optimalizaci. Z hlediska možností změn, a hlavně nemožnosti řídit upgrade konzolí u modalit apod. je vhodné pojetí, kdy jsou data uchovávána v pokud možno nezměněné podobě. DICOM standard má v sobě zabudovanou jednu velice užitečnou věc. Aby nebrzdil případný rozvoj dodavatelů modalit nebo pracovních stanic, umožňuje používání tzv. privátních DICOM tagů nebo objektů. Tyto objekty či tagy jsou v krajním případě podporovány jen jedním výrobcem. Přesto je žádoucí, aby soubory s privátními informacemi byly uchovatelné a vyvolatelné z obecných DICOM archivů.

Tak které PACS jsou ty dobré?

Většina PACS funguje velice dobře v období, kdy jsou do nich data ukládána a nedojde jejich kapacita. Problémy nastávají v momentě, kdy je kapacita překročena, anebo je v archivu příliš mnoho dat. Pro zákazníka to znamená, že úskalí zakoupeného systému začne vnímat velice, velice pozdě. Proč? Protože PACS systém se zpomaluje pomalu a plíživě a jednotlivé rozdíly v koncepčním pojetí se projeví zejména v době, kdy jsou vytahována historická data pro porovnání. Aby byl PACS funkční a spolehlivý, pak je potřebné nalézt správné dimenze jeho vnitřního nastavení či konfigurace. Jiné jsou požadavky na systém pracující pro ordinaci s jedním rentgenem a ultrazvukem než mnohem komplexnější požadavky na pracoviště s exponovaným provozem s traumatologií apod. Vždy je potřebné se ptát, jaký informační systém zákazníkovi vyhovuje a ten zvolit. Je pochopitelné, že zejména tam, kde jde o velký objem přijímaných dat, bude potřeba uvažovat digitalizaci v jiném rozměru než tam, kde je jen několik rentgenových modalit či ultrazvuků.

Milan Pilný
Autor pracuje jako produktový manažer systému MARIE PACS dodávaného na český trh firmou OR-CZ.