Тема 4.4 — Подключённые устройства, IoT и клиническая инженерия

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

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

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

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

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

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

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

Клиническая инженерия — специальность в рамках биомедицинской инженерии, отвечающая за безопасное и эффективное использование медицинской техники в организации здравоохранения. В NHS эти команды часто называют медицинской инженерией, медицинской физикой или Electronic and Biomedical Engineering (EBME). Управление медицинскими изделиями — их основная дисциплина: ведение точной инвентаризации, плановое профилактическое обслуживание, калибровка, ремонт, оповещения о безопасности, обучение и контролируемый вывод из эксплуатации в конце срока службы.

Операционная технология (OT) — аппаратное и программное обеспечение, отслеживающее или управляющее физическими процессами и оборудованием, в отличие от обычных информационных технологий (ИТ), обрабатывающих деловые данные. Клинические устройства и системы зданий — это OT: у них реальные физические эффекты, долгие жизненные циклы и ограничения (время работы, сертификация, поведение в реальном времени), из-за которых обычная ИТ-практика — перезагрузка, обновление, замена — рискованна или запрещена без благословения производителя. Поверхность атаки (attack surface) — совокупность точек, где злоумышленник может проникнуть в систему или повлиять на неё; подключённые устройства резко расширяют её, потому что каждое — маленький, часто не укреплённый компьютер в вашей сети.

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

Наконец, регуляторная рамка. В Великобритании Medicines and Healthcare products Regulatory Agency (MHRA) регулирует медицинские изделия, а постмаркетинговый надзор — наблюдение за безопасностью и эффективностью после выхода продукта на рынок — общая обязанность производителей и операторов, использующих устройства и сообщающих о них. Носимые технологии и дистанционный мониторинг пациентов выносят все эти понятия за пределы здания, в дом и карман пациента.

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

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

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

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

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

5. Планируйте весь жизненный цикл, включая конец срока службы, до покупки. Клиническая жизнь устройства регулярно переживает поддержку ПО производителем, создавая годы неподдерживаемого риска, обращённого в интернет. При закупке требуйте спецификацию программных компонентов (software bill of materials), заявленное обязательство поддержки и обновлений, функции безопасности по замыслу и чёткую дату окончания поддержки и закладывайте бюджет замены под эту дату, а не под механическую (см. тему 6.3 — Закупки и коммерческие вопросы). Вывод из эксплуатации — тоже контролируемый шаг: сотрите данные пациентов, отзовите учётные данные и сетевой доступ и обновите реестр, потому что забытый монитор в кладовой — всё ещё живой путь внутрь.

6. Доставляйте данные устройств в запись безопасно и осмысленно. Ценность подключённых устройств реализуется, когда показания попадают в клиническую запись точно, с нужным пациентом, единицами и метками времени и с ясным происхождением. Используйте признанные стандарты интероперабельности и интеграционное промежуточное ПО, а не индивидуальные связи «точка-точка», и проверяйте, что показание устройства каждый раз сопоставляется с правильным пациентом (см. тему 4.3 — Интероперабельность и стандарты данных). Жизненный показатель, приписанный не тому пациенту, или неоднозначная единица — угроза клинической безопасности, наряженная в удобство интеграции.

7. Проектируйте дистанционный мониторинг и носимые устройства для дома, а не для палаты. Когда уход переходит на дом, вы наследуете устройства на домашнем широкополосном доступе, общие для семей, заряжаемые эпизодически и используемые больными людьми. Проектируйте с учётом перебоев связи, ясной эскалации при выходе показаний за пороги, цифрового включения и явного согласия о том, что собирается и кто действует (см. тему 1.9 — Цифровое включение и доступность и тему 3.3 — Цифровые услуги для пациентов и граждан). Будьте честны в клинической ответственности: поток домашних показаний, за которым никому не выделены ресурсы наблюдать, — ложное успокоение, а не услуга.

