Запись клинических сессий: когда, как и конфликт с комплаенсом

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

Запись телемедицинской консультации – самое рискованное, что создаёт ваша платформа. Это персональные данные о здоровье (специальная категория по ст. 10 152-ФЗ) и сведения, составляющие врачебную тайну (ст. 13 323-ФЗ), которые копируются в один клик и хранятся дольше, чем длится звонок. Приказ Минздрава 193н не обязывает записывать консультации, но если запись сделана, она становится «сопутствующим материалом» и хранится 1 год (п. 49–51). Поэтому первое решение – записывать ли вообще. Если записываете, согласие и прозрачность нужны на двух уровнях: основание для обработки медданных плюс отдельное письменное согласие на любое использование записи за пределами лечения и честное предупреждение о записи лица и голоса до её начала. Самый сложный архитектурный выбор – где вести запись. Сервер пишет дёшево и надёжно, но должен видеть медиа в открытом виде, а это напрямую противоречит сквозному шифрованию. В статье разобраны этот конфликт, три способа его решить и меры (хранение в России, доступ, срок, удаление), которые не дают записи превратиться в утечку.

Зачем это читать

Если вы решаете, строить телемед-платформу или покупать готовую, запись – функция, которая на демо выглядит простой, а в продакшене превращается в главный источник ответственности. Кнопка «записать консультацию» – несколько строк кода. А утечка записи, судебный запрос, перепутанные пациенты или запрос на удаление, который вы не можете исполнить, – проблема уровня совета директоров. Статья написана для основателя, продакт-менеджера или ИТ-руководителя клиники, которому нужно решить, будет ли продукт записывать клиническое видео, и отстоять это решение перед юристом, безопасником, проверяющим и пациентом. Зачем мы пишем? Кто может смотреть? Где лежит файл? Сколько храним? Что будет, когда пациент попросит копию или удаление? Это продуктовые решения задолго до того, как они станут инженерными. Ошибка здесь – не просто баг: в медицине это инцидент, о котором придётся уведомлять Роскомнадзор.

Первое решение: писать или не писать

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

Причина в асимметрии рисков. Живая консультация – тоже обработка медданных, но она длится двадцать минут и заканчивается. Запись – те же медданные, застывшие в файле, который можно скопировать, переслать, положить не туда, истребовать по запросу, слить и хранить годами. Временный риск превращается в постоянный. Это может быть оправдано, но только ради конкретной цели, а не по умолчанию.

Веские причины записывать есть. Запись может дополнять медицинскую документацию и помогать при разборе спорного случая. Она может понадобиться для наставничества, когда опытный врач разбирает консультации ординатора. Её можно использовать для внутреннего контроля качества или, всё чаще, для ИИ-помощника врача, который расшифровывает разговор и готовит черновик протокола приёма: так работает ИИ-помощник, доступный участковым врачам московских поликлиник [16]. Все эти причины законны. Но ни одна из них не звучит как «мы пишем всё, потому что платформа это умеет».

Нажмите, чтобы увеличить

Цель – не формальность: от неё зависит вся архитектура. Запись, сделанная в лечебных целях, по 193н хранится как сопутствующий материал 1 год. Для наставничества может понадобиться узкий, ограниченный по времени доступ для одного рецензента. Если аудио нужно только ИИ-помощнику, рассмотрите потоковую обработку без сохранения файла: уже созданная запись консультации становится сопутствующим материалом со своим сроком хранения, и правило «удалить через пять минут после подписания протокола» может ему противоречить. Где проходит граница между буфером распознавания и записью, решайте с юристом. Сначала ответьте на вопрос «зачем»: от него зависят ответы на вопросы «сколько хранить», «кому давать доступ» и «где хранить».

Запись – это медданные с первого кадра

Если вы решили записывать, относитесь к файлу как к медданным с первого кадра: так оно и есть. Любое аудио или видео, по которому можно узнать человека, – его персональные данные. Запись консультации раскрывает факт обращения и состояние здоровья, а это одновременно специальная категория ПДн (ст. 10 152-ФЗ) и врачебная тайна (ч. 1 ст. 13 323-ФЗ) [1][7]. Достаточно того, что камера сняла лицо пациента в окне телемед-приложения.

