Conception d’un formulaire

Principes généraux

La réalisation d’un formulaire et de ses effets post validation reposent :

  1. sur un modèle de données bien conçu.
  2. sur un formulaire rédigé dans les règles
  3. sur de possibles interactions entre champs de donnée via javascript
  4. sur un traitement post validation / prégénération PDF via class PHP propre au module

Élaboration du modèle de données

Le modèle de données se créer dans Configuration > Modèles des données > Données médicales.

Il est conseillé de créer une catégorie par formulaire envisagé et d’y ranger chaque type créé.

Découper l’information à recueillir avec précision

Il convient d’être parfaitement spécifique dans la création et l’utilisation d’un type de donnée. Par exemple, ne créez pas un champ "Longueur Cranio-Caudale" (LCC) en pensant l’utiliser quel que soit le type d’examen (écho 12 SA, écho 22 SA ...) et quel que soit le foetus. La bonne pratique est de faire un champ LCC écho 12 SA foetus A puis un autre pour le foetus B et ainsi de suite pour chaque examen.

Choix du type de champ

La clef d’un formulaire efficace est aussi le choix du type de champ utilisé. Les types utilisables sont :

Nom interne

A la création d’un nouveau type, il faut spécifier un nom interne. Il doit être unique dans le système. Les caractères utilisés doivent être alphanumériques, sans espace, sans accent ([a-zA-Z0-9]*). Il est prévu à terme que MedShakeEHR n’utilise plus l’identifiant numérique, mais uniquement ce nom. Soignez ce choix. Préfixez-le éventuellement d’une chaîne qui vous identifie.

Réponse par défaut

Le choix par défaut permet de pré remplir le champ avec du contenu qui pourra être modifié avant validation.

Notez bien que les champs de type select ne peuvent recevoir de réponse non prévue quand l’utilisateur les remplit : il convient donc que toutes les réponses soient proposées pour qu’il n’y ait pas d’impasse côté utilisateur.
Pour spécifier les choix du menu select, utilisez le champ réponse par défaut en adoptant un syntaxe yaml :

'doulpelv' : 'douleurs pelviennes'
'doulfid' : 'douleurs FID'
'doulfig' : 'douleurs FIG'
'dyspareunies' : 'dyspareunies'
'suspiendomet' : 'suspicion d'endométriose'
'bilaninfer' : 'bilan d'infertilité'
'suivipma' : 'suivi PMA'


Suivant le cas, vous pouvez ajouter si besoin un choix vierge en tête de menu en utilisant quelque chose comme

'Z' : ''

Ne changez JAMAIS le couple ’clé’ : ’label du menu’ quand un type de données a déjà été utilisé ! Vous perdriez toute liaison entre l’information stockée et sa signification !

Règles de rédaction du formulaire

Règles de base

Les formulaires se rédigent en respectant une syntaxe yaml. L’indentation d’une ligne à l’autre pour spécifier qu’un élément est contenu dans un autre est de 2 espaces supplémentaires en début de ligne par rapport au niveau supérieur.

Le premier niveau est structure: .

Lignes et colonnes

Imbriquer lignes et colonnes

Chaque questionnaire doit être pensé en termes de lignes et de colonnes. Notez bien qu’une colonne ne peut contenir de ligne. C’est une limitation actuelle de l’interpréteur qui construit le formulaire html à partir de votre rédaction yaml.

Une ligne fait 12 de large. Ceci est fixé, non modifiable, lié à l’utilisation de Bootstrap v3. Chaque colonne qui est ajoutée à une ligne peut donc faire une taille comprise entre 1 et 12. Tant que la somme des tailles des colonnes d’une ligne n’est pas égale à 12, on peut ajouter encore d’autres colonnes. Si on dépasse le nombre de 12, on s’expose à des problèmes d’affichage imprévisibles.

Chaque ligne est numérotée en commençant par 1 : row1, row2, row3 ... Indiquez 2 fois un même numéro de ligne expose à des problèmes imprévisibles d’affichage.
Chaque colonne doit être numérotée dans sa ligne : col1, col2 ...

