Explore
Уложитесь в мой дедлайн?
Oops! Something went wrong while submitting the form.
Персональные данные пациента — это информация, которая позволяет его идентифицировать: ФИО, дата рождения, адрес, телефон, email, паспортные данные, полис ОМС.
Но в медицине есть особая категория — специальные персональные данные. К ним относятся сведения о состоянии здоровья: диагнозы, результаты анализов, история болезни, записи в медицинской карте, назначения врача.
Разница между обычными и специальными данными неформальная — она определяет уровень защиты. Специальные защищены строже, потому что их утечка может привести к дискриминации при трудоустройстве, отказу в страховке или социальной стигматизации. Поэтому их выделяют в отдельную группу с повышенными требованиями.
Учитывая эту специфику, при разработке медицинских приложений мы в Purrweb сразу выделяем персональные данные пациентов в отдельные защищенные сущности — этот подход называется разграничение данных. Так система изначально строится с учетом разных уровней доступа, что снижает риски утечки на уровне архитектуры.
152-ФЗ «О персональных данных» устанавливает общие правила: как их собирать, на каком основании обрабатывать, как хранить и когда удалять. Закон требует получать согласие, обеспечивать безопасность и уведомлять Роскомнадзор о начале обработки персональных данных пациентов.
Но в медицине действует еще 323-ФЗ «Об основах охраны здоровья граждан», который вводит понятие врачебной тайны и устанавливает, у кого будет право на доступ к медицинской информации. Этот закон дополняет федеральный закон 152 ФЗ специфическими требованиями для медицинских организаций.
Роскомнадзор контролирует соблюдение законодательства. Он проводит проверки, выдает предписания и штрафует клиники за нарушения — от отсутствия согласий до утечки данных.
Мы в Purrweb учитываем эти нормы уже на этапе проектирования архитектуры. Данные размещаются только на серверах в России, что соответствует требованиям локализации. Применяем принцип защиты информации на этапе проектирования — алгоритм закладывается в систему изначально, а не добавляется потом как дополнительный слой.
Чтобы понять, как соблюдать требования законодательства, нужно разобраться, как медицинское ПО работает с данными на каждом этапе.
-1.png&w=1080&q=75)
Первый контакт пациента с системой происходит через форму на сайте или в мобильном приложении. Здесь он указывает базовые сведения: ФИО, телефон, email, иногда дату рождения.
Уже на этом этапе важно получить согласие на обработку персональных данных — через чекбокс с понятной формулировкой и ссылкой на политику конфиденциальности.
Когда пациент регистрируется в личном кабинете, объем собираемых данных расширяется: адрес, паспорт, полис ОМС, СНИЛС. Эта информация должна передаваться по защищенному соединению и сразу попадать в систему, а не оседать в промежуточных хранилищах.
Мы в Purrweb строим интеграции так, чтобы данные из формы мгновенно попадали в МИС или CRM по защищенным API, минуя логи почты и мессенджеры — это исключает риск утечки на промежуточных этапах.
После сбора данные структурируются и сохраняются в базе. Медицинская информационная система хранит полную медицинскую карту пациента: анамнез, результаты обследований, назначения, выписки. Эти сведения относятся к специальной категории и требуют усиленной защиты — шифрования, разграничения доступа по ролям, регулярного резервного копирования.
Важно правильно организовать структуру базы данных. Общие персональные данные и медицинские сведения должны храниться раздельно с разными уровнями доступа. Это позволяет администратору системы работать с технической частью, не имея доступа к врачебной тайне.
Часто клиники используют связку МИС и CRM: первая ведет медицинскую документацию, вторая — управляет коммуникацией с пациентами. При передаче данных между системами важно использовать защищенные каналы и передавать только необходимый минимум информации.
Например, для отправки напоминания о приеме CRM не нужен диагноз пациента — достаточно имени, времени визита и контактов.
Пациент должен иметь возможность видеть свой профиль и корректировать его. Личный кабинет позволяет обновить контакты, добавить информацию об аллергиях или хронических заболеваниях.
Система должна фиксировать, кто и когда внес изменения — это требование аудита. История изменений помогает отследить, если данные были изменены ошибочно или несанкционированно.
Если пациент отзывает согласие на обработку данных, клиника обязана удалить информацию, если нет законных оснований для хранения. Например, медицинская карта должна храниться по закону минимум 25 лет, но маркетинговые пометки в CRM можно удалить сразу.
Система должна предусматривать механизм безопасного удаления — не просто пометку записи как удаленной, а физическое стирание информации из базы и резервных копий.
Согласие пациента — один из ключевых элементов законной обработки персональных данных в клинике. Но не всегда оно требуется, и важно понимать эту разницу, чтобы не усложнять процессы там, где это не нужно.
Согласие необходимо, когда клиника обрабатывает данные для целей, не связанных напрямую с оказанием медицинской помощи. Например, для отправки рекламных рассылок, SMS-напоминаний о профилактических осмотрах, проведения маркетинговых исследований или передачи партнерам.
Также согласие обязательно при обработке биометрических персональных данных, если это не предусмотрено законом.
Клиника может обрабатывать данные без согласия, если это необходимо для оказания медицинской помощи. Когда пациент приходит на прием, заключается договор на оказание медицинских услуг — это и есть правовое основание для обработки.
Также согласие не требуется, если обработка персональных данных пациентов необходима для выполнения законодательных требований: передача данных пациента в ЕГИСЗ, предоставление информации по запросу суда или правоохранительных органов, ведение медицинской документации.
Согласие должно быть конкретным, информированным и добровольным. В интерфейсе это означает понятные формулировки без юридического жаргона, отдельные чекбоксы для разных целей обработки и возможность отказаться от необязательных опций.
В проектах мы реализуем гранулированное согласие — пациент видит отдельные чекбоксы под обработку данных для лечения, для маркетинга, для передачи партнерам. Каждое согласие сохраняется в базе данных с отметкой времени и версией политики, что позволяет доказать законность обработки при проверке.
Пациент имеет право отозвать согласие в любой момент. После отзыва клиника должна прекратить обработку данных для тех целей, на которые согласие отозвано.
Но если есть другие правовые основания — например, договор или закон — сведения продолжают обрабатываться. Медицинская карта не удаляется при отзыве согласия, потому что ее хранение — это законодательное требование, а не вопрос согласия.
⭐ Наш опыт
Для платформы видеоконсультаций с психологами мы сделали интерфейс, где пользователи могут легко управлять личными данными и согласиями на обработку. Клиенты выбирают психолога, записываются на сессию и начинают консультацию без лишних шагов.
Доступ врачей ограничен только необходимой информацией, а система уведомляет пользователя о каждом действии с данными. Интуитивный интерфейс позволяет безопасно взаимодействовать с сервисом, при этом пользователи видят, кто и какие сведения может использовать.
-1.png&w=1080&q=75)
Врачебная тайна — это отдельный режим защиты информации, который выходит за рамки обычных персональных данных. И он критичен при разработке медицинского ПО.
Врачебная тайна по 323-ФЗ охватывает не только диагноз и результаты анализов, но и сам факт обращения пациента за медицинской помощью, методы лечения, прогноз. Разглашение врачебной тайны влечет не только административную, но и уголовную ответственность.
Это значит, что данные, составляющие врачебную тайну, должны быть изолированы от остальной информации. Доступ к ним получают только те сотрудники, которым это необходимо для выполнения профессиональных обязанностей: лечащий врач, медсестра, заведующий отделением.
Мы в Purrweb разделяем врачебную тайну и персональные данные технически: создаем отдельные уровни доступа в системе, применяем автоматическое шифрование для медицинских записей. Даже если кто-то получит доступ к базе данных, без ключей расшифровки информация останется нечитаемой.
Логи системы настроены так, чтобы не фиксировать содержимое медицинских записей — только факт доступа и действия пользователя.
Частая ошибка — хранение медицинских данных в общедоступных для сотрудников системах. Например, когда администратор может открыть карточку любого пациента для «технической проверки».
Другая проблема — передача данных в CRM или аналитические системы без должной фильтрации. Маркетинговой команде не нужно знать диагнозы пациентов для отправки напоминаний о приеме.
Отдельная зона риска — фотографии «до/после» в косметологии и стоматологии. Даже если лицо пациента не видно полностью, такие снимки могут содержать идентифицирующие признаки и относятся к врачебной тайне. Их нельзя публиковать без письменного согласия пациента, а хранить нужно с тем же уровнем защиты, что и медицинскую карту.
Мессенджеры и колл-центры — еще одно слабое звено. Когда оператор обсуждает с пациентом детали приема в WhatsApp или администратор уточняет диагноз по телефону в открытом офисе, это нарушение врачебной тайны. Переписка должна вестись через защищенные каналы внутри МИС, а разговоры — в изолированных помещениях.
Требования законодательства нужно переводить в конкретные технические решения. Ниже — элементы, которые должны быть реализованы в каждом медицинском ПО.
Каждая форма, где пациент вводит персональные данные, должна содержать чекбокс согласия на обработку. Формулировка должна быть понятной, без отсылок к пунктам законов.
Рядом с чекбоксом — ссылка на полную политику конфиденциальности. Если данные собираются для разных целей (лечение, маркетинг, аналитика), нужны отдельные чекбоксы для каждой цели.
⭐ Наш опыт
Для пользователей лабораторных тестов важно видеть изменения своих показателей без лишних усилий. В Biogeek мы сделали веб-интерфейс, который автоматически извлекает данные из загруженных документов и строит наглядные графики.
Пациенты могут отслеживать динамику здоровья, а консультанты получают доступ только с согласия пользователя.
-1.png&w=1080&q=75)
Политика должна быть доступна в любой момент — ссылка в футере сайта или отдельный раздел в приложении. Документ описывает, какие данные собираются, для каких целей, кому передаются, как долго хранятся и как пациент может реализовать свои права.
Язык должен быть простым, без избыточной юридической терминологии. При изменении политики пациентов нужно уведомить и получить новое согласие, если изменения существенные.
В системе должны быть настроены роли с разными уровнями доступа. Врач видит полную медицинскую карту пациентов, администратор — только контактные данные для записи, маркетолог — обезличенную статистику.
Главврач или заведующий могут иметь расширенный доступ для контроля качества, но это должно логироваться. Технический администратор системы не должен иметь доступа к содержимому медицинских записей — только к настройкам и структуре базы данных.
⭐ Наш опыт
На платформе для вызова медсестры для забора анализов две роли: пациент и медсестра, каждая со своим уровнем доступа. Интерфейс пациента открыт всем пользователям платформы, а интерфейс медсестры — только зарегистрированным специалистам.
Медсестра получает список вызовов, видит данные клиентов и перечень анализов, а также формирует собственное расписание. Старшая медсестра выступает супер-админом, контролируя работу младших сотрудников.
Медицинские данные хранятся в МИС с шифрованием и резервным копированием. При передаче в CRM нужно фильтровать информацию: для маркетинговых рассылок достаточно имени и контактов, диагнозы передавать не нужно.
Интеграция должна работать по защищенным каналам с авторизацией и логированием каждой передачи данных.
Доступ к системе должен быть защищен надежной аутентификацией: сложные пароли, двухфакторная аутентификация для сотрудников с доступом к врачебной тайне.
Все соединения — только по HTTPS. Данные на серверах шифруются как при хранении, так и при передаче.
Если сотрудник отошел от компьютера, система должна автоматически завершить сеанс через несколько минут бездействия. Это предотвращает несанкционированный доступ. Особенно важно в регистратурах и кабинетах, где компьютер доступен нескольким людям.
Собирайте только те сведения, которые действительно нужны. Если для записи на прием достаточно имени и телефона, не требуйте паспортные данные на этом этапе. Чем меньше информации в системе, тем ниже риски при возможной утечке.
Мы в Purrweb реализуем все эти элементы в комплексе — от архитектуры базы данных до интерфейса форм. Это позволяет клинике получить готовое решение, которое соответствует требованиям законодательства без дополнительных доработок.
При интеграции с внешними системами важно понимать, кто и за что отвечает на каждом этапе передачи информации.
Единая государственная информационная система в сфере здравоохранения — это федеральная платформа, куда медицинские организации обязаны передавать данные о пациентах: сведения о случаях оказания медицинской помощи, рецепты, результаты исследований, выписные эпикризы.
Передача регулируется приказами Минздрава и требует соблюдения форматов данных, защищенных каналов связи и использования электронной подписи.
Клиника несет ответственность за полноту, достоверность и своевременность передачи данных. Если информация не отправлена или отправлена с ошибками, это может повлечь штрафы и проблемы при проверках.
Клиника остается оператором персональных данных и несет основную ответственность за их защиту, даже если техническую интеграцию выполняет подрядчик. Разработчик выступает как лицо, осуществляющее обработку по поручению оператора, и обязан обеспечить безопасность в процессе передачи.
Мы в Purrweb встраиваем безопасную передачу через сертифицированные интеграции и четко прописываем зоны ответственности в договоре: кто отвечает за настройку каналов связи, кто — за корректность данных, кто — за мониторинг и реагирование на инциденты.
⭐ Наш опыт
Пациенты с диабетом получают возможность контролировать уровень сахара с помощью системы Freelife, которая непрерывно принимает данные с сенсоров. Информация поступает в мобильное приложение и веб‑панель врача через шифрованные каналы, с разграничением прав доступа: пациент видит свои показатели, врач — только показатели пациентов.
История измерений хранится безопасно, а передача в внешние системы осуществляется через авторизованные интеграции. Такой подход позволяет одновременно отслеживать здоровье и минимизировать риски утечки персональных данных.
Без правильно оформленного пакета документов даже самая защищенная система не спасет от штрафов при проверке.
Этот документ описывает, как клиника собирает, хранит и использует данные пациентов. Политика должна быть доступна на сайте и в приложении, написана понятным языком и содержать информацию о целях обработки, сроках хранения, правах пациентов и контактах для обращений. При изменении политики нужно уведомлять пациентов.
Согласия оформляются в письменной или электронной форме и должны содержать конкретные цели обработки. Для специальных категорий требования строже — нужно явное согласие с указанием, какие сведения и для чего обрабатываются. Согласия хранятся в течение всего срока обработки данных и еще три года после.
Клиника должна утвердить положение о обработке персональных данных, регламент доступа к информационным системам, порядок реагирования на инциденты. Эти документы регулируют внутренние процессы и показывают при проверке, что у клиники выстроена система защиты персональных данных пациентов.
Если клиника передает обработку сведений подрядчикам, нужны договоры с разделом о защите персональных данных. В договоре прописываются обязанности подрядчика, меры защиты, ответственность за утечки.
Сотрудники должны знать, как работать с персональными данными: что можно, что нельзя, как реагировать на запросы пациентов, что делать при подозрении на утечку. Инструкции оформляются письменно, с ними знакомят под подпись.
Мы в Purrweb готовим полный пакет документов под конкретное приложение или информационную систему: политики, шаблоны согласий, регламенты. Все ссылки и политики встраиваются прямо в интерфейс, чтобы клиника получила готовое решение, а не набор технических компонентов без юридического сопровождения.
Этот чеклист поможет вам избежать типичных ошибок перед запуском медицинской платформы.
☐ Минимизация сбора данных
Не требуйте паспорт, СНИЛС или ИНН, если они не нужны на конкретном этапе. Для записи на прием достаточно имени и телефона.
☐ Уникальная политика конфиденциальности
Не копируйте шаблоны из интернета. Политика должна описывать именно ваши процессы: какие данные собираете, куда передаете, как храните.
☐ Разграничение доступа по ролям
Проверьте, что администратор не видит медицинские записи, а маркетолог — только обезличенную статистику. Каждый сотрудник должен иметь доступ только к необходимым данным.
☐ Защита персональных данных от несанкционированного доступа
Убедитесь, что используется HTTPS, настроена двухфакторная аутентификация для сотрудников, пароли хранятся в зашифрованном виде.
☐ Автоматическое завершение сеансов
Система должна разлогинивать пользователя после нескольких минут бездействия.
☐ Тестирование на проникновение (пентест)
Проведите пентест перед релизом, чтобы выявить уязвимости. Мы всегда проводим тесты на проникновение перед запуском — это позволяет найти слабые места в защите до того, как их обнаружат злоумышленники.
☐ Логирование доступа к данным
Проверьте, что система фиксирует, кто и когда обращался к персональным данным пациентов.
☐ Наличие всех документов
Убедитесь, что готовы политика конфиденциальности, шаблоны согласий, договоры с подрядчиками, инструкции для сотрудников.
Создание медицинского ПО — это не только код и серверы, но и забота о безопасности и удобстве пациентов на каждом этапе. От интерфейсов и форм согласий до интеграции с МИС, CRM и внешними системами — каждая деталь влияет на защиту персональных данных.
Когда архитектура продумана, роли разграничены, а интерфейсы интуитивны, пациенты могут уверенно пользоваться сервисом, а клиники — минимизировать риски утечки и ошибок.
➡️ Если вы планируете разработку медицинского сайта, приложения или МИС, команда Purrweb поможет создать решение, которое соответствует требованиям законодательства с первого дня. Свяжитесь с нами через форму и получите оценку проекта через 48 часов.
%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)-1.png)
.svg)
%20(1)%20(1).avif)
%20(1)%20(1).avif)