8. Репетируйте потерю ваших устройств и сообщайте о неисправностях наверх. Допускайте, что класс устройств однажды станет недоступен — из-за вымогателя, отзыва или сбоя сети, — и репетируйте клиническую резервную процедуру, чтобы персонал не импровизировал во время инцидента (см. тему 3.9 — Непрерывность бизнеса и аварийное восстановление). Параллельно направляйте неисправности устройств, «почти-ошибки» и нежелательные события в постмаркетинговый надзор MHRA через схему Yellow Card, потому что ваши сообщения — способ поймать системные дефекты устройств, прежде чем они навредят кому-то ещё.

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

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

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

3. Что происходит клинически, когда класс этих устройств недоступен, небезопасен или скомпрометирован, и репетировали ли мы это когда-нибудь? Подключённые устройства отказывают классом, а не поодиночке: событие вымогателя, ошибка прошивки, отзыв или сбой сети могут одновременно вывести из строя все насосы или мониторы одного типа. Обсудите, потеря каких классов устройств причинила бы наибольший вред, какова ручная или альтернативная клиническая резервная процедура и знает ли её персонал на передовой или будет импровизировать под давлением. Выведите на свет компромисс между доступностью и безопасностью: давление держать хрупкое устройство клинически работающим против риска оставить известную дыру открытой и кто уполномочен принимать это решение. Подумайте, обнаружили бы вы вообще скомпрометированное устройство, ведущее себя неочевидно неправильно: монитор, показывающий правдоподобные, но ложные значения, поймать труднее, чем тот, что погас. Хороший ответ определяет классы наибольшего вреда, подтверждает, что для каждого есть отрепетированная и обеспеченная ресурсами резервная процедура, и откровенен о слепых пятнах обнаружения, которые остаются.

4. Покупаем ли мы и бюджетируем ли программную жизнь устройства или только его механическую жизнь? У сканера может быть пятнадцатилетняя клиническая жизнь, тогда как операционная система внутри теряет поддержку безопасности через пять, так что закупочное решение сегодня тихо обязывает вас к десятилетию необновляемого риска, если никто не планирует это. Обсудите, считает ли ваш процесс закупки спецификацию программных компонентов, заявленное обязательство обновлений, функции безопасности по замыслу и явную дату окончания поддержки условиями контракта или приятными дополнениями, отпадающими под давлением цены. Выясните, кто держит бюджет замены и под какую дату он назначен: точку механического отказа или точку окончания поддержки ПО, наступающую годами раньше. Подумайте о неудобных случаях, уже имеющихся в хозяйстве: устройствах, купленных до того, как кто-либо задал эти вопросы, теперь годы за пределами поддержки и без видимого финансирования замены. Выведите напряжение между клиническими командами, желающими новейших возможностей, финансами, желающими выжать активы на весь физический срок, и безопасностью, видящей растущее обязательство. Честный ответ связывает решение о покупке со стоимостью полного жизненного цикла, называет владельца бюджета замены и признаёт, где хозяйство уже несёт нефинансируемый риск устаревания ПО.

5. Для устройств, переходящих в дома пациентов: кто на самом деле смотрит на показания и проектировали ли мы для людей, которые ими пользуются? Дистанционный мониторинг и носимые устройства переносят парк устройств на домашний широкополосный доступ, общий с семьёй, заряжаемый эпизодически и обслуживаемый больными людьми, так что палатные допущения о связи, контроле и поддержке перестают действовать. Обсудите, отвечает ли названная, обеспеченная ресурсами клиническая команда за действия по домашним показаниям или данные текут на дашборд, за которым никому не выделено финансирование смотреть, — ложное успокоение, наряженное услугой. Выведите напряжение цифрового включения: программа домашнего мониторинга может тихо исключить тех, у кого нет надёжного широкополосного доступа, подходящего устройства или уверенности им пользоваться, расширяя то самое неравенство, которое должна была сужать (см. тему 1.9 — Цифровое включение и доступность). Подумайте о согласии и ясности ответственности: пациентам и опекунам нужно знать, что собирается, кто это видит и что происходит, когда показание превышает порог. Взвесьте тягу быстро масштабировать эти программы против обязанности сделать их безопасными и справедливыми. Хороший ответ подтверждает, кто смотрит и эскалирует, откровенен о рисках исключения и рассматривает домашние устройства как управляемую клиническую услугу, а не удобный канал данных.