structure:
 row1:
   col1:
   col2:
   ....
 row2:
   col1:
   ...
Paramètres pour les lignes

Un titre de ligne peut être spécifié via head: 'titre de ligne'.
Une class CSS spécifique à la ligne peut être ajoutée via class: 'maClassCss' (ce qui permet par exemple des interactions javascript).

structure:
 row1:                              
   class: 'maClassCss maClassCss2'
   head: Un titre de ligne'    
   col1:
Paramètres pour les colonnes

Un titre de colonne peut être spécifié via head: 'titre de colonne'.
La largeur de colonne est spécifiée via size: X ou X est un nombre de 1 à 12 (cf plus haut).
Les champs de recueil de données à inclure dans la colonne sont passés dans bloc:. Ils apparaîtront dans l’ordre indiqué, chacun prenant la pleine largeur de la colonne parente.

 ...
 row3:                              
   col1:                              
     head: 'Titre de colonne'    
     size: 3
     bloc:                          
       - 71                        
       - 74          
       - 206            
   col2:                              
   ...



A partir de la v2.0.0 de MedShakeEHR on peut également inclure du texte brut en lieu et place d’un bloc :

 ...
 row3:                              
   col1:                              
     size: 3
     bloc:                          
       - 71                        
       - 'Mon texte brut'      
   col2:                              
   ...



A partir de la v2.2.0 de MedShakeEHR on peut également inclure un template Twig pour, par exemple, insérer une image, un SVG ou tout autre élément dans le questionnaire :

 ...
 row3:                              
   col1:                              
     size: 3
     bloc:                          
       - 71                        
       - 'Mon texte brut'  
       - template{schemaRachis}    
   col2:                              
   ...



Le templates recherché et inséré sera alors schemaRachis.html.twig.

Paramétrage de chaque élément d’une colonne

Indépendamment de leur définition dans le modèle de données, chaque champ de recueil peut subir des modifications au niveau du formulaire. Ces modifications sont indiquées après le numéro d’identifiant du type de donnée et séparées par des virgules (sans espaces).

Interactions entre champs d’un formulaire via JavaScript

Chaque formulaire affiché sur l’écran de l’utilisateur appelle un fichier JavaScript situé dans public_html/js/module/formsScripts/.

Ce fichier est nommé par le nom interne du formulaire pour lequel il agit (et une extension .js).
Des fonctions communes peuvent également être stockées dans public_html/js/module/common.js.

Concernant l’interaction, il est fortement conseillé de sélectionner les champs du formulaire en fonction de data-internalName. L’évolution de MedShakeEHR va dans le sens de l’abandon d’identifiant numérique, même si les formulaires de consultation fonctionnent toujours pour le moment avec cette méthode.

Traitement post validation / prégénération PDF via class PHP propre au module

Les modifications suggérées ci-dessous touchent au module de MedShakeEHR. Nous vous suggérons de ne pas modifier seul de votre côté ces fonctions, mais de proposer une modification des sources de l’application (Github) afin qu’elles soient incluses à la prochaine version.

Traitement post validation / pré sauvegarde propre au module

class/msModuleDataSave.php permet de traiter chaque type de données avant son insertion en base de données. Attention, il n’y a pas ici de gestion d’erreur, mais un simple formatage la plupart du temps.

Calculs médicaux propres au module

Les calculs médicaux propres au module utilisé sont disponibles dans class/msModuleCalcMed.php.

Préparation à la génération de courriers

class/msModuleDataCourrier.php permet de déclencher des mécanismes pour l’obtention de données complémentaires quand un type particulier de données est passé au système pour impression.

 
Editeur : E.I.R.L. Bertrand Boutillier immatriculée sous le numéro 480 239 631 au tribunal de commerce de Saint-Brieuc
Hébergement : ONLINE (Scaleway), 8 rue de la ville l’Evêque - 75008 Paris, FRANCE (RCS PARIS B 433 115 904)