Volet Gestion d'agendas partagés...plateforme de gestion d’agenda centralisé, qui est utilisée par les patients pour chercher des disponibilités de professionnels et pour la

Volet Gestion d'agendas partagés

CI-SIS Spécifications fonctionnelles

Agence du Numérique en Santé

9, rue Georges Pitard – 75015 Paris

T. 01 58 45 32 50

esante.gouv.fr



Statut : Validé | Classification : Publique | Version : v1.2



Statut : Validé | Classification : Publique | Version v1.2 page 1/45

Ce document est diffusé sous licence ouverte v2.0

SOMMAIRE

1. Introduction ............................................................................................................................................... 2

1.1. Exemples de cas d’usage ..................................................................................................................... 2

1.1.1. Prise de rendez-vous dans un centre de santé................................................................................... 2

1.1.2. Prise de rendez-vous chez un masseur-kinésithérapeute .................................................................. 2

1.2. Méthode d’élaboration des spécifications fonctionnelles ................................................................ 3

1.3. Lectorat cible ......................................................................................................................................... 3

2. Élaboration des spécifications métier .................................................................................................... 4

2.1. Étape 1: Organisation du contexte métier .......................................................................................... 4

2.2. Étape 2: Définition des processus collaboratifs ................................................................................ 4

2.2.1. Cas d'utilisation « Gestion des ressources » ...................................................................................... 5

2.2.2. Cas d'utilisation « Gestion des disponibilités » ................................................................................... 5

2.2.3. Cas d'utilisation « Consultation Agenda » .......................................................................................... 5

2.2.4. Cas d'utilisation « Prise de rendez-vous » .......................................................................................... 5

2.3. Étape 3: Description détaillée du processus et identification des flux ........................................... 7

2.3.1. Gestion des ressources ....................................................................................................................... 8

2.3.2. Gestion des disponibilités des ressources .......................................................................................... 9

2.3.3. Consultation d’agenda .......................................................................................................................11

2.3.4. Prise de rendez-vous ........................................................................................................................12

2.4. Étape 4: Qualification des échanges ................................................................................................. 13

2.5. Étape 5: Identification des informations métier ............................................................................... 14

2.6. Étape 6: Modèle des flux structurés .................................................................................................. 15

2.6.1. Flux 1 – GestionRessources .............................................................................................................16

2.6.2. Flux 2 – PlageDisponibiliteRessource ...............................................................................................21

2.6.3. Flux 3 – DemandeConsultation .........................................................................................................24

2.6.4. Flux 4 – ReponseConsultation ..........................................................................................................30

2.6.5. Flux 5 – PriseRendezVous ................................................................................................................36

2.6.6. Flux 6 – PropositionAutresRessources .............................................................................................39

2.6.7. Flux 7 – ConfirmationRendezVous ...................................................................................................43

Annexe 1 : Documents de référence ........................................................................................................... 44

Annexe 2 : Historique du document ............................................................................................................ 45





1. INTRODUCTION

Ce document présente une étude « métier » pour la mise en œuvre d’un mécanisme de gestion d’agenda partagé

dans le domaine sanitaire, médico-administratif, médico-social ou social afin d’évaluer les besoins en interopérabilité

correspondants et la manière dont ceux-ci peuvent être traités. L’étude menée concerne la modélisation des flux qui

existent entre les composants d’un système d’information ou entre des systèmes d’informations qui participent à la

mise en œuvre de la gestion d’agenda partagé.

A noter que les contraintes de sécurité concernant les flux échangés ne sont pas traitées dans ce document. En

effet, les aspects relatifs à la sécurité sont du ressort du système d’information les implémentant.

Ces exigences « métier » sont mises en œuvre par les volets transport et service du CI-SIS.

1.1. Exemples de cas d’usage

Ci-dessous des exemples d’utilisation de la gestion d’agenda partagé dans lesquels il est supposé qu’il existe une

plateforme de gestion d’agenda centralisé, qui est utilisée par les patients pour chercher des disponibilités de

professionnels et pour la prise de rendez-vous. Cette plateforme gère également les agendas des patients.

1.1.1. Prise de rendez-vous dans un centre de santé

Le patient prend rendez-vous chez son médecin généraliste :

soit directement en ligne par l’outil de rendez-vous du centre

soit par téléphone et c’est une personne tierce (secrétariat par exemple) qui bloque le créneau proposé dans l’outil du médecin

Le système d’information (SI) du centre de santé est interfacé avec la plateforme de façon à pouvoir communiquer

avec le service de gestion de rendez-vous de la plateforme.

Si le patient est connu de la plateforme, le rendez-vous pris dans le SI est alors transmis à l’outil de gestion de

rendez-vous de la plateforme, qui le centralise dans l’agenda patient.

1.1.2. Prise de rendez-vous chez un masseur-kinésithérapeute

Le patient est connecté sur la plateforme. Il cherche les masseurs-kinésithérapeutes les plus proches de chez lui.

Les premiers créneaux disponibles pour chacun des professionnels de santé lui sont proposés, sous forme d'une

liste et d'une visualisation graphique.

Le LPS (Logiciel de Professionnel de Santé) est interfacé avec la plateforme de façon à pouvoir communiquer avec

le service de gestion de rendez-vous de la plateforme.

La plateforme, à partir des caractéristiques indiquées par le patient, recherche les informations indiquées par les PS

concernant les disponibilités des ressources. Ces disponibilités sont ensuite affichées dans la plateforme.

La prise de rendez-vous est immédiate ou différée selon les choix des professionnels.





1.2. Méthode d’élaboration des spécifications fonctionnelles

Les spécifications « métier » présentées dans ce document suivent la méthode1 d’élaboration des spécifications

fonctionnelles des échanges élaborée par l’ASIP Santé. Cette méthode est constituée de plusieurs étapes :

Étape 1: Organisation du contexte métier;

Étape 2: Définition des processus métier collaboratifs;

Étape 3: Description de chaque processus défini et identification des flux échangés

Étape 4: Qualification des flux échangés;

Étape 5: Pour chaque flux, identification des informations véhiculées;

