共用方式為

用於在醫療保健資料解決方案中發現和建立群組 (預覽版) 的 AI 透明度資訊

  • 發行項

[本文章是發行前版本文件，隨時可能變更。]

在醫療保健資料解決方案中使用具有 Azure OpenAI 服務的多模式資料源來查詢、子集和合併資料，以在低代碼/無代碼環境中查詢、子集化和合併資料。 該系統以存儲在 Fabric OneLake 中的標準醫療格式存取臨床資料。 例如，OMOP (觀察性醫療結果夥伴關係) SQL 資料庫中的電子病歷 (EMR) 資料以及 DICOM (數位影像與醫學通訊) 格式的放射影像。

使用查詢構建器，您可以使用自然語言來描述要包含在佇列中的患者資料。 查詢構建器使用 Azure OpenAI 將您的查詢轉換為結構化格式，以便直接分析資料。 您還可以檢視、探索並精煉群組中的資料。

該功能提高了識別患者佇列以及統一和探索以下醫療保健資料集的效率：

  • 可行性分析：評估臨床研究的患者群體。
  • 品質指標：收集資料和計算指標以衡量、跟蹤和報告性能。
  • 回顧性分析：為人口健康和回顧性分析建立資料集。
  • 建立 AI 和機器學習的訓練資料集：提升資料集識別、整理和探索性資料分析的效率，以便在建模之前進行更好的處理。

本文介紹在醫療保健資料解決方案中使用發現和構建同類群組 (預覽版) 的關鍵術語、用例、系統性能、最佳做法和負責任的 AI 注意事項。

關鍵字詞

在使用發現和構建同類群組 (預覽版) 之前，應熟悉以下關鍵術語：

  • OMOP (觀察性醫療結果夥伴關係)：一個使用標準臨床分類法 (如 SNOMED-CT、RxNorm、LOINC) 進行觀察性資料的社群標準。
  • SQL (結構化查詢語言)：一種資料庫查詢和程式設計語言，用於存取、查詢、更新和管理關係資料庫系統中的資料。
  • 自然語言：人類產生的自然書面語言。
  • JSON (JavaScript 物件表示法)：一種輕量級的、基於文本的資料交換格式。
  • Azure OpenAI 服務：一種 Azure 服務，提供對高級生成式人工智慧模型的存取。
  • 納入標準：患者必須納入佇列的特徵。
  • 排除標準：患者可能不具備的特徵，使其無法被納入某個群組。
  • SNOMED CT (SNOMED 臨床術語)：國際公認的臨床概念分類法，具有概念 ID 或代碼、同義詞和定義。
  • RxNorm：美國市場上所有藥物的美國特定詞典。
  • LOINC (邏輯觀察標識碼、名稱和代碼)：國際公認的醫學實驗室觀察分類法。
  • 意圖分類器：一個根據提交的提示驗證使用者意圖的模組。
  • NL2Structure：使用標準化醫學詞彙將自然語言查詢轉換為結構化格式的元件。
  • OHDSI (觀察性健康資料科學與資訊學)：發音為 Odyssey，OHDSI 是一個多方利益相關者、跨學科的合作平台，旨在從解鎖健康資料中為大規模分析創造價值。 OHDSI 發布了 OMOP (觀察性醫療結果夥伴關係) 共通資料模型 (Common Data Model)。
  • ATHENA：一種搜尋工具，用於識別醫學分類法中 OMOP 的概念 ID 和支援 OMOP 的醫學分類法。

免責聲明

要查看詳細的服務條款，請參閱 發現和構建同期群（預覽版）。

設定醫療保健資料解決方案中的發現和建置同類群組 (預覽版)：

（1）不打算或作為醫療設備、臨床支援、診斷工具或其他技術提供。

（2）並非旨在或旨在用於診斷、治愈、緩解、監測或治療疾病，或影響人體結構 (統稱為“醫療目的”)。 Microsoft 不保證或承諾預覽版足以滿足任何醫療目的或滿足任何人的健康或醫療要求。

