Go 1.27
API
編譯為單一靜態執行檔，運行在空白的容器映像上：沒有 shell、沒有作業系統套件，幾乎沒有可供攻擊的地方。影像以串流方式直接傳輸、不做緩衝，並負責登入、權限、稽核與報告。
技術架構
看得懂、也能完全掌握的技術架構
精簡而現代的技術架構，兼顧速度與安全：編譯式的 Go 1.27 API、Python 3.12 影像處理引擎，以及 PostgreSQL 17。
系統總覽
醫院或診所
您的院內網路
影像儀器
CT · MR · X 光 · 超音波
既有 PACS / RIS
選用
DICOM 節點
- 安裝在醫院網路內
- 接收來自儀器與 PACS 的檢查
- 透過加密網路傳送至雲端
或：網頁上傳
從瀏覽器上傳 DICOM 檔案或 ZIP 壓縮檔
PACSinfra 雲端
您的雲端帳號或自有伺服器
閘道
唯一對外開放的入口
PACSinfra
- 登入
- 權限
- 稽核
- 報告
- 影像代理
私有網路，無對外連接埠
DICOM 處理程式
驗證 · 去識別化 · 匯入
PostgreSQL
應用資料、稽核、工作佇列
Garage
S3 上傳暫存
您的團隊
登入後隨處可用
網頁應用程式 + 檢視器
檢查清單、檢視器、報告、管理
行動 App
隨時查看檢查清單、影像預覽與報告
應用程式
Python 3.12
DICOM 處理引擎
在記憶體中驗證、去識別化並匯入每個 DICOM 檔案，全部在資料進入影像封存系統之前完成。以獨立程序在多個 CPU 核心上平行運作，不需要另外維運訊息佇列。
限制： 去識別化涵蓋 DICOM 中繼資料，但不包含直接燒錄在影像像素中的文字。
Next.js 16 · React 19 · TypeScript 7
網頁應用程式與檢視器
快速的雙語網頁應用程式，提供英文與繁體中文介面，並內建 OHIF v3 醫療影像檢視器。
影像與儲存
Orthanc 25.6
成熟可靠的 DICOM 伺服器，作為影像封存系統。從不暴露在網際網路上。
PostgreSQL 17
應用程式資料、稽核軌跡、工作佇列與影像索引。
Garage 1.0
相容 S3 的物件儲存，用於上傳暫存。
部署
以 Docker Compose 部署於單台伺服器，nginx 是唯一對外開放的入口。不需要管理 Kubernetes。
單台伺服器，Docker Compose
- 網際網路 → nginx （唯一對外入口）
- → Go API （權限、稽核、報告、影像傳輸）
- → Orthanc （私有）
- → PostgreSQL 17 （私有）
- Python DICOM 處理程式 （從 PostgreSQL 資料表領取工作）
- → Garage （上傳暫存，私有）
容量與擴展
每個機構可處理 50,000 筆以上的檢查
PACSinfra 對檢查數量與儲存容量沒有設定上限。實際容量取決於您使用的伺服器，而架構中的每個部分都可以各自擴展。
5,000
位放射科醫師同時使用，零錯誤
每位模擬使用者都會開啟工作清單、開啟檢查，並像檢視器一樣載入整個序列的所有影像。檢查開啟時間低於 200 毫秒（p95）。
約 600
張影像／秒，完成去識別化並可搜尋
完整的端到端流程：上傳、去識別化、儲存與建立索引。一般 300 張影像的 MR 序列約 5 秒即可判讀。
50,000+
每個機構的檢查數，每頁約 3 毫秒
以單一機構 50,000 筆檢查實測：檢查清單約 3 毫秒即可開啟。每一頁都是索引查詢，從不掃描整個資料表，因此封存資料持續增加，速度依然不變。
負載與匯入數據皆以 k6 在單一台 5 CPU、8 GB 記憶體的機器上測得，負載產生器也在同一台機器上執行。無叢集、無 CDN。
規模超過一台伺服器？我做過這件事。
我在正式環境中維運 PACS 與醫療影像基礎設施超過四年，服務對象是澳洲一所大學的醫療研究團隊。隨著您的成長，我可以和您一起擴展系統：增加 DICOM 處理程式、將資料庫與影像儲存放到各自的伺服器，並透過 DICOM 節點連接更多院所。
品質
460+
項自動化測試
Go 與 Python 測試套件會在每次變更時執行，並搭配嚴格的程式碼檢查與型別檢查。全部通過才能發布。
180+
項租戶隔離測試
在受保護的程式碼完成之前就先寫好。測試會嘗試一個機構存取另一個機構檢查的所有方式，每一種都必須失敗。
100%
的機構路由經過權限檢查
API 啟動時會逐一走訪每個機構路由，只要有任何一個沒有宣告權限，就拒絕啟動。被遺忘的端點不可能上線。
實機
對真實封存系統測試
契約測試直接對真實的 Orthanc 與物件儲存執行，而不只是模擬物件，能抓出模擬環境會隱藏的問題。
每次發布也會由人工在實際運作的系統上進行端到端驗證：依照書面操作手冊，逐一檢查登入、上傳、去識別化、影像檢視、報告、受限存取與稽核軌跡。