6. Когда показание устройства попадает в клиническую запись, уверены ли мы, что это то значение, в тех единицах, для того пациента? Клиническая ценность подключённого устройства реализуется, только когда его данные попадают в запись точно, но каждая интеграция — также новый шанс приписать жизненный показатель не тому пациенту или потерять единицы и происхождение, стоящие за числом. Обсудите, текут ли данные устройств через проверенные стандарты интероперабельности и интеграционное промежуточное ПО с явными проверками сопоставления пациента или через индивидуальные связи «точка-точка», которых никто полностью не понимает (см. тему 4.3 — Интероперабельность и стандарты данных). Проверьте виды отказов, выглядящие как удобство, но являющиеся угрозой безопасности: неоднозначная единица, неверно отмеченное по времени показание, значение, записанное предыдущему пациенту, ещё залогиненному у кровати. Подумайте, как вы вообще обнаружили бы такую ошибку, учитывая, что правдоподобное, но неверное число куда опаснее очевидной дыры. Выведите компромисс между скоростью подключения нового устройства и работой по обеспечению гарантий, делающей его данные заслуживающими доверия. Честный ответ описывает, как сопоставление пациента и целостность единиц проверяются от начала до конца, называет владельца этой гарантии и рассматривает неверно приписанное показание как инцидент клинической безопасности, которым оно и является, а не как неприятность интеграции.

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

Meadowfield NHS Foundation Trust управляет острой больницей среднего размера и, всё чаще, виртуальной палатой, наблюдающей за пациентами на дому. После того как соседний траст пострадал от инцидента с вымогателем, распространившегося через неуправляемые клинические устройства, совет Meadowfield задаёт простой вопрос: сколько у нас подключённых устройств и кто ими владеет? Честный ответ — никто не может сказать. В базе клинической инженерии около 6000 активов; пассивный инструмент обнаружения сетевой команды видит ближе к 9000 вещей, ведущих себя как устройства. Разрыв и есть проблема.

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

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

Через шесть месяцев производитель выпускает полевое уведомление о безопасности о дефекте прошивки монитора. Поскольку реестр теперь точен и сверен, Meadowfield определяет все затронутые единицы за час, применяет проверенное исправление через контроль изменений и сообщает о собственной связанной «почти-ошибке» в MHRA по схеме Yellow Card. Работа была непритязательной — реестр, форум, проект сегментации, — но превратила невидимый бесхозный риск в управляемый.

Секторные линзы#

Стартап#

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

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

Устоявшийся малый поставщик — общая практика, общинная аптека, дом ухода или клиника на одной площадке — эксплуатирует скромный, но реальный парк подключённого оборудования: тонометры, ЭКГ-аппараты, датчики холодильников с вакцинами, спирометры и растущую струйку носимых устройств пациентов, всё в сети, за которой не следит выделенная ИТ-команда. Действуют те же обязанности перед MHRA, по кибербезопасности и клинической безопасности, что и у крупного траста, но клинико-инженерного отдела нет, а часто нет и собственных ИТ, поэтому начните с простого знания того, что у вас есть: короткий честный реестр с маркой, прошивкой и статусом поддержки лучше сложной системы, которую вы не сможете вести. Сильно опирайтесь на поставщиков и партнёров по управляемым услугам: настаивайте, чтобы контракты обслуживания, ответственность за обновления и даты окончания поддержки были записаны, потому что вы полагаетесь на них в возможностях, которые не можете обеспечить персоналом. Используйте момент покупки как главную точку контроля, так как замена устаревшего устройства для вас часто реалистичнее, чем укрепление на месте. Держите самые опасные позиции — холодильник с вакцинами холодовой цепи, монитор, которому доверяет клиницист, — вне плоской офисной сети, где компрометация могла бы достичь всего, даже если полная сегментация вам не по силам.

