Panoramica delle fasi di elaborazione dei dati dei dispositivi del servizio MedTech

Questo articolo offre una panoramica delle fasi di elaborazione dei dati del dispositivo all'interno del servizio MedTech. Il servizio MedTech trasforma i dati del dispositivo in osservazioni FHIR® per la persistenza nel servizio FHIR.

L'elaborazione dei dati dei dispositivi del servizio MedTech segue queste fasi e in questo ordine:

• Inserimento
• Normalize - Mapping del dispositivo applicato.
• Gruppo - (facoltativo)
• Transform - Mapping di destinazione FHIR applicato.
• Persist

Inserimento

L'inserimento è la prima fase in cui i messaggi del dispositivo vengono ricevuti da un hub eventi Hub eventi di Azure e immediatamente inseriti nel servizio MedTech. Il servizio Hub eventi supporta scalabilità elevata e velocità effettiva con la possibilità di ricevere ed elaborare milioni di messaggi del dispositivo al secondo. Consente inoltre al servizio MedTech di utilizzare i messaggi del dispositivo in modo asincrono, rimuovendo la necessità di attendere i dispositivi durante l'elaborazione dei messaggi del dispositivo. L'identità gestita assegnata dal servizio MedTech e il controllo degli accessi in base alle risorse di Azure vengono usati per l'accesso sicuro all'hub eventi.

Nota

JSON è l'unico formato supportato in questo momento per i dati dei messaggi del dispositivo.

Importante

Se si vuole consentire l'accesso da più servizi all'hub eventi, è necessario che ogni servizio abbia un proprio gruppo di consumer dell'hub eventi.

I gruppi di consumer consentono a più applicazioni che utilizzano di avere una visualizzazione separata del flusso di eventi e di leggere il flusso in modo indipendente al proprio ritmo e con i propri offset. Per altre informazioni, vedere Gruppi di consumer.

Esempi:

• Due servizi MedTech che accedono allo stesso hub eventi.

• Un servizio MedTech e un'applicazione writer di archiviazione che accedono allo stesso hub eventi.

Normalizza

Normalize è la fase successiva in cui i dati del dispositivo vengono elaborati usando il mapping dei dispositivi conforme e valido creato dall'utente/selezionato dall'utente. Questo processo di mapping comporta la trasformazione dei dati del dispositivo in uno schema normalizzato. Il processo di normalizzazione non solo semplifica l'elaborazione dei dati dei dispositivi in fasi successive, ma offre anche la possibilità di proiettare un messaggio del dispositivo in più messaggi normalizzati. Ad esempio, un dispositivo potrebbe inviare più segni vitali per la temperatura corporea, la frequenza degli impulsi, la pressione sanguigna e la frequenza di respirazione in un singolo messaggio del dispositivo. Questo messaggio del dispositivo creerebbe quattro osservazioni FHIR separate. Ogni osservazione FHIR rappresenta un segno vitale diverso, con il messaggio del dispositivo proiettato in quattro diversi messaggi normalizzati.

Gruppo - (facoltativo)

Il gruppo è la fase facoltativa successiva in cui i messaggi normalizzati disponibili nella fase di normalizzazione del servizio MedTech vengono raggruppati usando tre parametri diversi:

• Identità del dispositivo
• Measurement type
• Periodo di tempo

L'identità del dispositivo e il raggruppamento dei tipi di misura sono facoltativi e abilitati dall'uso del tipo di misura SampledData . Il tipo di misurazione SampledData fornisce un modo conciso per rappresentare una serie temporale di misurazioni da un messaggio del dispositivo in osservazioni FHIR. Quando si usa il tipo di misura SampledData, le misurazioni possono essere raggruppate in una singola osservazione FHIR che rappresenta un periodo di 1 ora o un periodo di 24 ore.

Trasformazione