Étape 6: Élaboration du modèle hiérarchique de chaque flux structuré (sous forme d’un ou plusieurs

diagramme de classes UML). Le modèle hiérarchique élaboré repose sur la reprise des composants

mutualisés dans le modèle des objets de santé (MOS2) et des nomenclatures associées. À l'issue de cette

élaboration, il se peut que de nouveaux composants jusqu'alors inexistants dans le MOS aient été définis

et soient intégrés par la suite au MOS.

1.3. Lectorat cible

Les lecteurs cibles sont principalement des chefs de projets ainsi que toute personne concernée par la maîtrise d’ouvrage et qui spécifie des projets avec des interfaces interopérables.

1 http://esante.gouv.fr/services/referentiels/ci-sis/demarche-elaboration 2 http://esante.gouv.fr/services/referentiels/mos/modele-des-objets-de-sante-mos-et-nomenclatures-associees-0





2. ÉLABORATION DES SPECIFICATIONS METIER

2.1. Étape 1: Organisation du contexte métier

Le but de cette étape est d’organiser la vue métier dans laquelle s’insère le mécanisme de gestion d’agenda et

d'identifier le ou les processus collaboratifs du périmètre du projet. Dans cette étape, les concepts suivants doivent

être définis:

- le domaine d'activité dans lequel se situe le projet; le domaine est composé d'un ou de plusieurs groupes de

processus;

- les groupes de processus qui sont composés eux-mêmes d’un ensemble de processus métier collaboratifs.

Le domaine « Gestion Agenda » illustré dans la Figure 1 contient un groupe de processus qui concerne la gestion

d’agenda et qui regroupe 4 processus.

La gestion des disponibilités

La consultation d’agenda

La prise de rendez-vous

La gestion des ressources

Figure 1 : Organisation du contexte métier

2.2. Étape 2: Définition des processus collaboratifs

Le but de cette étape est de définir les processus métier collaboratifs identifiés dans le diagramme défini à l’étape

1. Cette modélisation est entreprise de façon macroscopique en représentant ces processus par des diagrammes

de cas d’utilisation UML.

Les définitions des termes utilisés dans ce document sont présentées ci-dessous. À noter que chaque sous-section

peut contenir ses définitions propres.

Personne prise en charge : Il s’agit d’un usager ou d’un patient que ce soit au niveau sanitaire, médico-

administratif, médico-social ou social.

Professionnel : un professionnel est une personne qui participe à la prise en charge d’une personne que ce

soit au niveau sanitaire, médico-administratif, médico-social ou social.

Ressource : Une ressource est un terme générique pour désigner toute personne, lieu ou objet pour la prise

de rendez-vous. Une ressource peut être, par exemple, un professionnel ou un équipement mais aussi une

salle ou une personne prise en charge. Dans le cadre de la gestion de l’agenda, lorsque la ressource concerne

une personne en mobilité et donc susceptible de se déplacer dans des lieux différents, la ressource est





étendue au lieu où la personne se trouve. Par exemple, dans le cas d’un professionnel, la ressource

correspond au professionnel dans un de ses lieux d’exercice.

Agenda : un agenda regroupe l’ensemble des disponibilités et des indisponibilités d’une ressource sur une

période donnée. Dans le contexte de cette étude, les indisponibilités concernent des rendez-vous pris et qui

peuvent contenir les détails des rendez-vous (type, durée, lieu, etc.).

Plage de disponibilité : il s’agit des horaires et lieux de disponibilité d’une ressource (par exemple, les

horaires de consultation d’un professionnel de santé dans son cabinet).

Les Figures 2 à 5 ci-dessous représentent les cas d'utilisation (processus) identifiés. Les actions ainsi que les

acteurs concernés sont décrits dans les tables 1 et 2.

2.2.1. Cas d'utilisation « Gestion des ressources »

Figure 2 : Diagramme de cas d'utilisation Gestion des ressources

2.2.2. Cas d'utilisation « Gestion des disponibilités »

Figure 3 : Diagramme de cas d'utilisation Gestion des disponibilités

2.2.3. Cas d'utilisation « Consultation Agenda »

Figure 4 : Diagramme de cas d'utilisation Consultation Agenda

2.2.4. Cas d'utilisation « Prise de rendez-vous »

Figure 5 : Diagramme de cas d'utilisation Prise de rendez-vous





Cas d'utilisation Description

Gestion des ressources

La gestion des ressources concerne la création, la modification ou la suppression d'une ou de plusieurs ressources. Par exemple, un professionnel de santé peut déclarer un nouvel équipement dans son cabinet, nouveau lieu d’exercice, etc.

Gestion des disponibilités

La gestion des disponibilités concerne la création, modification ou suppression d'une disponibilité d’une ou de plusieurs ressources. Cette demande est initiée par un déclarant qui peut être un professionnel, une personne prise en charge ou une tierce personne autorisée à accéder à l'agenda.

Consultation d'agenda

La consultation d'agenda est initiée par un consommateur et concerne l'accès à un ou plusieurs agendas gérés par le gestionnaire d'agenda. Une personne qui consulte un ou plusieurs agendas peut consulter les disponibilités ou les indisponibilités de ces agendas.

Prise de rendez-vous

La prise de rendez-vous concerne l'allocation d'un créneau (date, heure, lieu) dans l'agenda d'une ressource ou de plusieurs ressources. Cette action est initiée par un demandeur de rendez-vous.

Table 1: Table des cas d'utilisation

Acteur Description

Gestionnaire d'agenda

Le gestionnaire d’agenda gère les demandes de déclaration, de modification ou de suppression de rendez-vous.

Gestionnaire de ressources

Le gestionnaire de ressources gère les demandes de gestion de ressources (lieu, équipement, personne prise en charge, professionnel, etc.).

Déclarant

Le déclarant peut initier une demande de création d’une nouvelle ressource à un gestionnaire de ressource ou d’une plage de disponibilité d’une ressource à un gestionnaire d’agenda. Il peut également modifier ou supprimer une ressource ou une plage de disponibilité d’une ressource existante. Le déclarant peut être soit le responsable de la ressource, soit un gestionnaire d’agenda ou un gestionnaire de ressources auprès duquel une ressource ou une plage de disponibilité d’une ressource a été déclarée et qui diffuse cette information à un autre gestionnaire d’agenda, ou à un autre gestionnaire de ressources.

Consommateur

Un consommateur consulte l’agenda d’une ressource gérée par un gestionnaire d’agenda. La consultation de l’agenda indique les éventuelles plages de disponibilité déclarées pour la ressource ainsi que ses indisponibilités et les détails des rendez-vous existants (types, durées, etc., cf. section 2.3.3). Le consommateur peut être la personne prise en charge, un professionnel intervenant dans la prise en charge d’une personne ou tout autre tiers autorisé à consulter l’agenda de la ressource concernée.

Demandeur

Un demandeur fait une demande auprès d’un gestionnaire d’agenda pour un rendez-vous dans les plages de disponibilité d’une ressource ou demande la modification d’un rendez-vous existant. Le gestionnaire d’agenda confirme le rendez-vous, rejette le rendez-vous ou propose un autre rendez-vous à accepter par le demandeur (ex. autres jours, autres horaires, autres ressources…). Le demandeur peut être la personne prise en charge (i.e. « bénéficiaire » du rendez-vous), un professionnel intervenant pour le compte d’une personne prise en charge ou un gestionnaire d’agenda auprès duquel un rendez-vous a été demandé et qui le diffuse à un autre gestionnaire d’agenda.

Table 2: Table des acteurs

Il est important de comprendre le lien entre le gestionnaire des ressources et le gestionnaire d’agenda. En effet, une

fois qu’une ressource est créée, le gestionnaire de ressources doit effectuer les tâches suivantes :

1- communiquer l’identifiant de la ressource au gestionnaire de l’agenda, mais aussi d’autres informations qui

peuvent être nécessaires pour ce dernier à pouvoir gérer les disponibilités (et les indisponibilités des

ressources), comme par exemple la spécialité d’un professionnel (si la ressource gérée est un

professionnel). Il s’agit d’un flux « technique » entre ces deux composants qui n’est pas modélisé dans

cette étude métier.





2- communiquer l’identifiant de la ressource créée au déclarant de la ressource (dans le cas où l’identifiant de

la ressource est générée par le gestionnaire de ressources et non défini par le déclarant). Ceci est

important pour que le déclarant puisse modifier ou supprimer des ressources, mais aussi pour déclarer les

disponibilités des ressources directement dans le gestionnaire d’agenda. Cette information peut circuler

dans un flux d’échange entre le gestionnaire de ressources et le déclarant (cf. section 2.3.1).

Il n’y a pas de contrainte architecturale d’implémentation du gestionnaire des ressources et du gestionnaire

d’agenda : ils peuvent être mis en œuvre au sein d’un même système ou sur plusieurs systèmes repartis.

2.3. Étape 3: Description détaillée du processus et identification des flux

Le but de cette étape est de décrire les processus métier définis dans les cas d'utilisation de l'étape 2 et d'identifier

les flux échangés par les acteurs. Les processus examinés sont modélisés avec des diagrammes d'activité UML.

Les interactions décrites correspondent à des interactions techniques3 entre composants de systèmes d’information.

Sauf indication contraire, il n’y a pas de contrainte architecturale d’implémentation de ces composants : ils peuvent

être mis en œuvre au sein d’un même système ou dans des systèmes différents. Ci-dessous les diagrammes

d’activités des processus identifiés dans l’étape 2. Les acteurs et les actions de chaque processus sont également

décrits.

À noter que les flux marqués en pointillés dans les Figures ci-dessous peuvent être des flux non-structurés, des flux

techniques ou des flux qui ne contiennent pas d’informations métier. Ils sont hors périmètre de cette étude métier.

3 Contrainte spécifique sur les composants techniques : étant donné les utilisateurs impliqués et les usages prévisibles en mobilité

via des applications spécifiques, il est important que les flux définis soient aisément intégrables dans des dispositifs mobiles

(smartphones, tablettes…).





2.3.1. Gestion des ressources

Figure 6 : Diagramme de cas d’activité Gestion des ressources

Acteurs

Acteur Description

Déclarant Un déclarant crée, modifie ou supprime une ressource (une personne prise en charge, un équipement, un lieu, etc.) à un gestionnaire de ressources.

Gestionnaire de ressources

Le gestionnaire de ressources gère les demandes de création, de modification ou de suppression des ressources.


Actions

Initier une demande de déclaration ou de suppression d’une ressource

Le déclarant effectue une déclaration, une modification ou une suppression d’une ressource existante.





Réceptionner la demande

Le gestionnaire de ressources réceptionne la demande initiée par le déclarant.

Traiter la demande

Le gestionnaire de ressources traite la demande. Il peut s’agir d’un accès à une base de données pour effectuer la

mise à jour des informations concernant les ressources, par exemple. De plus, cette étape peut concerner une

synchronisation des informations avec le gestionnaire d’agenda. Comme indiqué en section 2.2, les flux entre le

gestionnaire de ressources et le gestionnaire d’agenda sont hors du périmètre de cette étude.

Réceptionner la réponse du gestionnaire de ressources

Le déclarant réceptionne la réponse du gestionnaire de ressources concernant sa demande initiale. Ce flux peut

contenir l’identifiant de la ressource pour une utilisation ultérieure.

2.3.2. Gestion des disponibilités des ressources

Figure 7: Gestion des disponibilités des ressources





Acteurs

Acteur Description

Déclarant4

Un déclarant déclare une plage de disponibilité d’une ressource (professionnel éventuellement associé à un lieu d’exercice, équipement…) à un gestionnaire d’agenda, modifie ou supprime une plage de disponibilité existante.


Le gestionnaire d’agenda gère les demandes de déclaration, de modification ou de suppression de disponibilités pour les rendez-vous.


Actions

Initier une demande de déclaration, modification ou suppression de disponibilités d'une

ou de plusieurs ressources

Le déclarant effectue une déclaration, une modification ou une suppression de disponibilités de ressources dans

l'agenda.

Créer ou modifier ou supprimer les disponibilités d’une ou de plusieurs ressources

Le gestionnaire d’agenda traite la demande du déclarant.