Предприятие#

Крупный траст NHS или больничная группа управляет тысячами устройств от десятков поставщиков в разросшемся долгоживущем хозяйстве, и его задача — координация и масштаб. Реалистичная цель — сверенный реестр, дисциплинированная сегментация и совместный орган управления, охватывающий клиническую инженерию, ИТ и безопасность с реальными полномочиями, а не идеальное обновление везде, что невозможно из-за ограничений поставщиков. Встройте безопасность устройств в закупки, чтобы обязательства поддержки, функции безопасности по замыслу и даты окончания поддержки были условиями контракта, и привяжите бюджет замены к программной, а не механической жизни (см. тему 4.0 — Техническая архитектура, облако и унаследованные системы). В таком масштабе крупнейшие выигрыши дают небольшое число общехозяйственных мер, выполняемых последовательно, а не героизм на отдельных устройствах.

Правительство#

Национальный или региональный орган — NHS England, делегированное министерство здравоохранения, MHRA — формирует среду, в которой работает каждый оператор. Он задаёт стандарты безопасности устройств и закупочные рамки, ведёт национальную разведку угроз и оповещение, чтобы уязвимость, найденная в одном трасте, защищала всех, и регулирует устройства и их постмаркетинговый надзор. Его рычаг — сделать безопасность по замыслу и поддержку жизненного цикла рыночным умолчанием через стандарты и покупательную силу, чтобы отдельные трасты не вели каждый переговоры о безопасности с позиции слабости. Правительство несёт и обязанность равенства: обеспечить, чтобы программы домашнего мониторинга и носимых устройств не расширяли цифровой разрыв и чтобы отчётность о безопасности поднималась наверх, а системные дефекты устройств ловились на национальном уровне, а не открывались заново траст за трастом (см. тему 9.1 — Работа с местными и национальными правительствами).

Типичные виды отказов#

• Реестр, который лжёт. Аккуратная таблица, последний раз сверенная год назад, даёт ложную уверенность; устройства, которые вредят вам, — те, которых она никогда не перечисляла. Сверяйте непрерывно с сетевым обнаружением.
• Устройства в ничьей земле между командами. Когда ИТ говорит, что это оборудование клинической инженерии, а клиническая инженерия — что это сеть ИТ, никто не обновляет, не сегментирует и не наблюдает. Назначьте сквозное владение.
• Паралич обновлений или безрассудство обновлений. Обе крайности вредят пациентам: отсутствие обновлений оставляет известные дыры открытыми; установка непроверенных обновлений может сломать критичное для безопасности устройство. Проводите обновления через совместный клинический контроль изменений.
• Покупка по механической жизни с забвением программной. Пятнадцатилетний сканер на пятилетней поддержке ОС становится необновляемым обязательством. Бюджетируйте замену под окончание поддержки ПО.
• Плоские сети. Подключённые устройства в общей сети позволяют одной компрометации достичь всего. Сегментируйте по умолчанию.
• Домашний мониторинг без наблюдателя. Поток показаний носимых устройств, на которые нет ресурсов у клинициста действовать, — ложное успокоение и риск управления, а не услуга.
• Вывод из эксплуатации, которого нет. Списанное устройство, всё ещё в сети со старыми учётными данными и данными пациентов, — живой путь атаки. Сотрите, отзовите, отключите и обновите реестр.

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

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