Важная оговорка: запись лица – ещё не биометрия. Биометрическими данные становятся, когда по ним устанавливают личность, а распознавать пациента по лицу можно только через Единую биометрическую систему или аккредитованную систему (572-ФЗ). Пока вы просто храните видео, действуют правила для медданных; если запустить по архиву распознавание лиц, вы попадёте под отдельный и куда более жёсткий режим.

Из этого сразу следуют две вещи, о которых команды регулярно забывают.

Во-первых, у записи есть установленное место и установленный срок хранения. По 193н материалы консультации – заключения, протоколы, данные наблюдения – вносятся в электронную медицинскую карту в медицинской информационной системе консультирующей организации (п. 49–50), а аудио- и видеозаписи, сообщения и изображения относятся к сопутствующим материалам и хранятся 1 год (п. 51) [9]. Ещё до звонка пациенту сообщают, кто оператор информационной системы и где хранятся материалы (п. 37), так что архитектура хранения становится публичной информацией. И хранить можно только в России: с 1 июля 2025 года ПДн граждан РФ запрещено записывать и хранить в зарубежных базах данных (ч. 5 ст. 18 152-ФЗ).

Во-вторых, хранимую запись нужно уметь предоставить по запросу. Пациент вправе запросить сведения о своих персональных данных, и оператор отвечает в течение 10 рабочих дней с возможным продлением ещё на 5 (ст. 14 и 20 152-ФЗ) [4]. Он же вправе получать медицинские документы, их копии и выписки, в том числе в электронной форме (ч. 5 ст. 22 323-ФЗ) [8]. Если система не может найти и выгрузить записи одного пациента по запросу, это не функция, а брешь в соблюдении требований. «Пишем всё в бакет и никогда туда не смотрим» – не безопасная позиция, а куча медданных, которую невозможно проверить и которая рано или поздно утечёт. Каждой записи нужны владелец, правила доступа, срок хранения и порядок удаления; о них – ниже.

Согласие: два уровня, а галочка закрывает только один

Самая частая ошибка: команда добавляет галочку «Согласен на обработку персональных данных», выпускает релиз и считает, что защищена. На деле она закрыла только один из двух вопросов, которые возникают при записи, и часто не тот, о котором думает.

Первый уровень – медданные и врачебная тайна. Вопрос в том, на каком основании вы обрабатываете и передаёте сведения о здоровье. Медицинская организация, оказывающая помощь, обрабатывает их в медицинских целях силами людей, обязанных хранить врачебную тайну, – для этого отдельное согласие на обработку не требуется (п. 4 ч. 2 ст. 10 152-ФЗ). Платформе, которая сама не медорганизация, нужно письменное согласие пациента (ч. 4 ст. 9), а с 1 сентября 2025 года его оформляют отдельно от оферты, политики и договора [6]. Но главное начинается за пределами лечения. Показать запись студентам и ординаторам, разобрать её на конференции, опубликовать фрагмент, обучить на ней ИИ-модель – всё это передача сведений, составляющих врачебную тайну, и она допустима только с письменного согласия пациента или его законного представителя (ч. 3 ст. 13 323-ФЗ) [7]. Указывайте в согласии конкретную цель: согласие «на всё» не распространяется на новые способы использования.

Второй уровень – лицо, голос и прозрачность самой записи. Видеозапись – это ещё и изображение человека. Гражданский кодекс разрешает обнародовать и использовать изображение гражданина, в том числе в видеозаписи, только с его согласия (п. 1 ст. 152.1 ГК РФ) [10]. Для записи, которая не покидает лечебный контур, это фоновое требование, а для учебного ролика или кейса на конференции – прямое. Кроме того, 193н требует заранее сообщить пациенту, у кого и где хранятся материалы консультации. Отсюда инженерное правило: о записи пациент узнаёт до её начала, а не из пользовательского соглашения.

Таблица 1. Два уровня согласия на запись. Галочка «согласен на обработку ПДн» обычно закрывает только первый, и только для лечебных целей.

