Översikt över databearbetningsstegen för MedTech-tjänstens enhet

Artikel
11/08/2023

Den här artikeln innehåller en översikt över faserna för bearbetning av enhetsdata i MedTech-tjänsten. MedTech-tjänsten omvandlar enhetsdata till FHIR-observationer® för beständighet i FHIR-tjänsten.

Databehandlingen för MedTech-tjänstens enheter följer dessa steg och i den här ordningen:

Mata in
Normalisera – Enhetsmappning tillämpas.
Grupp – (valfritt)
Transformera – FHIR-målmappning tillämpas.
Kvarstår

Mata in

Inmatning är den första fasen där enhetsmeddelanden tas emot från en Azure Event Hubs-händelsehubb och omedelbart hämtas till MedTech-tjänsten. Event Hubs-tjänsten stöder hög skala och dataflöde med möjlighet att ta emot och bearbeta miljontals enhetsmeddelanden per sekund. Det gör också att MedTech-tjänsten kan använda enhetsmeddelanden asynkront, vilket tar bort behovet av att enheter väntar medan enhetsmeddelanden bearbetas. MedTech-tjänstens systemtilldelade hanterade identitet och Azure-resursbaserad åtkomstkontroll (Azure RBAC) används för säker åtkomst till händelsehubben.

Kommentar

JSON är det enda format som stöds just nu för enhetsmeddelandedata.

Viktigt!

Om du ska tillåta åtkomst från flera tjänster till händelsehubben måste varje tjänst ha en egen konsumentgrupp för händelsehubben.

Konsumentgrupper gör det möjligt för flera förbrukande program att ha en separat vy över händelseströmmen och att läsa strömmen oberoende av varandra i sin egen takt och med sina egna förskjutningar. Mer information finns i Konsumentgrupper.

Exempel:

Två MedTech-tjänster som har åtkomst till samma händelsehubb.
En MedTech-tjänst och ett program för lagringsskrivare som kommer åt samma händelsehubb.

Normalisera

Normalisera är nästa steg där enhetsdata bearbetas med hjälp av användarvald/användarskapad överensstämmelse och giltig enhetsmappning. Den här mappningsprocessen resulterar i att enhetsdata omvandlas till ett normaliserat schema. Normaliseringsprocessen förenklar inte bara bearbetningen av enhetsdata i senare skeden, utan ger också möjlighet att projicera ett enhetsmeddelande i flera normaliserade meddelanden. Till exempel kan en enhet skicka flera viktiga tecken för kroppstemperatur, pulsfrekvens, blodtryck och andningshastighet i ett enda enhetsmeddelande. Det här enhetsmeddelandet skulle skapa fyra separata FHIR-observationer. Varje FHIR-observation skulle representera ett annat viktigt tecken, där enhetsmeddelandet projiceras i fyra olika normaliserade meddelanden.

Grupp – (valfritt)

Grupp är nästa valfria steg där de normaliserade meddelanden som är tillgängliga från Normaliseringssteget för MedTech-tjänsten grupperas med tre olika parametrar:

Enhetsidentitet
Measurement type
Tidsperiod

Gruppering av enhetsidentitet och måtttyp är valfria och aktiverade med hjälp av måtttypen SampledData . Måtttypen SampledData ger ett kortfattat sätt att representera en tidsbaserad serie mått från ett enhetsmeddelande till FHIR-observationer. När du använder måtttypen SampledData kan mätningar grupperas i en enda FHIR-observation som representerar en 1-timmars period eller en 24-timmarsperiod.

Transformering

Transformering är nästa steg där normaliserade meddelanden bearbetas med hjälp av användarvald/användarskapad överensstämmelse och giltig FHIR-målmappning. Normaliserade meddelanden omvandlas till FHIR-observationer om en matchande FHIR-målmappning har skapats. Nu hämtas även enhetsresursen, tillsammans med dess associerade patientresurs, från FHIR-tjänsten med hjälp av enhetsidentifieraren som finns i enhetsmeddelandet. Dessa resurser läggs till som en referens till FHIR-observationen som skapas.

Kommentar

Alla identitetssökningar cachelagras när de har lösts för att minska belastningen på FHIR-tjänsten. Om du planerar att återanvända enheter med flera patienter rekommenderar vi att du skapar en virtuell enhetsresurs som är specifik för patienten och skickar den virtuella enhetsidentifieraren i nyttolasten för enhetsmeddelandet. Den virtuella enheten kan länkas till den faktiska enhetsresursen som överordnad.

Om det inte finns någon enhetsresurs för en viss enhetsidentifierare i FHIR-tjänsten beror resultatet på värdet för lösningstypen som angavs vid tidpunkten för MedTech-tjänstdistributionen. När det är inställt på Sökning ignoreras det specifika meddelandet och pipelinen fortsätter att bearbeta andra inkommande enhetsmeddelanden. Om värdet är Skapa skapar MedTech-tjänsten minimala enhets- och patientresurser i FHIR-tjänsten.

Kommentar

Lösningstypen kan också justeras efter distributionen av MedTech-tjänsten om en annan lösningstyp krävs senare.

MedTech-tjänsten tillhandahåller bearbetning i nära realtid och försöker även minska antalet begäranden som görs till FHIR-tjänsten genom att gruppera begäranden i batchar med 300 normaliserade meddelanden. Om det finns en låg mängd data och 300 normaliserade meddelanden inte har lagts till i gruppen sparas motsvarande FHIR-observationer i gruppen i FHIR-tjänsten efter ungefär fem minuter.

Kommentar

När flera enhetsmeddelanden innehåller data för samma FHIR-observation, har samma tidsstämpel och skickas inom samma enhetsmeddelandebatch (till exempel inom femminutersfönstret eller i grupper med 300 normaliserade meddelanden) sparas endast de data som motsvarar det senaste enhetsmeddelandet för FHIR-observationen.

Till exempel:

Enhetsmeddelande 1:

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

Enhetsmeddelande 2:

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

Förutsatt att dessa enhetsmeddelanden matades in inom samma femminutersfönster eller i samma grupp med 300 normaliserade meddelanden, och eftersom measurementdatetime är samma för båda enhetsmeddelandena (som anger att dessa innehåller data för samma FHIR-observation), sparas endast enhetsmeddelande 2 för att representera de senaste/senaste data.

Kvarstår

Persist är det sista steget där FHIR-observationer från transformeringssteget sparas i FHIR-tjänsten. Om FHIR-observationen är ny skapas den i FHIR-tjänsten. Om FHIR-observationen redan finns uppdateras den i FHIR-tjänsten. FHIR-tjänsten använder MedTech-tjänstens systemtilldelade hanterade identitet och Azure-resursbaserad åtkomstkontroll (Azure RBAC) för säker åtkomst till FHIR-tjänsten.