A DICOM-szolgáltatásokról
Még egy bevezető jellegű írásmű sem lehet teljes az alapvető DICOM szolgáltatások leírása nélkül.
Adatküldés DICOM eszközök között
Ahogyan azt már említettük, a DICOM formátum egyik fő célja, egy jól definiált fájlformátum és egy kommunikációs protokoll létrehozása. Ezt a fájl formátumot és a kommunikációs protokollt a DICOM eszközök megértik, ahogy ez a DICOM megfelelési tanúsítványukban áll. Mivel a szabvány megenged többféle számformátumot, az első lépés bármilyen DICOM kommunikációban a metaadatok cseréje, amit mindkét eszköz megért.
Egy másik fontos elem a DICOM kommunikációban az, ahogyan azonosítják egymást. Három adat segít azonosítani egy DICOM-eszközt: az IP cím, a port és az ún. Application Entity Title, amit általában rövidítve használunk "AE Title"-ként. Ha csatlakozunk egy DICOM eszközhöz, az első dolog a három karakterisztikus adatot megtudni mindkét szóban forgó eszközről. Mondjuk, az A eszköznek tudnia kell a B eszköz azonosítóit és viszont. A felhasználói felület, amin keresztül bevihetjük a partner eszköz adatait, eszközönként különböző lehet, és akár jelszóval védett. Ezért a gépek felelősének jelen, vagy legalábbis elérhetőnek kell lennie.
Adatok továbbítása
Amikor két DICOM berendezés összekapcsolódik, és felismeri egymást, elméletben mindkettő továbbíthat adatot a másik berendezés számára. A valóságban inkább csak az egyik játssza az adattároló, a másik az adatforrás szerepét. A DICOM szabvány mégsem erőlteti ezt a különbségtételt. Általában amikor csatlakozik egy A berendezéshez egy B készülék, meg kell határoznunk, hogy mi a B készülék szerepe A-hoz képest. Két lehetőség van: az A készülék vagy egy tárfelhasználó (a B készülék adatokat tud kapni a A készüléktől), vagy társzolgáltató (a B készülék tud az A készüléknek adatot küldeni). A B készülék szemszögéből is tekinthetjük. Ekkor a szerepek felcserélődnek. A következő lehetőségek vannak:
- Az A készülék a B készüléket társzolgáltatónak ismeri fel, és B pedig A-t mint tárfelhasználót
- Mindkét eszköz, A és B, mint tárfelhasználó és társzolgáltató is felismerik egymást
Triviális, hogy nincs értelme annak, hogy A és B mindketten felhasználók, de egyikük sem szolgáltató. Annak sincs, hogy mindkettő szolgáltató, de egyikük sem felhasználó.
DICOM Query és Retrieve
A fenti logikát követve beszélhetünk Query (lekérdezési) felhasználóról és Query szolgáltatóról. A felhasználó küldhet sztenderd Query-t a Query szolgáltatónak, és a szolgáltató válasza vizsgálati azonosítókból áll. Ha van olyan vizsgálat, ami a Query-nek megfelel a lekérdezett eszközön, az eszköztől elkérhetőek az adott vizsgálatok.
A DICOM Modality Worklist
Még nem vezettük be a "DICOM sorrend" fogalmát. Ez a sor általában a páciens név, modalitás fajtája és a vizsgálatra való beutalás. A fenti bekezdés logikáját követve mondhatjuk, hogy egy eszköz DICOM MW (Modality Worklist) szolgáltató. Ekkor, ha egy másik DICOM eszköz DICOM MW felhasználó, akkor ez utóbbi eszköz lekérdezheti az előzőt, és az eredmény a beutalók listája különböző páciensekre és vizsgálatokra.
A DICOM sorrend jöhet a kórházi információs rendszerből, vagy kézzel is készíthetőek egy DICOM eszközön. Egy másik szabvány, az ún. HL7 szabvány írja le a kommunikációs protokollokat és adatformátumokat, ami a DICOM és más kórházi informatikai rendszerek között zajlik. Ennek ismertetése nem témája jelen dokumentumnak.