傳統 DICOM 不適合網頁與行動裝置
瀏覽器和 App 沒辦法直接講 DICOM 協定,中間得另外架一層轉接程式,每一家的做法都不一樣。
DICOMweb Server
傳統的 DICOM 連線要設定 AE Title、開防火牆、處理關聯協商,對網頁、手機與雲端服務都不友善。DICOMweb Server 把影像變成一組標準的 Web API:會呼叫 HTTP 的程式,就能查詢、取像、上傳。
01 — 現況
瀏覽器和 App 沒辦法直接講 DICOM 協定,中間得另外架一層轉接程式,每一家的做法都不一樣。
AI、報告系統、院內自行開發的程式想拿影像,往往得等 PACS 原廠排時程、報價、開私有介面。
介面一多,存取紀錄散在各個系統裡,稽核或資安事件發生時,很難回答「這筆影像被誰調閱過」。
02 — 流程
文件內建在服務裡,每一支 API 都有參數說明、範例指令,還能直接在網頁上發送測試請求。
以單一登入或服務帳號取得存取權限,權限範圍由院方管理。
用 QIDO-RS 依病人、日期、檢查類別等條件搜尋檢查、序列與影像。
用 WADO-RS 取得 Metadata、原始 DICOM、縮圖,或指定 Frame 的 JPEG/PNG。
處理結果、報告或新影像以 STOW-RS 上傳,回到同一筆檢查底下。
實機畫面

所有 API 依功能分組:健康檢查、服務能力聲明、WADO-URI、認證、稽核記錄、影像匯入、QIDO-RS、STOW-RS、WADO-RS。每一支都有參數、回應與範例指令,按「Test Request」就能對實際的服務發送請求。文件有中、英文版本。

資料庫連線、API、影像儲存路徑是否正常,服務已運行多久、用了多少記憶體,每十秒自動更新。值班的人不必登入主機,就知道服務好不好。

每一個打到服務的請求都留下紀錄:時間、方法、路徑、來源與身分、回應狀態、耗時。可以依方法、路徑、狀態與日期篩選,也能一鍵排除管理介面本身的呼叫。查問題、做稽核都用得上。

在瀏覽器裡即時追蹤服務的日誌,可以選日期、等級與行數,輸入關鍵字即時過濾。排除問題時不需要 SSH 進主機翻檔案。

AE Title 與儲存根目錄、稽核的批次寫入策略、縮圖後處理的執行緒數與品質、單檔上傳大小上限、日誌等級與路徑,都在管理後台調整,哪些項目需要重啟也標示清楚。
架構示意
寫入與管理
DICOMweb Server
讀取
資料怎麼走
03 — 功能
QIDO-RS 查詢(檢查、序列、影像三個層級)、WADO-RS 取像與 Metadata、STOW-RS 上傳(可指定寫入既有的檢查),並保留 WADO-URI 給舊系統使用。
取得影像縮圖,或把多影格 DICOM 的指定 Frame 渲染成 JPEG/PNG。遇到沒有像素資料的物件(封裝 PDF、結構化報告、心電圖波形),會明確回覆不支援,並告知應該改用哪一種格式。
提供 DICOMweb Conformance Statement,對接的系統可以用程式讀取這台伺服器支援哪些功能,不必靠口頭確認。
管理後台與 API 的身分驗證都走 OpenID Connect 單一登入,可整合醫院既有的 AD 或 LDAP,同仁用院內帳號登入,和雲智其他產品共用同一次登入。伺服器本身不保存密碼,帳號停用後立即無法存取影像。
每一次 DICOM 存取都寫入稽核紀錄,連同登入的身分一起記下;採批次寫入以降低資料庫負擔。
可在背景預先產生縮圖,執行緒數、尺寸、品質與補掃間隔都可設定,清單頁開啟時不必即時運算。
提供給監控系統與容器平台使用的健康檢查 API,服務異常時可以自動告警或重啟。
04 — 規格
可搭配雲智的 Viewer、報告系統使用,也開放給院方與第三方系統介接。