В консультации с несколькими участниками вопрос стоит ещё острее. В кадре не только пациент, но и лечащий врач, консультант из другой клиники, переводчик, родственник, и их лица и голоса тоже попадают в файл. Безопасное инженерное решение – рассчитывать на согласие всех участников: получать явное согласие каждого до начала записи и фиксировать его в журнале, показывать индикатор «идёт запись» всю сессию и хранить событие согласия рядом с файлом, чтобы потом его можно было доказать. Понятная фраза в начале («Консультация будет записана и будет храниться год в медицинской информационной системе клиники. Вы согласны?») закрывает оба уровня сразу и ничего не стоит. Если вы предлагаете анонимную или псевдонимизированную платную консультацию (такая возможность упомянута в п. 37 193н), помните, что видеозапись с лицом сводит псевдонимизацию на нет, поэтому для таких консультаций запись по умолчанию должна быть выключена.

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

Где делается запись: сервер или клиент

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

Запись на сервере ведётся на медиасервере. Почти любая клиническая платформа с несколькими участниками пропускает видео через SFU (Selective Forwarding Unit) – медиасервер, который принимает поток каждого участника и пересылает его остальным. Раз все потоки и так проходят через SFU, записывать там естественно и дёшево: сервер сохраняет потоки в хранилище по мере поступления. Серверная запись надёжна (не зависит от того, не уснул ли ноутбук пациента), одинаково захватывает всех участников и становится стандартным выбором для любой крупной платформы. Жёсткое требование у неё одно, и к нему мы ещё вернёмся: сервер должен уметь читать медиа, то есть для сервера медиа не зашифровано сквозным образом.

Запись на клиенте ведётся в браузере или приложении средствами самого устройства (в браузере – через API MediaRecorder) [15]. Её большое преимущество в том, что она записывает медиа, которое сервер никогда не видит в открытом виде, и это единственный способ записать звонок с настоящим сквозным шифрованием. Недостатки вполне практические и серьёзные: она расходует процессор и батарею, зависит от устройства, которое может уснуть или исчерпать память, и захватывает только то, что видит одно это устройство. Для надёжной клинической записи одной клиентской записи мало.

// Клиентский захват через MediaRecorder – пишет то, что видит ЭТО устройство.
// Внимание: хрупко для клинической записи (зависит от того, не уснёт ли устройство),
// и всё равно запускать только после согласия и защищать полученный blob как медданные.
const recorder = new MediaRecorder(localAndRemoteMixedStream, {
  mimeType: "video/webm;codecs=vp9,opus",
});
const chunks = [];
recorder.ondataavailable = (e) => chunks.push(e.data);
recorder.onstop = () => uploadToComplianceBoundary(new Blob(chunks)); // хранилище в РФ, доступ по ролям
recorder.start(1000); // фрагмент раз в секунду: при сбое теряется не больше 1 с

Большинство работающих телемед-платформ пишут на сервере: они мирятся с тем, что медиа зашифровано на транспортном уровне, а не сквозным образом, и держат весь конвейер записи внутри строго контролируемой границы медданных. Это вполне законный выбор при условии, что SFU и хранилище размещены в России, а тот, кто их эксплуатирует, обрабатывает данные по поручению оператора: договор с перечнем данных и действий, целями, обязанностью конфиденциальности и требованиями к защите по ст. 19 (ч. 3 ст. 6 152-ФЗ) [2]. Как выстроить эту цепочку договоров, разобрано в статье о поручении обработки ПДн и договорах с подрядчиками. Как технически связать живой WebRTC-звонок с записью, рассказано в разделе Video Streaming: см. запись WebRTC и мост HLS. Здесь нас интересуют последствия для соответствия требованиям, а не кодеки.

Конфликт со сквозным шифрованием и три способа его решить

Это и есть конфликт из заголовка, и на нём стоит остановиться подробнее: здесь благие намерения упираются в устройство технологии.