Réceptionner la réponse du gestionnaire d’agenda

Le déclarant réceptionne la réponse du gestionnaire de ressources concernant sa demande initiale.

4 Le déclarant des disponibilités des ressources peut être le déclarant des ressources elles-mêmes. Dans le cas contraire, il est

supposé que le déclarant des disponibilités des ressources connait l’identifiant ou les identifiants des ressources

correspondantes. Par exemple, le déclarant peut communiquer l’identifiant de la ressource ou les ressources qui le(s)

concernent(nt) à d’autres personnes susceptibles d’interagir avec ce(s) ressource(s) (dans notre cas, le déclarant des

disponibilités des ressources).





2.3.3. Consultation d’agenda

Figure 8: Consultation Agenda

Acteurs

Acteur Description

Consommateur Le consommateur effectue une recherche des disponibilités ou des indisponibilités concernant une ou plusieurs ressources selon des critères de recherche.


Le gestionnaire d’agenda gère les demandes de consultation d'agenda d’une ou de plusieurs ressources.


Actions

Initier une demande de consultation d’agenda

Le consommateur initie une demande de consultation d'un ou de plusieurs agenda des ressources gérées par le gestionnaire

d'agenda.





Traiter la demande de consultation d'agenda

Le gestionnaire d’agenda réceptionne la demande et effectue une recherche en se basant sur les paramètres

précisés par le consommateur (date, heure, type de rendez-vous, etc.).

Renvoyer les disponibilités de la ressource selon les crit ères demandées

Le gestionnaire d'agenda envoie au consommateur les informations relatives aux critères précisées par ce dernier.

Réceptionner et visualiser les informations

Le consommateur réceptionne et visualise les informations retournées par le gestionnaire d'agenda. Parmi les

informations envoyées par le gestionnaire d’agenda au consommateur, se trouve l’identifiant des ressources qui

répondent aux critères de recherche du consommateur. Ces identifiants seront ensuite utilisés pour effectuer une

demande de rendez-vous qui peut affecter l’indisponibilité d’une ou de plusieurs ressources. A noter que les

identifiants des ressources retournées peuvent au préalable être connues par le consommateur et peuvent

constituer des critères de recherche.

2.3.4. Prise de rendez-vous

Figure 9: Prise de rendez vous





Acteurs

Acteur Description

Demandeur5

Un demandeur fait une demande auprès d’un gestionnaire d’agenda pour prendre un rendez-vous dans les plages de disponibilité d’une ou de plusieurs ressources. Le gestionnaire d’agenda confirme le rendez-vous, rejette le rendez-vous ou propose un autre rendez-vous à accepter par le demandeur (ex. autre jour, autres horaires, autre ressource…).

Gestionnaire d’agenda Le gestionnaire d’agenda gère les demandes de prise de rendez-vous.


Actions

Initier une demande de prise de rendez-vous

Le demandeur de rendez-vous initie une demande de prise de rendez-vous en précisant les informations

nécessaires (date/heure souhaitée, lieu, type rendez-vous, etc.). Ces informations seront transmises au

gestionnaire d'agenda pour un traitement.

Traiter la demande de prise de rendez-vous

Le gestionnaire d’agenda réceptionne la demande de prise de rendez-vous et la traite.

Réceptionner la confirmation du rendez-vous

Le demandeur réceptionne et traite les informations reçues du gestionnaire d'agenda qui peuvent être

synchronisées automatiquement dans son agenda.

Arrêter le processus du prise de rendez-vous

Le demandeur peut, à n’importe quel moment, arrêter le processus de prise de rendez-vous.

2.4. Étape 4: Qualification des échanges

Les flux échangés entre les acteurs ont été identifiés à l'étape 3. Cette nouvelle étape vise à qualifier les flux

d'informations entre les acteurs en définissant parmi eux, ceux qui sont structurés. Les flux d’informations ne sont

pas tous de même nature. En effet, certains sont non structurés tels que les lettres ou les appels vocaux et d’autres

sont structurés afin d'être interprétés par des applications. Seule cette dernière catégorie de flux est concernée.

Cette qualification est effectuée en élaborant un tableau répertoriant les flux identifiés à l'étape précédente.

Nom du flux Emetteur Récepteur Nature du flux

Flux 1 - GestionRessources Déclarant Gestionnaire de ressources Flux structuré

Flux 2-

GestionDisponibilitéRessources Déclarant Gestionnaire d’agenda Flux structuré

Flux 3 - DemandeConsultation Consommateur Gestionnaire d’agenda Flux structuré

5 Un demandeur de rendez-vous peut à n’importe quel moment terminer le processus de prise de rendez-vous. Ceci est exprimé dans la

Figure 9 par le flux en pointillé qui va vers l’action « Arrêter le processus de prise de rendez-vous ». De plus, il est supposé que le

demandeur de rendez-vous possède le(s) identifiants(s) de(s) ressource(s) qu’il veut utiliser. Le consommateur (Figure 8) et le demandeur

(Figure 9) peuvent être la même personne mais pas nécessairement : le demandeur de rendez-vous peut prendre un rendez-vous sans

effectuer une recherche pour la consultation d’agenda.





Flux 4 - RéponseConsultation Gestionnaire d’agenda

Consommateur Flux structuré

Flux 5 - PriseRendezVous Demandeur Gestionnaire d’agenda Flux structuré

Flux 6-

PropositionAutresRessources

Gestionnaire d’agenda

Demandeur Flux structuré

Flux 7 –

ConfirmationRendezVous

Gestionnaire d’agenda

Demandeur Flux structuré

Table 7 : Liste des flux identifiés

2.5. Étape 5: Identification des informations métier

Dans cette section, il s'agit de définir les informations métier présentes dans chaque flux identifié. La table ci-dessous

liste les concepts métier (avec une granularité plus ou moins fine) présents dans les flux identifiés.

Concepts Définition

Ressource

Une ressource est un terme générique pour désigner toute personne, lieu ou objet pour la prise de rendez-vous. Une ressource peut être, par exemple, un professionnel ou un équipement mais aussi une salle ou une personne prise en charge. Dans le cadre de la gestion de l’agenda, lorsque la ressource concerne une personne en mobilité et donc susceptible de se déplacer dans des lieux différents, la ressource est étendue au lieu où la personne se trouve. Par exemple, dans le cas d’un professionnel, la ressource correspond au professionnel dans un de ses lieux d’exercice.

