Вільний кабінет ще не означає, що клініка може відкрити додатковий запис. У той самий проміжок потрібні доступне обладнання, відповідна робоча роль і час на підготовку між прийомами. Якщо хоча б одного ресурсу бракує, привабливий календар залишиться лише картинкою.
ШІ можна залучити до підготовки варіантів адміністративної сітки та пояснення обмежень. Остаточні розрахунки потрібно перевіряти окремо, а зміни затверджувати людині. Нижче — авторський навчальний процес «Надалі» з повністю вигаданими даними. Це не клінічне сортування, рекомендації щодо лікування, оцінювання працівників чи юридична консультація.
1. Відокремте доступність від конкретних записів
Почніть із запитання: «Скільки блоків певного типу можна фізично розмістити за заданих умов?» Не передавайте моделі список пацієнтів і не просіть визначити, кому потрібен прийом раніше.
У специфікації HL7 FHIR R5 ресурс Schedule описує доступність без відомостей про фактичні прийоми. Для запису, що потребує кількох ресурсів, може знадобитися перевірка кількох розкладів. Це корисне концептуальне розмежування, а не твердження про можливості конкретної програми. HL7: Schedule.
Для навчального файлу достатньо таких полів: код вигаданого ресурсу, доступний інтервал, заблокований інтервал, тип блоку, тривалість і потрібна кількість одиниць. Ролі позначайте умовно: «роль А», а не прізвищем. Не додавайте діагнозів, контактів, приміток адміністратора або історії відвідувань.
Агрегування саме по собі не дає підстав вважати реальні відомості безпечними для передавання. У цьому вправлянні використовуйте числа, створені з нуля, без можливості відновити чийсь справжній запис. Перевірка реальних даних і дозволів на їх використання — окрема робота поза цим шаблоном.
2. Домовтеся про одиницю планування
Однакова кількість записів може означати різне навантаження на ресурси. Тому перед підрахунком визначте типи блоків і затверджені відповідальними фахівцями вимоги до них. Модель не повинна самостійно скорочувати тривалість прийому або підготовки, щоб отримати кращий результат.
Не прирівнюйте кількість проведених прийомів до всього попиту. У посібнику NHS з планування потужності пояснено: виконана робота відображає можливості сервісу і не тотожна попиту. NHS: посібник з агрегування моделей.
Для вправи задайте синтетичний запит: розмістити вісім однакових блоків. Нерозміщені блоки залишаються видимим дефіцитом потужності. ШІ не має приховувати їх, змінюючи одиниці або вигадуючи додаткові ресурси.
3. Перевірте невеликий приклад вручну
Усі умови нижче вигадані й не є нормами тривалості для будь-якої медичної послуги:
- Період планування: умовний день, 09:00–12:00.
- Кабінет К1: доступний протягом усього періоду.
- Обладнання О1: доступне, крім 10:00–10:20.
- Роль А: одна доступна одиниця, 09:00–11:30.
- Кожен блок займає 20 хвилин усіх трьох ресурсів: умовно 15 хвилин прийому та п’ять хвилин підготовки.
- Початки блоків: 09:00, 09:20, 09:40 і далі з кроком 20 хвилин. Подвійне бронювання заборонене.
Кабінет окремо дає дев’ять позицій. Однак спільно доступні лише шість: 09:00, 09:20, 09:40, 10:20, 10:40 та 11:00. Блок о 10:00 конфліктує з недоступністю обладнання. Блоки об 11:20 та 11:40 завершуються після доступності ролі А.
Отже, для восьми запитаних блоків дефіцит становить два. Другий кабінет сам по собі цього не виправить. В окремому сценарії, де відповідальний керівник уже підтвердив доступність ролі А до 12:00, можливі вісім блоків. Це умовний розрахунок, а не рекомендація продовжити комусь зміну.
4. Запишіть жорсткі обмеження окремо
Жорсткі обмеження не можна порушувати заради красивого підсумку. До них у цій вправі належать доступність кожного ресурсу, його кількість, повна тривалість блоку, підготовка, заблоковані проміжки та заборона перетинів.
Побажання, наприклад компактніше розташування вільних блоків, розглядайте лише після перевірки допустимості. Не додавайте оцінок «швидкості» або «надійності» окремих працівників. Доступність ролі — вхідна умова, а не рейтинг людини.
Для кожної запропонованої позиції перевірте весь інтервал, а не лише початок. Якщо блок закінчується об 11:40, доступність до 11:30 недостатня. Визначте також правило меж: у прикладі інтервал включає початок, але не включає кінець, тож суміжні блоки можуть мати спільну граничну хвилину.
Обов’язково позначте дату, часовий пояс і версію набору умов. У короткій вправі використовується одна часова шкала; для реального календаря неоднозначні дати або переходи часу потребують окремої технічної перевірки.
5. Дайте ШІ вузьке завдання
Ось редакційний шаблон запиту, а не перевірена функція певного продукту:
Працюй лише з наведеними синтетичними ресурсами. Підготуй чернетку доступних блоків, не створюючи записів. Не змінюй тривалості, доступність і заблоковані інтервали. Для кожного блоку вкажи початок, кінець, ресурси та перевірені обмеження. Окремо покажи конфлікти, нерозміщені блоки й відсутні вхідні дані. Якщо умови несумісні, повідом про дефіцит. Не ухвалюй клінічних або кадрових рішень.
Попросіть також короткий список змін щодо попереднього варіанта. Наприклад: «Додано два можливі блоки лише через зміну підтвердженої доступності ролі А». Це допомагає помітити, чи модель непомітно переписала іншу умову.
Не покладайтеся на самоперевірку моделі. NIST описує ризик упевнено поданих неправильних відповідей, зокрема хибних пояснень. Тому переконливий текст не замінює перевірки інтервалів. NIST: профіль ризиків генеративного ШІ.
6. Перевіряйте результат незалежно
Підготуйте звичайну таблицю або перевірений скрипт, який повторно обчислює тривалість і шукає накладання для кожного ресурсу. Для малих прикладів зробіть це вручну. Не використовуйте другий текстовий висновок тієї самої моделі як єдине підтвердження.
Корисний тест: навмисно запропонуйте два блоки з тим самим обладнанням одночасно. Перевірка повинна відхилити конфлікт. Окремо перевірте відсутню тривалість, дубльований ідентифікатор ресурсу та блок, який виходить за межі доступності. Невідоме значення не має автоматично означати «вільно».
Форма результату може містити п’ять пунктів: версія вхідних умов; допустимі блоки; знайдені конфлікти; нерозміщений залишок; питання до відповідального адміністратора. Зберігайте також відхилені варіанти з короткою причиною.
7. Затверджуйте зміни перед внесенням у календар
Вправу завершує не повний календар, а перевірена чернетка. У реальному процесі уповноважена людина окремо підтверджує ресурси, необхідні обмеження та право змінювати розклад. Перед збереженням потрібно знову перевірити актуальну доступність: після підготовки чернетки вона могла змінитися.
Захист від одночасного бронювання має забезпечувати система запису, а не обіцянка чатбота. Якщо механізм перевірки або збереження невідомий, не переносіть чернетку автоматично. Зберігайте попередню версію й журнал затверджених змін.
Для оцінювання вправи рахуйте конфлікти, пропущені обмеження та час перевірки разом із часом підготовки чернетки. Не обіцяйте економію або більше прийомів до вимірювання. Практичний результат — зрозуміло показати, що можна розмістити, чого бракує і яке рішення залишається за людиною.
Надалі. Матеріал підготовлено за допомогою ШІ (ChatGPT); приклад і шаблон є редакційними, без випробування в реальній клініці. Джерела перевірено 2 листопада 2026 року.
Обкладинка — повторно використана концептуальна ШІ-ілюстрація звірки записів, не медична документація чи фото клініки.
