リリース ノート 2024: Azure Health Data Services
この記事では、Azure Health Data Services の FHIR® サービス、DICOM® サービス、および MedTech サービスについて、2024 年にリリースされた機能、機能強化、バグ修正について説明します。
2024 年 7 月
Azure Health Data Services
FHIR サービス
JSON データの日付を Convert-Data 操作で文字列として扱うことを許可する
JSON データ内で指定された日付が、指定された形式とは異なる形式で返される可能性があります。 日付として識別される JSON ペイロード文字列の逆シリアル化中に、.NET DateTime オブジェクトに変換されます。 これらのオブジェクトは、Liquid テンプレート エンジンを通過する前に文字列に変換されます。 この変換により、日付値が再フォーマットされ、FHIR サービスのローカル タイムゾーンで表される可能性があります。
.NET DateTime オブジェクトへの文字列の強制変換は、ブール型パラメーター jsonDeserializationTreatDatesAsStrings
を使用して無効にすることができます。 true
に設定すると、指定されたデータは文字列として扱われ、Liquid エンジンに提供される前に変更されません。
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 を超えるストレージ容量を選択したお客様は、問題が解決されるまでストレージに対して課金されません。
関連するコンテンツ
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示