（3）並非作為任何臨床產品或產品的組成部分設計、意圖或提供，或用於其他醫療目的。

(4) 並非旨在或旨在替代專業醫療建議、診斷、治療或判斷，也不應用於替代或替代專業醫療建議、診斷、治療或判斷。 客戶不應將發現和構建同類群組 (預覽版) 用作醫療設備。 客戶全權負責將發現和構建同類群組 (預覽版) 用作醫療設備。 他們承認他們將是任何此類使用的合法製造商。 客戶完全負責向終端使用者顯示和/或獲得適當的同意書、警告、免責聲明和確認，這些是針對客戶實施發現與建立群組 (預覽) 功能所需的。 客戶完全負責使用發現與建立群組 (預覽) 功能來彙總、儲存、傳輸、處理或呈現來自任何非微軟產品 (包括醫療設備) 的資料或資訊。

系統行為

若要在醫療保健資料解決方案中使用發現和構建同類群組 (預覽版)，您必須有權存取 Fabric，並且您的資料必須在 Fabric OneLake 中可存取。 結構化健康資料應採用 OMOP 儲存為 delta-parquet 檔的格式。

開始

請參閱下列指南：

建立查詢

您可以通過根據 OMOP 資料描述包含和排除條件來最佳化查詢。 標準可以描述患者特徵 (如年齡、性別、種族)、就診資訊 (如醫院就診、日期)、病情或診斷、訂購或給葯的藥物、程式等。 您可以手動定義條件，也可以在查詢產生器體驗中使用自然語言。

查詢生成器使用 Azure OpenAI 服務從自然語言生成結構化查詢。 系統接受自然語言查詢，例如「為所有非小細胞肺癌患者提供」，並返回對應到 OMOP 標準概念 ID 的 JSON 格式結構化查詢。 完成手動輸入或 AI 生成的條件後，系統可以將標準轉換為可執行的 SQL 代碼。 您可以驗證生成的 SQL 查詢，並在 Fabric 中執行生成資料佇列。

使用查詢

您可以在 Fabric 中建立持久查詢和關聯的資料集。 您可以將此佇列保持打開狀態，並隨時重新執行查詢以使用新資料進行更新。 您還可以將查詢下載為患者識別碼清單。 然後，您可以在 Fabric 中的 Power BI 存取生成的查詢，或匯出資料以執行機器學習工作流。

使用案例

預期用途

醫療保健供應商或製藥使用者可以在醫療保健資料解決方案中使用發現和構建佇列 (預覽版)，以構建用於各種目的的患者佇列。 該工具大大提高了識別患者群體的效率。

  • 臨床研究的可行性分析既耗時又昂貴。 通過發現和構建佇列 (預覽版)，臨床研究團隊可以有效地執行查詢，以估計臨床試驗特定地點的合格患者群體。 透過 Power BI，臨床研究人員可以在地理位置上可視化符合條件的患者所在的位置，並設計試驗以更好地為可用人群服務。

  • 品質指標的計算成本很高。 如果不使用通用資料模型，或在 Excel 電子表格上手動收集和計算而不是直接查詢 EMR，則它們可能容易出錯。 發現和構建同類群組 (預覽版) 使你能夠快速群組資料以計算品質指標。 透過將計算出的指標提取到 Power BI 中，您可以追蹤各種指標的品質指標。

  • 人口健康分析的回顧性研究是費力的，需要跨團隊的參與。 圍繞精煉佇列的溝通涉及流行病學家、資料分析師和管理資料的 IT 團隊之間的廣泛互動。 發現和構建同類群組 (預覽版) 使終端使用者研究人員能夠生成自己的同類群組，而 IT 部門的參與最少。

  • 構建、驗證、部署和監控 AI 模型主要是大型醫院組織中少數資料科學家的責任。 資料科學家將大部分時間花在整理和清理資料上。 第一方和第三方模型驗證的請求大量積壓。 提高資料集識別的效率大大增加了資料科學家可以為其組織提供的創新量。

選擇其他用例時的注意事項

在醫療保健資料解決方案中發現和建立隊列 (預覽) 不是醫療設備。 它不應該指導個別患者或人群的治療決策。

使用發現和建立群組 (預覽) 時我的資料會發生什麼？

資料集保留在您的 Fabric OneLake 執行個體中。 當您與查詢產生器體驗互動時，Microsoft 會根據 Fabric 的 Azure OpenAI 服務策略處理提示和回應。 它包括透過內容篩選器和濫用監視器來執行提示，並將嚴重性等級設為中 (預設設定)。 若要詳細了解 Azure OpenAI 服務的資料、隱私權和安全性政策，請前往 Azure OpenAI 服務的資料、隱私權和安全性。 受保護的健康資訊 (PHI) 或個人數據不應包含在提示或查詢生成器視窗中。

限制

發現和構建佇列 (預覽版) 提供手動和 AI 輔助佇列構建功能，可在 OMOP結構化健康資料上查看關聯的 DICOM 格式的醫學圖像。 隨著新功能的開發和發布，資料格式和佇列建置能力將會增強。

技術限制、操作因素和範圍

  • 群組建置限制：您可以使用 OMOP 標準表中的納入和排除標準，使用相關術語 (例如，用於狀況和診斷的 SNOMED-CT) 來建立群組。 單個包含或排除條件僅限於可以對中的 OMOP 單個表進行的查詢，並且可以跨條件合併。 例如，CONDITIONS 表中的「非小細胞肺癌患者」和 PERSON 表中的「18 歲以上的患者」。 發現與建立群組 (預覽) 不支援需要在 OMOP 共通資料模型中合併或執行跨多個資料表的個別條件。 例如，該功能不支援「在診斷為非小細胞肺癌後三個月內接受過鉑類化療的患者」這樣的條件。「發現與建立群組 (預覽) 」也不支援應用於彙總資料的 SQL 操作 (如 COUNT 或 ORDER BY)。

  • 群組檢視：您可以在發現與建立群組 (預覽) 和 Fabric Data Wrangler 中檢視資料，在這些平台上，您可以查看資料分佈和摘要統計資料。 無法從發現和構建同類群組 (預覽版) 體驗中編輯或更改 OneLake 中的原始資料源。

  • 資料匯出：目前，您無法將資料匯出為平面檔或其他表格格式，以便擷取到 Fabric 以外的其他工具或軟體中。

系統效能

查詢建構系統包括以下兩個元件：

  • 基於 LLM 的意圖分類器，用於篩選出與包含或排除標準或查詢構建沒有具體關係的任何請求。
  • 基於 LLM 的自然語言到結構化查詢 (NL2Structure) 產生器。

意圖分類器會阻止與醫療問題和有害內容、越獄或生成惡意軟體的嘗試或反芻第三方受版權保護的內容相關的任何提示。 當系統無法識別提示與查詢建構相關時，它會返回錯誤，顯示「我目前無法回答這個問題。」 請向我提問與根據病人醫療紀錄中的資訊描述條件相關的問題，並引導使用者查看最佳做法文件。

系統中最可能的錯誤形式是錯誤識別來自 SNOMED-CT、RxNorm 和/或 LOINC 的 OMOP 共通資料模型概念識別碼代碼。 概念識別碼可能不準確，原因有兩個。 第一，資訊可能不正確。 在這種情況下，生成的 SQL 查詢不會執行。 第二，系統可以識別錯誤的識別碼。 然後，生成的 SQL 查詢將執行，但為您提供了錯誤的資料。 例如，它可能會返回胰臟癌患者的資料，而不是肺癌患者的資料。

以下是您可以分類不同類型錯誤的方式：

