Introduction à l'interface OPTITIME RMS
Pour les structures équipées du logiciel
d’optimisation des tournées
OPTITIME, certains rendez-vous is@dom seront gérés directement par
cette interface.
Le principe est : is@dom génère des
besoins et OptiTime
renvoie des rendez-vous.
Liste des données interfacées avec OptiTime :
- Création/mise à jour des tiers (Customers)
=>
tous les types de tiers ayant les paramètres Géolocaliser les adresses
et Synchronise les customers cochés.
- Création/mise à jour des intervenants (Workers),
de leur planning et indisponibilités
=> tous les intervenants cochés Planification par OptiTime
et le paramètre général Synchronise les workers.
- Création des besoins (Jobs) /
des rendez-vous O2L (cf.
Paramètre Exporter les rdv d'O2L)
=> tous les
besoins (besoins prévisionnel ou besoin manuel) des types de visites
cochés « RDV OptiTime ».
=> tous les
rendez-vous en O2L des types de visites
cochés « RDV OptiTime ». Les jobs sont préfixés avec un R.
Les deux applications discutent entre elles
:
. en temps réel grâce au
service OptiTime et aux
web
services mis en place.
. via une tâche planifiée, seul le fichier des jobs (besoins prévisionnels) est envoyé au
serveur OptiTime dans un fichier CSV généré automatiquement tous les
matins et si le paramètre général Envoi automatique des jobs à
OptiTime est coché.
Paramétrage à mettre en place
Paramètres
Application - Paramètres généraux - volet Planning
Visites -
onglet OptiTime
Planification Visites -
Types de visite
Planification Visites -
Planning
. Horaires : durée de la pause
+ détail de l’horaire en lecture, qui affiche en texte clair les options
saisies.
. Journées Affectations :
compétence urgence
. Semaine : lieux de
départ / arrivée
Annuaire -
Type de
tiers
Annuaire
Annuaire -
Personnel
interne
. Informations générales :
Identifiants - Secteurs géographiques - Fonction - Statut actif/inactif
(spécifique à la structure)
. Préférences
de passage
S'il n'existe pas d'horaires pour une journée cochée alors c'est 00:00 à
23h59.
. Visites Habilitations : Types prestations - Types de visites habilités
(uniquement celles gérées par OptiTime (sauf si spécifique structure)).
. Planning
Informations
Les customers (patients)
sont exportés dans OptiTime si :
• le Type de tiers est
coché Géolocaliser les adresses puis pour chaque tiers,
ceux pour lesquels la zone Adresse Visite, lieu de
dépôt/livraison est cochée.
L'adresse est l'adresse
principale si elle est cochée Visite, lieu de
dépôt/livraison, sinon la dernière adresse cochée
Visite, lieu de dépôt/livraison.
Le
géocodage est donc effectué par OptiTime. Si impossible une fenêtre
s'affiche pour choix décision.
Les workers (personnel interne d'is@dom)
sont exportés dans OptiTime si :
• Ils ont une adresse principale,
sinon c'est l'adresse de l'antenne.
L'intervenant préféré ou obligatoire dans OptiTime est l'intervenant
référent principal dans is@dom.
Informations exportées :
- Les identifiants de l’intervenant
- Ses secteurs géographiques
- Les types de visites pour lesquels
l’intervenant est habilité (on ne récupère que les types de
visite elles même cochés RDV OptiTime)
- Les types de prestations pour lesquelles l’intervenant est
habilité
- La fonction de l’intervenant et le statut
actif/inactif de l’intervenant (spécifique)
- Le
planning de l’intervenant.
L'organisation de l'intervenant est exportée dans
les timeTableCalendarPeriod selon les même règles que pour les customers
et workers à savoir :
- Organisation Optitime de l'antenne référente
- A défaut la référence externe de l'antenne
- A défaut
l'organisation du paramétrage général
Informations exportées avec le worker :
• FORFAIT : codes de
prescriptions liés aux types de prestations autorisés pour
l’intervenant.
• ZONE : zones géographiques de l’intervenant.
•
TYPE_VISITE : les types de visites de l'intervenant gérés par OptiTime
(sauf si spécifique structure).
L’organisation envoyée à OptiTime est la référence externe de
l’antenne liée à l’intervenant, ou le paramétrage général si pas de
valeur au niveau de l’antenne.
Type d’affectation Indisponibilité
: les raisons d’indisponibilités sont exportées.
Intégration des plannings des intervenants dans
OptiTime :
• Application de roulements
• Application de type de
semaine (nouveau)
• Ajout/modification/suppression d’affectation
manuelle
• Ajout/modification/suppression d’indisponibilité
•
Modification des jours chômés (la modification des jours fériés ne met
pas à jour le planning OptiTime).
Dès qu’une semaine est affectée par une
modification quelconque du planning, elle est envoyée à OptiTime.
L’intervenant doit être exporté dans OptiTime pour que son planning soit
modifiable dans is@dom (dès lors qu’il est habilité à réaliser un type
de visite lié à OptiTime).
Les commentaires du besoin/rendez-vous saisis OptiTime remontent dans is@dom.
Pour les Types de visite gérés par OptiTime, seuls les
rendez-vous figés dans OptiTime
sont transmis à is@dom et consultables dans la table des
rendez-vous.
Les durées de visite sont prises au niveau des
prestations uniquement dans le paramétrage des Types de
visites.
Schéma de l'interface entre is@dom et OptiTime
Se référer au Support de cours.
Autres informations
Synchronisation des jobs avec is@dom :
1. Si un job
est lié à un rendez-vous, que le rendez-vous est lié a une commande, si
le rendez-vous est annulé, le lien avec la commande est supprimé.
2.
Si un job est annulé et que le rendez-vous de ce job est lié à une
tournée, s'il existe :
a. Une
commande auto, alors elle est annulée,
b. Une commande manuelle, alors le lien avec le rendez-vous est
supprimé.
Si un JOB figé est lié à un besoin prévisionnel et que celui-ci n'existe plus dans is@dom, le rendez-vous est tout de même créé.
Dans l'export du JOB, la colonne "DATERDVPREV" contient la date du plus ancien prévisionnel antérieur à la date du besoin du même type pour le patient. La date est au format JJ/MM/AAAA. Pour rappel, cette colonne se base sur le prévisionnel existant du tiers.
Synchronisation des indisponibilités :
Lorsqu'elle est réalisée, le motif
d'indisponibilité (reason) est comparé aux types d'affectation is@dom de
type "indisponibilité".
Si le code d'affectation existe dans is@dom
et qu'il est actif, l'indisponibilité dans is@dom sera enregistrée avec
ce type, sinon c'est le type d'affectation des paramètres généraux qui
sera pris en compte.
Objet OptiTime utilisé :
<unavailabilities>
<unavailability reason="ADMIN"
unavailabilityReasonComment="test"
beginDate="2021-09-14T00:00:00"
endDate="2021-09-21T00:00:00"/>
</unavailabilities>
Si dans
is@dom, le type d'affectation "ADMIN" existe, qu'il est paramétré comme
une indisponibilité et qu'il est actif, alors le planning affichera une
indisponibilité de type "ADMIN", sinon l'indisponibilité sera celle des
paramètres généraux : Planning/visites - OptiTime : "Type de
d'indisponibilité".
Visites prévisionnelles
Dans la table du
prévisionnel OrdPlanningPrevisionnel, colonne
sIDJobOptitime.
Au moment de l'export d'un besoin vers OptiTime,
le sIDJobOptitime est initialisé avec le n° unique du besoin
prévisionnel, préfixé de B.
Lors du calcul du prévisionnel du tiers
(intégration de visite, recalcul manuel, modification des paramétrages,
...) :
- Mémorisation du prévisionnel exporté à OptiTime (présence
d'un sIDJobOptitime dans la table du prévisionnel) qui n'est pas lié à
un RDV.
- Recalcul du prévisionnel
- Comparaison entre le
prévisionnel mémorisé et le nouveau prévisionnel sur le type de visite,
et un chevauchement des dates min/max (dans le cas d'un changement de
paramétrage des délais avant/après date de visite)
Pour les
prévisionnels qui ont une correspondance entre le "prévisionnel
mémorisé" et le "nouveau prévisionnel" : mise à jour dans le nouveau
prévisionnel du sIDJobOptitime mémorisé.
Ainsi, si le besoin en visite n'a pas changé,
le job dans OptiTime n'est pas modifié et le nouveau prévisionnel
conserve le lien avec l'ancien.
S'il n'y a pas de correspondance (le
prévisionnel mémorisé ne fait plus partie du nouveau prévisionnel), le
job est annulé ou supprimé d'OptiTime, selon le paramétrage général.
Donc les besoins prévisionnels existants qui
ont été envoyés à OptiTime sont initialisés : sIDJobOptitime est égal à
"B" + le numéro du prévisionnel (iPKPrevisionnel)
is@service OptiTime :
Le service tente de
mettre à jour le AnnexData correspondant au numéro de
prévisionnel.
. JCRENEAU (non coché 'exporter' par défaut)
. SCHEDULEITEMS_AB_LIEUVISITE (non coché ‘exporter’ par défaut)
Export des jobs, la colonne JCRENEAU contiendra les valeurs suivantes :
. Agence si l'adresse de la visite est l'adresse d'une antenne
. Domicile dans les autres cas
La colonne
SCHEDULEITEMS_AB_LIEUVISITE contiendra les valeurs suivantes :
. #absolute|eq|Agence|string#
si l’adresse de la visite est l’adresse d’une antenne
. #absolute|eq|Domicile|string#
dans les autres cas.
Si
l'annexData JCRENEAU est "Agence", le lieu de rendez-vous "Association"
(code A) est enregistré dans le rendez-vous.
Dans le cas contraire il
n'est pas renseigné.
Besoins manuels
Prestations multiples, table
OrdPlanningPrevisionnelTypePrestation pour stocker les types de
prestations saisis dans les besoins prévisionnels.
L'écran de
saisie d'un besoin manuel proposera un choix multiple de types de
prestations.
Ces types de prestation seront envoyés dans le job dans
les colonnes :
. BD_PRESTATION
. JPRESTATION
.
SCHEDULEITEMS_AB_PRESTA
Si aucun type de prestation est
précisé, is@Dom envoie les prestations en cours du tiers compatibles
avec le type de visite (fonctionnement par défaut).
Si au moins un
type de prestation est précisé, is@Dom envoie les prestations
précisées dans le besoin manuel, le calcul de
durée prend en compte ces prestations précisées.
Pour
BD_PRESTATION et JPRESTATION, les types de prestations sont séparés par
des virgules (ex : PRESTA1,PRESTA2).
Pour
SCHEDULEITEMS_AB_PRESTA, les types de prestation sont envoyés selon ce
modèle :
#absolute|eq|PRESTA1|string# (1 prestation)
#absolute|eq|PRESTA1|string#absolute|eq|PRESTA2|string# (2 prestations)
#absolute|eq|PRESTA1|string#absolute|eq|PRESTA2|string#
absolute|eq|PRESTA3|string# (3 prestations)
Etc.
© ADS - 2021