Сначала два определения. Транспортное шифрование защищает медиа на пути между устройством и сервером, так что перехватчик в сети ничего не увидит, но сам сервер медиа читать может. WebRTC делает это по умолчанию с помощью DTLS-SRTP. Сквозное шифрование (end-to-end encryption, E2EE) идёт дальше: ключи есть только у устройств пациента и врача, поэтому даже сервер, который пересылает медиа, не может его прочитать. E2EE – золотой стандарт для самых чувствительных консультаций: психиатрия и психотерапия, наркология, всё, что связано с повышенным юридическим риском. Отдельный российский вопрос – нужны ли сертифицированные ФСБ средства криптографической защиты (СКЗИ), если модель угроз опирается на криптографию: браузерный WebRTC шифрует не по ГОСТ, и это решение фиксируют в модели угроз (подробно – в статье о шифровании, ГОСТ и СКЗИ).

В этом и состоит конфликт. Серверной записи нужно, чтобы сервер читал медиа, а настоящее E2EE именно это и исключает. Незаметно записать на сервере звонок с настоящим сквозным шифрованием нельзя: для сервера медиа – бессмысленный шум. Это не ошибка, которую можно обойти, а сама суть правильно работающего E2EE.

Нажмите, чтобы увеличить

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

Способ первый – запись на клиенте. Звонок остаётся зашифрованным сквозным образом, а запись ведётся на устройстве, у которого законно есть ключи (обычно в приложении врача, иногда в выделенном авторизованном клиенте-рекордере, который входит в звонок как участник внутри шифрования). Сервер никогда не читает медиа. Цена – ненадёжность клиентской записи и необходимость безопасно загрузить файл внутрь вашей границы медданных.

Способ второй – заявленный рекордер. Добавьте в зашифрованную сессию одного доверенного участника, единственная задача которого – запись, и сообщите пациенту, что он есть. Современный WebRTC поддерживает это через браузерные Insertable Streams: они позволяют конечным устройствам шифровать медиа поверх транспортного шифрования (часто на основе стандарта SFrame) [14]. Рекордер, у которого есть ключ, может расшифровать поток для записи, а сервер, пересылающий медиа, по-прежнему не может. Обязательное условие – прозрачность: «сквозное шифрование» и «тайная запись» не могут быть правдой одновременно.

Способ третий – сознательно отказаться от E2EE для записываемых сессий. Для большинства консультаций транспортное шифрование плюс хранилище записей в российском контуре, с поручением обработки и контролем доступа, – корректная и законная архитектура, а настоящее E2EE для них избыточно. Честный подход – решать для каждой сессии отдельно: предлагать настоящее E2EE (с клиентской записью или без записи) для особо чувствительных случаев и серверную запись с транспортным шифрованием для остальных. Чего делать нельзя никогда – продавать звонок как «зашифрованный сквозным образом», пока его пишет сервер. Это уже не тонкость регулирования, а ложное заявление о безопасности.

Общий принцип для всех трёх способов: запись и E2EE – прежде всего вопрос честности перед пациентом и только потом инженерная задача. Что бы вы ни записывали, пациент должен понимать, кто сможет это увидеть.

Сведённая запись или раздельные дорожки

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

Сведённая (composited) запись объединяет всех участников в один видеофайл: привычная сетка или участники рядом, ровно то, что они видели на экране. Это один файл, его легко смотреть, и он удобен рецензенту, который хочет увидеть консультацию такой, какой она была. Раздельные дорожки (per-track) – это аудио и видео каждого участника, сохранённые отдельными потоками. Такая запись занимает больше места и требует плеера, который умеет собрать её обратно, зато гораздо полезнее для дальнейшей работы: ИИ-помощник точнее расшифровывает каждого говорящего, когда его аудио отделено, рецензент может заглушить или скрыть одного участника, а дорожку одного человека (например, переводчика, отозвавшего согласие) можно удалить, не уничтожая всю запись.

Если запись будет смотреть человек, пишите сведённую; если её будет обрабатывать машина или нужны выборочная правка и удаление, пишите раздельные дорожки. Продуктам для психотерапии и продуктам с ИИ-помощником обычно нужны раздельные дорожки именно по этим причинам. В любом случае каждая дорожка – медданные и хранится внутри той же границы.

Хранение, доступ, срок и удаление: незаметная, но главная работа

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

Нажмите, чтобы увеличить

Шифруйте сохранённую запись. Закон требует защищать ПДн от неправомерного доступа, уничтожения, изменения, блокирования и копирования (ч. 1 ст. 19 152-ФЗ) [3]. Конкретные меры задают ПП 1119 (уровень защищённости информационной системы; для данных о здоровье он зависит от актуальных угроз и объёма данных) и приказ ФСТЭК № 21 с набором мер для этого уровня [11][12]. На практике для хранилища клинического видео единственное решение, которое можно отстоять, – шифрование при хранении, а там, где модель угроз требует криптографии, – СКЗИ. Требования будут ужесточаться, и это видно заранее: опубликованный в июле 2026 года проект приказа на замену № 21 добавляет оценку защищённости до начала обработки и требования к обработчикам; на сентябрь 2026 года он не подписан [13]. Подробности – в статье о требованиях к защите ПДн в 2026 году.

Контролируйте доступ и ведите журнал. Доступ к записям должен быть ролевым: смотреть их могут только те, кому это нужно для лечения, работы сервиса или наставничества, и каждый доступ фиксируется. Закон прямо называет правила доступа, регистрацию и учёт всех действий с ПДн (п. 8 ч. 2 ст. 19), а приказ ФСТЭК № 21 выделяет отдельную группу мер – регистрацию событий безопасности [3][12]. Для хранилища записей это значит, что в журнале видно, кто и когда воспроизвёл, скачал, выгрузил или удалил какую запись. Открывайте просмотр по короткоживущим подписанным ссылкам, а не по постоянным публичным адресам, чтобы утёкшая ссылка не давала доступ навсегда. Как строить такой журнал – в статье о журналах аудита и контроле доступа.

Соблюдайте правильный срок хранения и знайте, какой он. На этом различии ошибаются даже аккуратные команды. Срок «1 год» из п. 51 193н относится к сопутствующим материалам: аудио, видео, сообщениям, изображениям. Медицинское заключение и протокол консультации – это медицинская документация в ЭМК, и для них свои правила: с 1 сентября 2026 года электронные медицинские документы ведутся по приказу 209н, по которому срок хранения ЭМД не меньше, чем у бумажного аналога, а сроки по видам заданы в федеральном справочнике [17]. Не смешивайте два срока в одном бакете: видео хранится год, заключение – гораздо дольше. Задокументируйте сроки и соблюдайте их автоматически.

Удаляйте по графику и по запросу. Запись, которая больше не нужна, – это только риск. Закон требует хранить ПДн не дольше, чем этого требуют цели обработки, если срок не установлен законом или договором (ч. 7 ст. 5 152-ФЗ), а по достижении цели – уничтожить их в срок не более 30 дней (ч. 4 ст. 21) [5]. Настройте автоматическое удаление по истечении срока и порядок исполнения запросов. Отзыв согласия на вторичное использование (учебный ролик, датасет) тоже исполняется в течение 30 дней (ч. 5 ст. 21); как это соотносится со сроком, который 193н задаёт для записи в лечебном контуре, решает юрист. «Удалить» должно означать, что медиа действительно исчезло, включая резервные копии и производные (превью, расшифровки, кэши ИИ), а не спрятано за флагом.

Посчитаем, ведь именно на хранении растут и затраты, и риск. Пусть вы записываете 1 000 консультаций в день, и каждая даёт файл 500 мегабайт (0,5 ГБ). Это 1 000 × 0,5 ГБ = 500 ГБ в день, или 500 × 365 = 182 500 ГБ ≈ 182 ТБ в год. При ориентировочной цене объектного хранения порядка 2 ₽ за ГБ в месяц (сверяйте с прайсом провайдера и тарифом аттестованного сегмента) годовой объём записей обходится примерно в 182 500 ГБ × 2 ₽ ≈ 365 тыс. ₽ в месяц, то есть около 4,4 млн ₽ в год. При сроке 1 год и автоудалении это потолок: вы всегда храните записи только за последний год. Без удаления через пять лет вы храните записи за пять лет и платите 5 × 365 тыс. ₽ ≈ 1,8 млн ₽ в месяц за файлы, которые по закону уже следовало уничтожить. Точная цифра здесь не главное (перепроверьте цены и реальные размеры файлов для вашего кодека). Главное, что «писать всё и навсегда» – это постоянно растущие расходы и постоянно растущий риск утечки. Записывать меньше и удалять по графику и дешевле, и безопаснее.

Нажмите, чтобы увеличить

Психиатрия, наркология и другие чувствительные записи

Одна категория требует особой осторожности. Записи психиатрических и психотерапевтических консультаций, наркологической помощи, сведения о ВИЧ или репродуктивном здоровье – одни из самых чувствительных данных, которые может хранить платформа. Юридически это те же медданные, но для пациента цена утечки несоизмеримо выше, а для компании она и так велика: утечка данных специальных категорий, включая сведения о здоровье, обходится юрлицу в 10–15 млн ₽ (ч. 16 ст. 13.11 КоАП), повторная – в 1–3% выручки, но не менее 25 млн и не более 500 млн ₽ [18]. За незаконное использование и передачу компьютерной информации с ПДн предусмотрена и уголовная ответственность (ст. 272.1 УК РФ).

Практический вывод однозначен: если продукт работает в области психического здоровья или наркологии, включайте запись только по явному выбору пациента (opt-in), ограничивайте её охват и согласовывайте с юристом, а при сомнениях выбирайте сквозное шифрование с клиентской записью или вовсе не записывайте. Особенности направления – в статье о телемедицине ментального здоровья, лицензионные рамки – в статье о лицензии, аккредитации врачей, рецептах и особых направлениях.

Типичные ошибки

С записью связано много хорошо известных ловушек. Вот самые опасные.

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

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

Обещание «сквозного шифрования» при серверной записи. Маркетинговое утверждение, которое не может быть правдой, пока запись идёт на сервере. Выберите что-то одно и честно об этом рассказывайте.

Записи за рубежом или в бакете без договора и шифрования. Классическая утечка: клиническое видео в зарубежном облачном хранилище (прямое нарушение ч. 5 ст. 18 152-ФЗ) или в российском, но без поручения обработки, без шифрования и с вечными публичными ссылками. Место записи – внутри границы медданных в России, с шифрованием и журналом доступа.

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

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

Где здесь Фора Софт

Клиническая запись – это медданные и врачебная тайна. Её нужно обосновать согласием, зашифровать, вести журнал доступа к ней, хранить в России положенный срок и уметь удалить, а для чувствительных консультаций – записать, не нарушив обещание сквозного шифрования. Фора Софт разрабатывает видеосвязь реального времени с 2005 года, а на WebRTC – с момента появления технологии: видеоконференции, e-learning, стриминг и телемедицина, в том числе конвейеры записи и хранения для клинических продуктов. Решение «писать или нет», два уровня согласия, выбор между E2EE и записью, между сведённой записью и раздельными дорожками, шифрованное хранилище в российском контуре с контролем доступа и сроков – всё это мы проектируем как одну связанную задачу. Функция записи с ошибкой хотя бы в одном из этих пунктов – не функция, а будущий инцидент с уведомлением Роскомнадзора.

Главное

• По умолчанию безопаснее не записывать; каждая запись должна служить заявленной цели.
• 193н не обязывает записывать, но сделанная запись – сопутствующий материал со сроком хранения 1 год; заключение и протокол хранятся в ЭМК по своим срокам.
• Согласие нужно на двух уровнях: основание для обработки медданных, а для любого использования за пределами лечения – отдельное письменное согласие и согласие на использование изображения.
• Серверная запись дешёвая и надёжная, но несовместима с настоящим E2EE; конфликт решают клиентской записью, заявленным рекордером или отказом от E2EE в пользу транспортного шифрования, но не ложными обещаниями.
• Записи хранятся только в России, по поручению обработки, с шифрованием и журналом каждого доступа.
• Пациент вправе получить сведения и копии; удаление по сроку – не позже 30 дней после достижения цели, включая все производные.

Что читать дальше

• Шифрование для телемедицины: при передаче, при хранении, сквозное – и где нужны ГОСТ и СКЗИ
• Согласие пациента, запись и хранение данных
• Архитектура комплаенса: как встроить требования 152-ФЗ и 323-ФЗ в видеостек