您的系統不用改，
OPPA 從旁邊接上去。

FHIR R4 ＋ TW Core ＋ EMR-IGvalidator 0 error

OPPA 產出的病歷以 HL7 FHIR R4 格式輸出，對齊衛福部 TW Core IG 1.0.0 與電子病歷交換實作指引（EMR-IG）門診病歷（PMR）的資源形狀。

以 HL7 官方 validator_cli 實測，OPPA 產出的完整文件 Bundle 為 0 error； 其中對應門診病歷 S／O／A 三節的 ClinicalImpression，對 EMR-IG 的 PMRClinicalImpressionSubjective / Objective / Assessment profile 亦各為 0 error。

診斷編碼與主次診斷

診斷同時附健保 ICD-10-CM 2023 年版（申報用）與國際 ICD-10-CM 兩組編碼， 有對應者再附 SNOMED CT。

主診斷與次診斷以 FHIR 標準的 Encounter.diagnosis.rank 表達， 鑑別診斷以 Condition.verificationStatus 標記—— 皆為標準欄位，HIS 端不需要匯入任何 OPPA 專屬定義即可解讀。

OPPA 輸出預設帶 status = preliminary：這是供醫師確認的草稿， 經醫師於 HIS 簽核後才成為正式病歷。

逐行稽核軌跡

病歷中每一行都帶來源標記——出自逐字稿原話、由診斷回推的預期所見、 或引自文獻／知識庫——並以 FHIR extension 隨病歷一起交付。 院所端可逐行回溯每一句話的來源。

健保雲端與商用雲端，不是同一件事

貴司的診所客戶最常問的一題是「健保都在推雲端了，為什麼還要地端？」 這題值得先講清楚，因為它會影響您怎麼跟客戶介紹這個產品。

健保醫療資訊雲端查詢系統走的是健保資訊網服務系統（VPN）—— 封閉的專屬網路，醫事機構要先申請線路、再向健保署分區業務組提出申請才連得上， 入口是 10.253.253.242 這類內部網段的私有 IP。 那是國家級的私有網路。一般商用雲端 AI 則是把資料經公開網際網路送到第三方伺服器， 風險結構完全不同。

更關鍵的是兩者做的事方向相反：健保雲端是 查病人在其他院所既有的紀錄（把外面的資訊拿進來）； 語音病歷處理的是這一診正在發生的對話（決定要不要送出去）。 所以健保雲端化並不會取代「病歷生成要不要留在院內」這個決定—— 那一段本來就不在健保雲端的範圍裡。

對貴司而言的實務意義：OPPA 不碰健保 VPN 的任何作業， 不讀、不寫、不轉送，也不需要貴司為此做任何調整。 健保相關流程仍然完全走貴司既有的路徑。

這代表什麼、不代表什麼

上面的結果說的是：OPPA 產出的資源在格式與 profile 上通過官方 validator。 以下兩件事我們沒有宣稱，先講清楚比較不浪費雙方時間：

一、這不等於「通過 EMR-IG 認證」。 EMR-IG 目前沒有這種認證機制——實際上，衛福部自己發布的 Bundle-example-PMR 範例， 用同一支官方 validator 驗起來也有 error。我們講的是驗證輸出，不是資格。

二、整張門診病歷單不是 OPPA 一個人組得出來的。 單子裡另有 4 個必填節屬於病人身分與就診行政資料，那是 HIS 的權責範圍。 分工是：OPPA 供節，HIS 組單——這跟我們在界線那一節講的是同一件事。

另外，「可直接上傳電子病歷交換中心」我們也沒有這樣講。 上傳需要 TSP 資格，基層診所的時程另有規劃。