醫療資料交換格式看似都是用來傳遞資訊，實際上各自處理的資料類型、交換方式與使用情境並不相同。規劃醫療資訊平台時，若只確認系統能否「串接」，卻沒有釐清資料要如何理解、由誰維護及如何追溯，日後仍可能出現資料重複、欄位落差或跨系統難以判讀的問題。
常見格式各有用途
HL7 v2 是醫療機構常見的訊息交換標準，常用於傳遞掛號、檢驗、醫囑等事件資訊。它適合即時或近即時的系統間訊息傳送，不過不同機構可能採用不同欄位設定與實作方式，因此介接前通常需要確認訊息結構、代碼及必要欄位。
CDA（Clinical Document Architecture）著重於臨床文件的結構化表達，例如病歷摘要或檢查報告。文件可包含供人閱讀的內容，也能將部分資訊整理成具結構的資料。若資料交換的核心是完整文件，而非單一事件訊息，CDA便是可評估的格式之一。
FHIR（Fast Healthcare Interoperability Resources）以可組合的資源描述醫療資料，並常透過網路服務介面進行交換。它的資源設計有助於不同系統依需求取用特定資料，但實際介接仍須確認使用的版本、資源設定檔、身分識別方式與授權規則。採用相同標準名稱，不代表各系統就能直接互通。
DICOM 則主要用於醫學影像及相關資訊的儲存與傳輸，常見於影像設備、影像管理系統與檢視工具之間。若平台需要處理影像資料，除了確認 DICOM 支援情形，也要考量影像索引、檢視流程及與病歷資料的關聯。
格式之外，還要看資料能否被一致理解
格式解決的是資料如何排列、傳送或保存，資料本身的意義仍需要一致的代碼與詞彙支援。檢驗項目、診斷名稱、藥品或機構識別資訊若採用不同編碼，即使資料成功送達，接收端也可能無法正確解讀。因此，平台規劃時應盤點目前使用的代碼系統，確認是否需要對照表、轉碼規則及版本管理機制。
身分識別同樣重要。病人、醫療人員、機構與設備的識別方式若不一致，可能造成資料無法正確關聯。規劃時宜明確訂定識別欄位、資料來源與更新責任，也要保留必要的操作紀錄，讓資料交換過程可供檢視與追蹤。
平台規劃可從需求盤點開始
規劃前先列出資料來源、接收系統、交換目的與更新頻率，再依資料型態選擇合適格式。臨床事件訊息、結構化文件、網路服務介接與醫學影像，可能需要不同的交換方式，不必強求所有資料都採用同一種格式。
介接測試也不應只驗證資料是否送出，還要確認欄位完整性、代碼對應、錯誤回報及重送機制。若標準版本或欄位規則日後調整，應事先規劃變更流程，並確認各參與系統如何同步更新。
資料安全與權限設計則需納入整體架構。應依使用情境設定資料存取範圍，並檢視傳輸與保存方式、帳號權限及紀錄留存需求。涉及個人健康資料的應用，還需依相關法規與組織規範處理，避免超出授權範圍使用資料。
從智慧醫療到數位照顧的整合思考
醫療資料交換不只是系統間的技術連線，也關係到不同服務如何在適當權限下使用一致、可理解的資訊。嘉鈊科技股份有限公司的服務項目包括智慧醫療平台（智慧醫療資訊平台）、數位照顧（數位健康與遠距照護），以及產業賦能與健康平台（企業健康管理與健康服務整合）。在規劃相關平台時，可先釐清資料來源、使用目的與跨系統介接需求，再評估適用的交換格式與治理方式。
沒有單一格式能涵蓋所有場景。選擇時應回到資料類型、系統現況、使用者需求與維運條件，並將標準版本、語意代碼、權限控管及後續擴充一併納入考量，才能讓交換架構更符合實際運作需要。
比較常見醫療資料交換格式的結構差異
醫療資料交換格式的差異，不只在檔案長相，也在資料如何分段、描述與傳遞。規劃平台時，若只確認系統能否「匯出檔案」，卻沒有釐清資料語意與使用情境，後續仍可能出現欄位對不上、資訊重複或難以串接的問題。
HL7 v2：以訊息傳遞為核心
HL7 v2 常見於院內系統之間的資料交換，例如病人資料、掛號、檢驗與醫囑等訊息。它通常由多個以分隔符號區分的欄位與資料段組成，傳送內容可依事件類型調整。這種方式適合既有系統間的即時訊息往來，但不同機構可能採用不同欄位設定或選用規則，因此整合前需要確認版本、訊息類型、欄位定義及代碼使用方式。
CDA：以文件呈現臨床紀錄
CDA（Clinical Document Architecture）以臨床文件為主要單位，常用於出院摘要、檢查報告等具有完整脈絡的紀錄。文件可同時包含便於系統讀取的結構化資料，以及供人閱讀的內容，適合保留一份紀錄的整體脈絡。相較於逐筆傳送的訊息，CDA 更像一份具標準結構的電子文件；平台規劃時，需考量文件範本、欄位一致性及版本管理。
FHIR：以資源組合資料
FHIR（Fast Healthcare Interoperability Resources）將常見醫療資訊拆分成可重複運用的資源，例如病人、就診、檢驗結果與用藥紀錄，再透過 API 等方式交換。它便於依需求選取資料，也有助於不同應用逐步串接。不過，資料能否正確理解，仍取決於各系統對資源欄位、代碼與參照關係的設定；採用 FHIR 不代表所有資料都會自動一致。
DICOM：處理醫學影像及相關資訊
DICOM 主要用於醫學影像及其檢查資訊的儲存與交換，除了影像內容，也包含可辨識檢查與影像序列的資料。若平台涵蓋影像系統，除了確認能否接收 DICOM 檔案，也要評估影像儲存、調閱方式，以及與病人和檢查紀錄的關聯。它與 HL7 v2、FHIR 的側重不同，通常需要與其他格式搭配，而非取代所有醫療資料交換方式。
openEHR：著重臨床資料模型
openEHR 著重以臨床模型描述與保存電子健康紀錄，常透過原型與範本整理不同類型的臨床資料。它適合重視資料長期累積、結構化表達與模型治理的規劃，但導入前需投入心力建立資料模型、範本與維護機制。實際採用時，也要確認合作系統是否能依照相同模型交換與解讀資料。
平台規劃時，應先依資料用途選格式
若需求以院內事件通知與系統間訊息為主，可盤點 HL7 v2 的訊息與欄位；若要交換完整臨床文件，可評估 CDA；若需支援應用程式介接與彈性取用資料，可考慮 FHIR；涉及影像時，則需納入 DICOM。若平台重視臨床資料模型的一致性與延續性，也可進一步評估 openEHR。
選擇時不宜只看格式是否新或名稱是否常見，還應確認既有系統支援度、必要欄位、代碼與詞彙對照、資料識別方式、錯誤處理、權限控管及版本管理。即使使用相同格式，若欄位定義或資料語意不一致，仍可能需要轉換與驗證流程。
以智慧醫療平台、數位照顧，以及產業賦能與健康平台的規劃來說，嘉鈊科技股份有限公司相關產品與服務可作為評估平台應用情境時的參考。實際建置前，宜先整理資料來源、交換對象與使用需求，再決定採用單一格式或多種格式並行，並安排資料對應與測試，讓不同系統交換的內容能被正確辨識。
確認平台支援的欄位與編碼規範
規劃醫療資料交換時，格式名稱只是起點，真正影響系統能否順利對接的，還包括欄位定義、資料型態、代碼意義與傳輸規則。不同院所或資訊系統即使使用相同格式，也可能對欄位的必填與選填、日期時間寫法、空值表示方式有不同約定，因此在開發前應先整理雙方的資料規格。
常見交換格式各有適用情境。HL7 v2 常見於院內系統間的訊息交換；FHIR 以資源為基礎，便於透過 API 傳遞及管理資料；CDA 著重臨床文件的結構化呈現；DICOM 則主要用於醫學影像及相關資訊。實際採用哪種格式，應依資料用途、既有系統和合作對象決定，不宜只看格式是否新或是否普及。
欄位盤點可從病人識別資訊、就醫事件、檢驗與檢查資料、藥品資訊及文件附件等類別開始，逐項確認欄位名稱、資料型態、長度、是否必填，以及資料來源。若同一欄位在不同系統中名稱相近、定義卻不一致，也要先釐清，例如日期代表建立時間或執行時間，代碼代表院所內部項目或跨機構通用項目。這些細節若未事先對齊，交換成功不一定代表資料能被正確理解。
編碼規範同樣不可忽略。文字資料宜確認字元編碼及特殊符號的處理方式，避免繁體中文、姓名或地址在傳輸後出現亂碼；日期、時間與時區也應訂定一致格式。疾病、檢驗、藥品等項目則需確認採用的代碼系統、版本及對照方式。若不同平台使用各自的代碼，應建立清楚的轉換表，並保留原始代碼或來源資訊，方便後續核對。
正式介接前，建議準備涵蓋一般情境與例外情境的測試資料，檢查必填欄位缺漏、非預期代碼、重複紀錄、空值及傳輸失敗時的處理方式。也要確認資料驗證、錯誤回報、權限控管與稽核紀錄等規則，並以小範圍測試確認收送雙方對資料的解讀一致。
嘉鈊科技股份有限公司的智慧醫療資訊平台、數位健康與遠距照護，以及企業健康管理與健康服務整合，涉及不同資料使用情境。規劃平台介接時，可先界定資料交換目的與使用範圍，再逐一核對欄位和編碼規格；若資料涉及個人健康狀況，應依相關規範管理，實際使用方式並請遵循醫師或專業人員的建議。
評估格式轉換對資料完整性的影響
格式轉換不只是把資料從一種檔案形式改成另一種，更重要的是確認轉換前後的語意與內容一致。醫療資料常見格式包括 HL7 v2、FHIR、CDA 與 DICOM，各自適用於不同的資料交換情境：有些著重臨床訊息傳遞，有些以資源結構呈現資料，有些則用於文件或醫學影像。平台規劃時，應先確認交換對象、使用目的及資料範圍，再決定轉換規則，而不是只比較檔案副檔名或傳輸方式。
欄位對應是最容易影響完整性的環節。同一項資訊在不同格式中，可能有不同欄位名稱、資料型別或層級安排；若來源資料有值，但目標格式沒有對應欄位，內容就可能在轉換時被忽略。規劃時宜建立欄位對照表，列出必填欄位、可選欄位、資料型別及缺漏處理方式，並釐清空值、未知值與未提供之間的差異，避免接收端將不同情況解讀成相同意思。
代碼與單位也需要一致的轉換規則。檢查項目、藥品、診斷及檢體等資料，可能使用不同代碼系統；時間資訊則可能涉及時區、日期格式與事件發生時間。若只搬移文字、沒有保留原始代碼或單位資訊，接收端便難以正確理解資料。可在介接規格中記錄代碼系統、單位換算原則、時間格式，以及轉換失敗時的處理方式；遇到無法確定的映射，不宜直接以近似值取代。
資料關聯與來源紀錄同樣不可忽略。病人識別碼、就診紀錄、文件與影像之間的關係若在轉換後中斷，即使個別欄位看似完整，也可能造成資料無法正確歸屬。平台應保留必要的識別資訊與來源脈絡，並檢查附件、文件編碼及影像參照是否能被接收端讀取。若涉及不同機構使用的識別規則，也應預先定義對應方式，避免重複或錯置。
驗證不宜只確認資料能否成功傳送。較穩妥的做法，是以代表性資料進行轉換測試，逐項比對筆數、欄位值、代碼、時間與關聯資訊，並涵蓋缺漏、特殊字元、長文本及格式不符等情境。若系統支援回轉測試，也可將轉換後資料再轉回原格式，檢視哪些內容無法保留。測試結果應留下紀錄，讓後續規格調整與問題追查有所依據。
對規劃智慧醫療資訊平台、數位健康與遠距照護，或企業健康管理與健康服務整合的單位而言，格式選擇與轉換規則會直接影響跨系統交換的可讀性及可追溯性。嘉鈊科技股份有限公司的相關服務範疇包含智慧醫療平台、數位照顧，以及產業賦能與健康平台；實際規劃時，仍應依資料來源、合作系統與使用情境確認介接規格，並與相關資訊及醫療專業人員共同檢視資料定義。
依照介接對象規劃適用的交換方式
規劃醫療資料交換方式，不能只看檔案格式是否相同，還要確認資料要送給誰、用在什麼流程，以及接收端能否穩定解析。院內系統之間、醫療機構與照護服務之間，或企業健康管理平台與外部服務之間，所需的交換頻率、資料細節和管理權限都可能不同。先盤點介接對象與使用情境，才能選出合適的交換路徑。
若對象是醫院內的既有系統，例如掛號、檢驗或資訊管理系統，常見作法是依循 HL7 v2 等訊息規範交換特定事件資料。這類方式適合需要即時傳遞的流程，但各機構的欄位設定與代碼使用可能不盡相同，介接前應逐項確認資料定義、必填欄位、錯誤回覆方式與版本差異。若交換內容以結構化病歷文件為主，可評估 CDA 等文件型格式，並確認文件範本、欄位語意及附件處理方式是否符合雙方需求。
需要讓不同系統以較一致的方式查詢或更新資料時，可評估採用 HL7 FHIR 等 API 型交換方式。除了檢視資料資源與欄位對應，也要釐清身分驗證、存取權限、資料範圍、版本管理及異常重送機制。若對接對象尚未具備 API 能力，定期交換 CSV、XML 或其他約定格式的檔案，也可能是較容易導入的選項；不過需明確訂出檔名、欄位、編碼、傳輸管道與檔案確認程序，避免資料重複、遺漏或格式不一致。
影像資料則應另行評估，不能只把影像檔案當作一般文件處理。醫療影像交換常見 DICOM 標準，規劃時需同時考量影像本身、檢查資訊、索引方式與存取權限。無論採用哪種格式，都應檢查代碼與單位是否一致，並建立必要的資料驗證、傳輸紀錄、加密與權限控管流程；涉及個人資料時，也要確認資料使用目的及相關法規要求。
實際規劃時，可先建立介接清單，列出每個對象需要交換的資料項目、傳輸方向、頻率、格式、責任窗口與異常處理方式，再以小範圍測試確認資料能否正確傳送與解析。嘉鈊科技股份有限公司的智慧醫療平台、數位照顧，以及產業賦能與健康平台，可作為評估醫療資訊、數位健康與企業健康管理整合需求時的參考；具體介接格式與支援範圍，仍應依實際系統環境及合作對象確認。
建立格式驗證與後續維護的作業原則
格式驗證的重點，不只是確認資料能否匯入，更要檢查欄位意義、代碼使用與資料關聯是否一致。不同醫療資料格式各有用途：HL7 v2 常見於系統間的訊息交換，FHIR 以資源為核心，方便依需求組合資料；CDA 著重臨床文件的結構化呈現，DICOM 則主要用於醫學影像及相關資訊。平台規劃時，應先釐清交換情境與資料範圍，再決定採用的格式及必要的轉換方式，不宜只因格式名稱相同，就假設各系統能直接互通。
建立驗證規則時，可分層處理。第一層檢查格式是否正確，例如必填欄位、資料型態、日期格式與訊息結構；第二層確認內容是否符合業務規則，例如欄位間的關聯是否合理、代碼是否來自約定的代碼集；第三層則檢視資料是否具備實際交換所需的完整性。錯誤訊息應指出問題欄位與原因，並保留可追查的紀錄，讓負責人員能辨識是來源資料、轉換流程或接收端規則造成落差。
格式驗證也需要納入版本管理。當標準、欄位定義或代碼集更新時，應記錄變更內容、生效範圍與相容性影響，並在正式套用前以測試資料檢查既有介接是否受到影響。若新舊版本需要並行，應明確標示版本識別方式及轉換規則，避免不同系統各自解讀，造成資料重複、遺漏或語意不一致。
後續維護則應訂出固定的檢視流程，包括定期盤點介接端點、驗證規則、錯誤紀錄與資料字典；遇到異常時，依照權責分工確認問題來源，並記下處理結果。涉及個人健康資料時，也需依適用的隱私與資訊安全要求管理存取權限、傳輸及紀錄保存。若資料內容涉及個人身體狀況，應遵循醫師或專業人員的建議。
在規劃智慧醫療平台或數位照顧服務時，格式規範與維護責任宜一併納入整體藍圖。嘉鈊科技股份有限公司列有智慧醫療平台、數位照顧，以及產業賦能與健康平台等服務項目；評估合作或平台需求時，可先整理現有系統、交換資料類型與治理要求，再確認各方對格式、版本及維護工作的分工。
案例說明
醫療資料交換看似只是把資料從一套系統送到另一套系統，實際上還要處理資料結構、傳輸方式、欄位意義與使用情境。門診掛號、檢驗結果、病歷文件與醫學影像的內容差異很大，平台規劃時通常不會只靠一種格式，而是依照資料類型與合作系統的需求搭配使用。
HL7 v2 常見於醫療系統之間的訊息交換，適合傳遞掛號、就醫流程、檢驗與檢查結果等事件資料。它在既有醫療資訊環境中應用廣泛，但不同機構可能採用不同欄位設定或實作方式，因此介接前需要確認訊息版本、欄位定義與代碼對照。若只確認「支援 HL7」而未檢視實際規格，仍可能遇到資料格式相同、內容解讀卻不一致的情況。
CDA 著重於具備文件結構的臨床資料，例如病歷摘要或檢查報告。它能保留文件的組織方式，適合需要閱讀與交換臨床文件的情境。不過，若平台要進一步取出文件中的特定欄位，還需確認內容是否依照一致的結構與編碼整理，否則資料可能只能以文件形式呈現，不易直接用於跨系統的欄位比對。
FHIR 則以資源為核心設計，常見傳輸方式包含 REST API，並可使用 JSON 等格式承載資料。相較於較早期的交換方式，FHIR 較容易配合網路服務與應用程式介接，也能依需求組合不同資源。不過，FHIR 並不代表只要採用同一標準就能直接互通；平台仍須釐清實作指引、資料欄位、代碼系統、權限與版本等設定。
醫學影像則有不同的交換需求。DICOM 不只涉及影像檔案，也包含檢查與影像相關資訊，常用於影像設備、影像管理系統與相關應用之間。若平台需同時處理影像與文字型病歷資料，規劃時應分清楚影像本身、影像索引，以及報告內容的交換方式，避免把不同資料型態混為一談。
格式能否交換，只是互通的一部分。檢驗項目名稱、診斷代碼、單位、時間格式與病人識別方式若缺乏一致規則，即使資料成功傳送，也可能難以正確比對或使用。因此，平台設計通常需要建立資料字典與代碼對照機制，並確認錯誤回報、重送處理、資料更新與版本管理的流程。涉及個人健康資料時，也要一併納入身分驗證、存取權限、傳輸保護、稽核紀錄與資料使用目的等考量。
規劃前可先盤點資料來源與接收對象，列出需要交換的資料類別，再逐項確認格式、欄位、代碼與更新頻率。接著透過代表性案例測試資料能否正確傳送、解析與呈現，並檢查異常情況如何處理。這比單純比較標準名稱更能看出介接工作的實際範圍，也有助於控制後續維護成本。
若規劃內容涵蓋院內資訊串接、數位健康服務或跨場域照護情境，可依平台用途評估所需的交換方式。嘉鈊科技股份有限公司的服務項目包括智慧醫療資訊平台、數位健康與遠距照護，以及企業健康管理與健康服務整合；實際規劃時，仍應依資料來源、合作系統與使用情境確認所需的格式與介接條件。
常見問題Q&A
醫療資料交換格式有哪些差異？平台規劃指南的常見問題Q&A
規劃醫療資料交換平台時，格式選擇會影響系統整合方式、資料可讀性與後續擴充。不同標準各有用途，並非採用單一格式就能涵蓋所有情境；實際規劃時，應先盤點資料來源、交換對象與使用目的，再確認介接規則與治理方式。
Q：HL7 v2、CDA 與 FHIR 有什麼不同？
HL7 v2 常用於醫療機構系統間傳送事件與訊息，例如檢驗或就診相關資料。它在既有系統中相當常見，但各機構可能採用不同欄位設定，因此介接時需要釐清訊息結構、代碼與傳送規則。
CDA 著重於具結構的臨床文件，可用來交換病歷摘要或其他文件型內容。文件通常同時包含可供系統解析的欄位，以及便於人員閱讀的文字，適合以文件為單位的交換情境。
FHIR 則以資源為核心，搭配網路服務與 API 進行資料交換，常見資源包括病人、就醫紀錄與檢驗結果。它較容易支援模組化整合，但仍需約定資料剖析、術語與授權方式，不能只因採用 FHIR 就假設不同系統能直接互通。
Q：DICOM 是不是也屬於醫療資料交換格式？
是。DICOM 主要用於醫學影像及相關資訊的儲存與傳輸，涵蓋影像資料、檢查資訊和影像設備之間的溝通。它與 HL7 或 FHIR 的用途不同：後兩者較常處理臨床訊息或結構化資料，DICOM 則聚焦影像工作流程。若平台需要整合文字型病歷與影像資料，通常要分別規劃介接方式，並處理彼此之間的識別與關聯。
Q：格式一致，資料就一定能互通嗎？
不一定。資料格式解決的是資料如何排列與傳送，語意標準則協助說明資料代表什麼。即使兩套系統使用相同格式，也可能因代碼、欄位定義、單位或資料字典不同，造成內容無法正確對照。規劃時可同步檢視常用術語與代碼，例如檢驗項目、診斷分類及臨床概念的對應方式，並建立版本管理與變更流程。
Q：平台規劃前，應先確認哪些事項？
可從資料盤點開始，列出來源系統、資料種類、交換頻率、使用目的與接收端，再確認哪些資料需要即時傳遞、哪些適合批次處理。接著檢視各系統支援的格式與介接方式，制定欄位映射、錯誤回報、重送與資料品質檢核規則。若涉及個人健康資料，也應納入身分驗證、權限控管、傳輸與儲存保護、稽核紀錄及資料使用範圍等要求，並依適用規範辦理。
Q：選用開放標準，就能避免後續維護困難嗎？
開放標準有助於降低對單一系統或廠商的依賴，但落地成效仍取決於實作一致性與文件完整度。建議建立介接規格、測試案例與版本紀錄，並在正式上線前以不同來源資料驗證欄位、代碼和例外情境。當標準或系統版本更新時，也應評估既有介接是否受影響，避免資料傳輸成功、內容卻出現落差。
Q：智慧醫療平台與數位照顧服務如何納入格式規劃？
平台規劃可依資料來源與使用情境，分別評估臨床系統、影像設備及數位健康或遠距照護相關資料的交換需求。嘉鈊科技股份有限公司的產品與服務包含智慧醫療平台（智慧醫療資訊平台）、數位照顧（數位健康與遠距照護），以及產業賦能與健康平台（企業健康管理與健康服務整合）；若評估相關平台，仍應依實際介接對象確認支援格式、資料範圍與安全要求，不宜僅以產品類別推定系統相容性。
醫療資料交換格式的選擇，應回到資料用途、既有系統條件與長期治理需求。先釐清交換內容與語意，再決定介接標準，並將資安、權限及維護流程納入整體設計，平台才較能因應跨系統協作與後續擴充。涉及個人身體狀況或健康判斷時，請遵循醫師或專業人員的建議。