MedTech 서비스 디바이스 데이터 처리 단계 개요

아티클
02/23/2024

이 문서에서는 MedTech 서비스 내 디바이스 데이터 처리 단계를 간략하게 설명합니다. MedTech 서비스는 FHIR 서비스의 지속성을 위해 디바이스 데이터를 FHIR® Observation으로 변환합니다.

MedTech 서비스 디바이스 데이터 처리는 다음 단계와 순서를 따릅니다.

수집
정규화 - 디바이스 매핑이 적용되었습니다.
그룹 - (선택 사항)
변환 - FHIR 대상 매핑이 적용되었습니다.
Persist

수집

수집은 Azure Event Hubs Event Hubs에서 디바이스 메시지를 수신하고 즉시 MedTech 서비스로 가져오는 첫 번째 단계입니다. Event Hubs 서비스는 초당 수백만 개의 디바이스 메시지를 수신하고 처리하는 기능을 통해 높은 규모와 처리량을 지원합니다. 또한 MedTech 서비스가 디바이스 메시지를 비동기적으로 사용할 수 있으므로 디바이스 메시지가 처리되는 동안 디바이스가 기다릴 필요가 없습니다. MedTech 서비스의 시스템 할당 관리 ID 및 Azure 리소스 기반 액세스 제어(Azure RBAC)는 이벤트 허브에 대한 보안 액세스에 사용됩니다.

참고 항목

JSON은 현재 디바이스 메시지 데이터에 대해 지원되는 유일한 형식입니다.

Important

여러 서비스에서 이벤트 허브로의 액세스를 허용하려면 각 서비스에 자체 이벤트 허브 소비자 그룹이 있어야 합니다.

소비자 그룹을 사용하면 여러 소비 애플리케이션이 이벤트 스트림에 대한 별도의 보기를 가지며 자체 속도와 자체 오프셋을 사용하여 독립적으로 스트림을 읽을 수 있습니다. 자세한 내용은 소비자 그룹을 참조하세요.

예:

동일한 이벤트 허브에 액세스하는 두 개의 MedTech 서비스.
동일한 이벤트 허브에 액세스하는 MedTech 서비스 및 스토리지 작성자 애플리케이션.

Normalize

정규화는 사용자가 선택/사용자가 만든 적합하고 유효한 디바이스 매핑을 사용하여 디바이스 데이터를 처리하는 다음 단계입니다. 이 매핑 프로세스를 통해 디바이스 데이터가 정규화된 스키마로 변환됩니다. 정규화 프로세스는 이후 단계에서 디바이스 데이터 처리를 간소화할 뿐만 아니라 하나의 디바이스 메시지를 여러 정규화된 메시지로 프로젝션하는 기능도 제공합니다. 예를 들어, 디바이스는 단일 디바이스 메시지로 체온, 맥박수, 혈압, 호흡수에 대한 여러 생체 신호를 보낼 수 있습니다. 이 디바이스 메시지는 4개의 별도 FHIR Observation을 만듭니다. 각 FHIR Observation은 서로 다른 생체 신호를 나타내며 디바이스 메시지는 4개의 서로 다른 정규화된 메시지로 투영됩니다.

그룹 - (선택 사항)

그룹은 MedTech 서비스 정규화 단계에서 사용할 수 있는 정규화된 메시지가 세 가지 다른 매개 변수를 사용하여 그룹화되는 다음 선택적 단계입니다.

디바이스 ID
측정 유형
기간

디바이스 ID 및 측정 형식 그룹화는 선택 사항이며 SampledData 측정 형식을 사용하여 사용하도록 설정됩니다. SampledData 측정 형식은 디바이스 메시지의 시간 기반 일련의 측정을 FHIR Observation으로 표현하는 간결한 방법을 제공합니다. SampledData 측정 형식을 사용하면 측정값을 1시간 또는 24시간 기간을 나타내는 단일 FHIR Observation으로 그룹화할 수 있습니다.

Transform

변환은 사용자가 선택/사용자 만든 적합하고 유효한 FHIR 대상 매핑을 사용하여 정규화된 메시지를 처리하는 다음 단계입니다. 일치하는 FHIR 대상 매핑이 작성된 경우 정규화된 메시지가 FHIR Observation으로 변환됩니다. 이 시점에서 Device 리소스는 연결된 Patient 리소스와 함께 디바이스 메시지에 있는 디바이스 식별자를 사용하여 FHIR 서비스에서도 검색됩니다. 이러한 리소스는 생성되는 FHIR Observation에 대한 참조로 추가됩니다.

참고 항목

FHIR 서비스의 로드를 줄이기 위해 해결되면 모든 ID 조회가 캐시됩니다. 여러 환자에게 디바이스를 재사용할 계획이라면 환자별 가상 디바이스 리소스를 만들고 디바이스 메시지 페이로드에 가상 디바이스 식별자를 보내는 것이 좋습니다. 가상 디바이스는 실제 디바이스 리소스에 부모 디바이스로 연결될 수 있습니다.

특정 디바이스 식별자에 대한 디바이스 리소스가 FHIR 서비스에 없는 경우 결과는 MedTech 서비스 배포 시 설정된 해결 형식 값에 따라 달라집니다. 조회로 설정하면 특정 메시지가 무시되고 파이프라인은 계속해서 다른 수신 디바이스 메시지를 처리합니다. 만들기로 설정하면 MedTech 서비스가 FHIR 서비스에 최소한의 디바이스 및 환자 리소스를 만듭니다.

참고 항목

나중에 다른 해결 형식이 필요한 경우 MedTech 서비스 배포 후 해결 형식을 조정할 수도 있습니다.

MedTech 서비스는 거의 실시간 처리를 제공하며 요청을 300개의 정규화된 메시지 일괄 처리로 그룹화하여 FHIR 서비스에 대한 요청 수를 줄이려고 시도합니다. 데이터 양이 적고 300개의 정규화된 메시지가 그룹에 추가되지 않은 경우 해당 그룹의 해당 FHIR Observation은 약 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 Observation에 대한 데이터가 포함되어 있음을 나타냄) 디바이스 메시지만 2는 최신/가장 최근 데이터를 나타내기 위해 유지됩니다.

Persist

지속은 변환 단계의 FHIR Observation이 FHIR 서비스에서 지속되는 마지막 단계입니다. FHIR Observation이 새로운 경우 FHIR 서비스에서 만들어집니다. FHIR Observation이 이미 존재하는 경우 FHIR 서비스에서 업데이트됩니다. FHIR 서비스는 FHIR 서비스에 대한 보안 액세스를 위해 MedTech 서비스의 시스템 할당 관리 ID와 Azure 리소스 기반 액세스 제어(Azure RBAC)를 사용합니다.