Open Mathieu-Rousseau opened 2 months ago
@Mathieu-Rousseau tu ne vois pas la diff entre PUT et PATCH du coup?
created : oui si la création via adossement RASS compte.
est ce que vous faites bien un POST de la ressource ?
@sdemeyANS Vu avec les devs on ne fait ni de POST ni de PUT ni de PATCH via l'adossement RASS
@sdemeyANS Vu avec les devs on ne fait ni de POST ni de PUT ni de PATCH via l'adossement RASS
Même pour la partie CRUD Serveur @Mathieu-Rousseau ?
Oui en effet sur aucun des deux
Oui en effet sur aucun des deux
@Mathieu-Rousseau du coup vous ne faites pas de post put et patch même hors adossement RASS?
Non en effet, on fait du PUT sur task et questionnaire, et du put et patch sur task en 3.2 mais c'est tout
Non en effet, on fait du PUT sur task et questionnaire, et du put et patch sur task en 3.2 mais c'est tout
comment vous créez et modifiez vos ressources du coup? @Mathieu-Rousseau
et cette partie des specs doit repasser en draft? @Mathieu-Rousseau https://interop.esante.gouv.fr/ig/fhir/ror/0.4.0-snapshot-1/miseAjour_offre.html et celle-ci aussi ? https://interop.esante.gouv.fr/ig/fhir/ror/0.4.0-snapshot-1/saisie_offre.html
et cette partie des specs doit repasser en draft? @Mathieu-Rousseau https://interop.esante.gouv.fr/ig/fhir/ror/0.4.0-snapshot-1/miseAjour_offre.html et celle-ci aussi ? https://interop.esante.gouv.fr/ig/fhir/ror/0.4.0-snapshot-1/saisie_offre.html
Je te confirme qu'il faut les repasser en draft
Après avoir regardé avec l'équipe de DEV la seul opération FHIR de créa/modif développé en 3.2 semble être le PATCH sur Location
Après analyse l'IG qui va être publié semble présenté des différences avec ce qui à été développé en 3.2.
Normalement c'est à l'implémentation (le dev) d'être en cohérence avec le guide d'implémentation pas l'inverse....
Et on aurait pu faire de la qualité plutôt que de développer sans cesse des nouvelles features qui ne seront jamais développées.. L'IG en a bien besoin, de qualité..
Ce qui n'est pas possible à faire tant que l'API développée n'est pas versionnée et qu'on nous demande toujours des nouvelles features en dernière minute
et cette partie des specs doit repasser en draft? @Mathieu-Rousseau https://interop.esante.gouv.fr/ig/fhir/ror/0.4.0-snapshot-1/miseAjour_offre.html et celle-ci aussi ? https://interop.esante.gouv.fr/ig/fhir/ror/0.4.0-snapshot-1/saisie_offre.html
Je te confirme qu'il faut les repasser en draft
Après avoir regardé avec l'équipe de DEV la seul opération FHIR de créa/modif développé en 3.2 semble être le PATCH sur Location
il va falloir refaire une repasse sur tout l'IG dans ce cas pour mettre à jour les étiquettes draft dans ce cas. Pour le capability statement @Mathieu-Rousseau peux tu me fournir celui du ROR 3.2 en prod stp ?
D'ailleurs, c'est une mauvaise pratique d'indiquer draft dans l'IG, il faudrait :
Ca enlève la dépendance IG / serveur, qui est nécessaire à ce stade, les deux doivent évoluer de manière parallèle
- @Mathieu-Rousseau fournir le Capability statement ROR 3.2
@Mathieu-Rousseau pour faciliter la lecture et voir les différences, j'ai créé la branche https://github.com/ansforge/IG-fhir-repertoire-offre-ressources-sante/tree/test-cs-ror-prod32 et ajouté le Capability Statement de la prod ROR 3.2 : preview: https://ansforge.github.io/IG-fhir-repertoire-offre-ressources-sante/test-cs-ror-prod32/ig/artifacts.html
Je vois pas mal de diff entre le Capability de prod https://ansforge.github.io/IG-fhir-repertoire-offre-ressources-sante/test-cs-ror-prod32/ig/CapabilityStatement-ror-serveur-prod.html et celui des specs https://ansforge.github.io/IG-fhir-repertoire-offre-ressources-sante/test-cs-ror-prod32/ig/CapabilityStatement-ror-serveur.html
@sdemeyANS Comme vu ensemble lundi je te confirme qu'au niveau du CRUD :
En ce qui concerne les spécifications techniques :
Avait tu besoin d'autre chose pour la 3.2 ?
- Pour le Patch c'est uniquement sur Location et Task
- Pour le Post c'est uniquement sur Task et Questionnaire
cela ne correspond pas au capability statement du ROR 3.2 de prod que tu m'a fourni. Est-ce normal? https://ansforge.github.io/IG-fhir-repertoire-offre-ressources-sante/test-cs-ror-prod32/ig/CapabilityStatement-ror-serveur-prod.html
Description du problème
Après analyse l'IG qui va être publié semble présenté des différences avec ce qui à été développé en 3.2.
Pour le CRUD Serveur Location : read : oui search : oui updated / Patch : je ne suis pas certain de comprendre la différence entre les deux, quoi qu'il en soit aujourd'hui il est possible de modifier une partie de la location uniquement via API, via l'adossement RASS quasiment toutes les données sont modifiable. created : oui si la création via adossement RASS compte.
HealthcareService : read : oui search : oui updated / Patch : je ne suis pas certain de comprendre la différence entre les deux, quoi qu'il en soit aujourd'hui il est possible de modifier une partie du healthcare uniquement via API, via l'adossement RASS quasiment toutes les données sont modifiable. created : oui si la création via adossement RASS compte.
Organization : read : oui search : oui updated / Patch : je ne suis pas certain de comprendre la différence entre les deux, quoi qu'il en soit aujourd'hui il n'est pas possible de modifier une organization via API, via l'adossement RASS quasiment toutes les données sont modifiable. created : oui si la création via adossement RASS compte.
Practitioner : read : oui search : oui updated / Patch : je ne suis pas certain de comprendre la différence entre les deux, quoi qu'il en soit aujourd'hui il n'est pas possible de modifier un practitioner via API, via l'adossement RASS quasiment toutes les données sont modifiable. created : oui si la création via adossement RASS compte.
PractitionerRole : read : oui search : oui updated / Patch : je ne suis pas certain de comprendre la différence entre les deux, quoi qu'il en soit aujourd'hui il n'est pas possible de modifier un practitionerRole via API, via l'adossement RASS quasiment toutes les données sont modifiable. created : oui si la création via adossement RASS compte.
Questionnaire : read : oui search : non updated / Patch : je ne suis pas certain de comprendre la différence entre les deux, quoi qu'il en soit aujourd'hui il n'est pas possible de modifier un Questionnaire. created : oui
Pour le CRUD Consommateur Location : read : oui search : oui updated / Patch : je ne suis pas certain de comprendre la différence entre les deux, quoi qu'il en soit aujourd'hui il n'est pas possible de modifier une Location via API. created : non
HealthcareService : read : oui search : oui updated / Patch : je ne suis pas certain de comprendre la différence entre les deux, quoi qu'il en soit aujourd'hui il n'est pas possible de modifier un healthcare via API created : non
Organization : read : oui search : oui updated / Patch : je ne suis pas certain de comprendre la différence entre les deux, quoi qu'il en soit aujourd'hui il n'est pas possible de modifier une organization via API. created : non.
Practitioner : read : oui search : oui updated / Patch : je ne suis pas certain de comprendre la différence entre les deux, quoi qu'il en soit aujourd'hui il n'est pas possible de modifier un practitioner via API. created : non
PractitionerRole : read : oui search : oui updated / Patch : je ne suis pas certain de comprendre la différence entre les deux, quoi qu'il en soit aujourd'hui il n'est pas possible de modifier un practitionerRole via API. created : non
Questionnaire : read : oui search : non updated / Patch : je ne suis pas certain de comprendre la différence entre les deux, quoi qu'il en soit aujourd'hui il n'est pas possible de modifier un Questionnaire. created : non
Solution proposée
Il faudrait modifier l'IG en conséquence. Ceci étant dit n'aillant pas toute les informations pour comprendre la différence entre updated et patch, j'espère que tu trouvera la toute les informations nécessaire.