リリース ノート 2024: Azure Health Data Services
この記事では、Azure Health Data Services の FHIR® サービス、DICOM® サービス、および MedTech サービスについて、2024 年にリリースされた機能、機能強化、バグ修正について説明します。
2024 年 10 月
Azure Health Data Services
FHIR サービス
バグ修正
- エクスポートの検証: 無効な検索パラメーターにもかかわらずエクスポートが続行される問題が特定されました。 これらの条件下でのエクスポートを防ぐ変更が導入されています。 この機能は現在、厳密な検証フラグの背後にあり、10 月 30 日以降の既定の動作になります。
- 検索パラメーターの包含: 追加の検索パラメーター (たとえば、) がすべての期待される結果を返せず、
_include_has次のリンクを省略する場合がある問題を解決しました。 - エクスポート ジョブの実行: エクスポート ジョブの完了中に
System.ObjectDisposedException発生する頻度が低い場合は、早期終了を防ぐことで対処されています。 - HTTP 状態コードの更新: ジョブの作成時に
$reindex無効なパラメーターの HTTP 状態コードが 400 に更新され、エラー処理が向上しました。 - 検索パラメーターのクリーンアップ: 削除 API 呼び出しでトリガーされたときにデータベース内の検索パラメーターを完全にクリーンアップし、不完全な削除に関連する問題に対処するための修正プログラムが実装されました。
- 降順の並べ替えの問題: 関連するリソースが存在する場合でも、並べ替えられたフィールドにデータがない場合に、降順の並べ替え操作でリソースが返されない問題を解決しました。
- 認証エラー処理: マネージド ID がオフになっている状態でインポート要求が実行されたときに認証エラーを管理するための新しい catch ブロックを追加しました。
2024 年 9 月
Azure Health Data Services
FHIR サービス
輸出効率の向上
メモリ使用量を最適化するために、エクスポート機能が改善されました。 この変更により、エクスポート プロセスによってデータが BLOB ストレージに一度に 1 つのリソースにプッシュされ、メモリ消費量が削減されます。
2024 年 8 月
Azure Health Data Services
FHIR サービス
インポート操作のエラー処理
- インポート操作では、インポート プロセスを介して検索パラメーター リソースが取り込まれると、HTTP 400 エラーが返されます。 この変更は、インポート操作で取り込まれたときに、検索パラメーターが無効な状態にならないようにするためのものです。
- インポート操作では、ストレージ アカウントで構成の問題が発生した場合に、以前の HTTP 500 状態コードとは対照的に、HTTP 400 状態コードが返されます。 この更新プログラムは、インポート操作中にマネージド ID に関連付けられているエラー処理を改善することを目的としています。
2024 年 7 月
Azure Health Data Services
FHIR サービス
JSON データの日付を Convert-Data 操作で文字列として扱うことを許可する
JSON データ内で指定された日付が、指定された形式とは異なる形式で返される可能性があります。 日付として識別される JSON ペイロード文字列の逆シリアル化中に、.NET DateTime オブジェクトに変換されます。 これらのオブジェクトは、Liquid テンプレート エンジンを通過する前に文字列に変換されます。 この変換により、日付値が再フォーマットされ、FHIR サービスのローカル タイムゾーンで表される可能性があります。
.NET DateTime オブジェクトへの文字列の強制変換は、ブール値パラメーター jsonDeserializationTreatDatesAsStringsを使用して無効にすることができます。 に true設定すると、指定されたデータは文字列として扱われ、Liquid エンジンに提供される前に変更されません。
インポート操作の機能強化
FHIR サービスでは、リソース レベルでバージョンを指定せずにデータを取り込めるようになりました。 リソースの順序は、lastUpdated 値を使用して維持されます。 この拡張機能では、"allowNegativeVersions" フラグが導入されています。 フラグを true に設定すると、FHIR サービスは、明示的な lastUpdated 値を持ち、バージョンが指定されていないリソース レコードに負のバージョンを割り当てることができます。
バグの修正
- _security:not search パラメーター を使用するときの論理的に削除されたリソースの包含を修正しました。検索操作で _security:not search パラメーターを使用すると、論理的に削除されたリソースの ID が検索結果に含まれていました。 論理的に削除されたリソースが検索結果から除外されるように、問題を修正しました。
- SMART ユーザーとしてデータをエクスポートする SMART ユーザー としてデータをエクスポートする場合、書き込みスコープは不要になりました。 以前は、SMART ユーザーにデータをエクスポートするための "書き込み" 特権を付与する必要がありました。これは、より高い特権レベルを意味していました。 SMART ユーザーとしてエクスポート ジョブを開始するには、ユーザーが RBAC の FHIR エクスポート ロールのメンバーであることを確認し、SMART 臨床スコープの "読み取り" を要求します。 状態コードを HTTP 500 から HTTP 400 に更新する
- HTTP 500 から HTTP 400 への状態コードの更新 パッチ操作中に、ペイロードがパラメーター以外のリソースの種類の更新を要求した場合、内部サーバー エラー (HTTP 500) が最初にスローされました。 代わりに HTTP 400 エラーをスローするように更新されました。
パフォーマンスの向上
クエリの最適化は、データ範囲で FHIR リソースを検索するときに追加されます。 このクエリの最適化は、1 つの結合された CTE が生成されるときに効率的なクエリを実行するのに役立ちます。
2024 年 5 月
Azure Health Data Services
FHIR サービス
インポート操作に対するスケーリングの機能強化
インポート操作のスケーリング ロジックが改善され、複数のジョブを並列で実行できるようになります。 この変更は、インポート操作の監査ログに影響します。 個々のインポート ジョブの監査ログには複数の行があり、各行は内部処理ジョブに対応します。
バグ修正
- 修正済み: 実行時間の長い要求の HTTP 状態コード。 実行に 100 秒を超える時間がかかる FHIR 要求では、HTTP 500 ではなく HTTP 408 状態コードが返されます。
- 修正済み: バンドル内の履歴要求。 修正前に、バンドル内の履歴要求で HTTP 状態コード 404 が返されました。
スタンドアロン FHIR コンバーター (プレビュー)
プレビューに使用できるスタンドアロンの FHIR コンバーター API は、FHIR サービスから切り離され、コンテナー (Docker) イメージとしてパッケージ化されます。 レコードのソースから FHIR R4 バンドルにデータを変換できるだけでなく、FHIR コンバーターには次のものが用意されています。
- レコードのソースと FHIR R4 バンドルの間の双方向データ変換。 FHIR コンバーターは、たとえば、FHIR R4 形式のデータを元の HL7v2 形式に戻す変換を行うことができます。
- 既定の Liquid テンプレートのカスタマイズのエクスペリエンスが向上しました。
- Azure Data Factory (ADF) を使用して ETL (抽出、変換、読み込み) パイプラインを作成する方法を示すサンプル。
FHIR コンバーターのコンテナー イメージを実装するには、 「FHIR コンバーターの GitHub プロジェクト」を参照してください。
2024 年 4 月
DICOM サービス
拡張アップサート操作
拡張 Upsert 操作を使用すると、DICOM イメージをサーバーにアップロードし、既に存在する場合はシームレスに置き換えることができます。 この機能拡張の前に、ユーザーは Delete 操作を実行し、その後に、同じ結果を得るために、その後に、STOW-RS を実行する必要がありました。 拡張された Upsert 操作により、DICOM イメージの管理がより効率的で合理化されます。
必要な属性の拡張ストレージ
DICOM サービスを使用すると、ユーザーは最大 4 GB のサイズの DICOM ファイルをアップロードできます。 1 つの DICOM ファイルまたは 1 つの要求内のファイルの組み合わせがこの制限を超えることはできません。
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 Storage エコシステムと API を介してそのデータにアクセスして操作するための柔軟性が向上します。
DICOM サービスで Azure Data Lake Storage を使用することで、組織は次のことができます。
- Azure Storage API と DICOMweb API を使用して DICOM サービスによって格納された医療画像データに直接アクセスできるため、データにアクセスして操作する柔軟性が向上します。
- AzCopy、Azure Storage Explorer、Data Movement ライブラリなど、Azure Storage を操作するためのツールのエコシステム全体まで、医療画像データを開きます。
- Azure Synapse、Azure Databricks、Azure Machine Learning、Microsoft Fabric など、Azure Data Lake Storage とネイティブに統合されるサービスを使用して、新しい分析と AI/ML シナリオのロックを解除します。
- ストレージのアクセス許可、アクセス制御、階層、およびルールを管理するためのコントロールを付与します。
詳細情報:
- DICOM サービスと Azure Data Lake Storage を使用して医療画像データを管理する
- Azure Data Lake Storage を使用して DICOM サービスをデプロイする
FHIR サービス
バンドルの並列化 (GA)
バンドルは、既定で FHIR サービスで順次実行されます。 バンドル呼び出しでスループットを向上させるために、並列処理を有効にしました。
詳細情報:
インポート操作では、1 つのファイルで複数のリソースの種類を受け入れます
インポート操作では、要求パラメーターの入力ファイルごとにリソースの種類を指定できます。 この機能を強化することで、1 つのファイルに複数のリソースの種類を渡すことができます。
バグ修正
修正済み: インポート操作では、同じリソースの種類と lastUpdated フィールド値を持つリソースが取り込まれます。 この変更の前に、同じ型と
lastUpdatedフィールド値を持つバッチで実行されたリソースは、FHIR サービスに取り込まれませんでした。 このバグ修正により問題が対処されます。 PR#3768 を参照してください。修正済み: 3 つ以上のカスタム検索パラメーターを使用した FHIR 検索。 この修正の前に、3 つ以上のカスタム検索パラメーターを含むルートの 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 年 1 月
DICOM サービス
ファイルの一括更新
一括更新操作を使用すると、DICOM サービスに格納されている複数のファイルのイメージング メタデータを変更できます。 たとえば、一括更新を使用すると、1 つの非同期操作で 1 つ以上のスタディの DICOM 属性を変更できます。 API を使用すると、患者の人口統計に対する更新を実行し、時間のかかるアップロードを繰り返すコストを回避できます。
効率の向上以外に、一括更新機能は変更フィードの変更の記録を保持し、将来の取得のために元の変更されていないインスタンスを保持します。
詳細情報:
FHIR サービス
選択可能な検索パラメーター (プレビュー)
プレビューで使用可能な選択可能な検索パラメーター機能を使用すると、FHIR リソースの検索をカスタマイズおよび最適化できます。 この機能を使用すると、FHIR サービスに対して有効または無効にする組み込みの検索パラメーターを選択できます。 必要な検索パラメーターのみを有効にすると、より多くの FHIR リソースを格納でき、FHIR 検索クエリのパフォーマンスが向上する可能性があります。
詳細情報:
FHIR サービスと Azure Active Directory B2C の統合
医療組織は、Azure Active Directory B2C (Azure AD B2C) で Azure Health Data Services の FHIR サービスを使用できます。 組織は、組織の Microsoft Entra ID テナントにユーザー アカウントを作成したり、ユーザー アカウントを追加したりすることなく、さまざまなユーザーまたはグループに対してきめ細かいアクセス制御を使用して、FHIR サービスへのアクセスを許可する安全で便利な方法を得ることができます。 この統合により、組織は次のことができます。
- SMART on FHIR スコープを使用して FHIR リソースを認証およびアクセスするには、追加の ID プロバイダーを使用します。
- 詳細なアクセス制御、FHIR リソースの種類と相互作用、およびユーザーの基になる権限をサポートする SMART on FHIR スコープを使用して、ユーザー アクセス権またはアクセス許可を管理およびカスタマイズします。
関連コンテンツ:
- Azure Active Directory B2C を使用して FHIR サービスへのアクセスを許可する
- FHIR サービス用に複数のサービス ID プロバイダーを構成する
- FHIR サービスの ID プロバイダー構成のトラブルシューティング
- FHIR サービスに対して SMART on FHIR を有効にする
- サンプル: Azure ONC (g)(10) SMART on FHIR
最大 100 TB のストレージを要求する
FHIR サービスは大量の正常性データを格納および交換でき、各 FHIR サービス インスタンスのストレージ制限は既定で 4 TB です。 さらに多くのデータがある場合は、FHIR サービスのストレージを最大 100 TB まで増やすように Microsoft に依頼できます。
ストレージを増やすと、組織は大規模なデータ セットを処理して分析シナリオを実現できます。 たとえば、より多くのストレージを使用して、人口の正常性を管理し、調査を実施し、健康データから新しい分析情報を得ることができます。 さらに、より多くのストレージにより、大量のデータ (4 TB を超える) を持つ Azure API for FHIR のお客様は、Azure Health Data Services の FHIR サービスに移行できます。
4 TB を超えるストレージを要求するには、Azure portal でサポート要求を作成し、問題の種類のサービスとサブスクリプションの制限 (クォータ) を使用します。
Note
ストレージの課金メトリックに問題があるため、4 TB を超えるストレージ容量を選択したお客様は、問題が解決されるまでストレージに対して課金されません。