Lieu Informations relatives à une portion déterminée de l'espace, fixe ou mobile, du point de vue de son affectation ou de ce qui s'y passe.

PersonnePriseEnCharge C’est la personne prise en charge que ce soit au niveau sanitaire, médico-administratif, médico-social et social.

Professionnel Un professionnel est une personne qui participe à la prise en charge d’une personne que ce soit au niveau sanitaire, médico-administratif, médico-social ou social.

Equipement Un équipement est une ressource matérielle nécessaire à la réalisation d'une activité.

PlageDisponibilitéRessources Il s’agit des horaires et lieux de disponibilité d’une ressource (par exemple, les horaires de consultation d’un professionnel dans son cabinet).

PlageInDisponibilitéRessources Il s’agit des horaires et lieux de la non disponibilité d’une ressource (il s’agit généralement des rendez-vous pris).

TiercePersonne Une personne tierce peut être un membre de la famille ou un proche de la personne prise en charge.

ServiceSoins

Un service de soins correspond à un type de service proposé par un établissement pour lequel une personne prise en charge peut prendre rendez-vous. Par exemple un service de cardiologie dans un hôpital ou une unité d’échographie dans un centre d’imagerie médicale.

Table 8 : Liste des concepts « métier » identifiés





2.6. Étape 6: Modèle des flux structurés

Le but de cette étape est d'élaborer le modèle hiérarchique de chaque flux structuré à partir des concepts métier

définis à l'étape 5. Ce modèle hiérarchique est formalisé par des diagrammes de classes UML.

La représentation formalisée du flux doit prendre en compte deux exigences supplémentaires:

• harmonisation du modèle avec d'autres flux: il convient de réutiliser les classes génériques et mutualisées, mises

à disposition dans le modèle des objets de santé (MOS) ;

• hiérarchie: le modèle doit adopter une structure hiérarchique au plus proche du besoin métier.

Ci-dessous les correspondances effectuées avec les concepts identifiés et les classes MOS (dans sa version 1.1).

Objets identifiés Objets MOS correspondants Attributs MOS à

restreindre dans le modèle du flux

Lieu Lieu,

Adresse Oui

PersonnePriseEnCharge Patient,

PersonnePhysique Oui

ServiceSoins - -

Professionnel Professionnel, ExerciceProfessionnel, SituationExercice

Oui

Ressource - -

Equipement Equipement Oui

TiercePersonne PersonnePhysique Oui

PlageDisponibiliteRessources - -

PlageInDisponibiliteRessources - -

Table 9 : Liste des correspondances entre les concepts « métier » identifiés et les concepts du MOS

À noter que les objets identifiés qui ne se trouvent pas dans le MOS peuvent faire l’objet d’une demande d’évolution

du MOS ou rester spécifiques au projet.

Les sections qui suivent présentent les diagrammes de classes de chaque flux structuré identifié.

À noter que les Flux 5 - PriseRendezVous et Flux 7 – ConfirmationRendezVous sont modélisés avec le même

diagramme de classe, étant donné que ces flux peuvent contenir les mêmes informations métier.





2.6.1. Flux 1 – GestionRessources

Le Flux 1 concerne la création, modification ou suppression d’une ou de plusieurs ressources.

Figure 10: Diagramme de classe Flux 1

2.6.1.1. Classe "Ressource"

Nom Description Obligatoire

idRessource : [0..1] Identifiant Identifiant de la ressource Non6

libelle : [1..1] Texte Titre de la ressource Oui

description : [0..1] Texte Toute information complémentaire qui aide à la définition de la ressource

Non

informationComplementaire : [0..1] Texte

Des informations complémentaires concernant la ressource (par exemple, des contraintes spécifiques)

Non

typeRessource : [1..1] Code Le type de la ressource (équipement, lieu, personne prise en charge, professionnel, etc.)

Oui

dateDeclarationRessource : [0..1] DateHeure

Date et heure de la déclaration de la ressource Non

6 L’identifiant de la ressource peut être

1) Généré par le déclarant et transmis dans le flux. 2) Généré par le système et n’est pas transmis mis dans le flux. Dans ce cas, cet identifiant est envoyé au déclarant pour une utilisation

ultérieure.





2.6.1.2. Classe "Equipement"


typeEquipement : [0..1] Code Code spécifiant le type de l'équipement (Scanner, IRM, etc.). Non

libelle : [0..1] Texte Libellé de l'équipement. Non

reference : [0..1] Code Référence de l'équipement.

Non

idEquipement : [0..1] Identifiant Identifiant de l’équipement Non

2.6.1.3. Classe "Lieu"


nom : [0..1] Texte Nom, exprimé sous la forme de texte, du lieu Non

description : [0..1] Texte Description textuelle du lieu, indiquant comment l'atteindre Non

idLieu : [0..1] Identifiant L’identifiant du lieu Non

libelleVoie : [0..1] Texte Appellation qui est donnée à la voie par les municipalités. Ce libellé figure in extenso ou en abrégé sur les plaques aux différents angles de chaque rue. Synonyme: nom de la voie

Non

complementAdresse : [0..*] Texte

Toute information complémentaire pour mieux identifier l’adresse Non

numeroVoie : [0..1] Texte Un numéro dans la voie; dans les cas de numérotation sans extension, il est composé de 0 à 4 caractères numériques au maximum.

Non

codePostal : [0..1] Code

Code Postal : Code Postal ou code postal spécifique CEDEX * Code postal: Un code à 5 chiffres servant à l'acheminement et/ou à la distribution des envois. Il identifie un bureau distributeur dans la chaîne de traitement du courrier. * Code CEDEX (Courrier d'Entreprise à Distribution Exceptionnelle); le CEDEX est une modalité d'acheminement du courrier associée à des services particuliers de distribution offerts aux entreprises caractérisées par un adressage spécifique; le code postal spécifique CEDEX est un code attribué aux organismes, entreprises, services publics recevant un fort trafic. Il identifie un client ou un ensemble de clients. Il est positionné au lieu et place du code postal général dans le cas des adresses CEDEX. Ainsi, un code peut être associé à un client (code individuel) ou partagé entre plusieurs clients (code collectif).

