Обзор этапов обработки данных устройства службы MedTech

Это важно

Прекращение использования службы MedTech было инициировано 3 мая 2025 года. Если использование службы MedTech больше не является приоритетом, удалите экземпляр, который можно найти здесь. Поддержка активных инстанций в следующих регионах завершится 3 мая 2028 г.: Западная часть США 2, Южная часть Великобритании, Западная Европа, Восточная часть США, Восточная часть США 2, Центральная Индия, Северная Европа. Здесь можно найти версию службы MedTech с открытым исходным кодом.

В этой статье представлен обзор этапов обработки данных устройства в службе MedTech. Служба MedTech преобразует данные устройства в наблюдения FHIR® для сохранения в службе FHIR.

Обработка данных устройства службы MedTech выполняет следующие этапы и в этом порядке:

  • Глотать
  • Нормализовано — выполнено сопоставление устройств.
  • Группа — (необязательно)
  • Преобразование — применено сопоставление назначения FHIR.
  • Упорствовать

Снимок экрана: данные устройства, обработанные службой MedTech.

Глотать

Прием — это первый этап, на котором сообщения устройства получаются от Центры событий Azure концентратора событий и немедленно извлекаются в службу MedTech. Служба Центров событий поддерживает высокую масштабируемую и пропускную способность с возможностью получения и обработки миллионов сообщений устройств в секунду. Кроме того, служба MedTech позволяет асинхронно использовать сообщения устройств, удаляя необходимость ожидания устройств во время обработки сообщений устройства. Управляемое удостоверение системно назначенное и управление доступом на основе ресурсов Azure (Azure RBAC) используются для безопасного доступа к концентратору событий.

Замечание

JSON — это единственный поддерживаемый формат в настоящее время для данных сообщения устройства.

Это важно

Если вы собираетесь разрешить доступ из нескольких служб к концентратору событий, необходимо, чтобы каждая служба имеет собственную группу потребителей концентратора событий.

Группы потребителей позволяют нескольким приложениям-потребителям обеспечивать отдельное представление потока событий и читать поток независимо в своем темпе и с собственными смещениями. Дополнительные сведения см. в разделе "Группы потребителей".

Примеры:

  • Две службы MedTech, обращающиеся к одному концентратору событий.

  • Служба медицинских технологий и приложение для записи данных, обращающиеся к той же шине событий.

Нормализовать

Нормализация — это следующий этап, когда данные устройства обрабатываются с помощью пользовательского или созданного пользователем соответствия и допустимого сопоставления устройств. Этот процесс сопоставления приводит к преобразованию данных устройства в нормализованную схему. Процесс нормализации не только упрощает обработку данных устройства на последующих этапах, но и предоставляет возможность проецировать одно сообщение устройства в несколько нормализованных сообщений. Например, устройство может отправлять несколько жизненно важных признаков для температуры тела, частоты пульса, кровяного давления и скорости дыхания в одном сообщении устройства. Это сообщение устройства создаст четыре отдельных FHIR-наблюдений. Каждое наблюдение FHIR представляет собой другой важный знак, при этом сообщение устройства проецируется на четыре различных нормализованных сообщения.

Группа — (необязательно)

Группа является следующим необязательным этапом, где нормализованные сообщения, доступные на этапе нормализации службы MedTech, группируются с помощью трех различных параметров:

  • Идентичность устройства
  • Тип измерения
  • Период времени

Группирование типов устройств и удостоверений устройств является необязательным и включено с помощью типа измерения SampledData . Тип измерения SampledData предоставляет краткий способ представления временных рядов измерений из сообщения устройства в наблюденияХ FHIR. При использовании типа измерения SampledData измерения можно сгруппировать в одно наблюдение FHIR, представляющее 1-часовой период или 24-часовой период.

Преобразуй

Преобразование — это следующий этап, когда нормализованные сообщения обрабатываются с помощью сопоставления назначения FHIR, созданного пользователем или выбранного пользователем. Нормализованные сообщения преобразуются в наблюдения FHIR, если было создано сопоставление назначения FHIR. На этом этапе ресурс устройства , а также связанный ресурс "Пациент " также извлекается из службы FHIR с помощью идентификатора устройства, присутствующих в сообщении устройства. Эти ресурсы добавляются в качестве ссылки на наблюдение FHIR, которое создается.

Замечание

Все поиски идентификаций кэшируются после завершения, чтобы уменьшить нагрузку на службу FHIR. Если вы планируете повторно использовать устройства с несколькими пациентами, рекомендуется создать ресурс виртуального устройства, характерный для пациента, и отправить идентификатор виртуального устройства в полезных данных сообщения устройства. Виртуальное устройство может быть связано с фактическим ресурсом устройства как родительским.

Если в службе FHIR не существует ресурса устройства для заданного идентификатора устройства, результат зависит от значения типа разрешения , заданного во время развертывания службы MedTech. Если задано значение Lookup, конкретное сообщение игнорируется, и конвейер продолжает обрабатывать другие входящие сообщения устройства. Если задано значение Create, служба MedTech создает минимальные ресурсы устройств и пациентов в службе FHIR.

Замечание

Тип разрешения также можно изменить после развертывания службы MedTech, если требуется другой тип разрешения.

Служба MedTech обеспечивает почти обработку в режиме реального времени, а также пытается сократить количество запросов, сделанных в службу FHIR, сгруппировав запросы в пакеты из 300 нормализованных сообщений. Если объем входящих данных низкий, и в группу не будет добавлено 300 нормализованных сообщений, то соответствующие наблюдения FHIR в этой группе будут сохранены в службе FHIR приблизительно через пять минут.

Замечание

Если несколько сообщений устройства содержат данные для одного наблюдения FHIR, имеют одинаковую метку времени и отправляются в одном пакете сообщений устройства (например, в течение пяти минут или в группах 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"
}

Предполагая, что эти сообщения устройств были получены в одном и том же пятиминутном окне или в той же группе из 300 нормализованных сообщений, и поскольку measurementdatetime одинаков для обоих сообщений устройств (что указывает на то, что они содержат данные для одного и того же наблюдения FHIR), сохраняется только сообщение устройства 2, чтобы представлять самые новые данные.

Упорствовать

Сохранение — это последний этап, в котором наблюдения FHIR с этапа преобразования сохраняются в службе FHIR. Если наблюдение FHIR является новым, оно создается в системе FHIR. Если наблюдение FHIR уже существует, оно обновляется в службе FHIR. Служба FHIR использует управляемое удостоверение, назначенное системе службы MedTech, и управление доступом на основе ресурсов Azure (Azure RBAC) для безопасного доступа к службе FHIR.

Дальнейшие действия

Выбор метода развертывания для службы MedTech

Обзор карты устройств сервиса MedTech

Обзор сопоставления целевого назначения службы MedTech FHIR

Обзор примеров сопоставлений на основе сценариев сервиса MedTech

Замечание

FHIR® является зарегистрированным товарным знаком HL7 и используется с разрешением HL7 .