次の方法で共有

リリース ノート 2024: Azure Health Data Services

  • [アーティクル]

この記事では、Azure Health Data Services の FHIR® サービス、DICOM® サービス、および MedTech サービスについて、2024 年にリリースされた機能、機能強化、バグ修正について説明します。

2024 年 11 月

Azure Health Data Services

インポート操作の機能強化

  • エラー ログの機能強化: インポート操作中に、エラー ログは、FHIR サービスへのインジェスト中に失敗した特定のファイルを報告するようになりました。 この改善により、失敗したインポートに関するより詳細なフィードバックが提供されます。
  • インポート ジョブの取り消し: インポート ジョブを取り消しても、関連付けられている子ジョブの取り消しがトリガーされないバグが特定されました。 この問題は解決され、インポート ジョブをキャンセルすると、現在のオーケストレーター内のすべての関連する子ジョブも取り消されます。
  • エクスポートの検証の改善: 無効な検索パラメーターにもかかわらずエクスポートが続行される問題が見つかりました。 これらの条件下でのエクスポートを防ぐために、変更が実装されます。 これは既定の動作ですが、お客様は lenient フラグを使用してオーバーライドできます。 変更は先月お客様に伝達されました。
  • バンドル パフォーマンスの強化: バンドルの実行中のプロファイル更新プロセスが簡略化されました。 バンドルに ValueSet、 StructureDefinition、 CodeSystemの変更が含まれている場合、バンドルが完全に完了するまでプロファイルの更新は行われません。 この変更により、これらのリソースの種類に対する変更を処理するときに、複数の更新によって発生する遅延を減らすことで、バンドルのパフォーマンスが向上します。
  • コンテンツ タイプ ヘッダーの解析: application/x-www-form-urlencoded コンテンツ タイプ ヘッダーの解析に関連する問題が解決されました。
  • インデックス再作成の機能強化: 大規模な履歴データセットの処理を以前に制限していた人為的な制限や、お客様が限られたクエリ サイズを要求した場合を削除することで、インデックス再作成操作が改善されました。 さらに、インデックス再作成プロセスでは、既定のクエリ サイズで多数の連続した履歴または削除されたリソースを処理するときに、"完了" と誤って報告されます。 この問題は、インデックス再作成プロセスが正しく完了し、適切な状態を報告するために対処されています。

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 サービス

インポート操作のエラー処理

  1. インポート操作では、インポート プロセスを介して検索パラメーター リソースが取り込まれると、HTTP 400 エラーが返されます。 この変更は、インポート操作で取り込まれたときに、検索パラメーターが無効な状態にならないようにするためのものです。
  2. インポート操作では、ストレージ アカウントで構成の問題が発生した場合に、以前の 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 シナリオのロックを解除します。
  • ストレージのアクセス許可、アクセス制御、階層、およびルールを管理するためのコントロールを付与します。

詳細情報:

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 スコープを使用して、ユーザー アクセス権またはアクセス許可を管理およびカスタマイズします。

関連コンテンツ:

最大 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 を超えるストレージ容量を選択したお客様は、問題が解決されるまでストレージに対して課金されません。

関連するコンテンツ

リリース ノート 2021

リリース ノート 2022

リリース ノート 2023

既知の問題

Note

FHIR® は HL7 の登録商標であり、HL7 の許可を得て使用しています。

DICOM® は、医療情報のデジタル通信に関する標準出版物に関する米国電機工業会 (National Electrical Manufacturers Association) の登録商標です。