Formulaire compilé et exports
Ce que le service reçoit quand il demande un formulaire, les choix qu'il doit faire, et les raisons pour lesquelles un export échoue.
Le service (PrioRx, le site de rendez-vous) ne lit pas les formulaires dans le format de l'éditeur. Il demande un formulaire compilé : la version publiée convertie dans le format historique Schema.json, accompagnée des règles de réponse et de leur numéro de révision.
Ce qui est exporté
- Toujours la version publiée courante, sauf si le service demande explicitement un numéro de version, publiée ou archivée. Un brouillon ne s'exporte jamais.
- L'identité du formulaire : identifiant, alias, nom bilingue.
- Les trois sections de questions, sans les questions « papier seulement » ni leurs dépendantes.
- Les paramètres : facturation, actions de prescription, gabarits liés (indicateurs neutres pour un formulaire de rendez-vous).
- Les règles de réponse et leur révision, telles qu'elles sont au moment de la demande, indépendamment de la version.
- Les mots-clés, aplatis en une liste française et une liste anglaise.
L'adresse accepte l'identifiant ou n'importe quel alias du formulaire, présent ou passé.
Groupes de suivi
Pour un formulaire en disposition suivi de médicament, le service doit dire quels groupes de suivi il veut. Une adresse liste les groupes disponibles avec leur clé ; l'export exige ensuite au moins une clé valide.
| Situation | Réponse |
|---|---|
| Formulaire en consultation, groupes demandés | Refusé : « Consultation templates have no monitoring groups; omit the "groups" query parameter » |
| Formulaire en suivi, aucun groupe demandé | Refusé : « Monitoring group selection is required for drug-monitoring templates. Valid keys: … » |
| Clé de groupe inconnue | Refusé : « Unknown monitoring group key(s): … » |
Codes
Dans le formulaire compilé, les clés de question deviennent des codes en majuscules avec des tirets (allergie_penicilline → ALLERGIE-PENICILLINE) et les valeurs d'option deviennent des codes sans accents (Par téléphone → PAR-TELEPHONE). Voir Questions et Types de réponse.
Pourquoi un export échoue
Un formulaire publié peut ne pas être compilable. L'export répond alors avec l'une de ces raisons :
| Raison | Cause | Correctif |
|---|---|---|
invalid-pseudo-din | Le code de facturation par défaut n'a pas 8 chiffres, ou un code de remplacement n'est pas fait de 1 à 8 chiffres | Corriger dans Facturation ; en vigueur immédiatement |
missing-image-type | Une question de tri n'a pas de type d'image | Ajouter le type d'image et republier |
dangling-visibility-rule | Une règle de visibilité désigne une question absente de l'export (retirée par son support, ou supprimée) | Corriger la règle ou le support et republier |
uncodeable-coding-option | Une option de codage n'est pas un entier | Corriger dans Facturation |
colliding-synthesized-code | Deux éléments donnent le même code dans le document | Renommer une clé ou une valeur d'option et republier |
Sans version publiée, l'export répond « Template "…" has no published version ». Un numéro de version inexistant répond « Published version n not found ».
Version papier
Voir la version papier, dans le gestionnaire de publication, produit le PDF d'une version du formulaire, en français ou en anglais, sans les questions « en ligne seulement ». Chaque version de l'historique a son export, et le brouillon aussi quand il a des changements : vérifiez quelle version vous exportez.
Recherche par mot-clé
Le service peut aussi chercher un formulaire publié par mot-clé ; voir Recherche et mots-clés.
À savoir
- Corriger la facturation ou les règles de réponse ne demande pas de republier : le prochain export les reflète. Corriger une question, si.
- Un formulaire désactivé porte l'indicateur inactif dans son identité et la liste des formulaires : c'est ce que le service utilise pour ne plus le proposer. L'export d'une version publiée reste techniquement possible ; la désactivation n'efface rien.
- Le format
Schema.jsonest le format historique du service ; l'éditeur ne le montre pas. Les correspondances champ à champ sont documentées pour les développeurs dans le dépôt de l'application. - Le service reçoit les règles de réponse mais c'est lui qui les évalue ; l'application ne reçoit jamais de réponses de patients.