Base de données publique des médicaments vétérinaires autorisés en France

Bonjour Monsieur BONY, Merci pour votre contribution. Je prends en charge votre demande et reviens vers vous dès qu'une explication de cette erreur est identifiée. Cordialement, Dominique VALLEE

Bonjour Mme VALLEE, Merci pour votre retour. Au passage, vous pouvez également voir pour le <term-qsp> 6702 qui est également utilisé en tant que code dans les données mais n'est pas présent dans la définition. A l'exception de ces deux codes (6702 et 6946). L'intégralité des données est bien correctement référée à des codes définis, pour toute les autres références. Bien cordialement, Pierre BONY

Merci, monsieur Vallée ira bien (sourire) Je tâche de vous apporter une réponse dans la semaine Dominique VALLEE

Pardon... Je vous prie de m'excuser Mr VALLEE :-)

reBonjour Monsieur, En fait il s'agit d'unités... Je vais effectuer une correction pour que ce soit plus clair (remplacement de term-qsp par term-unite). Ne voulez-vous pas plutôt parler de 9702 ? Dominique VALLEE

Dans le fichier de données amm-vet-fr-v2-v.xml horodaté au [14/11/2024 13:20:01] Par exemple, pour le <medicinal-product> <src-id>1594</src-id> <nom>CANIGEN CHP/L</nom> <num>0374140</num> ... <excipient-qsp> <qte-qsp>1</qte-qsp> <term-qsp>6946</term-qsp> => ici, le <term-qsp> 6946 n'existe pas dans le fichier de définitions amm-vet-fr-v2-d.xml <term-pres /> </excipient-qsp> Egalement, pour <src-id>2670</src-id> <nom>VAXXITEK HVT+IBD SUSPENSION ET SOLVANT POUR SUSPENSION INJECTABLE</nom> <num>0776969</num> ... <excipient-qsp> <qte-qsp>1</qte-qsp> <term-qsp>6702</term-qsp> => ici, le <term-qsp> 6702 n'existe pas dans le fichier de définitions amm-vet-fr-v2-d.xml <term-pres>7210</term-pres> </excipient-qsp> Il existe bien une unité 6702: <entry> <source-code>6702</source-code> <source-desc>A DEFINIR</source-desc> </entry> et 6946 : <entry> <source-code>6946</source-code> <source-desc>Unité</source-desc> </entry> MAIS la définition xsd founie dans amm-vet-fr-v2-v.xsd : <xs:element name="excipient-qsp" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="qte-qsp" type="xs:string" minOccurs="0" /> <xs:element name="term-qsp" type="xs:string" minOccurs="0" /> <xs:element name="term-pres" type="xs:string" minOccurs="0" /> </xs:sequence> </xs:complexType> </xs:element> Ne permet PAS d'y ajouter un <term-unite> sans modification du xsd. J'ai d'ailleurs une question sur l'élément <sa> : <xs:element name="sa" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="term-sa" type="xs:string" minOccurs="0" /> <xs:element name="qte-sa" type="xs:string" minOccurs="0" /> <xs:element name="quantite" type="xs:string" minOccurs="0" /> <xs:element name="term-unite" type="xs:string" minOccurs="0" /> </xs:sequence> </xs:complexType> </xs:element> Quelle est la différence entre "qte-sa" et "quantite" dans ce cas (Aucun "sa" dans toute les données ne possède les 2 à la fois) Bien cordialement. Pierre

Bonjour Monsieur BONY, Je vous prie de m'excuser pour le retard. J'ai déployé ce matin l'export XML avec les différentes corrections évoquées précédemment. Le XSD est également actualisé Cordialement, Dominique VALLEE