Transform è la fase successiva in cui i messaggi normalizzati vengono elaborati usando il mapping di destinazione FHIR conforme e valido creato dall'utente/selezionato dall'utente. I messaggi normalizzati vengono trasformati in osservazioni FHIR se è stato creato un mapping di destinazione FHIR corrispondente. A questo punto, la risorsa Dispositivo, insieme alla risorsa Paziente associata, viene recuperata anche dal servizio FHIR usando l'identificatore del dispositivo presente nel messaggio del dispositivo. Queste risorse vengono aggiunte come riferimento all'osservazione FHIR creata.

Nota

Tutte le ricerche di identità vengono memorizzate nella cache una volta risolte per ridurre il carico nel servizio FHIR. Se si prevede di riutilizzare i dispositivi con più pazienti, è consigliabile creare una risorsa dispositivo virtuale specifica per il paziente e inviare l'identificatore del dispositivo virtuale nel payload del messaggio del dispositivo. Il dispositivo virtuale può essere collegato alla risorsa dispositivo effettiva come elemento padre.

Se nel servizio FHIR non esiste alcuna risorsa dispositivo per un determinato identificatore di dispositivo, il risultato dipende dal valore di Tipo di risoluzione impostato al momento della distribuzione del servizio MedTech. Se impostato su Ricerca, il messaggio specifico viene ignorato e la pipeline continua a elaborare altri messaggi del dispositivo in ingresso. Se impostato su Crea, il servizio MedTech crea risorse minime per dispositivi e pazienti nel servizio FHIR.

Nota

Il tipo di risoluzione può anche essere regolato dopo la distribuzione del servizio MedTech se è necessario un tipo di risoluzione diverso.

Il servizio MedTech fornisce un'elaborazione quasi in tempo reale e tenta anche di ridurre il numero di richieste effettuate al servizio FHIR raggruppando le richieste in batch di 300 messaggi normalizzati. Se è presente un volume ridotto di dati e 300 messaggi normalizzati non sono stati aggiunti al gruppo, le osservazioni FHIR corrispondenti in tale gruppo vengono mantenute nel servizio FHIR dopo circa cinque minuti.

Nota

Quando più messaggi del dispositivo contengono dati per la stessa osservazione FHIR, hanno lo stesso timestamp e vengono inviati all'interno dello stesso batch di messaggi del dispositivo (ad esempio, entro la finestra di cinque minuti o in gruppi di 300 messaggi normalizzati), solo i dati corrispondenti al messaggio del dispositivo più recente per l'osservazione FHIR sono persistenti.

Ad esempio:

Messaggio dispositivo 1:

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

Messaggio dispositivo 2:

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

Supponendo che questi messaggi del dispositivo siano stati inseriti nella stessa finestra di cinque minuti o nello stesso gruppo di 300 messaggi normalizzati e poiché measurementdatetime è lo stesso per entrambi i messaggi del dispositivo (che indicano che contengono dati per la stessa osservazione FHIR), solo il messaggio del dispositivo 2 viene salvato in modo permanente per rappresentare i dati più recenti o più recenti.

Persist

Persist è la fase finale in cui le osservazioni FHIR dalla fase di trasformazione vengono rese persistenti nel servizio FHIR. Se l'osservazione FHIR è nuova, viene creata nel servizio FHIR. Se l'osservazione FHIR esiste già, viene aggiornata nel servizio FHIR. Il servizio FHIR usa l'identità gestita assegnata dal sistema del servizio MedTech e il controllo degli accessi in base alle risorse di Azure per l'accesso sicuro al servizio FHIR.

Passaggi successivi

Scegliere un metodo di distribuzione per il servizio MedTech

Panoramica del mapping dei dispositivi del servizio MedTech

Panoramica del mapping di destinazione FHIR del servizio MedTech

Panoramica degli esempi di mapping basati su scenari del servizio MedTech

Nota

FHIR® è un marchio registrato di HL7 e viene usato con l'autorizzazione di HL7.