Vue d’ensemble des étapes de traitement des données des appareils medTech
Remarque
Fast Healthcare Interopérabilité Resources (FHIR®) est une spécification de santé ouverte.
Cet article fournit une vue d’ensemble des étapes de traitement des données des appareils au sein du service MedTech. Le service MedTech transforme les données d’appareil en observations FHIR pour la persistance dans le service FHIR.
Le traitement des données de l’appareil de service MedTech suit ces étapes et dans cet ordre :
- Ingérer
- Normaliser - Mappage d’appareil appliqué.
- Groupe - (facultatif)
- Transformation : mappage de destination FHIR appliqué.
- Persist
Ingérer
L’ingestion est la première étape où les messages d’appareil sont reçus d’un hub d’événements Azure Event Hubs et immédiatement extraits dans le service MedTech. Le service Event Hubs prend en charge la mise à l’échelle et le débit élevés avec la possibilité de recevoir et de traiter des millions de messages d’appareil par seconde. Il permet également au service MedTech de consommer des messages d’appareil de manière asynchrone, en supprimant la nécessité pour les appareils d’attendre pendant le traitement des messages de l’appareil. L’identité managée affectée par le système du service MedTech et le contrôle d’accès en fonction des ressources Azure (Azure RBAC) sont utilisés pour sécuriser l’accès au hub d’événements.
Remarque
JSON est le seul format pris en charge pour les données de message d’appareil.
Important
Si vous souhaitez autoriser l’accès à partir de plusieurs services au hub d’événements, il est nécessaire que chaque service dispose de son propre groupe de consommateurs Event Hub.
Les groupes de consommateurs permettent à plusieurs applications consommatrices d’avoir une vue distincte du flux d’événements et de lire le flux indépendamment à leur rythme et avec leurs propres décalages. Pour plus d’informations, consultez Groupes de consommateurs.
Exemples :
Deux services MedTech accédant au même hub d’événements.
Un service MedTech et une application enregistreur de stockage qui accèdent au même hub d’événements.
Normaliser
Normaliser est la phase suivante où les données d’appareil sont traitées à l’aide du mappage d’appareil conforme et valide créé par l’utilisateur/sélectionné par l’utilisateur. Ce processus de mappage entraîne une transformation des données d’appareils en un schéma normalisé. Le processus de normalisation simplifie non seulement le traitement des données des appareils à des étapes ultérieures, mais permet également de projeter un message d’appareil en plusieurs messages normalisés. Par exemple, un appareil peut envoyer plusieurs signes vitaux pour la température corporelle, la fréquence d’impulsions, la pression artérielle et la fréquence de respiration dans un seul message d’appareil. Ce message d’appareil créerait quatre observations FHIR distinctes. Chaque observation FHIR représenterait un signe vital différent, avec le message de l’appareil projeté en quatre messages normalisés différents.
Groupe - (facultatif)
Le groupe est la phase facultative suivante où les messages normalisés disponibles à partir de la phase de normalisation du service MedTech sont regroupés à l’aide de trois paramètres différents :
- Identité d’appareil
- Type de mesure
- Période
L’identité de l’appareil et le regroupement de types de mesure sont facultatifs et activés par l’utilisation du type de mesure SampledData . Le type de mesure SampledData fournit un moyen concis de représenter une série chronologique de mesures d’un message d’appareil en observations FHIR. Lorsque vous utilisez le type de mesure SampledData, les mesures peuvent être regroupées en une seule observation FHIR qui représente une période de 1 heure ou une période de 24 heures.
Transformation
La transformation est l’étape suivante où les messages normalisés sont traités à l’aide du mappage de destination FHIR conforme et valide créé par l’utilisateur/sélectionné par l’utilisateur. Les messages normalisés sont transformés en observations FHIR si un mappage de destination FHIR correspondant a été créé. À ce stade, la ressource Appareil, ainsi que sa ressource Patient associée, est également récupérée à partir du service FHIR à l’aide de l’identificateur d’appareil présent dans le message de l’appareil. Ces ressources sont ajoutées en tant que référence à l’observation FHIR en cours de création.
Remarque
Toutes les recherches d’identité sont mises en cache une fois résolues pour réduire la charge sur le service FHIR. Si vous envisagez de réutiliser des appareils avec plusieurs patients, il est recommandé de créer une ressource d’appareil virtuel spécifique au patient et d’envoyer l’identificateur d’appareil virtuel dans la charge utile du message de l’appareil. L’appareil virtuel peut être lié à la ressource appareil réelle en tant que parent.
Si aucune ressource d’appareil pour un identificateur d’appareil donné n’existe dans le service FHIR, le résultat dépend de la valeur du type de résolution défini au moment du déploiement du service MedTech. Lorsqu’il est défini sur Recherche, le message spécifique est ignoré et le pipeline continue de traiter d’autres messages d’appareil entrants. Si la valeur est Create, le service MedTech crée des ressources d’appareil et de patient minimales dans le service FHIR.
Remarque
Le type résolution peut également être ajusté après le déploiement du service MedTech si un autre type de résolution est ultérieurement requis.
Le service MedTech fournit un traitement en temps quasi réel et tente également de réduire le nombre de demandes adressées au service FHIR en regroupant les demandes en lots de 300 messages normalisés. S’il existe un faible volume de données et que 300 messages normalisés n’ont pas été ajoutés au groupe, les observations FHIR correspondantes dans ce groupe sont conservées dans le service FHIR après environ cinq minutes.
Remarque
Lorsque plusieurs messages d’appareil contiennent des données pour la même observation FHIR, ont le même horodatage et sont envoyés dans le même lot de messages d’appareil (par exemple, dans la fenêtre de cinq minutes ou dans des groupes de 300 messages normalisés), seules les données correspondant au dernier message d’appareil pour cette observation FHIR sont conservées.
Par exemple :
Message d’appareil 1 :
{
"patientid": "testpatient1",
"deviceid": "testdevice1",
"systolic": "129",
"diastolic": "65",
"measurementdatetime": "2022-02-15T04:00:00.000Z"
}
Message d’appareil 2 :
{
"patientid": "testpatient1",
"deviceid": "testdevice1",
"systolic": "113",
"diastolic": "58",
"measurementdatetime": "2022-02-15T04:00:00.000Z"
}
En supposant que ces messages d’appareil ont été ingérés dans la même fenêtre de cinq minutes ou dans le même groupe de 300 messages normalisés, et comme c’est measurementdatetime le même pour les deux messages d’appareil (indiquant ces données pour la même observation FHIR), seul le message d’appareil 2 est conservé pour représenter les données les plus récentes/les plus récentes.
Persist
Persist est la dernière étape où les observations FHIR de l’étape de transformation sont conservées dans le service FHIR. Si l’observation FHIR est nouvelle, elle est créée dans le service FHIR. Si l’observation FHIR existait déjà, elle est mise à jour dans le service FHIR. Le service FHIR utilise l’identité managée affectée par le système du service MedTech et le contrôle d’accès en fonction des ressources Azure (Azure RBAC) pour sécuriser l’accès au service FHIR.
Étapes suivantes
Dans cet article, vous avez découvert les étapes de traitement des messages de l’appareil medTech service.
Pour obtenir une vue d’ensemble des méthodes de déploiement du service MedTech, consultez
Pour obtenir une vue d’ensemble du mappage des appareils de service MedTech, consultez
Pour obtenir une vue d’ensemble du mappage de destination FHIR du service MedTech, consultez
Pour obtenir une vue d’ensemble des exemples de mappages basés sur des scénarios de service MedTech, consultez
FHIR® est une marque déposée de la Health Level Seven International, enregistrée auprès de l’U.S. Trademark Office et utilisée avec leur autorisation.