Почему конструктор дневниковых записей —
это не медицинская информационная система

Когда врач впервые открывает StomAI, у него почти всегда возникает один и тот же вопрос: «А это вместо нашей программы?» Ответ короткий — нет. И это не оговорка в пользовательском соглашении, а принципиальное устройство инструмента. Конструктор дневниковых записей и медицинская информационная система решают разные задачи, лежат в разных слоях рабочего процесса и несут разную ответственность. Путаница здесь дорого стоит: от неоправданных ожиданий до ввода персональных данных туда, где им не место.

Разберём границу спокойно и по пунктам.

Что делает МИС и что делает конструктор текста

Медицинская информационная система — это учётный контур клиники. Её работа начинается задолго до приёма и продолжается после него. МИС отвечает за то, чтобы у пациента была одна карта, у карты — история, у истории — хронология, а у клиники — возможность в любой момент поднять документ и показать его проверяющему, страховой компании или суду.

Типовой набор функций МИС:

• идентификация пациента и ведение единой электронной карты;
• хранение медицинской документации с фиксацией авторства и времени внесения;
• расписание, запись на приём, загрузка кабинетов и врачей;
• учёт услуг, прейскурант, счета, акты, работа со страховыми программами;
• склад и списание материалов;
• разграничение прав доступа между врачами, администраторами и руководством;
• журналирование действий, резервное копирование, выгрузка отчётности.

Всё это — про учёт. МИС отвечает на вопросы «кто», «когда», «что сделал», «сколько стоило» и «где это лежит».

Конструктор дневниковых записей отвечает на один вопрос: «как это сформулировать». Он работает в узком окне — от момента, когда врач закончил осмотр, до момента, когда текст оказался в карте. Внутри этого окна StomAI помогает собрать описание приёма: подобрать шаблон под клиническую ситуацию и код МКБ-10, отметить зубы на формуле, дополнить формулировку деталями конкретного случая и получить готовый абзац, который можно скопировать.

Удобная аналогия: МИС — это картотека и бухгалтерия, конструктор — рабочий стол, на котором врач собирает текст перед тем, как положить его в картотеку. Рабочий стол не хранит документы. Картотека не помогает подбирать слова.

Конструктор не конкурирует с МИС, потому что не делает ничего из того, за что МИС отвечает. Он закрывает участок, который МИС традиционно оставляет врачу: пустое текстовое поле и необходимость заполнить его связным описанием.

Где заканчивается шаблон и начинается учётная система

Граница проходит там, где текст перестаёт быть черновиком и становится записью в медицинской карте. До этой точки — зона шаблонизатора. После — зона учётной системы и ответственности клиники.

Разделим процесс по шагам, чтобы было видно, кто и что делает.

1. Приём и осмотр. Работа врача. Никакой инструмент не наблюдает за пациентом вместо него.
2. Формирование описания. Здесь полезен конструктор: он предлагает структуру дневниковой записи, типовые формулировки жалоб, объективного статуса, проведённого лечения и рекомендаций.
3. Проверка и правка. Врач читает получившийся текст и приводит его в соответствие с тем, что действительно было на приёме. Это ключевой шаг, и его нельзя делегировать.
4. Внесение в карту. Текст копируется в МИС или в бумажную форму 043/у. С этого момента запись существует в учётном контуре клиники.
5. Хранение, доступ, выгрузка. Полностью на стороне МИС и организационных регламентов клиники.

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

Конструктор не является медицинской документацией. Черновик в браузере — это не запись в карте. Юридическую силу имеет то, что внесено в учётную систему клиники с фиксацией автора и даты. Если текст не перенесён в карту, с точки зрения документооборота приёма не было описано.

Конструктор не заменяет форму 043/у. Медицинская карта стоматологического больного — утверждённая форма со своими требованиями к составу и ведению. StomAI помогает заполнить её содержательную часть быстрее и ровнее, но сама форма, порядок её ведения и хранения остаются за клиникой.

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

