Тема 1.5 — Нормативный ландшафт и соответствие требованиям

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

Почему это важно в здравоохранении и уходе#

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

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

Наконец, это государственные деньги и законодательная обязанность. Внедряя несоответствующую систему, вы не только подвергаете организацию принудительным мерам; вы можете нарушать обязанности перед пациентами и гражданами и тратить бюджетные средства на то, что не можете законно эксплуатировать. Поэтому эта тема обрамляет более подробные темы, которые следуют далее: о клинической безопасности (тема 1.6 — Клиническая безопасность и управление рисками), управлении информацией (тема 1.7 — Управление информацией, защита данных и кибербезопасность), этике данных (тема 1.8 — Этика данных, согласие и общественное доверие) и гарантиях (тема 6.4 — Управление и гарантии). Эта тема — навигатор; те — подробные карты.

Ключевые понятия#

Три уровня обязательств. Самое полезное различие — между законодательным регулированием, обязательными стандартами и добровольными гарантиями. Законодательное регулирование — это закон: обеспечивается регулятором с юридическими полномочиями и не подлежит обсуждению (например, законодательство о защите данных или требование зарегистрировать медицинское изделие). Обязательные стандарты — договорные или политические требования, которым нужно соответствовать, чтобы действовать внутри системы, даже когда они не являются первичным законодательством, например национальные инструменты NHS, от которых зависит заказ. Добровольные гарантии — это когда вы выбираете демонстрировать качество относительно признанного эталона, чтобы создать доверие, выиграть закупки или упредить будущее регулирование. Знание того, к какому уровню относится то или иное требование, говорит, что произойдёт при его невыполнении: уголовное преследование, исключение с рынка или репутационный ущерб.

Care Quality Commission (CQC). Care Quality Commission — независимый регулятор здравоохранения и социального ухода за взрослыми в Англии. Он регистрирует, инспектирует и оценивает поставщиков по тому, безопасны ли услуги, эффективны, заботливы, отзывчивы и хорошо управляемы. Цифровые услуги от него не ускользают: там, где технологии — часть оказания ухода, вопросы CQC о безопасности и руководстве достигают систем, которые вы эксплуатируете, а его область «хорошо управляемо» всё чаще проверяет цифровую и информационную зрелость.

MHRA и медицинские изделия. Medicines and Healthcare products Regulatory Agency (MHRA) регулирует лекарства и медицинские изделия в Великобритании. Решающе важно: программное обеспечение может быть медицинским изделием: программное обеспечение как медицинское изделие (SaMD) — это ПО, предназначенное для медицинской цели (диагностика, профилактика, мониторинг, лечение), не будучи частью аппаратного изделия. Если ваше приложение рассчитывает дозу, сортирует симптом или интерпретирует изображение, оно очень вероятно является медицинским изделием и должно быть классифицировано, зарегистрировано и нести соответствующую маркировку соответствия до вывода на рынок.

Маркировка соответствия: UKCA и CE. Медицинскому изделию, выводимому на рынок Великобритании (Англия, Уэльс, Шотландия), нужна маркировка UKCA (UK Conformity Assessed), послебрекситовский британский аналог маркировки CE (Conformité Européenne). Пока изделия с маркировкой CE по-прежнему принимаются в Великобритании по переходным соглашениям, а Северная Ирландия следует правилам ЕС, поэтому нужная вам маркировка зависит от того, где вы выводите изделие на рынок. Это живая, меняющаяся область; считайте точное требование тем, что нужно подтвердить, а не предполагать.

NICE и Evidence Standards Framework. National Institute for Health and Care Excellence (NICE) готовит руководства о том, что работает и что экономически эффективно. Его Evidence Standards Framework (ESF) для цифровых медицинских технологий определяет, соразмерно риску, доказательства, которые цифровой продукт должен показать до принятия системой. NICE не является лицензирующим привратником, как MHRA, но его суждения сильно формируют закупки: прохождение регистрации MHRA доказывает, что изделие безопасно продавать; соответствие ожиданиям доказательств, согласованным с NICE, помогает доказать, что его стоит покупать (см. тему 1.3 — Решения на основе доказательств).

