Come usare i modelli CalculatedContent con il mapping dei dispositivi del servizio MedTech
Nota
Fast Healthcare Interoperability Resources (FHIR®) è una specifica sanitaria aperta.
Questo articolo offre una panoramica dell'uso dei modelli CalculatedContent all'interno di un mapping dei dispositivi di servizio MedTech.
Nozioni di base sul modello CalculatedContent
I modelli Calcolaticontent del servizio MedTech supportano due linguaggi di espressione JSON: JSONPath e JMESPath. Le espressioni vengono usate per identificare il modello da usare con un determinato messaggio di dispositivo JSON (ad esempio TypeMatchExpression) e per estrarre valori specifici necessari per creare un messaggio normalizzato, ad esempio TimestampExpression, DeviceIdExpression e così via.
Nota
Se non si definisce un linguaggio di espressione, i modelli di mapping dei dispositivi del servizio MedTech usano il linguaggio di espressione predefinito configurato per il modello. Il valore predefinito è JSONPath, ma è possibile sovrascriverlo se necessario.
Un'espressione è definita come:
<name of expression> : {
"value" : <the expression>,
"language": <the expression language>
}
Nell'esempio seguente viene typeMatchExpression definito come:
"templateType": "CalculatedContent",
"template": {
"typeName": "heartrate",
"typeMatchExpression": {
"value" : "$..[?(@heartRate)]",
"language": "JsonPath"
},
...
}
I modelli CalculatedContent consentono la corrispondenza sui valori e l'estrazione di valori da un messaggio del dispositivo letti da un hub eventi di Hub eventi di Azure tramite le espressioni seguenti:
| Elemento | Descrizione | Esempio di espressione JSONPath | Esempio di espressione JMESPath |
|---|---|---|---|
| typeMatchExpression | Espressione valutata dal servizio MedTech rispetto al payload del messaggio del dispositivo. Se il servizio trova un valore di token corrispondente, considera il modello una corrispondenza. Il servizio valuta tutte le espressioni successive rispetto al valore del token estratto corrispondente qui. | $..[?(@heartRate)] |
[Body][?contains(keys(@), `heartRate`)] \| @[0] |
| deviceIdExpression | Espressione da estrarre l'identificatore del dispositivo. | $.matchedToken.deviceId |
@.matchedToken.deviceId |
| timestampExpression | Espressione per estrarre il valore timestamp per il valore della OccurrenceTimeUtc misura. |
$.matchedToken.endDate |
@.matchedToken.endDate |
| patientIdExpression | Espressione da estrarre l'identificatore del paziente. Obbligatorio quando il tipo di risoluzione dei servizi MedTech è impostato su Crea e facoltativo quando il tipo di risoluzione del servizio MedTech è impostato su Ricerca. | $.matchedToken.patientId |
@.matchedToken.patientId |
| encounterIdExpression | Facoltativo: espressione per estrarre l'identificatore di incontro. | $.matchedToken.encounterId |
@.matchedToken.encounterId |
| correlationIdExpression | Facoltativo: espressione per estrarre l'identificatore di correlazione. È possibile usare questo output per raggruppare i valori in una singola osservazione nel mapping di destinazione FHIR. | $.matchedToken.correlationId |
@.matchedToken.correlationId |
| valori[].valueExpression | Espressione da estrarre il valore desiderato. | $.matchedToken.heartRate |
@.matchedToken.heartRate |
Nota
Il tipo Di risoluzione specifica in che modo il servizio MedTech associa i dati del dispositivo alle risorse del dispositivo e alle risorse del paziente. Il servizio MedTech legge le risorse dispositivo e paziente dal servizio FHIR usando identificatori di dispositivo e identificatori dei pazienti. Se un identificatore di verifica viene specificato ed estratto dal payload dei dati del dispositivo, viene collegato all'osservazione se esiste un incontro nel servizio FHIR con tale identificatore. Se l'identificatore di verifica è stato normalizzato correttamente, ma non esiste un'eccezione FHIR Encounter con tale identificatore, viene generata un'eccezione FhirResourceNotFound . Per altre informazioni sulla configurazione del tipo di risoluzione del servizio MedTech, vedere Configurare la scheda Destinazione.
Linguaggi di espressione
Quando si specifica la lingua da usare per l'espressione, i valori seguenti sono validi:
| Linguaggio delle espressioni | Valore |
|---|---|
| JSONPath | JsonPath |
| JMESPath | JmesPath |
Poiché JSONPath è il linguaggio di espressione predefinito, non è necessario includere il linguaggio dell'espressione all'interno di un modello CalculatedContent.
"templateType": "CalculatedContent",
"template": {
"typeName": "heartrate",
"typeMatchExpression": "$..[?(@heartRate)]",
...
}
È anche possibile impostare in modo esplicito il linguaggio di espressione predefinito per un modello CalculatedContent usando il defaultExpressionLanguage parametro:
"templateType": "CalculatedContent",
"template": {
"typeName": "heartrate",
"defaultExpressionLanguage": "JmesPath",
"typeMatchExpression": "[Body][?contains(keys(@), `heartRate`)] | @[0]",
...
}
Suggerimento
Per altre informazioni su JSONPath, vedere JSONPath - XPath per JSON. I modelli CalculatedContent usano l'implementazione JSON .NET per la risoluzione delle espressioni JSONPath.
Per altre informazioni su JMESPath, vedere Specifica JMESPath. I modelli CalculatedContent usano l'implementazione JMESPath .NET per la risoluzione delle espressioni JMESPath.
Funzioni personalizzate
È disponibile anche un set di funzioni personalizzate per il servizio MedTech. Le funzioni personalizzate del servizio MedTech non sono incluse nelle funzioni fornite come parte della specifica JMESPath. Per altre informazioni sulle funzioni personalizzate del servizio MedTech, vedere Come usare funzioni personalizzate con il mapping dei dispositivi del servizio MedTech.
Esempio
Quando il servizio MedTech elabora un messaggio di dispositivo, i modelli in CollectionContent vengono usati per valutare il messaggio. Viene typeMatchExpression usato per determinare se il modello deve essere usato per creare un messaggio normalizzato dal messaggio del dispositivo. Se restituisce typeMatchExpression true, i deviceIdExpressionvalori , timestampExpressione valueExpression vengono usati per individuare ed estrarre i valori JSON dal messaggio del dispositivo e creare un messaggio normalizzato. In questo esempio tutte le espressioni vengono scritte in JSONPath, ma sarebbe valido scrivere tutte le espressioni in JMESPath. Si tratta dell'autore del modello per determinare quale linguaggio delle espressioni è più appropriato.
Suggerimento
È possibile usare il debugger di mapping dei servizi MedTech per assistenza per la creazione, l'aggiornamento e la risoluzione dei problemi relativi ai mapping di destinazione del servizio MedTech e FHIR. Il debugger mapping consente di visualizzare e apportare facilmente modifiche inline in tempo reale, senza mai dover lasciare l'portale di Azure. Il debugger di mapping può essere usato anche per caricare i messaggi del dispositivo di test per vedere come verranno elaborati in messaggi normalizzati e trasformati in osservazioni FHIR.
In questo esempio viene usato un messaggio del dispositivo che acquisisce heartRate i dati:
{
"heartRate": "78",
"endDate": "2023-03-13T22:46:01.8750000",
"deviceId": "device01"
}
L'hub eventi arricchisce il messaggio del dispositivo prima che il servizio MedTech legge il messaggio del dispositivo dall'hub eventi:
{
"Body": {
"heartRate": "78",
"endDate": "2023-03-13T22:46:01.8750000",
"deviceId": "device01"
}
}
Questo mapping dei dispositivi viene usato per la fase di normalizzazione:
{
"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
Il servizio MedTech restituisce typeMatchExpression il payload dei dati del dispositivo in ingresso. Se il servizio trova un valore di token corrispondente, considera il modello una corrispondenza.
Il servizio MedTech valuta tutte le espressioni successive rispetto a un nuovo valore di token. Questo nuovo valore del token contiene sia il payload dei dati del dispositivo originale che il valore del token estratto corrispondente qui.
In questo modo, il payload dei dati del dispositivo originale e l'oggetto corrispondente sono disponibili per ogni espressione successiva. Il valore del token estratto è disponibile come proprietà 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"
}
}
Il messaggio normalizzato risultante avrà un aspetto simile al seguente dopo la fase di normalizzazione:
[
{
"type": "heartrate",
"occurrenceTimeUtc": "2023-03-13T22:46:01.875Z",
"deviceId": "device01",
"properties": [
{
"name": "hr",
"value": "78"
}
]
}
]
Suggerimento
Per assistenza alla risoluzione degli errori di distribuzione del servizio MedTech, vedere Risolvere gli errori di distribuzione del servizio MedTech.
Per assistenza per la risoluzione degli errori del servizio MedTech, vedere Risolvere gli errori usando i log del servizio MedTech.
Passaggi successivi
In questo articolo si è appreso come usare i modelli CalculatedContent con il mapping dei dispositivi del servizio MedTech.
Per informazioni su come usare le funzioni personalizzate del servizio MedTech, vedere
Per una panoramica del mapping di destinazione del servizio MedTech FHIR, vedere
Per una panoramica degli esempi di mapping basati su scenari di servizio MedTech, vedere
FHIR® è un marchio registrato di Health Level Seven International, registrato in U.S. Trademark Office e viene usato con l'autorizzazione.