版本資訊 2024：Azure Health Data Services
本文說明 2024 年針對 Azure Health Data Services 中 FHIR® 服務、DICOM® 服務和 MedTech 服務所發行的功能、增強功能和 Bug 修正。
2024 年 8 月
Azure 健康資料服務
FHIR 服務
匯入作業錯誤處理
- 當搜尋參數資源透過匯入程式內嵌時，匯入作業會傳回 HTTP 400 錯誤。 這項變更旨在防止搜尋參數在匯入作業內嵌時處於無效狀態。
- 匯入作業會傳回 HTTP 400 狀態代碼，而不是先前的 HTTP 500 狀態代碼，以防記憶體帳戶發生設定問題。 此更新旨在改善匯入作業期間與受控識別相關聯的錯誤處理。
2024 年 7 月
Azure 健康資料服務
FHIR 服務
允許在 Convert-Data 作業中將 JSON 數據中的日期視為字串
JSON 資料內提供的日期可能會以不同於所提供的格式傳回。 在還原串行化 JSON 承載字串期間，識別為日期的 JSON 承載字串會轉換成 .NET DateTime 物件。 然後，這些物件會先轉換成字串，再經過 Liquid 範本引擎。 這項轉換可能會導致重新格式化日期值，並在 FHIR 服務的當地時區表示。
您可以使用布林參數 jsonDeserializationTreatDatesAsStrings停用字串至 .NET DateTime 物件的強制。 當設定為 true時，提供的數據會被視為字串，而且在提供給 Liquid 引擎之前不會修改。
匯入作業增強功能
FHIR 服務現在允許擷取數據，而不需在資源層級指定版本。 資源的順序會使用 lastUpdated 值來維護。 這項增強功能引進了 「allowNegativeVersions」 旗標。 設定旗標 true 可讓 FHIR 服務為具有明確 lastUpdated 值且未指定任何版本的資源記錄指派負版本。
錯誤修正
- 已修正在搜尋作業中使用 _security：not search 參數 時，虛刪除資源的標識碼包含在搜尋結果中時，_security：not search 參數時，已包含虛刪除資源的標識符。 我們已修正此問題，讓虛刪除的資源現在已從搜尋結果中排除。
- 將數據匯出為 SMART 使用者將數據匯出為 SMART 使用者 不再需要寫入範圍。 之前，必須將「寫入」許可權授與SMART用戶以匯出數據，這隱含較高的許可權等級。 若要以SMART使用者身分起始匯出作業，請確定使用者是 RBAC 中 FHIR 匯出角色的成員，並要求「讀取」SMART 臨床範圍。 將狀態代碼從 HTTP 500 更新為 HTTP 400
- 如果在修補作業期間，將狀態代碼從 HTTP 500 更新為 HTTP 400 ，如果承載要求更新參數以外的資源類型，則一開始擲回內部伺服器錯誤 （HTTP 500）。 這已更新為改為擲回 HTTP 400 錯誤。
效能增強
使用數據範圍搜尋 FHIR 資源時，會新增查詢優化。 此查詢優化有助於有效率的查詢，因為會產生一個合併的 CTE。
2024 年 5 月
Azure 健康資料服務
FHIR 服務
調整匯入作業的增強功能
已改善匯入作業的調整邏輯，讓多個作業可以平行執行。 這項變更會影響匯入作業的稽核記錄。 個別匯入作業的稽核記錄有多個數據列，每個數據列對應至內部處理作業。
錯誤修正
- 已修正：長時間執行要求的 HTTP 狀態代碼。 需要超過 100 秒來執行的 FHIR 要求會傳回 HTTP 408 狀態代碼，而不是 HTTP 500。
- 已修正：套件組合中的歷程記錄要求。 在修正之前，套件組合中的歷程記錄要求傳回 HTTP 狀態代碼 404。
獨立 FHIR 轉換器 （預覽）
可供預覽的獨立 FHIR 轉換器 API 與 FHIR 服務分離，並封裝為容器 （Docker） 映射。 除了可讓您將資料從記錄來源轉換成 FHIR R4 套件組合之外，FHIR 轉換器還提供：
- 從記錄來源到 FHIR R4 套件組合和返回的雙向數據轉換。 例如，FHIR 轉換器可以將 FHIR R4 格式的數據轉換回 HL7v2 格式。
- 改善自定義 預設 Liquid 範本的體驗。
- 示範如何使用 Azure Data Factory 建立 ETL（擷取、轉換、載入）管線的範例。
若要實作 FHIR 轉換器容器映像，請參閱 FHIR 轉換器 GitHub 專案。
2024 年 4 月
DICOM 服務
增強的Upsert作業
增強的 Upsert 作業可讓您將 DICOM 映射上傳至伺服器，並在它已經存在時順暢地取代它。 在此增強功能之前，用戶必須執行Delete作業，後面接著 STOW-RS，才能達到相同的結果。 透過增強的 Upsert 作業，管理 DICOM 映射更有效率且簡化。
必要屬性的擴充記憶體
DICOM 服務可讓用戶上傳大小高達 4 GB 的 DICOM 檔案。 不允許單一要求中的單一 DICOM 檔案或檔案組合超過此限制。
FHIR 服務
大量刪除作業已正式推出
大量刪除作業允許跨不同層級刪除 FHIR 資源，讓醫療保健組織能夠遵守數據保留原則，同時提供異步處理功能。 大量刪除作業的優點如下：
- 在不同的層級執行大量刪除：大量刪除作業可讓您以異步方式從 FHIR 伺服器刪除資源。 您可以在不同層級執行大量刪除：
- 系統層級：可跨所有資源類型刪除 FHIR 資源。
- 個別資源類型：允許刪除特定的 FHIR 資源。
- 可自定義：查詢參數允許篩選原始資源以進行目標刪除。
- 異步處理：作業是異步的，提供輪詢端點來追蹤進度。
深入了解：
2024 年 3 月
DICOM 服務
與 Azure Data Lake Storage 整合已正式推出
Azure Health Data Services 中 DICOM 服務的 Azure Data Lake Storage 整合已正式推出。 DICOM 服務會使用 DICOMweb 標準，為醫療影像數據提供雲端規模的記憶體。 透過 Azure Data Lake Storage 的整合，組織可以完全掌控其映像數據，並增加透過 Azure 記憶體生態系統和 API 存取和使用該數據的彈性。
藉由搭配 DICOM 服務使用 Azure Data Lake Storage，組織就可以：
- 使用 Azure 記憶體 API 和 DICOMweb API，直接存取 DICOM 服務所儲存的醫療影像數據，以提供更多彈性來存取及處理數據。
- 開啟多達整個工具生態系統的醫學造影資料，以便與 Azure 儲存體搭配使用，包括 AzCopy、Azure 儲存體總管和資料移動程式庫。
- 解除鎖定新的分析和 AI/ML 案例，方法是使用原生與 Azure Data Lake Storage 的服務，包括 Azure Synapse、Azure Databricks、Azure Machine Learning 和 Microsoft Fabric。
- 授與管理儲存體權限、存取控制、階層和規則的控制權。
深入了解：
FHIR 服務
配套平行處理 （GA）
套件組合預設會在 FHIR 服務中以序列方式執行。 為了改善套件組合呼叫的輸送量，我們已啟用平行處理。
深入了解：
匯入作業接受單一檔案中的多個資源類型
允許在要求參數中具有每個輸入檔的資源類型匯入作業。 透過這項增強功能，您可以在單一檔案中傳遞多個資源類型。
錯誤修正
已修正：匯入作業會擷取具有相同資源類型和 lastUpdated 域值的資源。 在此變更之前，以相同類型和
lastUpdated域值在批次中執行的資源並未內嵌至 FHIR 服務。 此錯誤修正解決了問題。 請參閱 PR#3768。已修正：使用 3 個以上的自定義搜尋參數進行 FHIR 搜尋。 在此修正之前，根目錄有三個或多個自定義搜尋參數的 FHIR 搜尋查詢會導致 HTTP 狀態代碼 504。 請參閱 PR#3701。
已修正：改善套件組合處理的效能。 工作執行方法的更新，啟用配套處理效能改善。 請參閱 PR#3727。
2024 年 2 月
FHIR 服務
已啟用計算所有版本的資源
查詢參數 _summary=count 和 _count=0 可以新增至 _history 端點，以取得所有已建立版本的資源計數。 此計數包括歷程記錄和虛刪除的資源。
Revinclude 搜尋可以參考具有通配符的所有資源
FHIR 服務支援使用 revinclude的通配符搜尋。 將 新增 *.* 至查詢中的 revinclude 查詢參數，以指示 FHIR 服務參考對應至來源資源的所有資源。
錯誤修正
已修正：使用效能增強功能改善 FHIR 查詢回應時間。 若要改善效能，可以針對用於排序的搜尋參數指定遺漏修飾詞。 請參閱 PR#3655。
已修正：匯入作業會接受非循序資源版本的擷取。 在此變更之前，作業中的
import累加模式假設版本是循序整數。 修正這個錯誤之後，版本可以以非佇列順序內嵌。 請參閱 PR#3685。
2024 年一月
DICOM 服務
大量更新檔案
大量更新作業可讓您變更 DICOM 服務中儲存之多個檔案的映射元數據。 例如，大量更新可讓您針對單一非同步作業中的一個或多個研究修改 DICOM 屬性。 您可以使用 API 對患者人口統計執行更新，並避免重複耗時上傳的成本。
除了效率提升之外，大量更新功能會在變更摘要中保留變更記錄，並保存原始、未修改的執行個體以供日後擷取。
深入了解：
FHIR 服務
選擇的搜尋參數 （預覽）
可供預覽的可選取搜尋參數功能可讓您自定義和優化 FHIR 資源的搜尋。 此功能可讓您選擇要啟用或停用 FHIR 服務的內建搜尋參數。 只要啟用所需的搜尋參數，您就可以儲存更多 FHIR 資源，並可能改善 FHIR 搜尋查詢的效能。
深入了解：
將 FHIR 服務與 Azure Active Directory B2C 整合
醫療保健組織可以使用 Azure Health Data Services 中的 FHIR 服務搭配 Azure Active Directory B2C（Azure AD B2C）。 組織獲得安全且方便的方式，為不同的使用者或群組授與 FHIR 服務的存取權，而不需在其組織的 Microsoft Entra ID 租使用者中建立或傳入用戶帳戶。 透過這項整合，組織可以：
- 使用其他識別提供者，透過SMART on FHIR 範圍來驗證和存取FHIR資源。
- 使用SMART on FHIR 範圍來管理和自定義使用者訪問許可權，這些範圍支援精細訪問控制、FHIR 資源類型和互動，以及使用者的基礎許可權。
相關內容：
- 使用 Azure Active Directory B2C 將 FHIR 服務的存取權授與
- 設定 FHIR 服務的多個服務識別提供者
- 針對 FHIR 服務的識別提供者設定進行疑難解答
- 為 FHIR 服務啟用 SMART on FHIR
- 範例：Azure ONC （g）（10） SMART on FHIR
要求最多 100 TB 的記憶體
FHIR 服務可以儲存和交換大量的健康情況數據，而且每個 FHIR 服務實例預設的記憶體限製為 4 TB。 如果您有更多資料，您可以要求 Microsoft 增加最多 100 TB 的 FHIR 服務儲存體。
透過更多記憶體，組織可以處理大型數據集，以啟用分析案例。 例如，您可以使用更多記憶體來管理人口健康、進行研究，以及從健康數據取得新的見解。 此外，更多記憶體可讓具有大量數據（大於 4 TB）的 Azure API for FHIR 客戶移轉至 Azure Health Data Services 中的 FHIR 服務。
若要要求大於 4 TB 的記憶體，請在 Azure 入口網站 上建立支援要求，並使用問題類型服務與訂用帳戶限制（配額）。
注意
由於記憶體的計費計量有問題，選擇超過 4 TB 的記憶體容量的客戶，在問題解決之前，不會針對記憶體收取費用。