Réflexion par rapport à PractitionerRole.extension[as-ext-practitionerrole-name]

[nriss]

Est-ce cohérent que le PractitionerRole ait un nom ? En FHIR, c'est dans Practitioner qu'il faudrait mettre le nom (discuté avec @M-Priour )

[mchaabaoui]

ça se discute. une réunion interne été programmée sur ce sujet avec la participation de toutes les parties prenantes

[nriss]

• Nom - prénom dans le PractitionerRole : les noms et prénoms choisis dans le cadre d'une profession (donnée publique)
• Nom - prénom dans la ressource Practitioner : le noms et prénoms d'état civil (donnée restreinte)

L'usage de l'extension associée à PractitionerRole est pertinent pour décrire le nom associé (et choisi par le PS) à un exercice professionnel. Un praticien peut avoir plusieurs rôles, et pour chacun des rôle, il pourra renseigner le nom au choix à l'ordre en question.

Discuté le 26.05.2023 avec @mchaabaoui, @isa-ans, @nriss, Alexis Breithoff

[flrt]

Dans l'extraction publique (à plat), nous avons 1,7 million d'entrées.

Le nombre de PS ayant 2 noms d'exercice différents est au nombre de 91 ! Je ne vais pas faire le ratio en pourcentage tellement il est proche de 0…

Comme évoqué précédemment, il me semble vraiment raisonnable de :

• positionner l'identité de practitioner dans les champs prévus à cet effet
• supprimer l'extension sur practitionerRole
• avoir 91 resources Practitioner en double : 2 ressources Practitioner pour 1 même PS. Les id seraient différents mais pas l'identifier métier. FHIR est prévu pour cela.

[nriss]

Informations complémentaires:

• Le nom du PractitionerRole est le seul accessible dans les données publiques. Le nom officiel est une donnée restreinte.
• Le nom est vraiment associé à un PractitionerRole, il est choisi et donné par le PS lors de son inscription à l'ordre.
• Le nombre de PS ayant des noms d'exercices différents va augmenter avec de nouveaux types de PS dans le RPPS

Les usagers FHIR vont néanmoins s'attendre à avoir le nom dans Practitioner.name => Oblige du dev custom pour chercher dans l'extension

[nriss]

Au vu de la difficulté de décision dû aux impacts difficiles à estimer, la solution dans le nom du PractitionerRole est une solution satisfaisante et fonctionnelle nous permettant de reporter ces travaux.

[flrt]

donc en résumé, comme vous ne savez pas mesurer l'impact (?), alors qu'il faut un jeton pour accéder à l'API, et qu'une vraie concertation avec les utilisateurs pourrait lever les doutes, l'issue est clôturée.

L'extension ajoutée perdure alors que dans le même temps l'ANS recommande de limiter les extensions...

Difficile à comprendre.

[abreithoff]

Bonjour Mr Laurent,

au delà de la modélisation FHIR et du nombre de cas effectif en production, la manière dont le nom et prénom d'exercice sont enregistrés par les autorités compétentes nécessite d'offrir dans le modèle la possibilité d'un nom et prénom différent par couple "profession-civilité d'exercice (c'est à dire militaire, civil, étudiant)", en plus du nom et prénom existants sur l'état civil du professionnel, qui lui est unique. Il nous semble donc plus logique de positionner ces deux données au sein de la ressource contenant ces deux informations (profession et civilité d'exercice) pour ne pas disposer d'un modèle contraignant. Dans le cas contraire, il faudrait pouvoir spécifier dans practitionner le fait qu'un nom et prénom d'exercice correspond à tel ou tel profession (médecin, pharmacien ou autre), afin que les consommateurs de l'API puissent adapter le nom et prénom affichés à la profession concernée. Concernant le fait qu'il s'agit d'une extension, nous espérons, sur la base de notre raisonnement, pouvoir faire évoluer le modèle standard dans le futur pour prise en compte de ces modalités d'enregistrement.

[flrt]

Je ne comprends pas la dernière phrase. Que veut dire "faire évoluer le modèle standard...pour prise en compte de ces modalités d'enregistrement" ?

[abreithoff]

Désolé, ce n'était effectivement pas très clair. Il s'agit de tenter d'intégrer dans le standard FHIR français cette notion de nom et prénom d'exercice professionnel qui est spécifique à notre modélisation nationale pour éviter de passer par une extension.

[cdelanchy]

Bonjour,

Je comprends tout à fait la logique de distinction nom/prénom civil et nom/prénom d'exercice, et que l'une est privée et l'autre est publique et liée à un exercice. Si on met tout dans le Practitioner, cela va compliquer le lien entre les différents exercices/situations d'exercice, et ça va être dur de dire, lors d'une recherche, quels Practitioner peuvent être affichés (car données publiques) et lesquels ne peuvent pas (données privées).

N'est-il pas possible de faire entrer en jeu la ressource Person qui correspond à la Personne Physique (état civil), reliée à n Practitioner. Les Person contiennent alors les données privées (nom/prénom état civil) et les autres sont publiques. Je jette un peu une idée en l'air, mais sait-on jamais ?

Enfin, je ne comprends pas non plus la partie "intégrer dans le standard FHIR français" : il n'y a, à ma connaissance, qu'un seul standard FHIR (l'international). On y ajoute des profils spécifiques pour la France (via l'ANS et Interop'Santé) ; il ne me semble pas que l'on s'engage sur la création d'un autre standard spécifique à la France ?

[nriss]

@cdelanchy tu imagines donc qqc comme:

• Person contient le nom et le prenom d'état civil
• Practitioner contient le nom d'exercice, autant de Practitioner que de situation d'exercice par PS

C'est bien ça ?

Je me souvient que Luc Chatty avait suggéré l'usage de Person lors du PAt effectivement, il y a clairement qqc à creuser, je me pose aussi la question de la complexité / de la conduite du changement : est-ce que l'effort en vaut la peine ? J'ai du mal à concevoir la balance bénéfices - risques

Qu'en penses-tu @MohammedChaabaoui ?

[cdelanchy]

Oui, c'est à ça que je pense, @nriss. Mais je ne suis pas du tout un expert en modélisation, donc je ne peux pas dire si ça match tous les uses-cases ou pas.

[LucChattyFyrstain]

Hello ! je jump dans la discussion ! Nous avons effectivement évoqué lors du Projectathon l'usage de la Resource Person. Mais je rejoins @nriss sur le ROI pas clair en l'état actuel des choses (refonte du modèle, qui vient déjà d'être refondu). Un middle ground entre la solution de @flrt (https://github.com/ansforge/IG-fhir-annuaire/issues/21#issuecomment-1570175375) et celle de @cdelanchy (https://github.com/ansforge/IG-fhir-annuaire/issues/21#issuecomment-1757092136) pourrait être le suivant :

• Si le nom d'exercice est effectivement donné lors de l'inscription à l'ordre alors il me semble logique d'avoir un Practitioner par ordre.
• Concernant la gestion des noms, Practitioner.name est un tableau. On peut avoir un name de type usual et un name de type official avec l'un des deux n'étant pas accessible dans les données publiques.
• L'impact sera juste qu'effectivement, on peut s'attendre avoir plusieurs Practitioner avec le même identifiant métier (ou pas ? quid du RPPS avec l'inscription à plusieurs ordres ?)
• Cela évite de devoir rajouter une ressource supplémentaire (Person) dont bien que j'en soit fan, l'utilité me semble discutable pour répondre aux besoins de 91 professionnels. Si en revanche ce cas de figure à vocation à s'étendre il faudra peut-être y réfléchir.

Sur la partie modélisation je manque un peu d'information sur les besoins pour être sur que ça matche tous les use-cases, mais je suis preneur si il y a des docs de travail

[abreithoff]

Le cas de figure a vocation à s'étendre dans les prochaines années : nous avons aujourd'hui 7 professions à ordre et demain l'ensemble des professions ADELI en 2024 + les professionnels à rôle. Les croisements vont donc devenir de plus en plus nombreux, partant du principe qu'un professionnel à la fois médecin et pharmacien, c'est rare mais pas impossible (il faut avoir fait beaucoup d'étude ☺️) mais qu'un médecin - psychologue (profession Adeli) beaucoup moins. Un médecin exerçant une des nombreuses professions à rôle, cela le sera encore moins. Je note l'idée de l'intégration de la ressource "Person" qui rend l'ensemble plus pertinent. Dans ce modèle, on se repositionnerait sur 3 ressources à l'image du Modèle d'objets de Santé : personne physique, professionnel, Exercice professionnel/situation d'exercice. Mais cela ne change pas le fond : Le positionnement du nom d'exercice dans practitioner sans y basculer la profession et la civilité d'exercice n'a pas de sens à mon avis. Basculer les 3 est nécessaire pour déterminer quel nom d'exercice a été enregistré par quelle autorité d'enregistrement. En effectuant cette bascule complète, on ferait le choix de fusionner "professionnel/exercice professionnel" dans practitioner d'un côté et la situation d'exercice dans practitionerRole de l'autre. C'est un choix que nous avons écarté initialement au profit de la fusion Exercice professionnel/situation d'exercice dans practitionerRole.

[LucChattyFyrstain]

Le cas de figure a vocation à s'étendre dans les prochaines années : nous avons aujourd'hui 7 professions à ordre et demain l'ensemble des professions ADELI en 2024 + les professionnels à rôle. Les croisements vont donc devenir de plus en plus nombreux, partant du principe qu'un professionnel à la fois médecin et pharmacien, c'est rare mais pas impossible (il faut avoir fait beaucoup d'étude ☺️) mais qu'un médecin - psychologue (profession Adeli) beaucoup moins. Un médecin exerçant une des nombreuses professions à rôle, cela le sera encore moins. Je note l'idée de l'intégration de la ressource "Person" qui rend l'ensemble plus pertinent. Dans ce modèle, on se repositionnerait sur 3 ressources à l'image du Modèle d'objets de Santé : personne physique, professionnel, Exercice professionnel/situation d'exercice. Mais cela ne change pas le fond : Le positionnement du nom d'exercice dans practitioner sans y basculer la profession et la civilité d'exercice n'a pas de sens à mon avis. Basculer les 3 est nécessaire pour déterminer quel nom d'exercice a été enregistré par quelle autorité d'enregistrement. En effectuant cette bascule complète, on ferait le choix de fusionner "professionnel/exercice professionnel" dans practitioner d'un côté et la situation d'exercice dans practitionerRole de l'autre. C'est un choix que nous avons écarté initialement au profit de la fusion Exercice professionnel/situation d'exercice dans practitionerRole.

Je pense qu'alors il faudra réfléchir à une nouvelle modélisation avec la ressource Person, mais je ne le ferai pas dans un premier temps. Je suis d'accord que cela transforme le Practitioner en situation d'exercice et la Person en l'identité, mais c'est ce que ces ressources sont faites pour faire, cela ne me choque pas (je suppose @abreithoff que le choix initial a été fait sans la ressource Person dans le scope ?)

Côté Hospitals On FHIR le sujet devrait arriver sur le tapis. Je propose d'attendre un feedback sur les besoins terrain hospitaliers (en particulier stockage FHIR de leur côté des ressources FHIR) avant de se lancer dans un refacto de la modélisation.

La question est plus, avons nous besoin d'une modélisation intermédiaire pour les noms @flrt, @nriss si on se dit que la cible sera un potentiel refacto avec la ressource Person en 2024 ?

[nriss]

Le cas de figure a vocation à s'étendre dans les prochaines années : nous avons aujourd'hui 7 professions à ordre et demain l'ensemble des professions ADELI en 2024 + les professionnels à rôle. Les croisements vont donc devenir de plus en plus nombreux, partant du principe qu'un professionnel à la fois médecin et pharmacien, c'est rare mais pas impossible (il faut avoir fait beaucoup d'étude ☺️) mais qu'un médecin - psychologue (profession Adeli) beaucoup moins. Un médecin exerçant une des nombreuses professions à rôle, cela le sera encore moins. Je note l'idée de l'intégration de la ressource "Person" qui rend l'ensemble plus pertinent. Dans ce modèle, on se repositionnerait sur 3 ressources à l'image du Modèle d'objets de Santé : personne physique, professionnel, Exercice professionnel/situation d'exercice. Mais cela ne change pas le fond : Le positionnement du nom d'exercice dans practitioner sans y basculer la profession et la civilité d'exercice n'a pas de sens à mon avis. Basculer les 3 est nécessaire pour déterminer quel nom d'exercice a été enregistré par quelle autorité d'enregistrement. En effectuant cette bascule complète, on ferait le choix de fusionner "professionnel/exercice professionnel" dans practitioner d'un côté et la situation d'exercice dans practitionerRole de l'autre. C'est un choix que nous avons écarté initialement au profit de la fusion Exercice professionnel/situation d'exercice dans practitionerRole.

Je pense qu'alors il faudra réfléchir à une nouvelle modélisation avec la ressource Person, mais je ne le ferai pas dans un premier temps. Je suis d'accord que cela transforme le Practitioner en situation d'exercice et la Person en l'identité, mais c'est ce que ces ressources sont faites pour faire, cela ne me choque pas (je suppose @abreithoff que le choix initial a été fait sans la ressource Person dans le scope ?)

Côté Hospitals On FHIR le sujet devrait arriver sur le tapis. Je propose d'attendre un feedback sur les besoins terrain hospitaliers (en particulier stockage FHIR de leur côté des ressources FHIR) avant de se lancer dans un refacto de la modélisation.

La question est plus, avons nous besoin d'une modélisation intermédiaire pour les noms @flrt, @nriss si on se dit que la cible sera un potentiel refacto avec la ressource Person en 2024 ?

Je pense effectivement que le refacto aura du sens plus tard !

J'ai également l'impression que ce changement de nom n'a pas de ROI énorme, mettre le nom dans PR me semble ok et tout à fait à la portée des éditeurs de chercher le nom dans l'extension (et le nom officiel dans Practitioner.name pour les personnes ayant les autorisations)

[flrt]

Inconvénients de la modélisation actuelle :

• La ressource Practitioner qui contient l'identité du professionnel dans la spécification FHIR est vide de sens concernant l'identité puisqu'elle n'est pas accessible
• La ressource PractitionerRole qui est définie par le standard FHIR comme une relation modélisant le role d'un professionnel de santé dans une organisation (au sens large) se voit augmentée de données sur le nom qui dépassent son périmètre de définition
• pour permettre l'ajout d'un nom dans la ressource PractitionerRole, il est nécessaire de définir une extension regroupant les données du nom qui sont déjà définies dans Practitioner
• les recherches simples de professionnel avec on identifant (RPPS) nécessitent des recherches liées, plus couteuses (en expression, temps de traitement serveur et client, volume de données échangées) et moins claires

