Валидация данных в электронной форме

Проверки при вводе экономят недели разбора. Но настроенные наугад, они мешают работе и заставляют сотрудников искать обходные пути.

Ниже — как выбрать правила, которые действительно ловят ошибки.

Что такое валидация

Валидация — это проверка значения в момент ввода или сохранения. Она сравнивает данные с ожидаемыми: диапазоном, форматом, связью с другими полями.

Проверка не исправляет данные, а обращает внимание сотрудника на возможную ошибку.

Валидация работает только тогда, когда сотрудник понимает её смысл. Правило, смысл которого не объяснён, воспринимается как помеха и обходится.

Виды проверок

Простейшие проверяют формат и обязательность. Более сложные сравнивают значения между полями, например дату окончания с датой начала.

Отдельно выделяют проверки на совпадение с внешними справочниками: кодами, единицами измерения, терминами.

Отдельно стоит проверять дубли: повторная запись визита встречается чаще, чем кажется, особенно при сбоях системы.

Проверку на дубли удобно сочетать с предупреждением о похожей записи. Сотрудник может подтвердить, что это разные визиты, и случай останется в журнале.

Жёсткие и мягкие правила

Жёсткая проверка блокирует сохранение. Мягкая — предупреждает, но позволяет продолжить с пояснением.

Жёсткие правила ставят там, где ошибка очевидна. Если значение может быть необычным, но верным, лучше предупреждение.

Практика показывает: блокирующих проверок должно быть немного. Основную работу делают предупреждения с обязательным пояснением.

Диапазоны

Диапазоны задают по реальным данным и здравому смыслу: возраст, вес, лабораторные показатели. Слишком узкий диапазон отсекает верные значения, слишком широкий бесполезен.

Границы стоит пересматривать по мере накопления данных.

Границы диапазонов стоит сверять с лабораторными референсами и единицами измерения. Ошибка в единицах превращает верное значение в «выброс».

Логические связи

Проверки связей ловят противоречия: дата визита раньше согласия, препарат назначен после завершения курса, показатель вне допустимого интервала при указанном состоянии.

Каждая связь должна быть описана в словаре, иначе сотрудник не понимает, что именно нарушено.

Проверки связей настраивают после того, как определены все поля. Иначе правила придётся переписывать при каждом изменении формы.

Сообщения

Текст сообщения объясняет, что не так и что сделать. Формулировка «ошибка 4021» бесполезна.

Хорошее сообщение указывает поле, причину и допустимый вариант.

Сообщение должно появляться рядом с полем, а не только в конце страницы. Иначе сотрудник ищет ошибку в десяти полях вручную.

Если поле допускает несколько форматов, перечислите их в подсказке. Пример заполнения снижает число ошибок лучше, чем любое предупреждение.

Настройка и тестирование

Перед запуском правила проверяют на наборе примеров: корректных, пограничных и ошибочных. Тестирование выявляет правила, которые блокируют верные данные.

Изменения в правилах фиксируют с датой.

Тестовые примеры стоит сохранять: при следующем изменении правил их используют повторно, не придумывая заново.

Обучение сотрудников

Сотрудники должны понимать смысл проверок, а не просто обходить их. Разбор двух-трёх случаев помогает лучше инструкции.

Отдельно объясняют, как поступить, если данные верны, но не проходят проверку.

Полезно вести короткий перечень типичных ошибок, которые ловят проверки. Он помогает новым сотрудникам быстрее освоиться.

Журнал отклонений

Если сотрудник обошёл проверку с пояснением, запись должна сохраняться. По таким случаям видно, какие правила стоит смягчить.

Без журнала настройки никогда не улучшаются.

Просматривайте журнал раз в месяц: если одно правило обходят регулярно, оно, скорее всего, настроено неверно.

Отдельный журнал стоит завести и для случаев, когда проверка сработала верно, а сотрудник всё равно ошибся. Такие записи показывают, каких правил не хватает.

Отклонения удобно отслеживать так же, как износ аккумулятора: важны конкретные показатели за период, а не одно измерение.

Влияние на анализ

Слишком строгие правила могут вытеснить реальные отклонения в комментарии, где их никто не учитывает. Это хуже, чем отсутствие проверки.

Поэтому правила обсуждают с тем, кто будет анализировать данные.

Обсуждение правил с аналитиком занимает полчаса, но избавляет от ситуации, когда половина значений ушла в комментарии.

Пример: слишком узкий диапазон

Правило ограничивает вес значениями до 120 кг. У участника с весом 124 кг сотрудник вводит 120 и оставляет комментарий.

При анализе выясняется, что часть данных искажена. Правило меняют на предупреждение с обязательным пояснением.

История показывает: проверка должна помогать фиксировать факт, а не подгонять его.

После изменения правила проверьте, не искажены ли данные за прошлый период. Если да, отметьте это в отчёте о качестве.

Чек-лист

Определены обязательные поля и форматы.
Заданы диапазоны по реальным данным.
Описаны логические связи.
Жёсткие правила отделены от предупреждений.
Сообщения объясняют причину.
Правила протестированы на примерах.
Ведётся журнал обходов.
Настройки пересматриваются по данным.

Частые вопросы

Сколько правил нужно?

Столько, сколько помогают. Десяток продуманных проверок полезнее сотни формальных.

Можно ли менять правила после старта?

Можно, с фиксацией версии и даты. Уже собранные данные при этом не пересчитываются автоматически.

Что делать, если верное значение не проходит проверку?

Оставить пояснение и зафиксировать случай. Затем решить, нужно ли менять правило.

Кто отвечает за настройку?

Обычно тот, кто ведёт базу данных, по согласованию с исследователем.