ICO и законодательство о защите данных. Information Commissioner's Office (ICO) — независимый регулятор Великобритании по защите данных и свободе информации. Он обеспечивает соблюдение британского Общего регламента по защите данных (GDPR) и Data Protection Act 2018, определяющих, как можно законно обрабатывать персональные данные, а данные о здоровье относятся к «особой категории» с самой сильной защитой. ICO может расследовать, предписывать изменения и налагать значительные штрафы. Содержательная часть рассмотрена в теме 1.7; здесь достаточно удержать в голове, что ICO — ваш регулятор защиты данных и что данные о здоровье несут более высокую планку.

Обязательные инструменты NHS. Помимо первичного права, NHS ведёт собственные обязательные инструменты. Data Security and Protection Toolkit (DSPT) — ежегодная самооценка, которую должна пройти каждая организация, работающая с данными пациентов NHS, чтобы продемонстрировать стандарты безопасности данных и управления информацией. Digital Technology Assessment Criteria (DTAC) — базовый уровень, которому должна соответствовать цифровая медицинская технология, чтобы быть закупленной организациями NHS; он охватывает клиническую безопасность, защиту данных, техническую безопасность, интероперабельность и удобство использования. Стандарты клинической безопасности DCB0129 (для производителей) и DCB0160 (для внедряющих организаций) предписывают задокументированный процесс управления клиническими рисками — журнал опасностей, специалиста по клинической безопасности, обоснование безопасности — и составляют основу темы 1.6.

Профессиональные регуляторы. Регулируются не только продукты, но и люди. General Medical Council (GMC) регистрирует врачей и устанавливает для них стандарты, а Nursing and Midwifery Council (NMC) делает то же для медсестёр и акушерок. Когда клиницисты проектируют, одобряют или эксплуатируют цифровые услуги, их профессиональные обязанности идут вместе с ними: специалист по клинической безопасности, согласующий систему, действует в рамках профессиональной подотчётности, а не просто роли в оргструктуре.

Горизонт и контекст: режим ЕС. Даже за пределами ЕС важны Закон об искусственном интеллекте и Регламент (ЕС) 2017/745 (Регламент ЕС о медицинских изделиях, MDR): они задают направление движения, обязывают вас, если вы обслуживаете рынки ЕС или Северную Ирландию, и часто предвосхищают, куда пойдут британские правила. Сканирование горизонта на такие изменения само по себе — дисциплина соответствия.

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

Лучшие практики#

1. Классифицируйте услугу, прежде чем спорить о контролях. Первый вопрос — не «соответствуем ли мы?», а «кто мы с юридической точки зрения?». Рано определите, является ли ваш продукт медицинским изделием (и каков его класс риска), являетесь ли вы контролёром или обработчиком данных и какие обязательные инструменты NHS применимы. Неверная классификация делает неверным каждое последующее решение; верная показывает, какие из уровней и органов выше на самом деле вас обязывают.

2. Создайте и поддерживайте живую карту и реестр соответствия. Перечислите каждое применимое для услуги обязательство по законодательному регулированию, обязательным стандартам и добровольным гарантиям и фиксируйте по каждому владельца, текущий статус, подтверждающие доказательства и дату следующего пересмотра. Держите его живым, пересматриваемым по расписанию, а не документом, написанным один раз для бизнес-кейса и больше никогда не открываемым. Хороший реестр в любой день отвечает: «кто владеет этой обязанностью и где доказательства?».

3. Назначайте единоличную ответственность за каждое обязательство. Размытая ответственность — способ, которым соответствие терпит неудачу: каждый считает, что ею владеет кто-то другой. Дайте каждой обязанности названного владельца (инспектор по защите данных для защиты данных, специалист по клинической безопасности для DCB0129/0160, старший ответственный за информационные риски для DSPT) и сделайте столбец владельцев в карте реальным, с полномочиями и временем на исполнение. Ответственность, у которой нет имени, — не ответственность.

4. Будьте соразмерны и ориентируйтесь на риск, а не на галочки. Регулирование заслуживает той же соразмерности, что и доказательства (см. тему 1.3): сосредоточьте строгость там, где риск для пациентов, равенства и доверия наибольший, и держите низкорисковую работу лёгкой. Соответствие «для галочки» (заполнение формы при упущении смысла) и расточительно, и опасно, потому что создаёт ложные гарантии. Стремитесь удовлетворить цель каждого требования, что обычно удовлетворяет и букву.

5. Относитесь к обязательным инструментам NHS как к входным данным проекта, а не к выходным воротам. DTAC, DSPT и DCB0129/0160 дешевле и эффективнее всего, когда встроены в поставку с самого начала, а не навешены перед запуском. Сбой DTAC, обнаруженный при запуске, может стоить месяцев; обоснование клинической безопасности, собранное задним числом, тонко и неубедительно. Вплетите эти инструменты в исследование и поставку, чтобы их выполнение было побочным продуктом хорошей работы.

6. Сканируйте горизонт на нормативные изменения и отвечайте за реакцию. Регулирование движется: сроки UKCA смещаются, Закон ЕС об ИИ вводится поэтапно, режим программного обеспечения как медицинского изделия развивается. Назначьте человека, отслеживающего соответствующих регуляторов и консультации, ведите короткий список наблюдения за «нормативными изменениями» относительно вашей карты соответствия и превращайте сигналы в плановую работу до того, как сроки станут авралом. Быть застигнутым врасплох заранее известным изменением правила — устранимый, самонанесённый сбой.

7. Ведите доказательства непрерывно и делайте их готовыми к аудиту. Регуляторы, заказчики и проверяющие CQC по «хорошо управляемо» просят вас показать, а не утверждать. Держите журналы опасностей, оценки воздействия на защиту данных, представления DSPT и доказательства DTAC актуальными и доступными, а не восстанавливайте их под давлением инспекции. Непрерывные доказательства к тому же дешевле периодической суматохи, которую они заменяют.

8. Координируйтесь между регуляторами, а не в «силосах». Поскольку одна услуга затрагивает много органов, её функции соответствия должны разговаривать друг с другом: ответственные за клиническую безопасность, управление информацией и владелец продукта должны разделять единый взгляд на услугу, а не вести три несвязанных. Изменение, удовлетворяющее MHRA, может создать проблему защиты данных; исправление UX может изменить профиль клинического риска. Ведите соответствие как единую согласованную картину, привязанную к вашему более широкому управлению (тема 6.4 — Управление и гарантии).

Вопросы для обсуждения с командой#

1. Для нашей флагманской цифровой услуги можем ли мы назвать каждого применимого регулятора и обязательный стандарт, их владельцев и где лежат актуальные доказательства, не заставляя никого идти и выяснять? Это проверяет, держите ли вы карту на самом деле или лишь верите, что соответствуете. Это важно, потому что в здравоохранении и уходе обязательства действительно пересекаются: приложение для сортировки может быть медицинским изделием по MHRA, операцией обработки данных по ICO, закупаемой технологией, нуждающейся в DTAC, и частью услуги, инспектируемой CQC, одновременно, а пробел на любом одном уровне может остановить услугу или навредить пациентам. Противоречие, которое стоит вынести на свет, — между комфортом допущения «этим занимается IG» или «регулируется поставщик, а не мы» и дискомфортом подтверждения названного владельца и живых доказательств по каждой обязанности. Разберите услугу конкретно: перечислите органы, отнесите каждое обязательство к его уровню (законодательное, обязательное, добровольное) и попробуйте предъявить актуальные доказательства по трём из них прямо сейчас. Если не получается, вы нашли первый пробел. Хороший, честный ответ — заполненный реестр соответствия с названными владельцами и датированными доказательствами и откровенность о том, какие обязанности сейчас не имеют владельца или не подтверждены доказательствами, а не уверенный взмах рукой в сторону «мы соответствуем».

2. Где мы делаем соответствие «для галочки» (удовлетворяем форму, упуская суть) и где мы чрезмерно усложняем низкорисковую работу? Тема выступает за соразмерное, ориентированное на риск соответствие, и этот вопрос заставляет честно проверить оба направления сбоя. Это важно, потому что ложные гарантии активно опасны в критичной для безопасности среде: DSPT с отметкой «выполнено» или обоснование клинической безопасности, собранное за неделю до запуска, могут выглядеть соответствующими, оставляя реальные опасности неуправляемыми, а тем временем тяжёлый процесс гарантий, душащий низкорисковое изменение содержания, тратит дефицитную мощность и порождает цинизм по отношению ко всему режиму. Компромисс для обсуждения в том, что соразмерность требует суждения и уверенности в его защите, что труднее администрировать, чем единое правило, считающее всё высокорисковым. Возьмите два-три текущих пункта (один действительно высокорисковый, один низкорисковый) и спросите, соответствовала ли применённая строгость риску для пациентов, равенства и доверия или определялась привычкой и страхом. Подумайте, формирует ли ваша работа по DTAC и DCB0129/0160 проект по-настоящему или подгоняется задним числом, чтобы пройти. Хороший ответ называет конкретный случай галочки и конкретный случай чрезмерного усложнения и обязуется калибровать строгость по риску, а не применять один грубый стандарт везде.

3. Как мы узнаем, что затрагивающее нас регулирование вот-вот изменится, и кто отвечает за превращение этого сигнала в плановую работу? Это проверяет сканирование горизонта: дисциплину, отличающую организации, заставшие врасплох сроками, от тех, что планируют заранее. Это важно, потому что ландшафт сейчас необычно живой (сроки маркировки UKCA и CE, режим программного обеспечения как медицинского изделия, поэтапный Закон ЕС об ИИ, развивающиеся инструменты NHS), а изменение правила, о котором вы знали, но к которому не подготовились, — самонанесённая рана, способная снять услугу с рынка. Противоречие в том, что у сканирования горизонта нет немедленной отдачи, поэтому оно первым отбрасывается под давлением поставки, а его отсутствие незаметно, пока не наступит срок. Выясните, кто сейчас отслеживает соответствующих регуляторов и консультации, есть ли список наблюдения, привязанный к вашей карте соответствия, и как сигнал становится задачей с владельцем и датой, а не тревогой во чьём-то почтовом ящике. Подумайте, услышали бы вы вообще об изменении, затрагивающем только Северную Ирландию или обращённые к ЕС части вашей услуги. Хороший ответ называет человека или роль, отвечающие за сканирование нормативного горизонта, указывает на конкретный список наблюдения и описывает последний раз, когда предстоящее изменение было превращено в плановую работу до срока.

4. Честно ли мы классифицировали, чем мы являемся (медицинское изделие или нет, контролёр или обработчик), или тихо выбрали толкование, снижающее наше бремя? Это выносит на свет самое важное решение темы, потому что классификация определяет каждое последующее обязательство и это самое лёгкое место для самообмана. Это важно, потому что все стимулы тянут в одну сторону: назвать продукт «приложением для хорошего самочувствия», а не ПО как медицинским изделием, или «обработчиком», а не контролёром, значит уклониться от расходов, доказательств и проверки; но если алгоритм интерпретирует данные, чтобы информировать клиническое действие, или вы определяете цели обработки, честная классификация не опциональна, и регулятор применит её независимо от ваших предпочтений. Противоречие в том, что более дешёвое прочтение часто достаточно защитимо, чтобы пережить внутренний разговор, но не запрос MHRA или ICO, а неверная классификация — самый быстрый путь к принудительным мерам и рухнувшему каналу продаж NHS. Проработайте это конкретно: сформулируйте, что продукт делает на самом деле, получите юридическую консультацию, а не полагайтесь на предчувствие основателя, и проверьте, пережил бы ваш заявленный класс прочтение регулятором тех же фактов. Хороший, честный ответ показывает задокументированную классификацию, достигнутую рано с консультацией, называет того, кто её согласовал, и откровенен в отношении любого пограничного решения и того, как оно удерживается под пересмотром по мере изменения продукта.

5. Когда одно изменение нашей услуги затрагивает сразу нескольких регуляторов, видят ли наши функции соответствия единую общую картину или три несвязанные? Это проверяет координацию, сбой, о котором предупреждает тема, когда клиническая безопасность, управление информацией и продукт держат каждый частичный взгляд. Это важно, потому что одна услуга действительно охватывает несколько органов: изменение UX приложения для сортировки может изменить профиль его клинического риска, исправление, удовлетворяющее MHRA, может открыть вопрос защиты данных, а требование DTAC может затронуть все сразу, так что «силосная» структура означает, что никто не владеет всей позицией соответствия, а изменения проваливаются между командами. Противоречие в том, что специализированные функции организованы по дисциплинам по веским причинам, но услугу пациент воспринимает как одно целое, а согласование этих взглядов требует координационных усилий, которые ни одна отдельная команда не заинтересована финансировать. Выясните, есть ли одна общая карта соответствия на услугу или несколько частных, надёжно ли изменение в одной области запускает пересмотр в остальных и как это связано с управлением на уровне совета (тема 6.4). Хороший ответ указывает на единый согласованный вид каждой услуги, описывает недавнее изменение, оценённое сразу всеми затронутыми регуляторами вместе, и честен в том, где дисциплины всё ещё действуют в «силосах».

6. Там, где наша услуга зависит от стороннего поставщика, знаем ли мы точно, какие обязанности его, а какие остаются нашими, или мы предполагаем «они регулируются, значит, мы защищены»? Это выявляет разрыв общей ответственности, который питают и неверная классификация, и размытая принадлежность, потому что покупка регулируемого компонента не передаёт ваши собственные обязанности. Это важно, потому что поставщик может иметь маркировку соответствия медицинского изделия, тогда как вы, внедряющая организация, всё ещё должны обоснование клинической безопасности по DCB0160, остаётесь контролёром данных ваших пациентов и отвечаете перед CQC за то, как управляется услуга, а шов между «их соответствием» и «вашим» — именно то место, где обязательства теряются. Противоречие и коммерческое, и нормативное: поставщики предпочитают контракты, подразумевающие, что бремя несут они, и соблазнительно принять этот комфорт, а не точно картировать границу. Проработайте одни реальные отношения с поставщиком: перечислите, что на самом деле покрывают контракт и их маркировка, что остаётся вашей законодательной или обязательной обязанностью и фиксирует ли ваш реестр это разделение с названными владельцами на вашей стороне. Хороший, честный ответ письменно различает обязательства поставщика и сохраняемые за вами, называет владельца каждой сохраняемой обязанности и может показать доказательства, которые вы держите, а не те, которые предполагаете у поставщика.

На практике: пример из здравоохранения и ухода#

Интегрированная система ухода (ICS) планирует внедрить приложение для смартфонов, позволяющее пациентам с хроническими заболеваниями записывать симптомы, а алгоритм помечает тех, у кого может ухудшаться состояние, для клинического рассмотрения. Соблазн — считать это «просто приложением» и запустить его.

Вместо этого директор по цифровым технологиям начинает с классификации. Поскольку алгоритм интерпретирует данные пациентов, чтобы информировать клиническое действие, юридическая консультация подтверждает, что это программное обеспечение как медицинское изделие, поэтому действует режим MHRA, а поставщик должен иметь правильную маркировку соответствия для рынка Великобритании: вопрос UKCA, который команда помечает для наблюдения по мере развития переходных соглашений по CE. ICS — контролёр данных пациентов, поэтому её обязывают обязанности ICO по защите данных, и открывается оценка воздействия на защиту данных (питающая тему 1.7). Поскольку приложение закупается органами NHS, применяется DTAC, а поскольку оно внедряется в клиническое использование, DCB0160 требует обоснования клинической безопасности, журнала опасностей и названного специалиста по клинической безопасности (тема 1.6).

Команда строит карту соответствия: каждое обязательство помещено на свой уровень, у каждого есть названный владелец (инспектор по защите данных, специалист по клинической безопасности, старший ответственный за информационные риски, руководитель продукта) и реестр отслеживает статус и доказательства. Вместо того чтобы считать DTAC и обоснование безопасности воротами запуска, они вплетают их в поставку с исследования, так что журнал опасностей растёт вместе с проектом. Evidence Standards Framework NICE формирует то, какие доказательства эффективности они требуют от поставщика до масштабирования. Заметка сканирования горизонта отмечает Закон ЕС об ИИ как значимый для будущего алгоритма и любых амбиций, обращённых к ЕС. Когда позже CQC проверяет руководство услуги, ICS отвечает на вопросы «хорошо управляемо» живым реестром и актуальными доказательствами, а не суматохой. Приложение выходит позже наивного плана, но законно.

Отраслевые перспективы#

Один и тот же ландшафт налагает очень разное бремя в зависимости от того, где вы находитесь.

Стартап#

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

Малый бизнес#

Устоявшийся небольшой поставщик (практика врача общей практики, общественная аптека, дом престарелых, клиника в одном месте или небольшой поставщик health-tech, миновавший стадию стартапа) несёт те же законодательные и обязательные обязанности, что и крупный траст, но без инспектора по защите данных, специалиста по клинической безопасности или команды соответствия для их исполнения. DSPT по-прежнему нужно проходить каждый год, данные пациентов по-прежнему подпадают под планку особой категории, а любое внедрённое клиническое ПО по-прежнему втягивает DCB0160, но обычно всё это ложится на управляющего практикой или владельца, уже управляющего деятельностью. Реалистичный ход — сделать карту соответствия намеренно небольшой, но реальной, опираться на общую или заказанную экспертизу (федерацию, CSU или документацию поставщика по клинической безопасности), а не притворяться, что держите каждую специальность внутри, и быть щепетильным в отношении обязанностей, которые нельзя делегировать, например оставаться контролёром данных собственных пациентов. Принимать гарантии поставщика за покрывающие ваши сохраняемые обязанности — характерная здесь ловушка: покупайте помощь, но сохраняйте названную принадлежность того, что юридически ваше.

Крупная организация#

Траст NHS или крупная ICS держит много услуг одновременно, поэтому её вызов — координация в масштабе портфеля: десятки систем, каждая затрагивает нескольких регуляторов, с обязательствами, которые не должны теряться между командами. Сбой — организационные «силосы»: клиническая безопасность, управление информацией и закупки каждая держит частичный взгляд, поэтому никто не видит всей позиции соответствия данной услуги. Лекарство — общая карта соответствия на услугу, единоличная ответственность, привязанная к управлению на уровне совета (тема 6.4), и непрерывные, готовые к аудиту доказательства, чтобы проверка CQC по «хорошо управляемо» или запрос ICO получали ответ из живой позиции. Крупная организация health-tech или фармацевтики приносит зрелый аппарат регуляторных дел, но должна остерегаться превращать его в фабрику соответствия, оторванную от того, как продукты на самом деле создаются.

Государство#

Национальный орган (NHS England, Департамент здравоохранения и социального обеспечения, MHRA, NICE) часто сам является регулятором или автором обязательного инструмента, поэтому его способы работы задают планку, которую должна преодолеть вся система, а его решения привлекают внимание парламента и общественности. Здесь работа по соответствию — подотчётность в масштабе населения: инструмент вроде DTAC или ESF формирует целый рынок, поэтому соразмерность и ясность самого стандарта — обязанности, а не любезности, ведь плохо откалиброванное национальное требование либо везде задерживает полезные инновации, либо везде пропускает риск. Национальные органы несут и ответственность за сканирование горизонта для системы, предвидя, как Закон ЕС об ИИ, MDR и режимы маркировки соответствия должны повлиять на британскую политику. Прозрачность в отношении того, что требует стандарт и почему, — часть поддержания общественного доверия в масштабе.

Типичные способы сбоя#

• Неверная классификация. Настаивание, что продукт не медицинское изделие или что вы обработчик, а не контролёр, чтобы уйти от бремени. Противоядие: классифицировать честно и рано, с юридической консультацией; классификация определяет всё остальное.
• Соответствие для галочки. Заполнение DSPT или обоснования безопасности, чтобы пройти, пока основной риск не управляется. Противоядие: удовлетворять цель, а не только форму; проверять, формирует ли артефакт проект на самом деле.
• Соответствие как ворота запуска. Обнаружение пробелов DTAC или клинической безопасности при запуске. Противоядие: вплетать обязательные инструменты в поставку с исследования.
• Размытая принадлежность. Каждая обязанность считается чьей-то ещё. Противоядие: единоличная ответственность по каждому обязательству в живом реестре.
• «Силосы» регуляторов. Клиническая безопасность, IG и продукт держат несвязанные взгляды на одну услугу. Противоядие: одна общая карта соответствия, согласованное управление.
• Нет сканирования горизонта. Быть застигнутым врасплох изменением правила, которое можно было предвидеть. Противоядие: список наблюдения с владельцем, привязанный к карте соответствия.
• Устаревшие доказательства. Восстановление журналов опасностей и оценок под давлением инспекции. Противоядие: непрерывные, готовые к аудиту доказательства.