Les cas d'utilisation majoritaires

• chercher le RPPS d'un professionnel avec son nom : Avec la modélisation actuelle, il faut 2 ressources et une recherché liée, systématiquement. En ayant le nom, à sa place dans Practitioner, une seule resource est nécessaire. Une recherche simple (sur une seule ressource mais aussi avec l'expressivité du standard) et efficace
• chercher à quel professionnel correspond 1 RPPS : Une recherche sur Practitioner suffit dans 99% des cas. Pour quelques cas, à la marge, il y a plusieurs résultats et il faut en effet, refaire une recherche en impliquant PractitionerRole pour en savoir plus. Si le nom est sur PractitionerRole, il y aura également plusieurs résultats, sauf que la recherche sera systématiquement plus complexe.

Quant au ROI :

• simplifier l'utilisation de l'API
• rester dans l'esprit de FHIR et de la loi de Pareto
• être plus proche du standard et donc plus facilement compréhensible, sans demander de traitement spécifique pour les développeurs
• limiter l'utilisation des extensions, surtout quand les concepts existent déjà dans le standard, et donc être conformes aux préconisations de l'ANS

En enfin, sur les impacts, je pense que ce n'est pas un problème, c'est toujours en beta. Donc entendable. Pourquoi ne pas interroger les principaux utilisateurs du service ? Et intégrer le nom comme extension dans PractitionerRole de façon généralisée (au niveau de fr.core) ne doit pas être fait, de mon point de vue.