糖尿病資料互通性的必要性：從患者負擔到標準化臨床資料流
各位早安。這個場次的主題不是自動胰島素傳輸（AID）系統，也不是 GLP-1 藥物，而是關於數據互通性（Data Interoperability）。讓我再重複一次：互通性。我們剛才還在討論，有些臨床醫師可能會問：「你們在說什麼？什麼互通？」我們之所以坐在這裡主持——我是 Lutz Heinemann，旁邊是 Hans de Vries——是因為我們看到了互通性的迫切需求。我們剛才還在聊，在推動這個主題時我們必須多麼固執，因為大家可以看到，台下的聽眾並沒有幾百人。
儘管如此，我們所看到的許多發展，以及未來糖尿病治療的走向，都與互通性息息相關。這就是為什麼我們在規劃這場研討會時，邀請了三位臨床同仁來為大家介紹這個主題。此外，我不確定我們是否有給予足夠的關注，但除了數據互通性之外，還有裝置互通性（Device Interoperability）。接下來我們將看到講者們會帶來什麼樣的精彩內容，我想請 Hans 來介紹第一位講者。
Hans de Vries：這是我的榮幸。第一位講者是三位優秀講者之一的 Johan Jendle。他是瑞典厄勒布魯大學（Örebro University）的教授暨糖尿病研究中心主任，也是一位著名的糖尿病學家、發表過廣泛研究的學者，同時也是《Diabetes, Obesity and Metabolism》期刊的副主編。他曾接受 Abbott、Eli Lilly 等多家公司的演講費，並擔任其諮詢委員會成員。Johan，請上台。
互通性的定義與臨床現況
非常感謝 Hans 和 Lutz，也熱烈歡迎大家。我今天要談的是為什麼我們需要互通性（Interoperability）。
那麼，什麼是互通性？如果我們看定義，它是指電腦系統或軟體交換並使用資訊的能力，或者是不同製造商所生產的裝置之間的互通性。所以，這確實是一個非常廣泛的定義。
在過去的十年裡，我們看到了糖尿病照護的巨大演進，出現了各種用於胰島素給藥、葡萄糖監測、血酮監測等裝置，為我們的患者帶來了附加價值。今天，許多裝置都是相互連接的。這可以是葡萄糖感測器和幫浦之間的連接——無論是傳統幫浦、管線式胰島素幫浦（Tethered insulin pump）還是無管線的貼片式幫浦（Patch pump），也可以是與之連接的智慧型胰島素筆或血酮計等其他測量設備。這些設備的數據通常會傳輸到智慧型手機上的個人糖尿病管理（PDM）應用程式，再透過雲端伺服器連接到數據分析電腦與照護者的行動應用程式。
在臨床實務中，我們可以看到患者在中心，他們周圍有少數幾種連續葡萄糖監測（CGM）系統可以使用；我們也有大約兩百種可以下載數據的血糖機（BG meters）；還有大約半打左右會定期下載數據的胰島素幫浦；此外還有那些具備連線功能的胰島素筆。這些都是患者每天在使用的設備。患者每天都在使用數據，但我會說，從歷史上看，這些數據一直無法被其他人使用，因為過去並沒有開放的 API（應用程式介面，Application Programming Interface）。但如今的趨勢是將其開放，讓互通性成為可能。
跨國數據整合倡議：EDDIG 與 iCoDE
正如 Lutz 剛才提到的，歐洲有一個推動數據整合的倡議組織 EDDIG（歐洲糖尿病數據整合小組，European Diabetes Data Integration Group）。因為我們需要標準來促進這些流程。我們有兩個不同的工作小組，包含了來自臨床專業人員、醫療科技（MedTech）與製藥產業的利害關係人以及各方專家，共同討論並尋求如何應對這個領域面臨的挑戰，並尋求實用的解決方案與全歐洲的共識。正如稍後 Peter 會進一步討論的，這也包含了促進數據整合到我們的**電子健康紀錄（EHR，Electronic Health Records）**中。
如果我們把目光轉向海外，美國也有 iCoDE 和 iCoDE2 計畫。iCoDE 致力於為 CGM 數據傳輸到電子健康紀錄提供建議；而 iCoDE2 則針對胰島素數據的整合進行同樣的工作。這個計畫由 David Klonoff 和 Juan Espinoza 領導，參與的群體非常廣泛，也包含了產業界和來自歐洲的參與者，我自己也是其中一員。
數據分享的三個層級與自動化
重申一次，前面提到的所有關於互通性的內容，核心都在於自動化（Automatization）。身為終端使用者的患者收集數據，然後這些數據需要透過應用程式和行動裝置，發送請求與接收回應，經由 API 傳輸到網路伺服器（通常是雲端），接著才能被下載並用於各種目的。
我們可以看到數據的使用分為不同的層級：
- 第一層級（Level 1）：屬於糖尿病患者（PwD）個人裝置之間的數據分享。患者使用血糖機、連續葡萄糖監測儀或血酮計，並可以基於自身的同意來分享這些數據。
- 第二層級（Level 2）：與醫療照護提供者（HCP）或患者主動選擇的第二方分享數據。這可能包括家人、追蹤者（follower）、工作同事，或是學校裡的指定人員與醫療人員，例如用於虛擬門診或照護應用程式。
- 第三層級（Level 3）：與醫療照護提供者以外的其他第三方分享數據。這可能是科學資料庫、商業資料庫或開發資料庫。其目的可能用於科學研究、產品開發、行銷活動，甚至是保險公司。這裡必須特別注意的是，這類分享有時可能並非糖尿病患者主動做出的選擇。
電子健康紀錄（EHR）的整合挑戰
我們很熟悉從裝置下載數據給患者本人、醫療照護提供者，或是追蹤者/照顧者，這些模式已經沒有什麼爭議。但是，如何促進數據下載到我們的**電子健康紀錄（EHR）**中？這當中會遇到什麼問題？該如何推動？此外，從裝置傳輸到製造商，或是傳輸到付款方（例如醫療體系，或在某些保險公司扮演重要角色的國家傳輸給保險公司），這些情況又該如何處理？
我們希望整合嗎？這是必要的嗎？能夠在電子健康紀錄中隨時取得胰島素和葡萄糖數據，並能回溯查看隨時間發生的變化，答案是肯定的，我們絕對希望如此。
但這無疑充滿了挑戰。這些落差包含了缺乏技術知識與資源來支援整合；技術實作上有太多不同的選項；還有許多法規遵循、通訊、工作流程與參與度方面的考量。這些挑戰層層疊加，增加了成本，而這些負擔最終都落在醫療體系或健康組織身上。
我們還必須知道，不同供應商在數據存取方式上存在差異。這個資料鏈中的任何改變都會導致數據流動出現問題，通常這會迫使我們需要一個第三方數據聚合平台（Third-party aggregator）來介入。這不僅昂貴、耗時，且可能存在技術限制。而在臨床上，我們根本沒有時間容許數據流出現中斷。
數據標準、安全性與術語框架
目前已經有許多標準可以用來確保這裡的數據流動，但我們需要深入探討幾個關鍵因素：我們能確定這些參與方的身分認證（Identity）嗎？裝置之間是否有穩定且高品質的交互通訊（Crosstalk）？當我們下載數據時，術語（Terminology）是否統一且不會造成障礙？
在這些領域，目前有許多標準與框架可供參考。例如，在安全性方面有 HIPAA、HITRUST、SOC2、NIST CSF；在通用數據模型上有 Open mHealth、IEEE、OMOP；身分認證有 OAuth2.0、NPI、EMPI、UDI；互通性標準有 CCD、CDA、HL7、FHIR、SMART on FHIR；術語方面則有 LOINC、RxNORM、SNOMED、CPT、ICD-10 等等。儘管有這麼多框架，但目前對於該使用哪一套並沒有定論，而且在不同地區、國家或大洲之間，情況可能會有很大的差異。
數據所有權與倫理考量
另一個經常被忽視的問題是：誰擁有這些數據？（Data ownership）
我們最近發表了一篇論文《醫療數據所有權明確立法的需求》（The need for clear medical data ownership laws），探討了這方面的爭議。目前對於所有權的歸屬存在著模糊地帶：究竟是患者？臨床醫師？研究人員？醫院？還是醫療設備製造商擁有這些數據？
患者的權利是什麼？患者應該為自己保留數據，還是為了推動創新與更好的治療，將數據分享給研究人員、公共衛生專業人員或公司這種「公共利益」是一件好事？同時我們也面臨著監管上的挑戰，當你從更宏觀的視角來看，這牽涉到多個國家與大洲的規範。
我們還有倫理上的考量：數據擁有者（或患者）是否在知情同意下分享數據？分享的目的是什麼？
其中最具挑戰性的或許是分享利益的分配。如果患者分享了數據，而這些數據隨後被轉化為產品開發、政策制定或其他金錢收益，這些利益是否應該回饋給提供數據的患者？
法規障礙與網路安全
接著談談法規上的障礙。是的，不同大洲、國家和地區之間存在著巨大的差異。例如，在美國是「山姆大叔」（政府）擁有數據，但在歐洲，數據是屬於患者的。這是一個相當大的差異。
我們也面臨著法規的動態變化。回顧歐洲的法規時間軸，從 2016 年的 GDPR（一般資料保護規則）、2017 年的 MDR（醫療器材法規），一直到近年推動的 DGA（資料治理法，2022）、NIS2（網路安全指令，2022）、2023 年的歐洲數據法案（Data Act），以及 2024 年的 AI 法案（AI Act）。這些法規在全面強制執行之前通常有一段緩衝期，要在這其中導航將是一條棘手的道路。
然後，我們面臨著一個微妙的難題：如何在**存取（Access）、安全性（Security）與整合（Integration）**之間取得平衡。
對於網路安全（Cybersecurity），我們的經驗法則（Rules of thumb）是：防止數據被濫用或遺失，並具備恢復遺失數據的能力。為了確保安全，有許多具體的行動可以採取，例如由友善的駭客進行滲透測試（Penetration Testing）、針對 API 注入進行壓力測試，以及鎖定 SQL 注入攻擊。但這也衍生出新的問題：如何將安全性與數據的連線和存取需求融合？如果系統癱瘓或發生安全漏洞，該由誰來承擔責任？這也牽涉到數據該如何儲存的問題，Peter 稍後會對此進行探討。
總結來說，我們面臨的障礙包括：複雜的法規、需要交涉的眾多主管機關（如 FDA、EMA、歐盟認證機構）、糖尿病科技極快的發展速度、網路安全問題，以及數據存取權的缺乏。
展望未來與結論
在未來，我們極有可能會將**機器學習（Machine Learning）**加入這個領域，例如透過生物標記與預測模型來預測糖尿病的結果（如 180 天的糖尿病酮酸中毒風險、90 天的糖化血色素變化，以及 30 天的 CGM 目標範圍內時間）。
總結來說，我們正在邁向**物聯網（Internet of Things, IoT）**的時代，我們擁有大數據，並有機會使用人工智慧。我們也能夠將生物標記（Biomarkers）與機器學習結合，以獲得更深入的理解。我們需要保持開放，使用開放的 API 來分享數據；我們需要同時具備高水準的安全性與便利的存取方式，才能真正改善糖尿病的管理與照護。
最後，我代表 EDDIG 小組感謝大家的聆聽。
Q&A：患者數據分享的補償機制
Hans de Vries：非常感謝 Johan 帶來精彩的演講。由於時間關係，我們只能回答一個來自 App 的問題。問題是：您是否考慮過建立一種系統，用來補償那些產生數據並將其分享給（例如）公司的糖尿病患者？換句話說，既然在歐洲，這些數據明確屬於糖尿病患者，您認為這些數據應該轉化為某種金錢報酬嗎？還是我們不該走這條路？
Johan Jendle：我認為這是一個非常困難的問題。這可能會像迴力鏢一樣反撲，導致系統與設備的成本增加。你也可以從慈善的角度來看待這件事：透過分享數據，你將有助於開發能改善糖尿病照護的儀器和設備。所以我會呼籲在這裡採取一點「互相退讓、互惠互利（give and take）」的態度。但話說回來，這也不代表數據可以免費分享給任何人。我認為必須與數據提供者進行公開的討論，以獲得數據擁有者的明確同意。
Lutz Heinemann：在最近一次的糖尿病科技會議上，有許多關於這個主題的討論和簡報。最近在《糖尿病科學與技術期刊（JDST）》上甚至有一篇由大約 80 位作者共同發表、探討數據庫等議題的文章。所以我必須說，這絕對是一個非常熱門的話題。
英國 NHS 的互通性經驗與挑戰
Lutz Heinemann：非常感謝 Johan。接下來我要邀請來自英國的 Iain Cranston。我特別強調英國，是因為 Johan 剛才提到不同地區和大洲之間存在差異。對我來說，英國仍然屬於歐洲大陸的一部分，但請 Iain 為我們解釋一下，歐洲和英國在數據所有權標準等方面有什麼不同。
Iain Cranston：非常感謝，很高興來到這裡。我完全無法解釋為什麼英國「不是」歐洲的一部分，我們幾年前似乎是腦袋撞到了才做出這種決定。所以現在，我們只能使用自己的系統，而這些系統通常並不符合實際需求。
我是一名在英國南海岸執業的臨床醫師。我接觸這個主題的契機，其實是從醫學教育開始的。從大約 2015 年開始，我參與了一個相當普及的教育計畫，探討人們如何使用 CGM 裝置的數據。我非常清楚地意識到，未來會有大量這類裝置出現；為了訓練未來的臨床醫師有效使用這些裝置，我們需要像心電圖（ECG）那樣，有一個共通的輸出格式，讓我們能理解所看到的資訊。
所以，我最初對互通性問題的看法非常基本：我希望能從任何裝置中獲得標準化的輸出結果，這樣我就能為我看到的每一位患者提供相似的建議，因為我可以在腦海中——或者在現代透過 AI——以有效的方式處理這些數據。
雲端資料庫與「匿名數據」的迷思
但當然，把互通性侷限在「個人裝置叢集（Personal device cluster）」是非常狹隘的看法。我們多數臨床醫師在開會時，想到的數據互通性可能就是左上角那個個人裝置的封閉迴圈。但現實情況是，這些裝置叢集為了進行通訊，已經需要透過雲端來實現互通性。
我們都認可雲端資料庫是資訊的中央儲存庫。但為了讓這個雲端資料庫運作，它必須與許多其他的雲端資料庫進行通訊。這就引發了我們關於數據二次利用（Secondary uses）的問題，例如用於人口級別的糖尿病審計、服務規劃與委託、臨床結果研究、數位糖尿病科技審查與重新設計，甚至將健康資訊視為一種「商品」。
在醫療照護中，我們經常談論「匿名數據（Anonymized data）」的概念。如果你只有一個資料庫，你或許可以擁有匿名數據；但如果你有多個雲端資料庫在互相通訊，現實中根本不存在所謂的「匿名數據」。我們所有人都知道，我們的銀行帳戶、購買紀錄、社群媒體歷史都在那裡，當所有東西都儲存在這些資料庫中時，要做到真正的匿名是非常困難的。我認為這正是許多問題的核心所在。
制定英國糖尿病數據標準：PRSB 的經驗
帶著這樣的認知，大約在四、五年前，我被招募擔任英國 PRSB（專業紀錄標準委員會，Professional Record Standards Body）的兩位臨床顧問之一。這是一個為英國國民保健署（NHS England）提供紀錄標準建議的半官方機構。
我們在英國建立了一個使用者網路，包含了糖尿病患者、產業界以及臨床機構，目標就是「制定標準」。大約四年前我們啟動了這個流程，因為當時英國的糖尿病照護根本沒有正式的數據標準。
在建立標準的過程中，我們清楚地意識到：如果僅僅把「我在診所幫你量了血壓」當作需要連結到你身上的數據，這種看待 21 世紀個人照護數據的方式實在太侷限了。因此，我們將糖尿病數據標準拆分為兩個部分：
- 系統層級的糖尿病紀錄（Diabetes record）：這是跨系統儲存的通用資訊，如人口統計資料、檢驗結果、問題清單、照護計畫、眼底篩檢與結構化衛教等。
- 糖尿病自我管理資訊（Diabetes self-management information）：這是在家收集並與醫療人員分享的數據，包含葡萄糖/血酮指標、胰島素劑量指標、血壓與體重等。這些個人資訊在糖尿病的臨床管理中，重要性絕對不亞於結構化衛教等通用資訊，甚至往往更加重要。
經過幾年的推進，我們建立了一套數據標準。這套 2023 年發布的《糖尿病紀錄資訊標準》涵蓋了平均葡萄糖、目標範圍內時間（TIR）、葡萄糖管理指標（GMI）以及重大低血糖發作次數與平均持續時間等指標。這份標準讀起來可能非常枯燥，但它讓我們能夠擁有正確編碼的資訊。令我驚訝的是，當我們依據多年來國際會議上討論的共識標準制定出這套規範時，卻發現這些標準對應的代碼（Codes）在系統中根本不存在！因此，我們必須與編碼機構合作，建立新的 SNOMED CT 等概念代碼（包含評估、葡萄糖指標、胰島素劑量、駕駛與餐時碳水化合物攝取量），這樣我們才能真正有效地使用這些系統。
標準的實作與前導測試
我們目前所處的階段，是將這套標準付諸實行。在英國，實施標準的流程要求我們必須將任何數據標準與現有的醫療紀錄傳遞架構連結，顯然，對齊 HL7 FHIR（FHIR UK Core） 數據集對於這項工作非常重要。
接著，我們會從國家層級發布一份「資訊標準通知（Information Standards Notice, ISN）」。這份通知要求任何製造相關設備的廠商，以及使用這些設備的醫療專業人員，都必須遵守這些數據標準（第一階段為標準化記錄，第二階段為標準化分享）。在發布通知的同時，我們會進行前導測試（Piloting and testing）。這通常是一個為期九個月到一年的標準導入期，讓大家有時間改變實務作法以達到要求。這項工作在過去一年半左右的時間裡已經在英國逐步落實。
然而，雖然這是一項非常正面的行動，但它似乎還沒有完全觸及我們前面討論的核心問題。因此，我們圍繞著這個標準開展了許多前導專案，例如 Digibete、針對兒科照護的「MyT1D」，以及「MyWay Diabetes」等應用程式。有些專案偏向教育性質，有些專案的範圍超越了英國本土，還有些是非常在地化的健康區域專案，旨在檢視篩檢計畫中是否存在數據落差。
到目前為止，我們所應用的這套標準，已經成功涵蓋了臨床觀察數據與個人自我管理結果的整合……