MedTech サービスデバイスのデータ処理ステージの概要

Important

MedTech サービスの廃止は、2025 年 5 月 3 日に開始されました。 MedTech サービスの使用が優先されなくなった場合は、ここで見つかるインスタンスのプロビジョニングを解除します。次のリージョンでのアクティブインスタンスのサポートは、2028 年 5 月 3 日に終了します。米国西部 2、英国南部、西ヨーロッパ、米国東部、オーストラリア東部、米国東部 2、インド中部、北ヨーロッパ。 MedTech サービスのオープンソースバージョンについては、こちらをご覧ください。

この記事では、 MedTech サービス内のデバイスデータ処理ステージの概要について説明します。 MedTech サービスは、FHIR サービスでの永続化のためにデバイスデータを FHIR® 監視に変換します。

MedTech サービスデバイスのデータ処理は、次の段階と順序に従います。

摂取する
正規化 - デバイスマッピングが適用されました。
グループ - (省略可能)
変換 - FHIR 宛先マッピングが適用されました。
持続する

摂取する

取り込みは、デバイスメッセージが Azure Event Hubs イベントハブから受信され、すぐに MedTech サービスにプルされる最初のステージです。 Event Hubs サービスは、1 秒あたり何百万ものデバイスメッセージを受信して処理できる高スケールとスループットをサポートします。また、MedTech サービスでデバイスメッセージを非同期的に使用できるため、デバイスメッセージの処理中にデバイスが待機する必要が排除されます。 MedTech サービスのシステム割り当てマネージド ID と Azure リソースベースのアクセス制御 (Azure RBAC) は、イベントハブへのセキュリティで保護されたアクセスに使用されます。

注

現時点では、デバイスメッセージデータでサポートされている形式は JSON のみです。

Important

複数のサービスからイベントハブへのアクセスを許可する場合は、各サービスに独自のイベントハブコンシューマーグループが必要です。

コンシューマーグループを使用すると、複数の消費アプリケーションでイベントストリームを個別に表示し、独自のペースで独自のオフセットを使用してストリームを個別に読み取ります。詳細については、「コンシューマーグループ」を参照してください。

例 :

同じイベントハブにアクセスする 2 つの MedTech サービス。
同じイベントハブにアクセスする MedTech サービスとストレージライターアプリケーション。

ノーマライズ

正規化は、ユーザーが選択した、またはユーザーが作成した準拠した有効なデバイスマッピングを使用してデバイスデータが処理される次の段階です。このマッピングプロセスにより、デバイスデータが正規化されたスキーマに変換されます。正規化プロセスは、後の段階でのデバイスデータ処理を簡略化するだけでなく、1 つのデバイスメッセージを複数の正規化されたメッセージに投影する機能も提供します。たとえば、デバイスは、1 つのデバイスメッセージで、体温、パルスレート、血圧、呼吸数に関する複数のバイタルサインを送信できます。このデバイスメッセージでは、4 つの個別の FHIR 観測が作成されます。各 FHIR の観測値は異なる重要な記号を表し、デバイスメッセージは 4 つの異なる正規化されたメッセージに投影されます。

グループ - (省略可能)

グループは、MedTech サービスの正規化ステージから使用できる正規化されたメッセージが、次の 3 つの異なるパラメーターを使用してグループ化される次の 省略可能な ステージです。

デバイス ID
測定の種類
期間

デバイス ID と測定の種類のグループ化は省略可能であり、 SampledData 測定の種類を使用することで有効になります。 SampledData 測定の種類は、デバイスメッセージから FHIR Observations への時間ベースの一連の測定値を表す簡潔な方法を提供します。 SampledData 測定の種類を使用する場合、測定は 1 時間または 24 時間の期間を表す単一の FHIR 観測にグループ化できます。

変形する

変換は、ユーザーが選択した/ユーザーが作成した準拠および有効な FHIR 宛先マッピングを使用して正規化されたメッセージを処理する次の段階です。一致する FHIR 宛先マッピングが作成されている場合、正規化されたメッセージは FHIR Observations に変換されます。この時点で、デバイスリソースとそれに関連付けられている Patient リソースも、デバイスメッセージに存在するデバイス識別子を使用して FHIR サービスから取得されます。これらのリソースは、作成される FHIR 監視への参照として追加されます。

注

すべての ID 参照は、FHIR サービスの負荷を減らすよう解決されるとキャッシュされます。複数の患者でデバイスを再利用する場合は、患者に固有の仮想デバイスリソースを作成し、デバイスメッセージペイロードで仮想デバイス識別子を送信することをお勧めします。仮想デバイスは、親として実際のデバイスリソースにリンクできます。

特定のデバイス識別子のデバイスリソースが FHIR サービスに存在しない場合、結果は MedTech サービスのデプロイ時に設定された 解決の種類 の値によって異なります。 Lookup に設定すると、特定のメッセージは無視され、パイプラインは引き続き他の受信デバイスメッセージを処理します。 [作成] に設定すると、MedTech サービスによって、FHIR サービス内に最小限の Device リソースと Patient リソースが作成されます。

注

後で別の 解像度の種類 が必要な場合は、MedTech サービスのデプロイ後に 解像度の種類 を調整することもできます。

MedTech サービスは、ほぼリアルタイムの処理を提供し、要求を 300 の正規化されたメッセージのバッチにグループ化することによって、FHIR サービスに対する要求の数を減らそうとします。データ量が少ない場合、正規化されたメッセージが 300 件グループに追加されていない場合、そのグループ内の対応する FHIR の監視は、約 5 分後に FHIR サービスに保持されます。

注

複数のデバイスメッセージに同じ FHIR Observation のデータが含まれており、同じタイムスタンプがあり、同じデバイスメッセージバッチ内で送信される場合 (たとえば、5 分間のウィンドウ内または 300 個の正規化されたメッセージのグループ内)、その FHIR Observation の最新のデバイスメッセージに対応するデータのみが保持されます。

例えば次が挙げられます。

デバイスメッセージ 1:

{    
   "patientid": "testpatient1",    
   "deviceid": "testdevice1",
   "systolic": "129",    
   "diastolic": "65",    
   "measurementdatetime": "2022-02-15T04:00:00.000Z"
}

デバイスメッセージ 2:

{   
   "patientid": "testpatient1",    
   "deviceid": "testdevice1",    
   "systolic": "113",    
   "diastolic": "58",    
   "measurementdatetime": "2022-02-15T04:00:00.000Z"
}

これらのデバイスメッセージが同じ 5 分間のウィンドウ内または 300 個の正規化されたメッセージの同じグループに取り込まれたと仮定すると、両方のデバイスメッセージで measurementdatetime が同じであるため (同じ FHIR 監視のデータが含まれていることを示します)、デバイスメッセージ 2 のみが最新/最新のデータを表すために保持されます。

持続する

Persist は、変換ステージの FHIR Observations が FHIR サービスに保持される最後のステージです。 FHIR Observation が新しい場合は、FHIR サービスで作成されます。 FHIR 監視が既に存在する場合は、FHIR サービスで更新されます。 FHIR サービスは、MedTech サービスのシステム割り当てマネージド ID と Azure リソースベースのアクセス制御 (Azure RBAC) を使用して、FHIR サービスへのセキュリティで保護されたアクセスを行います。