Übersicht über die Datenverarbeitungsphasen des Medizintechnikdienstgeräts

Artikel
11/20/2023

Dieser Artikel enthält eine Übersicht über die Gerätedatenverarbeitungsphasen innerhalb des Medizintechnikdiensts. Der Medizintechnikdienst transformiert Gerätedaten in FHIR®-Beobachtungen zur Persistenz im FHIR-Dienst.

Die Datenverarbeitung von Medizintechnikdiensten folgt den folgenden Phasen und in dieser Reihenfolge:

Erfassen
Normalisieren – Angewendete Gerätezuordnung.
Gruppe - (Optional)
Transformation : Angewendete FHIR-Zielzuordnung.
Persist

Erfassen

Bei der Erfassung handelt es sich um die erste Phase, in der Gerätenachrichten von einem Azure Event Hubs-Event Hub empfangen und sofort in den Medizintechnikdienst übertragen werden. Der Event Hubs-Dienst unterstützt hohen einen Maßstab und Durchsatz mit der Möglichkeit, Millionen von Gerätenachrichten pro Sekunde zu empfangen und zu verarbeiten. Außerdem ermöglicht es dem Medizintechnikdienst, Gerätenachrichten asynchron zu nutzen und die Notwendigkeit zu entfernen, dass Geräte warten müssen, während Gerätenachrichten verarbeitet werden. Die vom Medizintechnikdienst vom System zugewiesene verwaltete Identität und die ressourcenbasierte Azure-Zugriffssteuerung (Azure RBAC) werden für den sicheren Zugriff auf den Event Hub verwendet.

Hinweis

Derzeit wird JSON als einziges Format für die Gerätenachrichtendaten unterstützt.

Wichtig

Wenn Sie den Zugriff von mehreren Diensten auf den Event Hub zulassen möchten, ist es erforderlich, dass jeder Dienst über eine eigene Event Hub-Consumergruppe verfügt.

Mithilfe von Consumergruppen können mehrere verarbeitende Anwendungen eine separate Ansicht des Ereignisdatenstroms aufweisen und den Datenstrom unabhängig voneinander in einem unabhängigen Tempo und mit eigenen Offsets lesen. Weitere Informationen finden Sie unter Consumergruppen.

Beispiele:

Zwei Medizintechnikdienste, die auf denselben Event Hub zugreifen.
Ein Medizintechnikdienst und eine Storage Writer-Anwendung, die auf denselben Event Hub zugreift.

Normalisieren

Normalisieren ist die nächste Phase, in der Gerätedaten mithilfe der vom Benutzer ausgewählten/vom Benutzer erstellten konformen und gültigen Gerätezuordnung verarbeitet werden. Dieser Zuordnungsprozess führt zur Transformation der Gerätedaten in ein normalisiertes Schema. Der Normalisierungsprozess vereinfacht nicht nur die Gerätedatenverarbeitung in späteren Phasen, sondern bietet auch die Möglichkeit, eine Gerätenachricht in mehrere normalisierte Nachrichten zu projizieren. Ein Gerät kann beispielsweise mehrere Vitalparameter für Körpertemperatur, Pulsfrequenz, Blutdruck und Atemfrequenz in einer einzelnen Gerätenachricht senden. Diese Gerätenachricht würde vier separate FHIR-Beobachtungen erstellen. Jede FHIR-Beobachtung würde ein anderes vitales Zeichen darstellen, wobei die Gerätenachricht in vier verschiedene normalisierte Nachrichten projiziert wurde.

Gruppe - (Optional)

Gruppe ist die nächste optionale Phase, in der die normalisierten Nachrichten, die über die Normalisierungsphase des Medizintechnikdiensts verfügbar sind, mithilfe von drei verschiedenen Parametern gruppiert werden:

Geräteidentität
Art der Messung
Zeitraum

Geräteidentitäts- und Messtypgruppierung sind optional und durch die Verwendung des SampledData-Messtyps aktiviert. Dieser SampledData-Messtyp bietet eine übersichtliche Möglichkeit zur Darstellung einer zeitbasierten Messreihe von einer Gerätenachricht in FHIR-Beobachtungen. Wenn Sie den SampledData-Messtyp verwenden, können Messungen in eine einzelne FHIR-Beobachtung gruppiert werden, die einen 1-Stunden-Zeitraum oder einen 24-Stunden-Zeitraum darstellt.