• Есть один авторитетный реестр устройств, постоянно сверяемый с сетевым обнаружением, с названным владельцем.
• Совместный форум ИТ, клинической инженерии и кибербезопасности имеет реальные права решения о подключении, обновлении, сегментации и выводе из эксплуатации.
• Подключённые устройства находятся в сегментированных сетевых зонах, разрешающих только действительно нужные им потоки.
• Обновления и прошивки регулируемых устройств проверяются и проводятся через клинический контроль изменений, с планами отката.
• Закупочные контракты требуют спецификацию программных компонентов, функции безопасности по замыслу и заявленную дату окончания поддержки.
• Бюджеты замены привязаны к сроку программной поддержки, а не только к механической жизни.
• Вывод из эксплуатации стирает данные пациентов, отзывает учётные данные и сетевой доступ и обновляет реестр.
• Данные устройств попадают в клиническую запись через проверенную интеграцию с проверками сопоставления пациента и единиц.
• Программы домашнего мониторинга и носимых устройств имеют обеспеченную ресурсами клиническую эскалацию, явное согласие и включение по замыслу.
• Клиническая резервная процедура при потере каждого класса устройств наибольшего вреда задокументирована и отрепетирована.
• О неисправностях устройств, «почти-ошибках» и нежелательных событиях сообщается в MHRA через схему Yellow Card.

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

• MHRA — Medical devices: guidance for manufacturers, operators and users и схема сообщений Yellow Card о нежелательных инцидентах и полевых уведомлениях о безопасности.
• NHS England / NHS Digital — Data Security and Protection Toolkit и руководство по безопасности сетей и устройств для организаций здравоохранения и ухода.
• NCSC (National Cyber Security Centre) — руководство по операционным технологиям, сегментации сети и защите подключённых устройств.
• NHS England / стандарты IEC — хорошая практика клинической инженерии и управления медицинскими изделиями (включая IEC 80001 по управлению рисками ИТ-сетей, включающих медицинские изделия).
• NICE — Evidence Standards Framework for Digital Health Technologies и руководство по дистанционному мониторингу и носимым устройствам.
• Institute of Physics and Engineering in Medicine (IPEM) — профессиональное руководство по клинической и биомедицинской инженерии.

Литература#

1. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
2. Internet of things — Wikipedia — https://en.wikipedia.org/wiki/Internet_of_things
3. Clinical engineering — Wikipedia — https://en.wikipedia.org/wiki/Clinical_engineering
4. Biomedical engineering — Wikipedia — https://en.wikipedia.org/wiki/Biomedical_engineering
5. Operational technology — Wikipedia — https://en.wikipedia.org/wiki/Operational_technology
6. Network segmentation — Wikipedia — https://en.wikipedia.org/wiki/Network_segmentation
7. Attack surface — Wikipedia — https://en.wikipedia.org/wiki/Attack_surface
8. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
9. Postmarketing surveillance — Wikipedia — https://en.wikipedia.org/wiki/Postmarketing_surveillance
10. Wearable technology — Wikipedia — https://en.wikipedia.org/wiki/Wearable_technology
11. Remote patient monitoring — Wikipedia — https://en.wikipedia.org/wiki/Remote_patient_monitoring
12. Infusion pump — Wikipedia — https://en.wikipedia.org/wiki/Infusion_pump
13. Medicines and Healthcare products Regulatory Agency — Medical devices: guidance and Yellow Card reporting — GOV.UK — https://www.gov.uk/government/organisations/medicines-and-healthcare-products-regulatory-agency
14. National Cyber Security Centre — Guidance on operational technology and device security — NCSC — https://www.ncsc.gov.uk/
15. NHS England — Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
16. National Institute for Health and Care Excellence — Evidence Standards Framework for Digital Health Technologies — NICE — https://www.nice.org.uk/about/what-we-do/our-programmes/evidence-standards-framework-for-digital-health-technologies
17. Institute of Physics and Engineering in Medicine — Clinical and biomedical engineering guidance — IPEM — https://www.ipem.ac.uk/