Télésuivi - Paramétrage API fournisseurs

is@dom

Paramétrage is@dom API (autres que RESMED)

Fiche Fournisseur

Demander au fournisseur les renseignements comme l'identifiant de connexion, le certificat, la session Id, ...
Fiche Fournisseur, pavé API du volet Télésuivi à remplir avec ADS :

Pour chaque fournisseur les informations nécessaires sont :

Pour RESMED, ces informations sont à compléter avec la page API Resmed.

Type de prestations

Renseigner les types de prestations traitées par l'API parmi celles cochées Gestion du télésuivi.

Créer un patient par DM installé

Les API AirView et EncoreAnywhere ne permettent pas d'associer plusieurs appareils à un même patient. Pour contourner cette limitation, il faut créer via l'API un patient par appareil installé.
Spécificité Philips : pour une même organisation, on ne peut pas avoir le même PatientUUID pour deux patients ; pour contourner la limitation, le code patient transmis sera : [sCodeAnnuaire] + "-" + [DATE+HEURE création].

Pour un évènement TELEOBS, il y aura un ECN/GUID (cf. zone Numéro ECN) par appareil coché Observance ou Card to Cloud :

Avant de créer un patient sur la plateforme fournisseur, is@dom vérifie que ce n'est pas déjà le cas en vérifiant si son ECN/GUID est renseigné dans is@dom.
Si ce n'est pas le cas, is@dom interroge l'API pour vérifier si le patient existe déjà sur la plateforme fournisseur.
Si le patient existe déjà, is@dom récupère l'ECN/GUID et le renseigne dans is@dom.
Si Créer un patient par DM installé est :
. Décoché, alors le fonctionnement actuel est conservé.
. Coché, alors is@dom envoie une nouvelle demande de création.

Un nouvel ECN/GUID sera récupéré et sera spécifique à l'appareil dans l'évènement.

Particularités Philips

Si pour une raison indéterminée, le patient est créé sur l'API Philips mais que son ECN n'est pas renseigné dans is@dom, on recherche ce patient dans l'API par :
- nom + prénom + date de naissance
- puis nom + prénom
- puis code patient comme nom + prénom + date de naissance
- puis code patient comme nom + prénom
- puis code patient comme nom + date de naissance
- puis nom + date de naissance
- puis nom
- et enfin code patient.

Si le patient est trouvé, on contrôle que le code patient reçu est bien le code patient is@Dom, alors on utilise l'ECN de la plateforme pour le patient is@Dom.
Si le patient n'est pas trouvé :
. Soit c'est le robot qui a pris la main et dans ce cas l'ECN n'est pas mis à jour (on ne sait pas si c'est le bon patient)
. Soit c'est une action manuelle à faire depuis is@Dom ; l'ECN est proposé et l'utilisateur décide.

Les recherches se font sur association des champs suivant : code, nom, prénom, date de naissance.
Si la recherche ne renvoie rien, l'information est correctement transmise au cours de la procédure.

Création de patient
Les messages d'erreur dont le code est "ValidationFailure" sont transmis au destinataire des messages d'erreur.

Les données sont récupérées entre J-8 et J-1.

Particularités SEFAM

Nouvelle méthode de récupération des données de la téléobservance pour le fournisseur SEFAM ; les données sont récupérables depuis l'API après identification par Token et récupérées au format JSON.

L'interface de récupération des données de téléobservance doit se connecter à l'API avec l'identifiant et le mot de passe fournis par SEFAM.
Les données seront récupérées, vérifiées et intégrées dans is@dom.
Contrôle de l'existence du patient.

Lors de l'ajout d'un modem SEFAM à un patient, is@dom créera ou mettra à jour le patient sur la plateforme SEFAM.
Si un patient a déjà un modem SEFAM et que des informations requises par l'API sont modifiées, la fiche patient sur l'API sera mise à jour.
Les informations transmises à SEFAM seront :
- No Patient
- Nom et Prénom
- Date de naissance
- Sexe
- Modem SEFAM installé : n° série

Lorsque le modem est retiré, il sera retiré sur la plateforme toujours par l'intermédiaire de l'API.

Le numéro de la méthode utilisée est renseigné par ADS.

Les valeurs (durée, IAH, etc) à zéro seront considérées comme données effectives et réelles à condition que ces valeurs à zéro se trouvent entre la précédente fois où l'on a reçu une valeur quelle qu'elle soit (appareil qui a donc transmis) (date 1) et la donnée positive reçue ce jour (date 2).
Afin de récupérer les éventuelles nouvelles valeurs, il est demandé au fournisseur les données entre la date 1 et la date 2 afin éventuellement d'écraser les zéros enregistrés.
Cela nécessite d'interroger l'API à partir du dernier relevé comportant une véritable valeur pour chaque appareil SEFAM jusqu'à J-1 de l'exécution du robot.

Le relevé sera intégré si la valeur est :
- ACTIVE (journée avec une véritable utilisation)
- INACTIVE (journée avec une utilisation à 0)
Si la valeur est UNKNOWN : le relevé sera ignoré.
La recherche des données repartira à j+1 du dernier relevé avec une utilisation supérieure à 0 (donc ACTIVE).
Le statusDay n'est conservé dans isadom.

Particularités SRETT

(natif ou API de référence)
La date de désappairage envoyée est J-1 de la date pour les autres fournisseurs.
Que ce soit un matériel SRETT ou un matériel autre géré par la plateforme Vestalis en API de référence.

Lors d'un appairage Vestalis, si l'ECN de l'appareil n'est pas connu, Vestalis est interrogé pour le récupérer. Puis si l'appareil n'est pas connu de Vestalis alors is@Dom demande sa création.
L'API SRETT ne permet plus de créer des appareils Lowenstein (juin 022) car ils sont récupérés chaque nuit.
Si à l'issue de la demande préalable de récupération d'ECN, l'appareil Lowenstein n'est pas identifié : la procédure d'appairage sera stoppée.

2 méthodes :
. aggregated-data/patients/daily-data : Le robot récupère les données des 3 derniers jours concernés pour tous les patients d'un coup.
. aggregated-data/by-update-date/patients/daily-data : Cette méthode permet de récupérer les données par date de réception.