Non

2.6.1.4. Classe "PersonnePriseEnCharge"


idPersonnePriseEnCharge : [0..1] Identifiant

Identifiant(s) de la personne prise en charge (identifiants de santé, identifiants locaux, etc.).

Non

adresse : [0..*] Adresse Adresse(s) de correspondance permettant de contacter la personne prise en charge.

Non

telecommunication : [0..*] Telecommunication

Adresse(s) de télécommunication (numéro de téléphone, adresse email, URL, etc.).

Non





2.6.1.5. Classe "Professionnel"


idPP : [1..1] Identifiant

Identifiant national de la personne physique: ** Pour les professionnels: N° RPPS ou ADELI ** Pour les acteurs non professionnels de santé employés d’une structure : l’identifiant est composé de l’identifiant principal de la structure et de l’identifiant interne attribué par la structure ** Pour les étudiants, l'identifiant est le numéro SIRIUS ou le numéro Etudiant (identifiant ordinal dont les règles de génération sont propres à chaque ordre).

Oui

2.6.1.6. Classe "ExerciceProfessionnel"


nomExercice : [0..1] Texte Nom sous lequel exerce le professionnel. Non

prenomExercice : [0..1] Texte Prénom sous lequel exerce le professionnel. Non

profession : [1..1] Code Profession exercée ou future profession de l'étudiant. Oui

2.6.1.7. Classe "SituationExercice"


adresseSE : [1..*] Adresse

Adresse(s) de correspondance permettant de contacter les professionnels - lorsque les structures ne sont pas identifiées : cas des remplaçants ou des professionnels venant de s’inscrire mais non encore installés; - hors de leurs lieux d’exercice, s’ils le souhaitent. Remarque : La première occurrence correspond aux coordonnées de correspondance du RPPS.

Oui


Adresse(s) de télécommunication du professionnel (numéro de téléphone, adresse email, URL, etc.).

Non

2.6.1.8. Classe "EntiteGeographique"


idNat_Struct : [1..1] Identifiant Identification nationale de l'Entité Géographique propre aux SI de l'ASIP Santé et au CI-SIS. Cette identification est obtenue par la concaténation du type d'identifiant national de structure (provenant de la nomenclature TRE_G07-TypesIdentifiantsStructures) et de l'identifiant de la structure: ** 0 + Identifiant cabinet ADELI ** 1 + N° FINESS (entité juridique et entité géographique indéterminées) ** 3 + N° SIRET ** 4 + Identifiant cabinet RPPS Synonyme : Struct_IdNat (CI-SIS)

Oui

denominationEG : [0..1] Texte

Nom sous lequel l'entité géographique exerce son activité. Dans le cas d'un établissement enregistré dans le FINESS, cet attribut correspond à la notion de "raison sociale d'un établissement" renseignée dans le FINESS.

Non

adresseEG : [0..*] Adresse Adresse(s) géopostale(s) de l'entité géographique en fonction de l'usage (adresse administrative, adresse entrée des véhicules, adresse entrée piétonne, etc.).

Non





2.6.1.9. Classe "ServiceSoins"


idServiceSoins : [0..1] Identifiant Identifiant du service de soins. Non

denominationServiceSoins : [0..1] Texte Nom du service de soins Non

typeService : [0..1] Code Type du service. Non

2.6.1.10. Classe "Patient"


idPatient : [0..*] Identifiant Identifiant(s) du patient (identifiants de santé, identifiants locaux, etc.). Non7

2.6.1.11. Classe "PersonnePhysique"


nomFamille : [0..*] Texte

Toute personne possède un nom de famille (appelé auparavant nom patronymique). Ce nom figure sur l'acte de naissance. Il peut s'agir par exemple du nom du père. Ref.: Service-public.fr Synonymes : nom patronymique, nom de naissance.

Non

prenomUsuel : [0..*] Texte

Le prénom usuel est un des prénoms inscrit dans l'acte de naissance. Non

2.6.1.12. Classe "PersonneTierce"


idPersonneTierce : [0..1] Identifiant Identifiant de la personne tierce. Non

adresse : [0..*] Adresse Point(s) de contact de la personne tierce. Non

telecommunication: [0..*] Telecommunication


Non

7 Étant donné que l’IdPatient peut changer (ex. migration INS-C vers l’INS), l’IdRessource est utilisé comme identifiant stable dans le

périmètre de la gestion d’agenda partagé. En conséquence, l’IdPatient n’est pas considéré comme une donnée obligatoire pour le cas

d’usage générique. Selon le contexte projet de mise en œuvre du cas d’usage, il peut bien sûr être rendu obligatoire.





2.6.1.13. Classe "SavoirFaire"


Specialite: [0..1] Code

Spécialité ordinale.

Les valeurs de ce code sont répertoriées dans la nomenclature TRE_R38 -SpecialiteOrdinale.

Non

Competence: [0..1] Code

Compétence acquise par le professionnel.

Les valeurs de ce code sont répertoriées dans la nomenclature TRE_R39-Competence.

Non

CompetenceExclusive: [0..1] Code

Compétence exclusive.

Les valeurs de ce code sont répertoriées dans la nomenclature TRE_R40-CompetenceExclusive.

Non

OrientationParticuliere: [0..1] Code

Orientation particulière.

Les valeurs de ce code sont répertoriées dans la nomenclature TRE_G13-OrientationParticuliere.

Non

CapaciteSavoirfaire: [0..1] Code

Capacité de médecine.

Les valeurs de ce code sont répertoriées dans la nomenclature TRE_R43-CapaciteSavoirFaire.

Non

QualificationPAC: [0..1] Code

Qualification de praticien adjoint contractuel.

Les valeurs de ce code sont répertoriées dans la nomenclature TRE_R44-QualificationPAC.

Non

FonctionQualifiee: [0..1] Code

Fonction qualifiée.

Les valeurs de ce code sont répertoriées dans la nomenclature TRE_R45-FonctionQualifiee.