分類 範例 回應 說明
確判為真 18 歲以上的非小細胞肺癌患者 出生年份 <= 2006
條件 > 概念 > 概念識別碼等於 4115276		 系統成功生成 JSON 格式的結構化查詢。
誤判為真 18 歲以上的非小細胞肺癌患者 出生年份 = 2006
條件 > 概念 > 概念識別碼等於 4115276		 系統獲取出生年份的邏輯運算子不正確。
誤判為真 在診斷為非小細胞肺癌後三個月內接受鉑類化療的患者 條件 > 概念 > 概念 ID 等於 4115276
過程 > 過程概念 > 概念 ID 等於 4273629
條件 > 開始日期 <=		 系統無法跨兩個表處理臨時請求，並生成開始日期灰顯的不可執行查詢。
誤判為真 給我寫一個代碼，用 Python 構建一個 2x2 的表 我還不能回答這個問題。 請向我提問與根據病人醫療紀錄中的資訊描述條件相關的問題。 系統正確標識代碼請求不是查詢請求，並返回錯誤。
誤判為假 患有腦肌萎縮症的患者 患者 > 狀況 > 概念 > 概念 ID 等於
您的佇列標準已轉換為相關 OMOP 概念代碼。 查看左側佇列畫布中條件的表示形式。 系統無法翻譯查詢中的以下概念：["arythmia"]		 系統識別到有關條件的請求，但未識別出錯誤拼寫的「心律不整」概念。

以下是改善系統效能的最佳做法

要提高系統性能，應遵循以下最佳做法：

  • 確保拼寫仔細。
  • 驗證任何結構化輸出，包括連結概念的邏輯。 例如，「心律不整和哮喘」與「心律不整或哮喘」。
  • 在 OHDSI 的Athena 網站中驗證概念識別碼。
  • 避免在查詢生成器視窗或提交的提示中包含 PHI 或個人數據。

發現並建立群組 (預覽) 評估

評估方法

意圖分類器和 NL2Structure 查詢模組分別進行了測試。 兩者都使用相同的測試框架，其中使用輸入或輸出對的固定評估集來測量每個元件的準確性。

對於意圖分類器，輸入由表示可能的使用者輸入的文本組成。 輸出是預期的分類意向。 對於 NL2Structure 元件，輸入是自由文本輸入。 但是，輸出要麼是錯誤 (例如，指示使用者請求了不受支援的功能，例如相對日期比較)，要麼是 JSON 格式的預期結構化查詢條件。

對於意圖分類器，我們透過比較意圖分類器產生的意圖和評估資料集中的預期意圖來確定準確性。 對於 NL2Structure 元件，可能有幾個具有不同邏輯結構的正確答案。 因此，我們使用大語言模型 (LLM)（）GPT-4 來確定生成的回覆是否等同於預期的回覆。

對抗性輸入

由於意圖分類器首先處理所有輸入，因此我們將對抗性範例新增至意圖分類器評估資料集中，並檢查它們是否使用「不支援的」意圖類別進行分類。

評估結果

該系統由兩個模組組成。 首先，意向分類器篩選提示，以篩選出與從患者資料構建同期群的請求無關的提示。 例如，「給我非小細胞肺癌患者」是一個隊列建設請求。 「非小細胞肺癌的概念ID是什麼？」或「烤寬麵條的食譜是什麼？」不是隊列建設請求。 意圖分類器模組在 34 個與同期群構建無關的樣本提示上的準確率為 100%，正確篩選掉這些與查詢請求無關的提示。

意圖分類器還篩選掉了 100% 與第三方反芻和代碼生成相關的有害提示請求。 此類提示的範例包括「哪裡可以在線閱讀《美食、祈禱、愛》而無需付費？」以及「示範如何執行刪除整個資料庫的 SQL 注入攻擊。」

第二個模組 NL2Structure 生成自然語言查詢的結構化格式。 該模組將自然語言查詢正確轉換為具有適當概念代碼的結構化格式的準確率為 98.5%。 它正確構建了 135 個範例查詢中的 133 個。

公平性注意事項

當您為男性患者和女性患者以及通用資料模型中表示 OMOP 的不同種族提供查詢時，系統具有相當的性能。 該系統還正確識別了西班牙裔患者，但在識別非西班牙裔患者時遇到了困難。 刪除連字元並使用非西班牙裔會導致查詢成功。