Модель зрелости#

Контрольный список#

• Правовая классификация услуги (медицинское изделие и класс; контролёр/обработчик) подтверждена и задокументирована.
• Живая карта соответствия перечисляет каждое обязательство на законодательном, обязательном и добровольном уровнях.
• У каждого обязательства есть единоличный названный владелец с полномочиями и временем на исполнение.
• Обязательные инструменты NHS (DTAC, DSPT, DCB0129/0160) встроены в поставку, а не навешены при запуске.
• Строгость калибруется по риску для пациентов, равенства и доверия, а не единообразное проставление галочек.
• Доказательства (журналы опасностей, DPIA, DSPT, DTAC) актуальны, доступны и готовы к аудиту.
• Названный владелец ведёт сканирование нормативного горизонта по поддерживаемому списку наблюдения.
• Требования к маркировке соответствия (UKCA/CE) для соответствующего рынка подтверждены, а не предполагаются.
• Функции соответствия разделяют единый согласованный взгляд на каждую услугу, привязанный к управлению (тема 6.4).
• Реестр пересматривается по графику, а не пишется один раз и забрасывается.

Ключевые источники#

• Care Quality Commission — How CQC regulates и единая рамка оценки (cqc.org.uk).
• MHRA — Medical devices: software applications (apps) и руководство Software and AI as a Medical Device (gov.uk).
• NICE — Evidence Standards Framework for digital health technologies (ESF) (nice.org.uk).
• Information Commissioner's Office — Guide to Data Protection и Guide to the UK GDPR (ico.org.uk).
• NHS England — Data Security and Protection Toolkit (DSPT) (dsptoolkit.nhs.uk).
• NHS England — Digital Technology Assessment Criteria (DTAC).
• NHS Digital / NHS England — стандарты управления клиническими рисками DCB0129 и DCB0160.
• GMC — Good medical practice; NMC — The Code (профессиональные стандарты).
• GOV.UK — руководство по маркировке UKCA и маркировке CE для рынка Великобритании.

Ссылки#

1. Regulatory compliance — Wikipedia — https://en.wikipedia.org/wiki/Regulatory_compliance
2. Care Quality Commission — Wikipedia — https://en.wikipedia.org/wiki/Care_Quality_Commission
3. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
4. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
5. UKCA marking — Wikipedia — https://en.wikipedia.org/wiki/UKCA_marking
6. CE marking — Wikipedia — https://en.wikipedia.org/wiki/CE_marking
7. National Institute for Health and Care Excellence — Wikipedia — https://en.wikipedia.org/wiki/National_Institute_for_Health_and_Care_Excellence
8. Information Commissioner's Office — Wikipedia — https://en.wikipedia.org/wiki/Information_Commissioner%27s_Office
9. General Data Protection Regulation — Wikipedia — https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
10. Data Protection Act 2018 — Wikipedia — https://en.wikipedia.org/wiki/Data_Protection_Act_2018
11. General Medical Council — Wikipedia — https://en.wikipedia.org/wiki/General_Medical_Council
12. Nursing and Midwifery Council — Wikipedia — https://en.wikipedia.org/wiki/Nursing_and_Midwifery_Council
13. Artificial Intelligence Act — Wikipedia — https://en.wikipedia.org/wiki/Artificial_Intelligence_Act
14. Regulation (EU) 2017/745 (EU Medical Device Regulation) — Wikipedia — https://en.wikipedia.org/wiki/Regulation_(EU)_2017/745
15. How CQC regulates — Care Quality Commission — https://www.cqc.org.uk/about-us/how-we-do-our-job/how-we-regulate
16. Software and AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
17. Evidence Standards Framework for digital health technologies (ESF) — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
18. Guide to the UK GDPR — Information Commissioner's Office — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/
19. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
20. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
21. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
22. UKCA marking guidance — GOV.UK — https://www.gov.uk/guidance/using-the-ukca-marking