Format Address Organization

[paulineheurtebise]

Description du problème

Bonjour, Remontée de la CNAM, le format de l'adresse ne respecte la la structure definition.

Fichier•s concerné•s

Plusieurs exemples trouvés avec les id : 001-02-33182 ou 001-02-76018

Solution proposée

[mchaabaoui]

Je ne suis pas certain d'avoir bien compris la question. cela dit, dans l’API, les lignes d'adresse comportent des extensions et sont plus complètes que celles originales (uniquement un string). On y retrouvera par exemple le numéro et le nom de la rue de manière distincte et typée. Comme la ligne d'adresse n'est constituée que d'extensions, il faut noter cela en JSON avec un "_" (cas d'un champ primitif string). Le null indique qu'il faut aller regarder dans le champ _line[0]. La plupart des clients FHIR comprennent cette notation. En résumé, cette notation est liée à la norme lors de l'utilisation de JSON pour le format de réponse.

[paulineheurtebise]

Tout à fait pour le "_line" . En revanche je trouve ca étonnant d'avoir le bloc "line": [null] car le service ne doit pas renvoyer les attributs non renseignés, il n'y a pas besoin de ce bloc si uniquement les extensions sont saisies, juste la part "_line" suffit non ?

[mchaabaoui]

j'ai cru comprendre (à reconfirmer avec le développeur ayant implémenté la solution) que l'on n'avait pas le choix. c'est la norme qui impose cette notation. j'ai discuté avec @nriss sur ce sujet étant donné que ça soulève beaucoup de questions de la part des clients. l'une des pistes évoquée étant de remplir également l'adresse line avec l'adresse complète ??? A suivre ...

[nriss]

Normalement, il ne faut pas qu'il y ait de null comme indiqué ici :

https://www.hl7.org/fhir/R4/json.html#primitive

Je propose que : soit on enlève "line", soit on remplace par l'adresse complète si on l'a

[mchaabaoui]

je partage le retour de @ansforge/synodis à ce sujet.

En fait, le null est présent car c'est un tableau. Le rendu que nous produisons est ok. Après je sais que ce point embête pas mal de gens mais c'est nécessaire en javascript. Voici la doc qui en réfère :

Pour comprendre pourquoi cela est fait comme cela, imaginons que nous avons un tableau avec valeur + extensions. nous aurions : line: [valeur1, valeur2...] _line: [extention1, extension2....]

Mais si valeur 1 est null, il faut bien conserver l'index pour savoir que valeur 2 est associé à extension 2 : line: [null, valeur2...] _line: [extention1, extension2....]

Et donc il faut toujours avoir un élément du tableau dans le champ lié à la valeur.

[paulineheurtebise]

Ce qui m’embête c'est que pour moi on est pas exactement dans ce cas là. Nous il y a pas de valeur2 dans l'exemple, il y a juste null. Et de ma compréhension s'il y a juste null il y a pas de nécessité à renvoyer l'attribut. A mon sens aujourd'hui nous avons : line : [null] -->tableau complétement vide _line : [extension1, extension2, extension3]

Et pour moi on devrait juste avoir : _line : [extension1, extension2, extension3]

D'ailleurs quand je génère cet exemple à partir des fsh il met uniquement le _line.

[nriss]

D'accord avec toi @paulineheurtebise, la spec concerne un élément multivalué natif, les null sont rajoutés dans les extensions dans le cas où il n'y a pas d'extension pour l'attribut associé.

Dans l'exemple de l'API annuaire, les null sont au niveau de l'attribut natif, ce qui est différent.

En quoi est-ce qu'il y a un problème avec le JSON si on ne met pas null dans line ?