リリース ノート 2024: Azure Health Data Services
この記事では、Azure Health Data Services の FHIR® サービス、DICOM® サービス、および MedTech サービスについて、2024 年にリリースされた機能、機能強化、バグ修正について説明します。
2024 年 5 月
Azure Health Data Services
スタンドアロン 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 エクスプローラー、Data Movement ライブラリなど、Azure Storage を操作するためのツールのエコシステム全体まで、医療画像データを開きます。
- Azure Synapse、Azure Databricks、Azure Machine ラーニング、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 search can reference all resources with wildカード character
FHIR サービスでは、a0/> を使用した野生カード検索が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 (テラバイト)を超えるストレージ容量を選択したお客様は、問題が解決されるまでストレージに対して課金されません。