И наоборот: от МИС не стоит ждать, что она научит формулировать. Большинство систем предоставляют поле ввода и, в лучшем случае, набор статичных шаблонов, заведённых когда-то администратором. Они не адаптируются под ситуацию, не привязаны к зубной формуле и не помогают, когда клинический случай чуть сложнее типового.

Данные пациента: что не нужно вводить в конструктор

Это самый важный раздел статьи, и он требует максимально ясных формулировок.

Конструктор текста не нуждается в персональных данных, чтобы работать. Чтобы собрать описание лечения кариеса дентина на 36 зубе, системе достаточно знать клиническую картину и номер зуба. Имя пациента, его телефон и адрес не улучшают формулировку ни на слово. Значит, вводить их незачем — а любые данные, которые не нужны для результата, вводить не следует.

Что не нужно указывать в полях конструктора:

• фамилию, имя, отчество пациента;
• дату рождения и возраст в связке с именем;
• номер медицинской карты, полиса, СНИЛС, паспортные данные;
• телефон, адрес, email и аккаунты в мессенджерах;
• место работы, должность, сведения о родственниках;
• любые уникальные детали, по которым человека можно узнать, — вплоть до «пациентка, администратор нашей клиники».

Что ввести уместно и достаточно:

• клиническую ситуацию: жалобы, данные осмотра, результаты зондирования и перкуссии, описание рентгенограммы;
• номера зубов по зубной формуле;
• код диагноза по МКБ-10;
• выполненные манипуляции, материалы, анестезию;
• рекомендации и план следующего визита;
• обезличенные характеристики, значимые клинически: «беременность, второй триместр», «аллергия на артикаин», «пациент 7 лет».

Персональные данные — обязанность и пациента, и клиники. Они должны оставаться там, где для них есть законные основания обработки, подписанное согласие, разграниченный доступ и журнал операций: в МИС клиники и в бумажной карте. Идентификация записи происходит при переносе текста в карту — карта уже знает, чей это приём. Склеивать обезличенный клинический текст с личностью пациента — работа учётной системы, а не шаблонизатора.

Отдельно о привычке подставлять реальные данные «чтобы было нагляднее». Этот сценарий чаще всего возникает при демонстрации инструмента коллегам или при обучении администраторов. Используйте условные обозначения: «пациент А», «зуб 46», «мужчина 34 лет». Результат будет тем же, а лишнего следа не останется.

Простое правило, которое стоит повесить рядом с рабочим местом: в конструктор — клиника случая, в МИС — личность пациента. Если возник соблазн ввести что-то третье, скорее всего, вводить это не нужно вовсе.

Как встроить конструктор в текущий рабочий процесс

Хорошая новость: менять ничего не придётся. Конструктор работает рядом с существующей системой, а не вместо неё. Ни миграции данных, ни интеграции, ни согласования с поставщиком МИС для начала работы не требуется — достаточно браузера и буфера обмена.

Базовый сценарий на приёме

Врач завершает манипуляции, открывает StomAI во второй вкладке или на планшете, отмечает зубы на формуле, выбирает подходящий шаблон по диагнозу, уточняет детали — объём препарирования, использованные материалы, особенности анестезии. Получившийся текст перечитывает, правит под реальность приёма и копирует в поле дневника в МИС. Дальше всё идёт по обычному маршруту клиники: сохранение, подпись, учёт услуг.

На практике тяжелее всего даётся не копирование, а именно шаг проверки. Готовый складный абзац создаёт ощущение завершённости, и его хочется вставить не читая. Привычка перечитывать текст целиком до вставки — главное, что отличает корректное использование инструмента от формального.

Сценарий «в конце смены»

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

Что имеет смысл договориться внутри клиники