Non

DESCNonQualifiant: [0..1] Code

Diplôme d'études spécialisées complémentaires (DESC).

Les valeurs de ce code sont répertoriées dans la nomenclature TRE_R42-DESCnonQualifiant.

Non

DroitExerciceComplementaire: [0..1] Code

Droit d'exercice complémentaire.

Les valeurs de ce code sont répertoriées dans la nomenclature TRE_R97-DroitExerciceCompl.

Non





2.6.2. Flux 2 – PlageDisponibiliteRessource

Le Flux 2 concerne la création, modification ou suppression d’une ou de plusieurs disponibilités pour une ou plusieurs

ressources.

Figure 11: Diagramme de classe - Flux 2





2.6.2.1. Classe "PlageDisponibiliteRessource"


idDisponibiliteRessource : [1..1] Identifiant de la disponibilité d’une ressource Oui

idRessource : [1..1] Identifiant Identifiant de la ressource Oui8

dureeAllocation : [0..1] Heure Durée de temps allouée à chaque rendez-vous (et donc à chaque indisponibilité de la ressource)

Non

debutDisponibilite : [1..1] DateHeure La date et heure à laquelle la ressource est disponible Oui

finDisponibilite : [0..1] DateHeure La date et heure à laquelle la ressource cesse d’être disponible

Non

dateDeclarationPlageDisponibilite : [0..1] DateHeure

Date et heure de la déclaration de disponibilité de la ressource

Non9




Identifiant(s) de la personne prise en charge. Non



idPatient : [0..*] Identifiant Identifiant(s) du patient (identifiants de santé, identifiants locaux, etc.).

Non





Non




8 Il est supposé que le déclarant ayant l’intention de déclarer, modifier ou supprimer des disponibilités de ressources, possède au préalable

leurs identifiants que ce soit par stockage local de l’identifiant (par exemple s’il est l’acteur qui a créé la ressource auprès du gestionnaire

de ressource) ou par interrogation préalable du gestionnaire de ressource (flux hors périmètre du cas d’usage cf. section 2.2). 9 Cette information peut être générée par le système au moment du traitement de la demande.


















2.6.3. Flux 3 – DemandeConsultation

Le Flux 3 concerne la consultation d’agenda d’une ou de plusieurs ressources. La classe

PlageIndisponibilitéRessource dans ce diagramme contient des informations pour identifier les rendez-vous pris

ainsi que leurs détails.

Figure 12 Diagramme de classe – Flux 3

2.6.3.1. Classe "ParamètresGénériques"

Cette classe contient les paramètres génériques de consultation des ressources ainsi que leurs disponibilités.


idRessource : [0..1] Identifiant Identifiant de la ressource Non10

debutDisponibilite: [0..*] DateHeure Début de disponibilité du déclarant Non

finDisponibilite: [0..*] DateHeure Fin de disponibilité du déclarant Non

typeRessource : [0..*] Code Le type de la ressource (équipement, lieu, personne prise en charge, professionnel, etc.)

Non

10 idRessource n’est pas obligatoire dans ce contexte parce que le consommateur peut ne pas avoir cette information au préalable. Par

contre, si le consommateur possède cette information, elle peut tout à fait constituer un critère de recherche.











idPatient : [0..*] Identifiant Identifiant du patient (identifiants de santé, identifiants locaux, etc.). Non





Non





profession : [0..1] Code Profession exercée ou future profession de l'étudiant. Non









Non



Non




Non



Non


Non
















Non




Non



Non



typeEquipement : [0..1] Code Code spécifiant le type de l'équipement (Scanner, IRM, etc.). Non


libelle : [0..1] Texte Libellé de l'équipement. Non

reference : [0..1] Code Référence de l'équipement.

Non





2.6.3.11. Classe "PlageIndisponibiliteRessource"


idRDV : [0..1] Identifiant Identifiant du rendez-vous (indisponibilité) dans l’agenda de la ressource.

Non

dateDebutRDV : [0..1] DateHeure Date et heure du début de rendez-vous Non

dateFinRDV : [0..1] DateHeure Date et heure de la fin du rendez-vous Non

datePriseRDV : [0..1] DateHeure Date à laquelle le rendez-vous est pris Non

typeRDV: [0..1] Code Type de rendez-vous (ex : IRM, PET, consultation générale, etc.) Non

dureeRDV : [0..1] Heure La durée allouée au rendez-vous Non







Non





Non








Non




Non




Non




Non








Non




Non




Non




Non




Non





2.6.4. Flux 4 – ReponseConsultation

Le Flux 4 concerne la réponse du système au Flux 3 – ConsultationAgenda. Il peut contenir les informations

concernant les disponibilités ou les indisponibilités d’une ou de plusieurs ressources qui répondent aux critères de

recherche.

Figure 13 : Diagramme de classe – Flux 4







idDisponibilitéRessource : [1..1] Identifiant Identifiant de la disponibilité de la ressource Oui

idRessource : [1..1] Identifiant Identifiant de la ressource Oui

informationComplementaire : [0..1] Texte Toute information complémentaire concernant la disponibilité de la ressource

Non

debutDisponibilite: [1..1] DateHeure Début de disponibilité du déclarant Oui

finDisponibilite: [1..1] DateHeure Fin de disponibilité du déclarant Oui

dureeAllocation : [0..1] Heure Durée de temps allouée à chaque rendez-vous

Non





Oui










Oui



Non








Oui



Non


Non
















Non




Non



Non




Non





Non









Non









adresse : [0..*] Adresse

Adresse(s) de correspondance permettant de contacter la personne prise en charge : - lorsque les structures ne sont pas identifiées : cas des remplaçants ou des professionnels venant de s’inscrire mais non encore installés; - hors de leurs lieux d’exercice, s’ils le souhaitent. Remarque : La première occurrence correspond aux coordonnées de correspondance du RPPS.

Non


Adresse(s) de télécommunication de la personne prise en charge (numéro de téléphone, adresse email, URL, etc.).

Non



typeEquipement : [0..1] Type Type de l’équipement Non

libelle : [0..1] Texte Nom de l’équipement Non