Transformieren

Transformation ist die nächste Phase, in der normalisierte Nachrichten mithilfe der vom Benutzer ausgewählten/vom Benutzer erstellten konformen und gültigen FHIR-Zielzuordnung verarbeitet werden. Normalisierte Nachrichten werden in FHIR-Beobachtungen transformiert, wenn eine entsprechende FHIR-Zielzuordnung erstellt wurde. An diesem Punkt wird die Device-Ressource zusammen mit der zugehörigen Patient-Ressource anhand des in der Gerätenachricht vorhandenen Gerätebezeichners auch vom FHIR-Dienst abgerufen. Diese Ressourcen werden als Verweis auf die zu erstellende FHIR-Beobachtung hinzugefügt.

Hinweis

Alle Identitätssuchen werden nach der Auflösung zwischengespeichert, um die Auslastung des FHIR-Diensts zu verringern. Wenn Sie Geräte für mehrere Patienten wiederverwenden möchten, empfiehlt es sich, eine für den Patienten spezifische virtuelle Geräteressource zu erstellen und den Bezeichner des virtuellen Geräts in der Gerätenachrichtennutzlast zu senden. Das virtuelle Gerät kann als übergeordnetes Element mit der tatsächlichen Geräteressource verknüpft werden.

Wenn keine Geräteressource für einen bestimmten Gerätebezeichner im FHIR-Dienst vorhanden ist, hängt das Ergebnis vom Wert des Auflösungstyps ab, der zum Zeitpunkt der Bereitstellung des Medizintechnikdiensts festgelegt wurde. Wenn die Einstellung auf den Wert Lookup festgelegt ist, wird die betreffende Nachricht ignoriert. Die Pipeline verarbeitet weiterhin andere eingehende Gerätenachrichten. Bei Festlegung auf Erstellen erstellt der Medizintechnikdienst minimale Geräte- und Patientenressourcen im FHIR-Dienst.

Hinweis

Der Auflösungstyp kann auch nach der Bereitstellung des Medizintechnikdiensts angepasst werden, wenn später ein anderer Auflösungstyp erforderlich ist.

Der Medizintechnikdienst bietet nahezu echtzeitbasierte Verarbeitung und versucht auch, die Anzahl der Anforderungen an den FHIR-Dienst zu reduzieren, indem Anforderungen in Batches von 300 normalisierten Nachrichten gruppiert werden. Wenn eine geringe Menge an Daten vorhanden ist und 300 normalisierte Nachrichten nicht zur Gruppe hinzugefügt wurden, werden die entsprechenden FHIR-Beobachtungen in dieser Gruppe nach ungefähr fünf Minuten im persistent im FHIR-Dienst gespeichert.

Hinweis

Wenn mehrere Gerätenachrichten Daten für dieselbe FHIR-Beobachtung enthalten, denselben Zeitstempel aufweisen und innerhalb desselben Gerätenachrichtenbatches gesendet werden (z. B. innerhalb des fünfminütigen Fensters oder in Gruppen von 300 normalisierten Nachrichten), werden nur die Daten, die der neuesten Gerätenachricht für diese FHIR-Beobachtung entsprechen, beibehalten.

Beispiel:

Gerätenachricht 1:

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

Gerätenachricht 2:

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

Angenommen, diese Gerätenachrichten wurden innerhalb desselben fünfMinütigen Fensters oder in derselben Gruppe von 300 normalisierten Nachrichten aufgenommen, und da die measurementdatetime für beide Gerätenachrichten (die angibt, dass diese Daten für dieselbe FHIR-Beobachtung enthalten) identisch ist, wird nur die Gerätenachricht 2 beibehalten, um die neuesten/aktuellsten Daten darzustellen.

Persist

Persistent speichern ist die letzte Phase, in der die FHIR-Beobachtungen aus der Transformationsphase im FHIR-Dienst persistent gespeichert werden. Wenn die FHIR-Beobachtung neu ist, wird sie im FHIR-Dienst erstellt. Wenn die FHIR-Beobachtung bereits vorhanden ist, wird sie im FHIR-Dienst aktualisiert. Der FHIR-Dienst verwendet die vom System zugewiesene verwaltete Identität des Medizintechnikdiensts und die ressourcenbasierte Azure-Zugriffssteuerung (Azure RBAC) für den sicheren Zugriff auf den FHIR-Dienst.