Como utilizar modelos CalculatedContent com o mapeamento de dispositivos do serviço MedTech
Nota
Fast Healthcare Interoperability Resources (FHIR®) é uma especificação de cuidados de saúde aberta.
Este artigo fornece uma descrição geral de como utilizar modelos CalculatedContent num mapeamento de dispositivos do serviço MedTech.
Noções básicas do modelo CalculatedContent
Os modelos CalculatedContent do serviço MedTech suportam duas linguagens de expressão JSON: JSONPath e JMESPath. As expressões são utilizadas para identificar que modelo utilizar com uma determinada mensagem de dispositivo JSON (por exemplo: TypeMatchExpression) e para extrair valores específicos necessários para criar uma mensagem normalizada (por exemplo: TimestampExpression, DeviceIdExpression, etc.).
Nota
Se não definir uma linguagem de expressão, os modelos de mapeamento de dispositivos do serviço MedTech utilizam a linguagem de expressão predefinida configurada para o modelo. A predefinição é JSONPath, mas pode substituí-lo, se necessário.
Uma expressão é definida como:
<name of expression> : {
"value" : <the expression>,
"language": <the expression language>
}
No exemplo seguinte, typeMatchExpression é definido como:
"templateType": "CalculatedContent",
"template": {
"typeName": "heartrate",
"typeMatchExpression": {
"value" : "$..[?(@heartRate)]",
"language": "JsonPath"
},
...
}
Os modelos CalculatedContent permitem a correspondência e a extração de valores de uma mensagem de dispositivo lida a partir de um hub de eventos Hubs de Eventos do Azure através das seguintes expressões:
| Elemento | Descrição | Exemplo de expressão JSONPath | Exemplo de expressão JMESPath |
|---|---|---|---|
| typeMatchExpression | A expressão que o serviço MedTech avalia em relação ao payload da mensagem do dispositivo. Se o serviço encontrar um valor de token correspondente, considera o modelo uma correspondência. O serviço avalia todas as expressões posteriores relativamente ao valor do token extraído correspondente aqui. | $..[?(@heartRate)] |
[Body][?contains(keys(@), `heartRate`)] \| @[0] |
| deviceIdExpression | A expressão para extrair o identificador do dispositivo. | $.matchedToken.deviceId |
@.matchedToken.deviceId |
| timestampExpression | A expressão para extrair o valor de carimbo de data/hora para o valor da OccurrenceTimeUtc medida. |
$.matchedToken.endDate |
@.matchedToken.endDate |
| patientIdExpression | A expressão para extrair o identificador do paciente. Necessário quando o tipo de Resolução dos serviços MedTech está definido como Criar e opcional quando o tipo de Resolução do serviço MedTech está definido como Pesquisa. | $.matchedToken.patientId |
@.matchedToken.patientId |
| encounterIdExpression | Opcional: a expressão para extrair o identificador de encontro. | $.matchedToken.encounterId |
@.matchedToken.encounterId |
| correlationIdExpression | Opcional: a expressão para extrair o identificador de correlação. Pode utilizar esta saída para agrupar valores numa única observação no mapeamento de destino FHIR. | $.matchedToken.correlationId |
@.matchedToken.correlationId |
| values[].valueExpression | A expressão para extrair o valor pretendido. | $.matchedToken.heartRate |
@.matchedToken.heartRate |
Nota
O tipo de Resolução especifica a forma como o serviço MedTech associa os dados do dispositivo aos recursos do Dispositivo e aos recursos do Paciente. O serviço MedTech lê os recursos dispositivo e paciente do serviço FHIR com identificadores de dispositivos e identificadores de pacientes. Se for especificado um identificador de encontro e extraído do payload de dados do dispositivo, este será associado à observação se existir um encontro no serviço FHIR com esse identificador. Se o identificador de encontro for normalizado com êxito, mas não existir nenhum Encontro FHIR com esse identificador de encontro, é emitida uma exceção FhirResourceNotFound . Para obter mais informações sobre como configurar o tipo de Resolução do serviço MedTech, veja Configurar o separador Destino.
Linguagens de expressão
Ao especificar o idioma a utilizar para a expressão, os seguintes valores são válidos:
| Expressão de idioma | Valor |
|---|---|
| JSONPath | JsonPath |
| JMESPath | JmesPath |
Uma vez que JSONPath é a linguagem de expressão predefinida, não é necessário incluir a linguagem de expressão num modelo CalculatedContent.
"templateType": "CalculatedContent",
"template": {
"typeName": "heartrate",
"typeMatchExpression": "$..[?(@heartRate)]",
...
}
Também pode definir explicitamente a linguagem de expressão predefinida para um modelo CalculatedContent com o defaultExpressionLanguage parâmetro :
"templateType": "CalculatedContent",
"template": {
"typeName": "heartrate",
"defaultExpressionLanguage": "JmesPath",
"typeMatchExpression": "[Body][?contains(keys(@), `heartRate`)] | @[0]",
...
}
Dica
Para obter mais informações sobre JSONPath, veja JSONPath – XPath para JSON. Os modelos CalculatedContent utilizam a implementação JSON .NET para resolver expressões JSONPath.
Para obter mais informações sobre jMESPath, veja JMESPath Specification (Especificação do JMESPath). Os modelos CalculatedContent utilizam a implementação JMESPath .NET para resolver expressões JMESPath.
Funções personalizadas
Também está disponível um conjunto de funções personalizadas para o serviço MedTech. As funções personalizadas do serviço MedTech estão fora das funções fornecidas como parte da especificação JMESPath. Para obter mais informações sobre as funções personalizadas do serviço MedTech, veja Como utilizar funções personalizadas com o mapeamento de dispositivos do serviço MedTech.
Exemplo
Quando o serviço MedTech está a processar uma mensagem de dispositivo, os modelos no CollectionContent são utilizados para avaliar a mensagem. O typeMatchExpression é utilizado para determinar se o modelo deve ou não ser utilizado para criar uma mensagem normalizada a partir da mensagem do dispositivo. Se a typeMatchExpression avaliação for verdadeira, os deviceIdExpressionvalores , timestampExpressione valueExpression são utilizados para localizar e extrair os valores JSON da mensagem do dispositivo e criar uma mensagem normalizada. Neste exemplo, todas as expressões são escritas no JSONPath. No entanto, seria válido escrever todas as expressões no JMESPath. Cabe ao autor do modelo determinar qual a linguagem de expressão mais adequada.
Dica
Pode utilizar o depurador de Mapeamento do serviço MedTech para obter assistência na criação, atualização e resolução de problemas do dispositivo de serviço MedTech e mapeamentos de destino FHIR. O depurador mapeamento permite-lhe ver e fazer ajustes inline facilmente em tempo real, sem nunca ter de sair do portal do Azure. O depurador de Mapeamento também pode ser utilizado para carregar mensagens de dispositivos de teste para ver como serão processadas em mensagens normalizadas e transformadas em Observações FHIR.
Neste exemplo, estamos a utilizar uma mensagem de dispositivo que está a heartRate capturar dados:
{
"heartRate": "78",
"endDate": "2023-03-13T22:46:01.8750000",
"deviceId": "device01"
}
O hub de eventos enriquece a mensagem do dispositivo antes de o serviço MedTech ler a mensagem do dispositivo a partir do hub de eventos:
{
"Body": {
"heartRate": "78",
"endDate": "2023-03-13T22:46:01.8750000",
"deviceId": "device01"
}
}
Estamos a utilizar este mapeamento de dispositivos para a fase de normalização:
{
"templateType": "CollectionContent",
"template": [
{
"templateType": "CalculatedContent",
"template": {
"typeName": "heartrate",
"typeMatchExpression": "$..[?(@heartRate)]",
"deviceIdExpression": "$.matchedToken.deviceId",
"timestampExpression": "$.matchedToken.endDate",
"values": [
{
"required": true,
"valueExpression": "$.matchedToken.heartRate",
"valueName": "hr"
}
]
}
}
]
}
Importante
O serviço MedTech é avaliado typeMatchExpression em relação ao payload de dados do dispositivo recebido. Se o serviço encontrar um valor de token correspondente, considera o modelo uma correspondência.
O serviço MedTech avalia todas as expressões posteriores relativamente a um novo valor de token. Este novo valor de token contém o payload de dados do dispositivo original e o valor do token extraído correspondido aqui.
Desta forma, o payload de dados do dispositivo original e o objeto correspondente estão disponíveis para cada expressão posterior. O valor do token extraído está disponível como a propriedade matchedToken.
{
"Body": {
"heartRate": "78",
"endDate": "2023-03-13T22:46:01.8750000",
"deviceId": "device01"
},
"matchedToken": {
"heartRate": "78",
"endDate": "2023-03-13T22:46:01.8750000",
"deviceId": "device01"
}
}
A mensagem normalizada resultante terá o seguinte aspeto após a fase de normalização:
[
{
"type": "heartrate",
"occurrenceTimeUtc": "2023-03-13T22:46:01.875Z",
"deviceId": "device01",
"properties": [
{
"name": "hr",
"value": "78"
}
]
}
]
Dica
Para obter assistência para resolver erros de implementação do serviço MedTech, veja Resolver erros de implementação do serviço MedTech.
Para obter assistência para resolver erros do serviço MedTech, veja Resolver erros com os registos do serviço MedTech.
Passos seguintes
Neste artigo, aprendeu a utilizar modelos CalculatedContent com o mapeamento de dispositivos do serviço MedTech.
Para saber como utilizar as funções personalizadas do serviço MedTech, consulte
Para obter uma descrição geral do mapeamento de destino FHIR do serviço MedTech, veja
Para obter uma descrição geral dos exemplos de mapeamentos baseados em cenários do serviço MedTech, veja
FHIR® é uma marca registada da Health Level Seven International, registada no Escritório de Marcas Registadas dos EUA, e é utilizada com permissão.
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários