Créer des enquêtes pour CareSuite

La création d'enquêtes est une exigence fondamentale pour opérationnaliser les applications Contact et Care. CareSuite fonctionne avec Kobotoolbox comme générateur de formulaires plug-in pour permettre aux utilisateurs

Guide de création d'enquêtes CareSuite

Ce guide fournit des meilleures pratiques complètes et des anti-modèles pour la création d'enquêtes dans CareSuite

Types d'enquêtes dans CareSuite

CareSuite prend en charge quatre principaux types d'enquêtes :

1. Enquête d'admission

Objectif: Collecte de données pour la création de cas dans un projet
Portée: Niveau projet (chaque projet a une enquête d'admission)
Utilisation: Utilisé lors de la création ou de la mise à jour des cas
Stockage: Les réponses aux enquêtes sont stockées sur l'entité Case
Caractéristiques principales: Requise pour tous les projets, utilisée pour la création de cas

2. Enquête démographique

Objectif: Collecte d'informations démographiques au niveau du profil
Portée: Niveau organisation (chaque organisation a une enquête démographique)
Utilisation: Utilisée pour collecter et mettre à jour les données démographiques du profil
Stockage: Les réponses aux enquêtes sont stockées sur l'entité Profile (profile.survey)
Caractéristiques principales: Utilisé pour la recherche globale de profils et la collecte de données démographiques

3. Enquête de suivi

Objectif: Collecte de données de suivi après orientation
Portée: Niveau projet (optionnel, chaque projet peut avoir une enquête de suivi)
Utilisation: Remplie par les gestionnaires de cas après la prestation du service
Stockage: Réponses aux enquêtes stockées en tant que réponses d'enquête de suivi par référence

4. Enquêtes additionnelles

Objectif: Collecte de données supplémentaires personnalisée
Portée: Niveau projet (plusieurs enquêtes additionnelles par projet sont autorisées)
Utilisation: Enquêtes personnalisées pour des besoins spécifiques de collecte de données
Stockage: Les réponses aux enquêtes sont stockées dans additionalSurveyResponse table
Caractéristiques principales: Prend en charge des réponses uniques et multiples par cas par enquête

Exigences de format d'enquête

Format de fichier

Type de fichier: XML (.xml extension)
Type MIME: text/xml
Taille maximale du fichier: 10 Mo (MAX_SURVEY_FILESIZE = 10 * 1024 * 1024)
Norme de format: Format XForms/ODK (Open Data Kit)
Compatibilité: Doit être compatible avec le format Kobo Toolbox

Exigences de structure XML

Les enquêtes doivent respecter la structure XML XForms/ODK :

<?xml version="1.0"?>
<h:html xmlns="http://www.w3.org/2002/xforms" 
        xmlns:ev="http://www.w3.org/2001/xml-events" 
        xmlns:h="http://www.w3.org/1999/xhtml" 
        xmlns:jr="http://openrosa.org/javarosa" 
        xmlns:odk="http://www.opendatakit.org/xforms" 
        xmlns:orx="http://openrosa.org/xforms" 
        xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <h:head>
    <h:title>Titre de l'enquête</h:title>
    <model odk:xforms-version="1.0.0">
      <itext>
        <translation default="true()" lang="English (en)">
          <!-- Traductions de texte pour les étiquettes, les indices et les libellés d'options -->
        </translation>
      </itext>
      <instance>
        <!-- Structure des données du formulaire -->
      </instance>
      <bind>
        <!-- Liaisons de champs avec types et validation -->
      </bind>
    </model>
  </h:head>
  <h:body>
    <!-- Corps du formulaire avec champs de saisie -->
  </h:body>
</h:html>

Espaces de noms requis

http://www.w3.org/2002/xforms
http://www.w3.org/2001/xml-events
http://www.w3.org/1999/xhtml
http://openrosa.org/javarosa
http://www.opendatakit.org/xforms
http://openrosa.org/xforms
http://www.w3.org/2001/XMLSchema

Types de données pris en charge

Pour une répartition plus détaillée des types voir Types de données pris en charge

✅ Types entièrement pris en charge

1. string (Texte)

Type XML: type="string"
Utilisation: Champs de saisie de texte, noms, descriptions, notes
Opérateurs de requête: Égal, Différent, Commence par, Se termine par, Contient, Ne contient pas, Est vide, N'est pas vide, Dans, N'est pas dans

Exemple:

<bind nodeset="/form/field_name" type="string"/>
<input ref="/form/field_name">
  <label>Étiquette du champ</label>
</input>

2. int (Entier)

Type XML: type="int"
Utilisation: Nombres entiers (âge, comptes, scores)
Opérateurs de requête: Égal, Différent, Supérieur à, Inférieur à

Exemple:

<bind nodeset="/form/caller_age" type="int"/>
<input ref="/form/caller_age">
  <label>Âge</label>
</input>

3. date (Date)

Type XML: type="date"
Utilisation: Champs de date (sans composante temporelle)
Opérateurs de requête: Égal à, Après, Avant, Entre
Format: Format de date ISO (AAAA-MM-JJ)

Exemple:

<bind nodeset="/form/BTS_Date" type="date"/>
<input ref="/form/BTS_Date">
  <label>Date</label>
</input>

4. select1 (Sélection unique)

Type XML: type="string" avec <select1> entrée
Utilisation: Menu déroulant à choix unique / boutons radio
Opérateurs de requête: Égal, Différent, Est vide, N'est pas vide

Exemple:

<bind nodeset="/form/gender" type="string"/>
<select1 ref="/form/gender">
  <label>Quel est votre genre ?</label>
  <item>
    <label>Femme</label>
    <value>female</value>
  </item>
  <item>
    <label>Homme</label>
    <value>male</value>
  </item>
</select1>

5. select (Sélection multiple)

Type XML: type="string" avec <select> entrée
Utilisation: Cases à cocher/listes à choix multiple
Stockage: Valeurs stockées en tant que chaîne séparée par des espaces (p. ex., "value1 value2 value3")
Opérateurs de requête: Égal, Différent, Est vide, N'est pas vide

Exemple:

<bind nodeset="/form/race" type="string"/>
<select ref="/form/race">
  <label>Sélectionnez tout ce qui s'applique</label>
  <item>
    <label>Hispanique ou Latino</label>
    <value>hispanic_or_latino</value>
  </item>
  <item>
    <label>Blanc</label>
    <value>white</value>
  </item>
</select>

❌ Types non pris en charge

Les types de données suivants sont NON pris en charge et doivent être évités :

time - Champs uniquement heure (utiliser string ou un champ date séparé)
dateTime - Date et heure combinées (utiliser date type et stocker l'heure séparément si nécessaire)
decimal - Nombres décimaux (peuvent fonctionner comme int, mais non pris en charge explicitement)
boolean - Valeurs booléennes (utiliser select1 avec des options "yes"/"no" à la place)
geopoint - Coordonnées géographiques (stocker comme lat/lng séparés string ou int champs)
geotrace - Trajectoires géographiques
geoshape - Formes/polygones géographiques
binary - Téléversements de fichiers (non pris en charge dans les enquêtes)
barcode - Lecture de codes-barres
intent - Intentions d'applications externes

Bonnes pratiques

1. Nomination des champs

✅ À FAIRE :

Utiliser des noms de champs descriptifs, en minuscules avec des underscores : caller_age, first_time_caller, hear_about_211
Utiliser des conventions de nommage cohérentes dans toute l'enquête
Garder les noms de champs concis mais significatifs
Utiliser snake_case pour les noms de champs composés

❌ À NE PAS FAIRE :

Utiliser des espaces dans les noms de champs
Utiliser des caractères spéciaux (sauf les underscores)
Utiliser le camelCase (utiliser snake_case à la place)
Utiliser des noms de champs extrêmement longs

Exemple :

<!-- Bien -->
<bind nodeset="/form/caller_frequency" type="string"/>

<!-- Mal -->
<bind nodeset="/form/CallerFrequency" type="string"/>
<bind nodeset="/form/caller frequency" type="string"/>

2. Organisation des champs avec des groupes

✅ À FAIRE :

Organiser les champs liés en utilisant <group> éléments
Utiliser des noms de groupe descriptifs : group_AARP_careprovider, group_kick_it
Imbriquer des groupes si nécessaire pour créer des hiérarchies logiques

Exemple :

<bind nodeset="/form/group_callback_contact" relevant="..." required="false()"/>
<bind nodeset="/form/group_callback_contact/given_familyName" required="false()" type="string"/>
<bind nodeset="/form/group_callback_contact/telephone_001" required="false()" type="string"/>

3. Utiliser itext pour tout le contenu textuel

✅ À FAIRE :

Toujours utiliser <itext> traductions pour les étiquettes, les indices et les libellés d'options
Référencer le texte en utilisant jr:itext() fonction
Conserver le texte réel dans la section itext, pas en ligne

Exemple :

<itext>
  <translation default="true()" lang="English (en)">
    <text id="/form/gender:label">
      <value>Quel est votre genre ?</value>
    </text>
    <text id="/form/gender/hint">
      <value>Ne poser la question que si incertain</value>
    </text>
    <text id="/form/gender/female:label">
      <value>Femme</value>
    </text>
  </translation>
</itext>

<select1 ref="/form/gender">
  <label ref="jr:itext('/form/gender:label')"/>
  <hint ref="jr:itext('/form/gender:hint')"/>
  <item>
    <label ref="jr:itext('/form/gender/female:label')"/>
    <value>female</value>
  </item>
</select1>

4. Logique conditionnelle (attributs relevant)

✅ À FAIRE :

Utiliser relevant attributs pour l'affichage conditionnel des champs
Utiliser des expressions XPath claires et lisibles
Tester tous les chemins de la logique conditionnelle

Exemple :

<bind nodeset="/form/smoke_cigarettes" type="string"/>
<bind nodeset="/form/group_kick_it" 
      relevant="/form/smoke_cigarettes = 'yes'" 
      required="false()"/>

5. Champs obligatoires

✅ À FAIRE :

Utiliser required attributs avec des conditions XPath claires
Envisager d'utiliser une logique conditionnelle pour l'obligation lorsque c'est approprié
Autoriser les champs à être optionnels lorsque les données peuvent ne pas être disponibles

Exemple :

<!-- Requis lorsqu'un autre champ est vide -->
<bind nodeset="/form/gender" 
      required="/form/Incomplete_General_Screener = ''" 
      type="string"/>

<!-- Toujours optionnel -->
<bind nodeset="/form/other_race" 
      relevant="/form/race = 'other'" 
      required="false()" 
      type="string"/>

6. Validation et contraintes

✅ À FAIRE :

Utiliser des contraintes regex pour la validation de format (numéros de téléphone, e-mails, etc.)
Fournir des messages de contrainte clairs en utilisant jr:constraintMsg
Valider les données au niveau du champ lorsque c'est possible

Exemple :

<!-- Validation du numéro de téléphone -->
<bind nodeset="/form/telephone" 
      constraint="regex(.,'^[0-9]{10}$')" 
      jr:constraintMsg="Format : xxxxxxxxxx (Veuillez ne pas ajouter de caractères de formatage)" 
      required="false()" 
      type="string"/>

<!-- Validation de l'e-mail -->
<bind nodeset="/form/email" 
      constraint="regex(., '^[A-Za-z0-9._%+-]+@[A-Za-z0-9-]+[.][A-Za-z.]{2,}$')" 
      required="false()" 
      type="string"/>

7. Champs calculés

✅ À FAIRE :

Utiliser calculate attributs pour les valeurs calculées
Marquer les champs calculés comme readonly="true()"
Inclure des contraintes qui empêchent la modification manuelle si nécessaire

Exemple :

<bind nodeset="/form/isolation_score" 
      calculate="/form/group_xe5xh95/score_calc" 
      constraint="regex(., /form/group_xe5xh95/score_calc)" 
      jr:constraintMsg="Veuillez ne pas modifier" 
      readonly="true()" 
      type="int"/>

8. Valeurs préchargées

✅ À FAIRE :

Utiliser jr:preload pour les valeurs auto-peuplées (horodatages, IDs d'instance)
Utiliser des paramètres de préchargement appropriés

Exemple :

<!-- Horodatage de début -->
<bind jr:preload="timestamp" 
      jr:preloadParams="start" 
      nodeset="/form/start" 
      type="dateTime"/>

<!-- Horodatage de fin -->
<bind jr:preload="timestamp" 
      jr:preloadParams="end" 
      nodeset="/form/end" 
      type="dateTime"/>

<!-- ID d'instance -->
<bind jr:preload="uid" 
      nodeset="/form/meta/instanceID" 
      readonly="true()" 
      type="string"/>

9. Gestion des dates

✅ À FAIRE :

Utiliser date() fonction pour les valeurs de date par défaut
Définir des dates par défaut en utilisant <setvalue> événements lorsque c'est approprié
Utiliser des contraintes de date pour la validation

Exemple :

<bind nodeset="/form/BTS_Date" 
      constraint=". = date('today()')" 
      relevant="..." 
      required="false()" 
      type="date"/>
<setvalue event="odk-instance-first-load" 
          ref="/form/BTS_Date" 
          value="today()"/>

10. Gestion des données incomplètes

✅ À FAIRE :

Inclure des options pour gérer la collecte de données incomplète
Fournir des options standard : "N'a pas été demandé", "Refus de répondre", "Appel interrompu prématurément", "Appel de crise - N'a pas été demandé"
Rendre les champs conditionnellement obligatoires en fonction du statut de complétion

Exemple :

<select ref="/form/Incomplete_General_Screener">
  <label>Collecte de données incomplète</label>
  <item>
    <label>N'a pas été demandé</label>
    <value>did_not_ask</value>
  </item>
  <item>
    <label>Refus de répondre</label>
    <value>declined_to_answer</value>
  </item>
  <item>
    <label>Appel interrompu prématurément</label>
    <value>call_terminated_early</value>
  </item>
</select>

<!-- Rendre d'autres champs obligatoires seulement lorsqu'ils ne sont pas incomplets -->
<bind nodeset="/form/gender" 
      required="/form/Incomplete_General_Screener = ''" 
      type="string"/>

Anti-modèles courants et choses à éviter

1. ❌ Utilisation de types de données non pris en charge

Problème : L'utilisation de types de données non pris en charge (dateTime, time, binary, etc.) causera des problèmes de stockage, de requête et d'affichage des données.

Solution :

Utiliser date au lieu de dateTime (stocker l'heure séparément si nécessaire)
Utiliser string pour les valeurs booléennes avec des options select1
Utiliser string ou des int champs séparés pour les coordonnées géographiques

2. ❌ Nommage incohérent des champs

Problème : Un nommage incohérent (mélange de camelCase, snake_case, espaces) rend les enquêtes plus difficiles à maintenir et à interroger.

Solution :

Utiliser toujours snake_case pour les noms de champs
Établir et suivre un document de convention de nommage
Utiliser des noms descriptifs qui indiquent l'objectif du champ

3. ❌ Texte en ligne au lieu d'itext

Problème : Le codage en dur du texte directement dans les définitions de champs rend les traductions difficiles et la maintenance plus complexe.

Solution :

Toujours utiliser <itext> traductions
Référencer le texte en utilisant jr:itext()
Conserver tout le texte destiné aux utilisateurs dans la section itext

4. ❌ Espaces de noms XML manquants ou incorrects

Problème : Des espaces de noms manquants ou incorrects peuvent provoquer des erreurs d'analyse.

Solution :

Inclure tous les espaces de noms requis dans le <h:html> élément racine
Utiliser les URI d'espace de noms exacts spécifiés dans les exigences de format

5. ❌ Logique conditionnelle trop complexe

Problème : Des relevant ou required expressions très complexes sont difficiles à maintenir et à déboguer.

Solution :

Diviser les conditions complexes en expressions plus simples et testables
Utiliser des champs calculés intermédiaires lorsque nécessaire
Documenter la logique complexe avec des commentaires (si les commentaires XML sont pris en charge)

6. ❌ Liaisons de champs manquantes

Problème : Les champs définis dans le corps sans <bind> déclarations correspondantes peuvent ne pas fonctionner correctement.

Solution :

Toujours créer un <bind> élément pour chaque champ dans le corps du formulaire
S'assurer que les chemins nodeset correspondent exactement entre les éléments bind et input
Inclure les attributs appropriés type, required et relevant

7. ❌ Stockage incorrect des valeurs de sélection multiple

Problème : S'attendre à ce que les valeurs de sélection multiple soient stockées en tableaux alors qu'elles sont en réalité des chaînes séparées par des espaces.

Solution :

Se rappeler que <select> (sélection multiple) les valeurs sont stockées en tant que chaînes séparées par des espaces
Lors des requêtes, utiliser les opérateurs de chaîne appropriés
Lors de l'affichage, diviser la chaîne pour obtenir les valeurs individuelles

Exemple :

// Valeur de sélection multiple : "value1 value2 value3"
const selections = value.split(' '); // Séparer en tableau

8. ❌ Taille de fichier dépassant les limites

Problème : Les enquêtes dépassant 10 Mo seront rejetées lors de l'upload.

Solution :

Garder les enquêtes ciblées et éviter les champs inutiles
Optimiser le contenu itext (éviter les textes en double)
Supprimer les champs et groupes non utilisés
Envisager de diviser les très grandes enquêtes en plusieurs enquêtes additionnelles

9. ❌ Absence de validation pour les champs critiques

Problème : Les champs critiques (numéros de téléphone, e-mails, etc.) sans validation peuvent entraîner une mauvaise qualité des données.

Solution :

Toujours ajouter des contraintes regex pour les numéros de téléphone, e-mails, codes postaux
Fournir des messages de contrainte clairs et utiles
Tester la validation avec diverses entrées valides et non valides

10. ❌ Utilisation du type dateTime pour les dates

Problème : L'utilisation du dateTime type n'est pas prise en charge et peut provoquer des erreurs.

Solution :

Toujours utiliser type="date" pour les champs de date
Si l'heure est nécessaire, la stocker dans un string champ séparé
Remarque : Le système peut accepter dateTime dans les déclarations bind pour les champs de métadonnées (comme les horodatages de début/fin), mais utiliser date pour les dates saisies par l'utilisateur

11. ❌ Absence d'options pour données incomplètes

Problème : Ne pas fournir d'options pour la collecte de données incomplète rend difficile le suivi des raisons des enquêtes incomplètes.

Solution :

Inclure un "Incomplete General Screener" ou un champ similaire au début
Fournir des options standard pour les scénarios incomplets
Rendre les autres champs conditionnellement obligatoires en fonction du statut de complétion

12. ❌ Durcissement des valeurs d'option

Problème : Utiliser les libellés d'option comme valeurs rend l'analyse des données difficile et sujette aux erreurs.

Solution :

Toujours utiliser des valeurs en minuscules séparées par des underscores
Garder les libellés lisibles par les humains mais les valeurs cohérentes
Exemple : label="Female", value="female" (pas "Female" comme valeur)

13. ❌ Ne pas utiliser de groupes pour les champs liés

Problème : Des structures de champs plates rendent les enquêtes plus difficiles à naviguer et à comprendre.

Solution :

Grouper les champs liés en utilisant <group> éléments
Créer des hiérarchies logiques (par ex., group_callback_contact/telephone_001)
Utilisez des noms de groupe descriptifs

14. ❌ Identifiant d'instance Meta manquant

Problème : Ne pas inclure un champ meta/instanceID rend difficile le suivi des instances d'enquête.

Solution :

Incluez toujours une section meta avec instanceID
Utiliser jr:preload="uid" pour générer automatiquement des identifiants uniques
Conservez-le en lecture seule

Exemple :

<bind jr:preload="uid" 
      nodeset="/form/meta/instanceID" 
      readonly="true()" 
      type="string"/>

Conventions de nommage des champs

Modèles de nommage recommandés

Utilisez le snake_case: caller_age, first_time_caller, hear_about_211
Soyez descriptif: caller_frequency pas freq
Utilisez des préfixes pour les groupes: group_AARP_careprovider, group_kick_it
Utilisez des suffixes pour les champs liés: telephone_001, email_001, givenName, familyName
Gardez les noms concis: Évitez les noms extrêmement longs, mais privilégiez la clarté

Exemples issus d'enquêtes en production

✅ Bons exemples :

Incomplete_General_Screener
caller_frequency
caller_age
BTS_Date
group_kick_it
group_callback_contact

❌ Évitez :

Casse mixte sans séparation : callerAge, CallerFrequency
Espaces : caller age, first time caller
Caractères spéciaux : caller-age, caller.age
Trop générique : field1, data, value

Lignes directrices sur la structure des enquêtes

1. Flux logique

Commencez par les options de script/ données incomplètes
Groupez les questions liées ensemble
Utilisez la logique conditionnelle pour afficher/masquer des sections
Terminez par des champs de métadonnées facultatifs

2. Champs obligatoires vs facultatifs

Rendez les champs obligatoires uniquement lorsqu'il est absolument nécessaire
Utilisez la logique de requis conditionnel lorsque approprié
Tenez compte des scénarios de collecte de données (appels incomplets, réponses refusées)

3. Organisation des groupes

Utilisez des groupes pour organiser les champs liés
Créez des groupes imbriqués pour les sous-sections
Nommez les groupes de manière descriptive

4. Ordre des champs

Classez les champs de manière logique (du général au spécifique, du requis au facultatif)
Gardez les champs conditionnels près de leurs champs parents
Groupez les types de champs similaires lorsque possible

Tests et validation

Avant le téléversement

Valider la structure XML
- Vérifiez que le XML est bien formé
- Vérifiez que tous les espaces de noms sont présents
- Assurez-vous que tous les champs ont des déclarations bind correspondantes
Testez dans Kobo Toolbox (Requis)
- Créez/testez les enquêtes dans Kobo Toolbox d'abord
- Vérifiez que toute la logique conditionnelle fonctionne correctement
- Testez avec différentes entrées de données
Vérifier les noms de champs
- Assurez la cohérence de la convention de nommage
- Vérifiez les fautes de frappe dans les chemins nodeset
- Vérifiez que les chemins bind correspondent aux chemins ref des inputs
Tester la logique conditionnelle
- Testez toutes les conditions pertinentes/obligatoires
- Vérifiez que les champs calculés fonctionnent correctement
- Vérifiez que les valeurs préchargées se remplissent
Vérifier la taille du fichier
- Assurez-vous que le fichier fait moins de 10 Mo
- Optimisez si nécessaire

Après le téléversement

Testez le flux de l'enquête
- Remplissez une réponse d'enquête de test
- Vérifiez que tous les champs apparaissent/disparaissent correctement
- Vérifiez les messages de validation
Vérifiez le stockage des données
- Soumettez une réponse de test
- Vérifiez que les données sont stockées correctement
- Vérifiez que les valeurs multi-sélection sont correctement stockées
Tester les requêtes
- Testez la recherche avancée avec les champs d'enquête
- Vérifiez que les requêtes de date fonctionnent correctement
- Vérifiez le filtrage des champs de sélection

Dépannage

Erreurs courantes

1. "Seul le fichier xml est autorisé"

Cause: Le fichier n'est pas reconnu comme XML
Solution: Assurez-vous que le fichier a .xml extension et le type MIME correct (text/xml)

2. "Le fichier d'enquête doit être fourni"

Cause: Aucun fichier n'a été téléchargé
Solution: Assurez-vous qu'une entrée de fichier a un fichier valide sélectionné

3. "La taille du fichier dépasse la limite"

Cause: Le fichier est plus grand que 10 Mo
Solution: Réduisez la taille du fichier en supprimant les champs inutilisés, en optimisant le contenu textuel ou en le divisant en plusieurs enquêtes

4. Les champs d'enquête n'apparaissent pas dans la recherche

Cause: Le type de champ peut ne pas être pris en charge, ou les métadonnées mal analysées
Solution: Vérifiez que le champ utilise un type pris en charge (string, int, date, select1, select)

5. Les valeurs multi-sélection ne s'affichent pas correctement

Cause: Attente d'un tableau lorsque les valeurs sont des chaînes séparées par des espaces
Solution: Séparez la chaîne séparée par des espaces lors du traitement : value.split(' ')

6. Les champs de date ne sont pas interrogeables

Cause: Utilisation du type dateTime au lieu de date
Solution: Changez en type="date" dans la déclaration bind

Conseils de débogage

Télécharger l'enquête existante
- Utilisez le bouton "Télécharger l'enquête" pour voir le XML de l'enquête actuelle
- Comparez-le avec votre nouvelle enquête pour identifier les différences
Vérifier les métadonnées de l'enquête
- Consultez les métadonnées de l'enquête dans les paramètres du projet
- Vérifiez que tous les champs sont listés avec les bons types
Tester progressivement
- Commencez par une enquête simple et ajoutez la complexité progressivement
- Testez après chaque changement majeur
Examiner les journaux
- Vérifiez les journaux du serveur pour les erreurs d'analyse XML
- Recherchez des erreurs spécifiques aux champs ou aux espaces de noms

Ressources supplémentaires

Kobo Toolbox: https://kobotoolbox.org (Outil recommandé pour la création et le test des enquêtes)
Spécification ODK XForms: https://getodk.github.io/xforms-spec/
Documentation XForms: https://www.w3.org/TR/xforms/

Liste de contrôle récapitulative

Lors de la création d'une enquête, assurez-vous :

PrécédentEnquêtes de collecte de données SuivantTypes de données pris en charge

Mis à jour il y a 1 mois

Ce contenu vous a-t-il été utile ?

Bonsoir

hashtagGuide de création d'enquêtes CareSuite

hashtagTypes d'enquêtes dans CareSuite

hashtag1. Enquête d'admission

hashtag2. Enquête démographique

hashtag3. Enquête de suivi

hashtag4. Enquêtes additionnelles

hashtagExigences de format d'enquête

hashtagFormat de fichier

hashtagExigences de structure XML

hashtagEspaces de noms requis

hashtagTypes de données pris en charge

hashtag✅ Types entièrement pris en charge

hashtag❌ Types non pris en charge

hashtagBonnes pratiques

hashtag1. Nomination des champs

hashtag2. Organisation des champs avec des groupes

hashtag3. Utiliser itext pour tout le contenu textuel

hashtag4. Logique conditionnelle (attributs relevant)

hashtag5. Champs obligatoires

hashtag6. Validation et contraintes

hashtag7. Champs calculés

hashtag8. Valeurs préchargées

hashtag9. Gestion des dates

hashtag10. Gestion des données incomplètes

hashtagAnti-modèles courants et choses à éviter

hashtag1. ❌ Utilisation de types de données non pris en charge

hashtag2. ❌ Nommage incohérent des champs

hashtag3. ❌ Texte en ligne au lieu d'itext

hashtag4. ❌ Espaces de noms XML manquants ou incorrects

hashtag5. ❌ Logique conditionnelle trop complexe

hashtag6. ❌ Liaisons de champs manquantes

hashtag7. ❌ Stockage incorrect des valeurs de sélection multiple

hashtag8. ❌ Taille de fichier dépassant les limites

hashtag9. ❌ Absence de validation pour les champs critiques

hashtag10. ❌ Utilisation du type dateTime pour les dates

hashtag11. ❌ Absence d'options pour données incomplètes

hashtag12. ❌ Durcissement des valeurs d'option

hashtag13. ❌ Ne pas utiliser de groupes pour les champs liés

hashtag14. ❌ Identifiant d'instance Meta manquant

hashtagConventions de nommage des champs

hashtagModèles de nommage recommandés

hashtagExemples issus d'enquêtes en production

hashtagLignes directrices sur la structure des enquêtes

hashtag1. Flux logique

hashtag2. Champs obligatoires vs facultatifs

hashtag3. Organisation des groupes

hashtag4. Ordre des champs

hashtagTests et validation

hashtagAvant le téléversement

hashtagAprès le téléversement

hashtagDépannage

hashtagErreurs courantes

hashtagConseils de débogage

hashtagRessources supplémentaires

hashtagListe de contrôle récapitulative

Guide de création d'enquêtes CareSuite

Types d'enquêtes dans CareSuite

1. Enquête d'admission

2. Enquête démographique

3. Enquête de suivi

4. Enquêtes additionnelles

Exigences de format d'enquête

Format de fichier

Exigences de structure XML

Espaces de noms requis

Types de données pris en charge

✅ Types entièrement pris en charge

❌ Types non pris en charge

Bonnes pratiques

1. Nomination des champs

2. Organisation des champs avec des groupes

3. Utiliser itext pour tout le contenu textuel

4. Logique conditionnelle (attributs relevant)

5. Champs obligatoires

6. Validation et contraintes

7. Champs calculés

8. Valeurs préchargées

9. Gestion des dates

10. Gestion des données incomplètes

Anti-modèles courants et choses à éviter

1. ❌ Utilisation de types de données non pris en charge

2. ❌ Nommage incohérent des champs

3. ❌ Texte en ligne au lieu d'itext

4. ❌ Espaces de noms XML manquants ou incorrects

5. ❌ Logique conditionnelle trop complexe

6. ❌ Liaisons de champs manquantes

7. ❌ Stockage incorrect des valeurs de sélection multiple

8. ❌ Taille de fichier dépassant les limites

9. ❌ Absence de validation pour les champs critiques

10. ❌ Utilisation du type dateTime pour les dates

11. ❌ Absence d'options pour données incomplètes

12. ❌ Durcissement des valeurs d'option

13. ❌ Ne pas utiliser de groupes pour les champs liés

14. ❌ Identifiant d'instance Meta manquant

Conventions de nommage des champs

Modèles de nommage recommandés

Exemples issus d'enquêtes en production

Lignes directrices sur la structure des enquêtes

1. Flux logique

2. Champs obligatoires vs facultatifs

3. Organisation des groupes

4. Ordre des champs

Tests et validation

Avant le téléversement

Après le téléversement

Dépannage

Erreurs courantes

Conseils de débogage

Ressources supplémentaires

Liste de contrôle récapitulative