- Номер US12407685B2 относится к выданному патенту США серии 2025 года.
- Логика документов этого класса воспроизводит один и тот же цикл.
- Согласие в бумажной модели — это текст, который кто-то должен прочитать и исполнить.
Патент US12407685B2 описывает механизм, в котором права доступа к электронной медицинской карте фиксируются не в настройках конкретной информационной системы, а в распределённом реестре. Пациент выдаёт согласие, согласие превращается в исполняемое правило, запрос врача проверяется автоматически, факт обращения попадает в неизменяемый журнал. Сами записи при такой архитектуре обычно остаются вне реестра: on-chain хранится хеш и указатель на защищённое хранилище. Ниже — разбор документа по первоисточнику, инженерные компромиссы схемы и регуляторные ограничения. Принадлежность патента Google требует отдельной проверки — на это есть прямая причина.
Что защищает патент US12407685B2 и действительно ли его правообладатель — Google?
Смарт-контракт
- Правило исполняется само
- Пациент видит выдачу
- Журнал выдачи фиксируется
Роли в МИС
- Доступ открывает администратор
- Внедряется быстрее
- Отзыв права проще
Номер US12407685B2 относится к выданному патенту США серии 2025 года. Предмет — управление доступом к медицинским данным средствами распределённого реестра.
Атрибуция «патент Google» в русскоязычных материалах часто возникает по одной технической причине: документ найден на Google Patents. Этот сервис индексирует патенты всех ведомств и правообладателей, а не только собственные заявки Google LLC. Правообладателем считается только то лицо, которое указано в поле Assignee. Проверяйте поле, а не источник ссылки.
Как проверить правообладателя, дату приоритета и правовой статус по первоисточнику?
Порядок проверки простой. Откройте страницу патента на Google Patents, зафиксируйте поля Assignee, Priority date, Filing date, Grant date и Status. Затем сверьте те же данные в USPTO Patent Public Search и Patent Center — там видны делопроизводство, уплата пошлин и переуступки прав.
Отдельно смотрите блок Worldwide applications. Он показывает семейство: continuation-заявки в США и зарубежные аналоги с индексами EP, WO, CN. Патент США действует только на территории США. Для рынка ЕС или России значение имеют именно национальные и региональные члены семейства, а не американский номер.
Что входит в объём охраны, а что остаётся за его пределами?
Объём охраны задаёт исключительно формула — claims. Описание и чертежи служат для истолкования терминов формулы, но сами по себе ничего не монополизируют. Это ключевая вещь для инженера: архитектура, нарисованная на схеме, но не попавшая в независимый пункт, остаётся свободной.
За пределами охраны остаются общие идеи — «хранить медкарты с использованием блокчейна», «вести аудит обращений», «шифровать записи». Такие формулировки слишком абстрактны для патентования. Охраняется конкретная комбинация признаков. Выпадение хотя бы одного признака из вашей реализации означает, что независимый пункт не нарушен.
Как по формуле патента выстроен сам механизм доступа к медицинской истории?
Логика документов этого класса воспроизводит один и тот же цикл. Регистрация идентичностей пациента и провайдера, запись политики доступа в реестр, проверка запроса, выдача ключа или токена, журналирование, отзыв.
Дальше — интерпретация типовой конструкции, а не цитата. Дословные формулировки пунктов с указанием их номеров берите на странице патента: редакция формулы при делопроизводстве меняется, и пересказ её не заменяет.
Какие признаки независимого пункта задают границы охраны?
В патентах на управление доступом к медицинским картам границы обычно очерчивают четыре-пять групп признаков.
Первая — объект: запись пациента и её фрагменты. Вторая — способ привязки: криптографический хеш записи и указатель на внешнее хранилище, размещённые в реестре. Третья — носитель политики: программный код, исполняемый узлами сети, с параметрами субъекта, объёма, срока и цели доступа. Четвёртая — процедура: приём запроса, автоматическая сверка с политикой, выдача либо отказ. Пятая — фиксация результата в реестре.
Для разработчика это даёт рабочую таблицу «признак → смысл → следствие». Признак превращается в проектное решение, решение — в риск нарушения. Проверять нужно каждый признак отдельно.
Лежат ли медицинские записи в реестре или там только хеш и указатель?
В практических решениях сами данные в блокчейн не пишут. On-chain идут хеш записи, указатель на хранилище и метаданные политики. Карта лежит off-chain — в хранилище клиники или в защищённом облаке.
Аналогия — камера хранения. В реестре лежит не чемодан, а квитанция с отпечатком содержимого. Предъявили квитанцию — проверили отпечаток — убедились, что чемодан не подменили. Так решаются сразу три задачи: контроль целостности, экономия пропускной способности и совместимость с требованиями о локализации данных.
Как согласие пациента превращается в исполняемое правило смарт-контракта?
Согласие в бумажной модели — это текст, который кто-то должен прочитать и исполнить. В реестровой модели согласие становится набором машиночитаемых параметров: идентификатор получателя, перечень разрешённых разделов, срок, цель обработки.
Параметры подписываются приватным ключом пациента и записываются в контракт. Дальше исполнение не зависит от добросовестности оператора системы. Правило проверяет код, а не администратор.
Можно ли выдать доступ к отдельному разделу карты и на ограниченный срок?
Да, и это главное практическое преимущество схемы. Гранулярность достигается тем, что карта разбита на фрагменты с отдельными ключами шифрования. Политика открывает конкретный фрагмент конкретному получателю.
Типовые сценарии: лаборатории — только результаты её собственных исследований; страховщику для выставления счёта — факт и код услуги без анамнеза; исследователю — деперсонализированная выборка. Срок задаётся как интервал или как число обращений. По истечении срока доступ закрывается без участия администратора.
Как устроен отзыв доступа и кому виден журнал обращений?
Отзыв — это новая транзакция, меняющая состояние политики. Прошлые записи журнала при этом не исчезают: реестр фиксирует и выдачу согласия, и его отмену. Техническая деталь существенна: если получатель успел скачать расшифрованный фрагмент, отзыв на эту копию уже не действует. Отзыв прекращает будущие обращения, а не изымает полученное.
Журнал обращений доступен пациенту полностью. Контролирующей организации и аудитору — в пределах их прав. Эффект близок к бортовому самописцу: запись ведётся независимо от того, кто обращался к данным.
Чем такая схема отличается от ролевого доступа в обычной медицинской информационной системе?
Ролевая модель в МИС отвечает на вопрос «какая у вас должность». Реестровая — на вопрос «есть ли согласие именно этого пациента именно вам». Субъект принятия решения смещается от администратора к владельцу данных.
Компромисс очевиден. Централизованная МИС работает быстрее и дешевле в эксплуатации, но доверие в ней держится на одном операторе. Распределённый реестр снимает эту зависимость, но добавляет латентность, стоимость транзакций и управление ключами.
Что даёт неизменяемый журнал по сравнению с логами внутри МИС?
Логи внутри системы администрируются теми же людьми, чьи действия они фиксируют. Технически запись можно изменить или удалить. Для внутреннего контроля этого достаточно, для внешнего спора — не всегда.
Записи в распределённом реестре подтверждаются множеством узлов, и правка истории потребовала бы согласия сети. Для разбора инцидентов утечки это даёт доказательство, которое сложно оспорить. Цена — та же неизменяемость, которая создаёт проблемы с удалением данных.
В каких случаях задача закрывается без распределённого реестра?
Если всеми данными владеет одна организация, реестр не нужен — достаточно нормальных журналов и разграничения прав. Если участников несколько, но между ними есть доверенный посредник, работает классическая интеграционная шина со стандартами обмена.
Реестр оправдан, когда участников много, доверенного центра нет, а решения о доступе должны проверяться независимо. Это узкий, но реальный класс задач.
Как решения для обмена медицинскими данными выглядели до блокчейна?
Предпосылки сложились задолго до реестров. Сначала были локальные базы и обмен выписками на бумаге. Затем появились региональные обменные сети и интеграционные профили, которые согласовывали форматы сообщений между системами.
Доступ в этих решениях управлялся централизованными справочниками согласий. Узкое место — не формат, а именно согласие: оно давалось редко, фиксировалось неоднородно и плохо проверялось постфактум. Из этого разрыва и выросли реестровые проекты.
Чем этот документ отличается от смежных патентов правообладателя и от проектов вроде MedRec?
Сравнивать патенты корректно по формуле, а не по заголовку. Рабочие критерии: объект охраны (способ, система или носитель), тип сети, место хранения записи, модель согласия и наличие признаков гранулярности. Для подбора смежных документов используйте поиск по assignee и классам CPC — G16H и H04L9/50.
Академический проект MedRec показал саму идею: реестр как указатель на записи у разных провайдеров. Патентные формулы, как правило, уходят в детали — структуру политики, схему перевыдачи ключей, порядок журналирования. Идея свободна, конкретная реализация — нет.
Какие практические задачи закрывает технология в действующих проектах здравоохранения?
Управление доступом — не единственное применение блокчейна в медицине. По доступным обзорам, пилоты распределяются по нескольким направлениям.
Цепочки поставок и борьба с контрафактом — отслеживание серий препаратов от производителя до аптеки. Контроль за распределением донорских органов — фиксация очереди и решений без возможности переписать историю. Клинические биомедицинские исследования — защита протокола и первичных данных от незаметной правки. Медицинское страхование — сверка факта услуги при выставлении счёта. Мониторинг пациентов и анализ медицинских данных — подтверждение источника телеметрии. Блокчейн в здравоохранении остаётся преимущественно на стадии пилотов.
Какие шаги проходит проверка применимости и запуск пилота?
Последовательность, которая экономит время и снижает юридический риск:
- Сформулировать задачу без упоминания технологии: кто, к чему и на каком основании получает доступ.
- Проверить, нет ли доверенного центра. Если есть — сравнить с интеграционным решением.
- Выгрузить формулу US12407685B2 и смежных патентов семейства, разложить по признакам.
- Провести freedom-to-operate анализ с патентным поверенным по территориям запуска.
- Определить модель данных: что уходит off-chain, что остаётся on-chain.
- Выбрать тип сети. Для медицинских данных обычно разрешённая, с известными узлами.
- Спроектировать управление ключами и процедуру восстановления доступа.
- Согласовать правовую рамку: роли контролёра и обработчика, основания обработки, сроки.
- Запустить пилот на одном сценарии с измеримой метрикой.
- Оценить латентность, стоимость владения и реальную нагрузку на персонал.
Пилот должен проверять гипотезу, а не демонстрировать технологию.
Источники
Формула и правовой статус патента приведены по первоисточнику и могут измениться после уплаты пошлин, continuation-заявок или оспаривания. Проверяйте поля Assignee, Status и состав claims на дату обращения — для этого материала данные сверялись в октябре 2026 года. Дословные формулировки пунктов цитируйте по странице патента, а не по пересказу.
Разобрать сайт клиники
Пришлите URL — посмотрим, что мешает записям из поиска.