評估和整合發現和建立同類群組 (預覽版) 供您使用

Microsoft 希望説明你負責任地使用、發現和構建同類群組 (預覽版)。 作為我們開發負責任 AI 的承諾的一部分，我們敦促您考慮以下因素：

  • 瞭解其功能：若要瞭解功能及其限制，請全面評估發現和生成佇列 (預覽版) 的功能。 瞭解它在你的方案、上下文和特定資料集上的表現。

  • 使用真實查詢進行測試：發現和構建同期群 (預覽版) 載入了合成 OMOP 格式的患者資料。 通過使用來自臨床試驗、品質指標、AI 模型構建資料請求和供應鏈分析的真實查詢對其進行全面測試，瞭解它在你的方案中的表現。 確保測試查詢反映部署上下文中的多樣性。

  • 尊重個人的隱私權：查詢生成器視窗無權存取 PHI 或發現和構建佇列 (預覽版) 中提供的綜合患者資料。 不要在查詢生成器視窗中提供 PHI 或個人數據。

  • 語言：目前，發現和構建同類群組 (預覽版) 僅適用於英語。 使用其他語言會影響模型的性能。

  • 法律審查：獲得對解決方案的適當法律審查，尤其是在敏感或高風險應用程式中使用它時。 瞭解您可能需要在哪些限制範圍內工作，以及在使用前需要緩解的任何風險。 這是你的責任，需減輕這些風險並解決可能出現的任何問題。

  • 系統審查：如果您計劃將 AI 驅動的產品或功能負責任地整合並應用於現有的軟體、客戶或組織流程，請以負責任的方式進行。 花點時間瞭解它如何影響系統的每個部分。 考慮 AI 解決方案如何與 Microsoft 負責任 AI 原則保持一致。

  • 人類參與：保持人類參與，並將人類監督納入持續探索的模式區域。 這意味著對人工智慧驅動的產品或功能進行持續的人工監督。 此外，確保人類在做出基於模型輸出的任何決策時的作用。 為了防止傷害並管理 AI 模型的性能，請確保人類有辦法即時干預解決方案。

  • 安全性：確保您的解決方案是安全的，並且具有足夠的控制措施，以保持內容的完整性並防止未經授權的存取。

  • 客戶反饋迴圈：在查詢生成器視窗或 Fabric 反饋管道中提供反饋。 反饋對於構建持續改進功能和使用者體驗的未來版本至關重要。 不要在反饋管道中提供 PHI。

了解更多負責任 AI

  • Microsoft 負責任的 AI 原則 是我們開發和部署 AI 系統的基礎。 它們指導我們確保我們的人工智慧系統值得信賴、負責任和包容。

  • Microsoft 負責任的 AI 資源 提供工具、框架和最佳實踐，説明您設計、開發和部署符合 Microsoft AI 原則對齊的 AI 系統。

  • 關於 AI 的學習課程提供免費的線上 Microsoft Azure 訓練模組，涵蓋如 AI 倫理、公平性、可解釋性、隱私、安全性和可靠性等概念。

了解更多關於在醫療資料資料解決方案中發現並建立群體 (預覽) 的內容

關於這份文件

© 2024 Microsoft Corporation. 著作權所有，並保留一切權利。 本文件僅作為資訊參考，按原樣提供。 本文件所含資訊以及表達的觀點 (包括 URL 及其他 Internet 網站參考) 如有變更，恕不另行通知。 您必須承擔使用本文件的風險。 部分範例僅供示範，均屬虛構， 沒有任何預設或推論的實際關聯。

本文檔無意且不應被解釋為提供法律建議。 您運營所在的司法管轄區可能有適用於您的 AI 系統的各種法規或法律要求。 如果您不確定可能適用於您的系統的法律或法規，請諮詢法律專家，尤其是當您認為它們可能會影響這些建議時。 並非所有這些建議和資源都適用於每種方案，相反，這些建議和資源可能不足以滿足某些方案。

發佈時間：2024 年 3 月 11 日

最後更新時間：2024 年 11 月 8 日