ansforge / IG-fhir-repertoire-offre-ressources-sante

Définition des spécifications de l'API FHIR pour utiliser le Répertoire national de l’Offre et des Ressources en santé et accompagnement médico-social (ROR).
https://interop.esante.gouv.fr/ig/fhir/ror/
MIT License
2 stars 1 forks source link

Quelques questions sur patch Location #322

Closed jcserafini closed 2 months ago

jcserafini commented 4 months ago

Description du problème

Quelques questions sur l'implémentation de patch sur Location:

  1. Content type : Selon la spec FHIR, il y a 4 type de requêtes PATCH différentes en fonction du contentType :

Json patch : "application/json-patch+json" Xml patch : "application/xml-patch+xml" FHIRPath Patch json : "application/fhir+json" FHIRPath Patch xml : "application/fhir+xml"

l'IG ne précise pas ce qui est à implémenter et d'après les exemples le format est plutôt pour un FHIRPath Patch json (https://hl7.org/fhir/R4/fhirpatch.html) soit : "application/fhir+json"

On devrait donc implémenter le FHIRPath Patch json : ** "application/fhir+json", mais l'IG ne précise pas au consommateur le contentType à utiliser

2. Mais du coup l'implémentation sur l'API Anomalies demande le mauvais contentType : "application/json-patch+json" au lieu de "application/fhir+json" car on traite bien le cas d'un FHIRPath Patch json **

Si c'était du "application/json-patch+json", la RFC du json patch (https://datatracker.ietf.org/doc/html/rfc6902#page-6) détail le format de la requête qui devrait être du type :

[ { "op": "replace", "path": "/a/b/c", "value": 42 } ]

Et la RFC précise :

"Operation objects MUST have exactly one "op" member" "Additionally, operation objects MUST have exactly one "path" member. That member's value is a string containing a JSON-Pointer value RFC6901 that references a location within the target document (the "target location") where the operation is performed."

On est donc pas du tout sur ce type de patch, mais bien sur un FHIRPath Patch json : ** "application/fhir+json"

3. Il y à aussi un point flou sur le contenu de la requête. La documentation hl7 n'est pas clair sur ce point. Dans la doc du FHIRPath Patch(R4) il n'y a que les objets Parameters (https://hl7.org/fhir/R4/parameters.html) de mentionnés. Par contre la documentation des objets Bundle (https://hl7.org/fhir/R4/bundle.html) semble dire qu'on peut aussi les utiliser pour le PATCH (et toutes les autres méthode HTTP).

Doit on implémenter un seul en particulier ? Si oui, lequel ?

Si on doit implémenter les objets Bundle il y a plusieurs comportement possibles : https://hl7.org/fhir/R4/valueset-bundle-type.html

Dans notre cas d'usage on est surtout concerné par : * Transaction : The bundle is a transaction - intended to be processed by a server as an atomic commit.

Batch : The bundle is a set of actions - intended to be processed by a server as a group of independent actions.

Mais ils demandent chacun un traitement différent. L'IG n'a aucune info la dessus.

4 En revenant sur le PATCH des Anomalies, l'IG (https://ansforge.github.io/IG-fhir-repertoire-offre-ressources-sante/283-scenario-manquant-modification-donnees-capacitaires/ig/specifications_techniques_6.html) donne en exemple un objet de type Parameters mais anomalie implémente seulement un objet Bundle (https://hl7.org/fhir/R4/bundle.html) qui entoure le Parameters, mais ne supporte pas le Parameters seul.

Il y a donc un écart entre l'IG et ce qui est implémenté dans le ROR.

5 Je me demande aussi si il y a un sujet avec la norme FHIR et le scénario 1 du powerpoint. La spec fhir du patch dit : * "The FHIRPath statement must return a single element"

de ce que je comprend du path dans l'exemple de l'IG :

{ "name": "path", "valueString": "Location.extension.where(url='https://interop.esante.gouv.fr/ig/fhir/ror/StructureDefinition/ror-location-supported-capacity')" }

Il cible toutes les extensions "ror-location-supported-capacity" qui est une liste de valeurs (en tout cas les UE et les Structures de rattachement ont une liste de "DetailCapacite" )

Impossible de cibler une "ror-location-supported-capacity", donc si je comprend bien dans tous les cas on ne remplace pas les valeurs mais on supprime et récré toutes les "ror-location-supported-capacity" de la location ?

Dans ce cas que fait on si il n'y a pas le même nombre dans le PATCH que dans la base ?

sdemeyANS commented 4 months ago

5 Je me demande aussi si il y a un sujet avec la norme FHIR et le scénario 1 du powerpoint. La spec fhir du patch dit : * "The FHIRPath statement must return a single element"

de ce que je comprend du path dans l'exemple de l'IG :

{ "name": "path", "valueString": "Location.extension.where(url='https://interop.esante.gouv.fr/ig/fhir/ror/StructureDefinition/ror-location-supported-capacity')" }

Il cible toutes les extensions "ror-location-supported-capacity" qui est une liste de valeurs (en tout cas les UE et les Structures de rattachement ont une liste de "DetailCapacite" )

Impossible de cibler une "ror-location-supported-capacity", donc si je comprend bien dans tous les cas on ne remplace pas les valeurs mais on supprime et récré toutes les "ror-location-supported-capacity" de la location ?

Dans ce cas que fait on si il n'y a pas le même nombre dans le PATCH que dans la base ?

précision il s'agit du scenario https://ansforge.github.io/IG-fhir-repertoire-offre-ressources-sante/main/ig/specifications_techniques_10.html#bed-management-sc%C3%A9nario-9-remplacement-de-toutes-les-donn%C3%A9es-capacitaires-draft

sdemeyANS commented 4 months ago

@mlr-kereval je te laisse prendre la suite. merci :)

mlr-kereval commented 4 months ago

Bonjour,

1/2. Le format supporté dans cet IG est bien le FHIRPath Patch JSON : application/fhir+json. Cette information est indiquée dans les capabilityStatement . Souhaitez-vous faire apparaitre le format à utiliser au niveau des tableaux "Construction de la requête de base" ?

3/4. Les scénarios actuels mettent à jour une seule ressource via une requête PATCH et n'utilisent donc pas le bundle. Concernant le PATCH des anomalies, le scénario a évolué pour une mise à jour unitaire. Le bundle a donc été retiré (#256).

  1. Ces risques ont été identifiés : • PR-304 : Nous n'avons pas trouvé de documentation permettant de valider avec certitude la syntaxe proposée. La requête n'a pas pu être testée sur HAPI/Matchbox. • L'expression proposée cible toutes les extensions "ror-location-supported-capacity". Le principe du PATCH est d'écraser les anciennes données par les nouvelles. Ce sujet a été abordé lors de l'atelier du 25/01. Il a été décidé de mettre à jour l'ensemble des capacités avec ce risque de supprimer potentiellement des capacités. Nous pouvons ajouter en préconisation de mettre la capacité à 0 au lieu de la supprimer.
sdemeyANS commented 4 months ago

@Mathieu-Rousseau je te laisse transmettre ce retour au dev?

sdemeyANS commented 3 months ago

@Mathieu-Rousseau est-ce que cette issue peut être close?

sdemeyANS commented 2 months ago

@Mathieu-Rousseau est-ce que cette issue peut être close?

N'ayant pas eu de retour je clos. @Mathieu-Rousseau n'hésite pas à rouvrir l'issue si nécessaire :)