MedTech サービスでのデバイス データの処理ステージの概要
この記事では、MedTech サービス内のデバイス データ処理ステージの概要について説明します。 MedTech サービスを使うと、デバイス データを FHIR® Observationsに変換し、FHIR サービスに保持することができます。
MedTech サービス デバイスのデータ処理は、次の順序で次のステージをたどります。
- 取り込み
- 正規化 - デバイス マッピングが適用されます。
- グループ - (省略可能)
- 変換 - FHIR 変換先マッピングが適用されます。
- Persist
取り込み
取り込みが最初のステージです。デバイス メッセージを Azure Event Hubs イベント ハブから受信すると、直ちに MedTech サービスに取り込みます。 Event Hubs サービスは、1 秒あたり数百万件のデバイス メッセージを受信して処理する機能により、高いスケールとスループットをサポートしています。 また、これによって MedTech サービスは非同期にデバイス メッセージを使用できるので、デバイス メッセージの処理中にデバイスが待機する必要がなくなります。 イベント ハブに対するセキュリティで保護されたアクセスのために、MedTech サービスのシステム割り当てマネージド ID と Azure リソースベースのアクセス制御 (Azure RBAC) が使われています。
Note
現時点でデバイス メッセージ データの形式としてサポートされているのは JSON のみです。
重要
複数のサービスからイベント ハブへのアクセスを許可する場合は、各サービスに独自のイベント ハブ コンシューマー グループが必要です。
コンシューマー グループを使うと、複数のコンシューマー アプリケーションがイベント ストリームの個別のビューを保有し、独自のペースで独自のオフセットを指定してストリームを別々に読み取ることができます。 詳細については、「コンシューマー グループ」を参照してください。
例 :
同じイベント ハブにアクセスする 2 つの MedTech サービス。
同じイベント ハブにアクセスする MedTech サービスとストレージ ライター アプリケーション。
Normalize
正規化が次のステージです。適合する有効なデバイス マッピング (ユーザーが選んだ、またはユーザーが作成したもの) を使ってデバイス データを処理します。 このマッピング プロセスにより、デバイス データが、正規化されたスキーマに変換されます。 正規化プロセスによって、後の段階でのデバイス データ処理が簡素化されるだけでなく、1 つのデバイス メッセージを複数の正規化されたメッセージに投影することもできます。 たとえば、デバイスから 1 つのデバイス メッセージで、体温、脈拍数、血圧、呼吸速度に関する複数の生命兆候を送信できます。 このデバイス メッセージの場合、4 つの個別の FHIR 観測記録が作成されます。 各 FHIR 観測記録は異なる生命兆候を表し、デバイス メッセージが 4 つの異なる正規化されたメッセージに投影されます。
グループ - (省略可能)
グループが次のステージであり、"省略可能" です。MedTech サービスの正規化ステージから取得した正規化されたメッセージを、3 種類のパラメーターを使ってグループ化します。
- デバイス ID
- Measurement type
- 期間
デバイス ID と測定タイプのグループ化は省略可能です。有効にするには、SampledData 測定タイプを使います。 SampledData 測定タイプを使うと、デバイス メッセージの時系列の測定を FHIR 観測記録の形式で簡潔に表すことができます。 SampledData 測定タイプを使うと、測定値を 1 時間または 24 時間を表す 1 つの FHIR 観測記録にグループ化できます。
変換
変換が次のステージです。適合する有効な FHIR 変換先マッピング (ユーザーが選んだ、またはユーザーが作成したもの) を使って、正規化されたメッセージが処理されます。 一致する FHIR 変換先マッピングが作成されている場合、正規化されたメッセージは FHIR 観測記録に変換されます。 また、この時点で、デバイス リソースとそれに関連付けられている患者リソースが、デバイス メッセージに含まれるデバイス識別子を使用して FHIR サービスから取得されます。 これらのリソースは、作成される FHIR 観測記録への参照として追加されます。
Note
FHIR サービスの負荷を軽減するために、すべての ID 参照は解決されるとキャッシュされます。 複数の患者に対してデバイスの再利用を予定している場合は、その患者に固有の仮想デバイス リソースを作成し、デバイス メッセージ ペイロードで仮想デバイス識別子を送信することをお勧めします。 仮想デバイスは、実際のデバイス リソースに親としてリンクさせることができます。
指定したデバイス識別子のデバイス リソースが FHIR サービスに存在しない場合、MedTech サービスのデプロイ時に設定した [Resolution type] (解決の種類) の値に応じて異なる結果になります。 [Lookup] (検索) に設定すると、特定のメッセージは無視され、パイプラインは他の受信デバイス メッセージの処理を続行します。 [Create] (作成) に設定すると、MedTech サービスにより、FHIR サービスに最小限のデバイスと患者のリソースが作成されます。
Note
MedTech サービスのデプロイ後に別の [Resolution type] (解決の種類) が必要になった場合は、[Resolution type] (解決の種類) を調整することもできます。
MedTech サービスは準リアルタイム処理を提供します。また、300 個の正規化されたメッセージのバッチへと要求をグループ化することで、FHIR サービスに対する要求数を減らそうと試みます。 データ量が少なく、300 個の正規化されたメッセージがグループに追加されていない場合、そのグループの対応する FHIR 観測記録は約 5 分後に FHIR サービスに保持されます。
Note
複数のデバイス メッセージに同じ FHIR 観測記録のデータが含まれ、同じタイムスタンプを持ち、同じデバイス メッセージ バッチ内で送信された場合 (たとえば、5 分の期間内、または 300 個の正規化されたメッセージのグループ内)、その FHIR 観測記録の最新のデバイス メッセージに対応するデータのみが保持されます。
次に例を示します。
デバイス メッセージ 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 観測記録が FHIR サービスに保持されます。 FHIR 観測記録が新しい場合は、FHIR サービスに作成されます。 FHIR 観測記録が既に存在する場合は、FHIR サービス内で更新されます。 FHIR サービスに対するセキュリティで保護されたアクセスのために、FHIR サービスには MedTech サービスのシステム割り当てマネージド ID と Azure リソースベースのアクセス制御 (Azure RBAC) が使われています。
次のステップ
MedTech サービスの FHIR 変換先マッピングの概要
MedTech サービス シナリオベースのマッピング サンプルの概要
Note
FHIR® は HL7 の登録商標であり、HL7 の許可を得て使用しています。