• Кто имеет право пользоваться конструктором: врачи, ассистенты, оба.
• В какой момент текст попадает в карту — сразу после приёма или в конце смены, с указанием предельного срока.
• Какие формулировки клиника считает обязательными: информированное согласие, предупреждение о рисках, рекомендации, срок следующего визита.
• Правило об обезличивании при работе с конструктором — лучше в письменном виде, одним абзацем в регламенте.
• Кто отвечает за единообразие записей в клинике: обычно главный врач или заведующий отделением.

Чего делать не стоит

• Хранить черновики в конструкторе как замену карте — это не хранилище.
• Копировать запись в карту без прочтения.
• Переносить шаблонную формулировку, если она не соответствует тому, что было сделано. Расхождение описания и фактического лечения — проблема куда серьёзнее, чем лишние десять минут на правку.
• Указывать манипуляции «на будущее», которые планируются, но ещё не выполнены.

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

Что остаётся за врачом и за клиникой

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

Диагноз ставит врач. Конструктор работает с кодами МКБ-10 как со справочником формулировок, а не как с диагностической системой. Он не осматривает пациента, не читает рентгенограммы и не выбирает между пульпитом и периодонтитом. Выбор диагноза — результат клинического мышления врача, и инструмент лишь помогает записать уже принятое решение.

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

Достоверность записи — на враче. Запись должна описывать то, что действительно произошло на приёме. Ни один шаблон не отвечает за соответствие текста реальности: это ответственность автора записи, и она не делится.

Хранение, доступ и защита данных — на клинике. Выбор МИС, настройка прав доступа, резервные копии, согласия на обработку персональных данных, сроки хранения документации, порядок выдачи копий карты по запросу — всё это организационный контур медицинской организации.

Юридическая значимость документа — на клинике. Подпись, дата, авторство, неизменность внесённой записи обеспечиваются учётной системой и внутренними регламентами, а не текстовым редактором.

Что при таком разделении остаётся инструменту? Довольно много, если смотреть по итогу рабочего дня: ровная структура записей у всех врачей клиники, меньше пропущенных обязательных пунктов, сокращение времени на дневники, отсутствие необходимости придумывать формулировку заново на каждом похожем приёме. Это не медицинская информационная система — и попытка стать ею сделала бы инструмент хуже в том, что он действительно умеет.

Если нужно одно предложение для объяснения коллегам: МИС хранит и учитывает, конструктор формулирует, врач отвечает. Другие материалы о ведении дневниковых записей — в блоге StomAI.

Вопрос-ответ

Может ли StomAI заменить медицинскую информационную систему клиники?

Нет. Конструктор не идентифицирует пациентов, не хранит медицинскую документацию, не ведёт расписание, учёт услуг и склад, не разграничивает права доступа. Он помогает собрать текст приёма, который затем переносится в МИС или бумажную карту. Учётный контур остаётся за медицинской информационной системой клиники.

Имеет ли запись, собранная в конструкторе, юридическую силу?

Сама по себе — нет, это черновик. Юридическое значение имеет запись, внесённая в медицинскую карту клиники с фиксацией автора и даты. StomAI не заменяет форму 043/у и не является медицинской документацией.

Какие данные пациента можно вводить в конструктор?

Только обезличенную клиническую информацию: жалобы, данные осмотра, номера зубов, код МКБ-10, выполненные манипуляции, материалы, рекомендации. ФИО, дату рождения, номер карты, полис, СНИЛС, телефон, адрес и прочие персональные данные вводить не нужно — они не влияют на формулировку и должны оставаться в МИС клиники.

Нужна ли интеграция с нашей МИС, чтобы начать работать?

Нет. Конструктор работает рядом с существующей системой: текст собирается в браузере и копируется в поле дневника вашей МИС через буфер обмена. Миграция данных и согласование с поставщиком МИС не требуются.

Ставит ли сервис диагноз?

Нет. Коды МКБ-10 используются как справочник формулировок. Диагноз, план лечения и достоверность внесённой записи — ответственность врача; инструмент помогает записать уже принятое клиническое решение.

Что должна зафиксировать клиника во внутреннем регламенте при использовании конструктора?

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