Bonjour Mr VALLEE, J'ai consulté les fichiers à l'instant mais il y a encore des points à vérifier : Je vais comparer la version récupérée le 10/11 et celle récupérée le 11/12 : - Pour le xsd de description : les fichiers sont binairement identiques - Pour le xml de description : Il y a de très nombreux ajouts qui semblent parfaitement logiques et le fichier semble bien plus cohérent. - Pour le xsd de données : ce dernier n'est pas horodaté au sein du fichier, mais en dehors de la déclaration de type de document qui a disparue (le <DOCTYPE...) je n'ai pas de changements de structure sur la version récupérée (peut être qu'il n'est pas encore à jour au 11/12 à 18h). - Pour le xml de données par contre, j'ai des changements problématiques et certains salutaires : - le renommage du doublon de seconde niveau de <modele-destine-vente> en <mod-vte> rends le xsd invalide - les enfants de <mdv-codes-gtin> sont maintenant des <mod-vte> au lieu de <mdv-gtin> ce qui ne cadre pas avec le xsd non plus. - le renommage de <term-qsp> en <term-unite> n'est pas reflété dans le xsd non plus. - la disparition de <qte-sa> pour <quantite> dans les <sa> est logique et bienvenu, mais le xsd pourrais dans ce cas ne plus avoir <qte-sa>. Il reste également que le xsd semble avoir des problèmes de structures (imbrications, numération des éléments) et de typages (tout est string, ce qui n'est pas vérifié expérimentalement, en particulier pour les codes, mais difficile de savoir si c'est voulu ou non). Aujourd'hui, nous ne pouvons pas importer ces données telles quelles et nous devons passer par une phase de normalisation lourde. Je vais vous poser une question très simple : Souhaitez vous notre aide pour préciser ce xsd et formaliser le xml en fonction ? Cela nous éviterais de devoir ajuster notre normalisation à chaque fois. Évidemment, nous aurions besoin de quelques précisions supplémentaire pour les questions d'imbrication, de numération et de typage. Si cela vous intéresse, n'hésitez pas à me le faire savoir pour en discuter. Bien cordialement. Pierre BONY

Bonjour monsieur BONY, Merci pour votre retour. Je vous propose de continuer d'échanger par mail : ircp@anses.fr Dominique VALLEE

Bonjour Mr BONY, Merci pour votre contribution. Suite à nos échanges fructueux, l'export au format XML_V2 a été amélioré au niveau de la qualité des données. Les fichiers XSD ont été enrichis par la même occasion. Dominique VALLEE

Bonjour, Merci pour votre signalement. Je prends en charge votre demande et la traite dans les meilleurs délais

Bonjour, Le contenu des enveloppes XML <para-rcp> est désormais alimenté correctement.

Merci, cela fonctionne dans l'archive compressé 7z (https://pro.anses.fr/RCP/amm-vet-fr-v2-v.7z), mais il semblerait que le fichier téléchargeable depuis https://pro.anses.fr/RCP/amm-vet-fr-v2-v.xml ne contienne toujours pas ces données para-rcp.

Bonjour, Le second lien n'existe plus sur le jeu de données. Il pointait sur la version du 24 août 2023. Cependant, désormais, il pointe sur le dernier export.

Up

merci de ne pas tenir compte de ce message.

Re-bonjour, le problème semble être apparu il y a 2j, votre serveur nginx aurait-il changé de configuration ?

Bonjour, oui même problème de mon coté : le chargement du fichier xml ne fonctionne plus depuis le 7 juin 2021

Bonjour Monsieur, Non, il n'est pas possible d’inclure dans l’export XML le nom du laboratoire exploitant le médicament, cette information n'est pas disponible dans notre base de données. Cordialement, Anses

merci pour votre réponse.

Bonjour, Sur le site IRCP le contenu est en HTML c'est pour cela qu'on voit des tableaux concernant les paragraphes du RCP, mais l’export Opendata est au format XML qui ne permet pas de présenter des informations sous forme de tableau. Cordialement, Anses

Bonjour, le format XML n'empêche pas d'inclure un tableau dans les données, il faut par contre définir un format pour le tableau. Le problème avec le contenu actuel est que le tableau 'est pas du tout exploitable. Est-il possible de definir un format pour les tableaux de votre coté et de le documenter dans la notice d'utilisation ?

Si vous avez iOS, vous pouvez utiliser mon application Medico Vet qui se base directement sur le site de l'ANSES https://apps.apple.com/fr/app/medico-vet/id1527969984