reference : [0..1] Code La référence de l’équipement Non





Non

dateDebutRDV : [1..1] DateHeure Date et heure du début de rendez-vous Oui

dateFinRDV : [1..1] DateHeure Date et heure de la fin du rendez-vous Oui

datePriseRDV : [0..1] DateHeure Date à laquelle le rendez-vous est pris Non

typeRDV: [0..1] Code Type de rendez-vous (ex : IRM, PET, consultation générale, etc.)

Non

dureeRDV : [0..1] Heure La durée allouée au rendez-vous Non










Non




Non




Non




Non




Non




Non




Non




Non




Non





2.6.5. Flux 5 – PriseRendezVous

Ci-dessous le diagramme de classe concernant la prise de rendez-vous, qui peut affecter une ou plusieurs

ressources dans le système.




idRessource : [1..1] Identifiant Identifiant de la ressource Oui

idDisponibiliteRessource : [0..1] Identifiant

Identifiant de la disponibilité de la ressource Non








Non11

dateDebutRDV : [1..1] DateHeure Date et heure du début de rendez-vous Oui

dateFinRDV : [0..1] DateHeure Date et heure de la fin du rendez-vous Non

datePriseRDV : [0..1] DateHeure Date à laquelle le rendez-vous est pris Non12

typeRDV: [0..1] Code Type de rendez-vous (ex : IRM, PET, consultation générale, etc.)

Non13

dureeRDV : [0..1] Heure La durée allouée au rendez-vous Non14





Non







11 Cette information est générée par le système au moment de la création de la demande rendez-vous. Elle peut ne pas circuler dans le flux

de prise de rendez-vous. 12 Cette information peut être générée par le système au moment de la création de la demande de rendez-vous. Elle peut ne pas circuler

dans le flux de prise de rendez-vous. 13 Cette information peut être générée par le système au moment de la création de la prise de rendez-vous, ou peut être fourni par le

demandeur de rendez-vous. Elle peut ne pas circuler dans le flux de prise de rendez-vous. 14 Cette information peut être générée par le système au moment de la création de la demande de rendez-vous. Par exemple, elle peut

être déduite du type du rendez-vous s’il est supposé que la durée d’un rendez-vous varie selon son type. Elle peut ne pas circuler dans le

flux de prise de rendez-vous.







idPatient : [0..*] Identifiant Identifiant(s) du patient (identifiants de santé, identifiants locaux, etc.). Non















2.6.6. Flux 6 – PropositionAutresRessources




idDisponibiliteRessource : [1..1] Identifiant

Identifiant de la disponibilité de la ressource Oui

idRessource : [1..1] Identifiant Identifiant de la ressource Oui15

debutDisponibilite: [1..1] DateHeure Début de disponibilité du déclarant Oui

finDisponibilite: [0..1] DateHeure Fin de disponibilité du déclarant Non

dureeAllocation : [0..1] Heure Durée de temps allouée à chaque rendez-vous Non

informationComplementaire : [0..1] Texte

Toute information complémentaire concernant la disponibilité de la ressource

Non

15 Cette information circulera dans le flux vers le consommateur (du gestionnaire d’Agenda) qui a l’intention

d’effectuer une prise de rendez-vous.









Oui










Non



Non




Oui



Non


Non
















Non




Non



Non




Non





Oui


Le prénom usuel est un des prénoms inscrit dans l'acte de naissance. Oui









adresse : [0..*] Adresse

Adresse(s) de correspondance permettant de contacter la personne prise en charge : - lorsque les structures ne sont pas identifiées : cas des remplaçants ou des professionnels venant de s’inscrire mais non encore installés; - hors de leurs lieux d’exercice, s’ils le souhaitent. Remarque : La première occurrence correspond aux coordonnées de correspondance du RPPS.

Non


Adresse(s) de télécommunication de la personne prise en charge (numéro de téléphone, adresse email, URL, etc.).

Non







Non



typeEquipement : [0..1] Type Type de l’équipement Non

libelle : [0..1] Texte Nom de l’équipement Non

reference : [0..1] Code La référence de l’équipement Non











Non




Non




Non




Non




Non




Non




Non




Non




Non

2.6.7. Flux 7 – ConfirmationRendezVous

Ce flux est modélisé par le même modèle hiérarchique du Flux 5 étant donné qu’ils peuvent contenir les mêmes

informations métier.





Annexe 1 : Documents de référence

Documents de référence

[1] Formulaire d’expression de besoins remonté par les porteurs de projets, disponible sur demande





Annexe 2 : Historique du document

Version Rédigé par Vérifié par Validé par

0.0.1 ASIP Santé Le 02/01/2016 ASIP Santé Le 02/01/2016 ASIP Santé Le 02/01/2016

Motif et nature de la modification : Diffusion du document pour consultation

0.0.2 ASIP Santé Le 02/02/2018 ASIP Santé Le 02/02/2018 ASIP Santé Le 02/02/2018

Motif et nature de la modification : Prise en compte de nouveaux commentaires

1.0

ASIP Santé Le 04/03/2019 ASIP Santé Le 04/03/2019 ASIP Santé Le 04/03/2019

Motif et nature de la modification : Publication

► Suppression classes Déclarant, DemandeurRDV, AutreTypeRessource ► Ajout classes ServiceSoins, EntiteGéographique, ExerciceProfessionnel, Situation Exercice

1.1

ANS Le 20/05/2020 ANS Le 20/05/2020 ANS Le 20/05/2020

Motif et nature de la modification : Mise à jour suite à l’intégration des commentaires de concertation des

spécifications techniques

► Ajout classe SavoirFaire ► Attributs typeRessource, profession, idPP, adresseSE rendus obligatoires ► IdNat_Struct remplace numFiness ► Ajout attribut idDisponibiliteRessource ► Changement cardinalités debutRDV, finRDV, debutDisponibilite, finDisponibilite, dureeAllocation ► Nom et prénom rendus optionnels

1.2

ANS Le 05/11/2020 ANS Le 05/11/2020 ANS Le 05/11/2020

Motif et nature de la modification :

► Prise en compte des impacts suite à la création de l’annexe INS ► Modification du document au format ANS