Visão geral dos estágios de processamento de dados do dispositivo de serviço MedTech

Este artigo fornece uma visão geral dos estágios de processamento de dados do dispositivo dentro do serviço MedTech. O serviço MedTech transforma os dados do dispositivo em Observações FHIR para persistência no serviço FHIR®.

O processamento de dados do dispositivo de serviço MedTech segue estas etapas e nesta ordem:

• Ingerir
• Normalizar - Mapeamento de dispositivo aplicado.
• Grupo - (Opcional)
• Transform - mapeamento de destino FHIR aplicado.
• Persistir

Ingerir

O Ingest é o primeiro estágio em que as mensagens do dispositivo são recebidas de um hub de eventos dos Hubs de Eventos do Azure e imediatamente puxadas para o serviço MedTech. O serviço Hubs de Eventos suporta alta escala e taxa de transferência com a capacidade de receber e processar milhões de mensagens de dispositivo por segundo. Ele também permite que o serviço MedTech consuma mensagens de dispositivo de forma assíncrona, eliminando a necessidade de os dispositivos esperarem enquanto as mensagens do dispositivo são processadas. A identidade gerenciada atribuída pelo sistema do serviço MedTech e o controle de acesso baseado em recursos do Azure (Azure RBAC) são usados para acesso seguro ao hub de eventos.

Nota

JSON é o único formato suportado no momento para dados de mensagens do dispositivo.

Importante

Se você vai permitir o acesso de vários serviços ao hub de eventos, é necessário que cada serviço tenha seu próprio grupo de consumidores do hub de eventos.

Os grupos de consumidores permitem que vários aplicativos consumidores tenham uma visão separada do fluxo de eventos e leiam o fluxo independentemente em seu próprio ritmo e com seus próprios deslocamentos. Para obter mais informações, consulte Grupos de consumidores.

Exemplos:

• Dois serviços MedTech acessando o mesmo hub de eventos.

• Um serviço MedTech e um aplicativo de gravador de armazenamento acessando o mesmo hub de eventos.

Normalizar

Normalizar é o próximo estágio em que os dados do dispositivo são processados usando o mapeamento de dispositivo válido e em conformidade selecionado pelo usuário/criado pelo usuário. Esse processo de mapeamento resulta na transformação de dados do dispositivo em um esquema normalizado. O processo de normalização não apenas simplifica o processamento de dados do dispositivo em estágios posteriores, mas também fornece a capacidade de projetar uma mensagem de dispositivo em várias mensagens normalizadas. Por exemplo, um dispositivo pode enviar vários sinais vitais para a temperatura corporal, pulso, pressão arterial e frequência respiratória em uma única mensagem do dispositivo. Esta mensagem de dispositivo criaria quatro observações FHIR separadas. Cada observação FHIR representaria um sinal vital diferente, com a mensagem do dispositivo projetada em quatro mensagens normalizadas diferentes.

Grupo - (Opcional)

Grupo é o próximo estágio opcional onde as mensagens normalizadas disponíveis no estágio de normalização do serviço MedTech são agrupadas usando três parâmetros diferentes:

• Identidade do dispositivo
• Measurement type
• Período de tempo

A identidade do dispositivo e o agrupamento do tipo de medição são opcionais e habilitados pelo uso do tipo de medição SampledData . O tipo de medição SampledData fornece uma maneira concisa de representar uma série baseada no tempo de medições de uma mensagem de dispositivo em Observações FHIR. Quando você usa o tipo de medição SampledData, as medições podem ser agrupadas em uma única Observação FHIR que representa um período de 1 hora ou um período de 24 horas.

Transformação

Transform é o próximo estágio em que as mensagens normalizadas são processadas usando o mapeamento de destino FHIR válido e em conformidade selecionado pelo usuário/criado pelo usuário. As mensagens normalizadas são transformadas em Observações FHIR se um mapeamento de destino FHIR correspondente tiver sido criado. Neste ponto, o recurso Dispositivo, juntamente com seu recurso Paciente associado, também é recuperado do serviço FHIR usando o identificador de dispositivo presente na mensagem do dispositivo. Estes recursos são acrescentados como referência à Observação FHIR que está a ser criada.

Nota

Todas as pesquisas de identidade são armazenadas em cache uma vez resolvidas para diminuir a carga no serviço FHIR. Se você planeja reutilizar dispositivos com vários pacientes, é aconselhável criar um recurso de dispositivo virtual específico para o paciente e enviar o identificador de dispositivo virtual na carga útil da mensagem do dispositivo. O dispositivo virtual pode ser vinculado ao recurso de dispositivo real como pai.

Se não existir nenhum recurso de dispositivo para um determinado identificador de dispositivo no serviço FHIR, o resultado dependerá do valor do tipo de resolução definido no momento da implantação do serviço MedTech. Quando definido como Pesquisa, a mensagem específica é ignorada e o pipeline continua a processar outras mensagens de dispositivo de entrada. Se definido como Criar, o serviço MedTech cria recursos mínimos de Dispositivo e Paciente no serviço FHIR.

Nota

O tipo de resolução também pode ser ajustado após a implantação do serviço MedTech se um tipo de resolução diferente for necessário posteriormente.

O serviço MedTech fornece processamento quase em tempo real e também tenta reduzir o número de solicitações feitas ao serviço FHIR, agrupando solicitações em lotes de 300 mensagens normalizadas. Se houver um baixo volume de dados e 300 mensagens normalizadas não tiverem sido adicionadas ao grupo, as Observações FHIR correspondentes nesse grupo serão mantidas no serviço FHIR após aproximadamente cinco minutos.

Nota

Quando várias mensagens de dispositivo contêm dados para a mesma Observação FHIR, têm o mesmo carimbo de data/hora e são enviadas dentro do mesmo lote de mensagens do dispositivo (por exemplo, dentro da janela de cinco minutos ou em grupos de 300 mensagens normalizadas), apenas os dados correspondentes à mensagem mais recente do dispositivo para essa Observação FHIR são persistentes.

Por exemplo:

Mensagem do dispositivo 1:

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

Mensagem do dispositivo 2:

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

Supondo que essas mensagens do dispositivo foram ingeridas dentro da mesma janela de cinco minutos ou no mesmo grupo de 300 mensagens normalizadas, e como a mesma é a mesma para ambas as mensagens do dispositivo (indicando que elas contêm dados para a mesma Observação FHIR), apenas a measurementdatetime mensagem do dispositivo 2 é persistida para representar os dados mais recentes/mais recentes.

Persistir

Persistir é a etapa final onde as Observações FHIR do estágio de transformação são persistidas no serviço FHIR. Se a Observação FHIR é nova, é criada no serviço FHIR. Se a Observação FHIR já existia, ela é atualizada no serviço FHIR. O serviço FHIR usa a identidade gerenciada atribuída pelo sistema do serviço MedTech e o controle de acesso baseado em recursos do Azure (Azure RBAC) para acesso seguro ao serviço FHIR.

Próximos passos

Escolha um método de implantação para o serviço MedTech

Visão geral do mapeamento de dispositivos de serviço MedTech

Visão geral do mapeamento de destino FHIR do serviço MedTech

Visão geral dos exemplos de mapeamentos baseados em cenários do serviço MedTech

Nota

FHIR® é uma marca registada da HL7 e é utilizada com a permissão da HL7 .