Тема 9.2 — Глобальное и международное цифровое здравоохранение

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

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

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

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

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

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

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

Глобальная стратегия ВОЗ и цифровые общественные блага. Всемирная организация здравоохранения (ВОЗ) опубликовала Глобальную стратегию по цифровому здравоохранению, представляющую цифровое здравоохранение как катализатор всеобщего здравоохранения — часто называемого всеобщим охватом услугами здравоохранения (UHC), цели, чтобы каждый мог пользоваться нужными услугами без финансовых трудностей. Центральная идея — цифровое общественное благо: ПО с открытым исходным кодом, открытые данные, открытые стандарты и открытый контент — иногда называемые «глобальными благами», — которые любая страна может принять и адаптировать, а не покупать проприетарные системы, которыми она не может владеть или которые не может себе позволить. Одобренные ВОЗ инструменты, такие как DHIS2 (платформа медицинской информации, используемая более чем в семидесяти странах) и OpenMRS (медицинская карта с открытым исходным кодом), — канонические примеры.

Международные стандарты интероперабельности и терминологии. Границы пересекаются не перемещением целых систем, а общим языком. Три стандарта делают большую часть работы: HL7 Fast Healthcare Interoperability Resources (FHIR) для обмена структурированными клиническими данными; SNOMED CT, международная клиническая терминология, управляемая SNOMED International; и МКБ-11 ВОЗ, одиннадцатый пересмотр Международной классификации болезней, используемый для кодирования смертности, заболеваемости и возмещения по всему миру. Это общий словарь, позволяющий английской записи, эстонской записи и статистическому отчёту ВОЗ значить одно и то же. (См. тему 4.3 — Интероперабельность и стандарты данных.)

mHealth и перепрыгивание. mHealth — мобильное здравоохранение — оказание услуг и информации здравоохранения через мобильные телефоны. Во многих LMIC мобильный уход — не понижение, а основной канал, и он иллюстрирует перепрыгивание: пропуск поколения инфраструктуры (здесь — проводной связи и бумагоёмких больничных ИТ) для перехода прямо к новой технологии. Урок для более богатых систем не в том, что телефоны дёшевы, а в том, что ограничение порождает проекты — offline-first, низкая пропускная способность, резерв по SMS, — более устойчивые, чем многие «передовые» альтернативы.

Суверенитет данных и трансграничные потоки данных. Суверенитет данных — принцип, что данные управляются законами юрисдикции, где они собраны или хранятся. Данные о здоровье — одна из самых строго контролируемых категорий, а правовые режимы резко расходятся: Общий регламент по защите данных (GDPR) Великобритании и ЕС опирается на правовые основания и права субъектов данных; американский Health Insurance Portability and Accountability Act (HIPAA) защищает более узкий набор «охватываемых субъектов»; Закон ЕС об искусственном интеллекте и Регламент ЕС о медицинских изделиях (Regulation (EU) 2017/745) налагают риск-ориентированные контроли на ПО как медицинское изделие. Инструмент, соответствующий в одном режиме, может быть незаконным в другом, а трансграничные потоки данных требуют явного правового механизма передачи, а не допущения.

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

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

  1. Принимайте глобальные стандарты, прежде чем изобретать местные. По умолчанию используйте HL7 FHIR, SNOMED CT и МКБ-11 для обмена, терминологии и классификации, потому что это общий язык, делающий возможными любое будущее международное сравнение, сотрудничество или смену поставщика. Каждая индивидуальная местная система кодов, которую вы создаёте, — стена, которую позже придётся сносить. Где существует национальный профиль — например, профили UK Core FHIR, — используйте его и вносите вклад обратно, а не форкайте тихо.

  2. Предпочитайте цифровые общественные блага и открытые стандарты проприетарной привязке. Закупая или строя, сильно взвешивайте варианты с открытым кодом, открытой спецификацией и независимым управлением, потому что они сохраняют вашу способность владеть, аудировать и выйти. Цифровые общественные блага вроде DHIS2 и OpenMRS проверены в национальном масштабе и свободны от лицензионной ренты; даже выбирая коммерческий продукт, настаивайте на открытых стандартах и переносимости данных, чтобы никогда не быть заложником. (См. тему 9.0 — Сотрудничество с партнёрскими организациями о проектировании против привязки к поставщику.)

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

  4. Никогда не поднимайте и не переносите национальную модель целиком. Успех Эстонии покоится на малом населении, обязательной национальной цифровой идентичности и высокодоверительном урегулировании, строившемся два десятилетия; здравоохранительный стек Индии покоится на определённой государственно-частной архитектуре и системе идентичности на миллиард человек. Извлечь один компонент и бросить в Англию — значит игнорировать леса, делающие его безопасным. Принимайте паттерн и перестраивайте реализацию под ваш правовой, демографический и доверительный контекст.

  5. Нанесите на карту правовой режим до того, как любые данные пересекут границу. Установите письменно правовое основание, механизм передачи и отношения операторов, прежде чем данные о здоровье покинут юрисдикцию, — не допускайте, что законный для Великобритании поток законен дальше. Где вы действуете по GDPR, HIPAA, Закону ЕС об ИИ и Регламенту ЕС о медицинских изделиях, считайте самый строгий применимый режим своим полом и записывайте, как соблюдается суверенитет данных для каждой популяции, чьи данные вы держите.

  6. Проектируйте под самые тяжёлые реалистичные условия, а не демонстрацию. Заимствуйте дисциплину LMIC — offline-first, низкая пропускная способность и изящная деградация, — потому что она порождает услуги, переживающие отказ связи, старое устройство и сельскую «белую зону» и дома. Инструмент, работающий только на быстром оптоволокне в клинике, неустойчив; равенство и клиническая безопасность улучшаются, когда вы предполагаете, что сеть откажет.

  7. Закрепляйте всё в равенстве и всеобщем охвате и проверяйте, кто исключён. Для каждого внедрения спрашивайте, сужает оно или расширяет разрыв — между странами и внутри вашего населения, — потому что цифровая услуга, обслуживающая связанных и уверенных и оставляющая других позади, — шаг от всеобщего охвата, а не к нему. Измеряйте принятие по группам, а не только в совокупности. (Это связано с темой 1.9 — Цифровое включение и доступность.)

  8. Управляйте ИИ и новыми технологиями по самой высокой применимой международной планке. Алгоритмы, обученные на одной популяции, могут навредить другой, а регуляторная почва быстро смещается под Законом ЕС об ИИ и сопоставимыми рамками. Документируйте происхождение обучающих данных, валидируйте на своей популяции и согласуйте управление с самым строгим режимом, которого вы касаетесь, а не самым мягким. (См. тему 8.4 — Управление ИИ и новыми технологиями.)

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

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

  2. Прежде чем любые данные о здоровье пересекут границу — включая облачный регион, поставщика или исследовательского партнёра в другой стране, — знаем ли мы правовое основание, механизм передачи и какой режим им управляет? Трансграничные потоки данных — место, где добрые намерения встречают жёсткий закон, и провал обычно тих: данные идут через облачный регион или зарубежную службу поддержки поставщика, пока никто не установил правовой механизм передачи. Ваша команда должна ясно различать мир правовых оснований и прав субъектов данных UK и EU GDPR, модель HIPAA США, защищающую более узкий набор охватываемых субъектов, и возникающие контроли Закона ЕС об ИИ и Регламента о медицинских изделиях для клинического ПО. Обсуждение должно конкретно охватить суверенитет данных: для каждой популяции, чьи данные вы держите, законы какой страны ими управляют и соблюдаете ли вы это? Оно должно также столкнуться с практическими ловушками — «глобальным» SaaS-продуктом с персоналом поддержки на другом континенте, ИИ-поставщиком, чья модель переобучается на ваших данных, исследовательским сотрудничеством, предполагающим взаимность, которой закон не даёт. Сильный ответ считает самый строгий применимый режим полом, записывает механизм передачи до перемещения данных и может назвать, кто подотчётен, когда спросит регулятор.

  3. Проектируем ли мы под связь, устройства и грамотность всех, кому служим, или только под уверенного связанного пользователя из демонстрации? Многие из самых устойчивых в мире технологий здравоохранения строились в условиях ограничений — перебои питания, низкая пропускная способность, общие или простые телефоны, много языков, — и эта дисциплина порождает услуги, обслуживающие и исключённых внутри богатой системы. Вашей команде следует изучить, предполагают ли её проекты быструю связь, современные устройства и высокую цифровую грамотность, и что происходит с пациентом, когда эти допущения не выполняются. Ставки равенства прямы: услуга, работающая только для хорошо связанных, расширяет разрыв, который должна была закрыть, и между странами, и внутри вашего населения, двигаясь от всеобщего охвата, а не к нему. Разговор должен рассмотреть offline-first поведение, изящную деградацию, резерв по SMS или голосу, доступность языка и уровня чтения и измеряется ли принятие по группам, а не только в совокупности. Он должен также спросить, заимствуете ли вы проверенные паттерны проектирования LMIC или игнорируете их из ощущения, что они «не для нас». Хороший ответ может указать на конкретные проектные решения, защищающие самого труднодостижимого пользователя, и на метрики, рано выявляющие исключение.

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

  5. Считаем ли мы партнёров с более низким доходом источниками проверенного проектирования и подлинными соавторами или получателями нашей благотворительности — и можем ли ясно сказать, что мы вносим обратно? Международное цифровое здравоохранение несёт устойчивую асимметрию власти, а благотворительная рамка — где богатая система «помогает» LMIC, жертвуя технологию, — и снисходительна, и надёжный путь к провалу, потому что игнорирует, что мобильный уход, платформы работников общественного здравоохранения и открытая национальная инфраструктура часто были впервые созданы именно в этих системах. Вашей команде следует изучить реальное или предлагаемое партнёрство и спросить, кому принадлежит результат, кто его поддерживает и подлинно ли поток обучения идёт в обе стороны. Напряжения конкретны: пожертвованная платформа, становящаяся нефинансируемой зависимостью, «сотрудничество», извлекающее данные или валидацию из популяции партнёра без взаимной выгоды, учебная поездка, берущая уроки и ничего не предлагающая взамен. Оно должно также столкнуться со взаимным смирением, которого требует тема: что делает ваша собственная система такого, чему могли бы научиться другие, и делитесь ли вы этим так же открыто, как ожидаете, что поделятся с вами? Честный ответ может указать на соглашения о совместном владении, вклады обратно в общие открытые ядра и партнёрство, которое имело бы смысл, даже если бы направление финансирования обратилось.

  6. Для любого алгоритма или модели ИИ, которые мы внедряем, можем ли мы показать, что они валидированы на популяции, которой реально будут служить, и управляются по самому строгому режиму, которого мы касаемся, а не самому мягкому? Модель, обученная и валидированная на одной популяции, может тихо навредить другой, а международное цифровое здравоохранение умножает этот риск, потому что инструменты, обучающие данные и поставщики пересекают границы быстрее, чем доказательства их безопасности. Ваша команда должна уметь отличать происхождение модели — откуда взялись её обучающие данные, против какой популяции она валидирована — от популяции, которой её теперь просят служить, и считать любой разрыв живой заботой клинической безопасности, а не бумажной деталью. Регуляторная почва быстро и неровно смещается: Закон ЕС об ИИ налагает риск-ориентированные контроли на высокорисковое клиническое ПО, Регламент ЕС о медицинских изделиях считает многие алгоритмы ПО как медицинским изделием, а британский закон местами мягче, что создаёт соблазн управлять по самому мягкому режиму, который вы можете защитить. Обсуждение должно выявить, кто подотчётен за повторную валидацию, как контролируются обновления модели и переобучение поставщиком и документирует ли организация происхождение обучающих данных вообще. Сильный ответ повторно валидирует на местной популяции до внедрения, согласует управление с высочайшей применимой международной планкой, чтобы сохранить варианты открытыми, и может объяснить этот выбор регулятору без смущения.

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

Вымышленному английскому органу на расстоянии вытянутой руки, «National Remote Monitoring Service», поручено закупить платформу для домашнего мониторинга долгосрочных состояний с возможностью сотрудничать над общим ядром с открытым кодом с министерствами здравоохранения двух стран-партнёров — одной страны ЕС-соседа с высоким доходом, другой — LMIC, масштабирующей работников общественного здравоохранения.

Соблазн — купить отполированную коммерческую платформу и считать международный аспект дипломатической любезностью. Команда противится. Она начинает со стандартов: любая платформа должна обмениваться данными как HL7 FHIR, кодировать наблюдения в SNOMED CT и классифицировать состояния по МКБ-11, чтобы данные значили одно и то же во всех трёх странах, а услуга не была привязана к одному поставщику. Она составляет короткий список из ядра цифрового общественного блага (стек на основе OpenMRS) наряду с двумя коммерческими вариантами, оценивая каждый по переносимости данных и выходу так же сильно, как по функциям.

В законе команда наносит режимы на карту до того, как сдвинется хоть байт. Данные английских пациентов остаются под UK GDPR в британском облачном регионе; сотрудничество с партнёром из ЕС идёт под EU GDPR с документированным механизмом передачи; никакие персональные данные не текут к партнёру LMIC и от него вообще — только деидентифицированные агрегированные показатели и сам код с открытым исходным кодом, являющийся цифровым общественным благом и не несущий риска суверенитета. Алгоритм мониторинга считается ПО как медицинским изделием и валидируется на английской популяции отдельно, потому что модель, настроенную где-то ещё, нельзя считать безопасной здесь; её управление согласовано с ожиданиями Закона ЕС об ИИ для высокого риска, даже там, где британский закон мягче, чтобы сохранить варианты открытыми.

Проект заимствует у партнёра из LMIC, а не поучает его. Платформа работников общественного здравоохранения там — offline-first с резервом по SMS, и английская услуга принимает тот же паттерн, что оказывается важно для сельских «белых зон» и пожилых пациентов дома. Через восемнадцать месяцев общее ядро с открытым кодом поддерживается совместно, каждая страна ведёт собственное законное внедрение, и ни один партнёр не копировал модель другого целиком. Английская команда может показать регулятору, какие именно данные лежат под каким законом, а министерство LMIC имеет совместно владеемую платформу, а не пожертвованную зависимость.

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

Стартап#

Стартап цифрового здравоохранения часто выходит на международные рынки, прежде чем готов к правовой сложности, которую они несут. Выигрыш реален — глобальные стандарты означают, что нативный FHIR, кодированный SNOMED продукт может в принципе продаваться где угодно, — но каждая новая страна приносит иной режим (GDPR, HIPAA, Закон ЕС об ИИ, национальные правила о медицинских изделиях) и иное ожидание суверенитета данных. Стройте под самый строгий режим, на который вы правдоподобно намерены выйти, держите персональные данные в регионе по проекту и считайте совместимость с цифровыми общественными благами рыночным преимуществом, а не угрозой. Основатели, перепрыгивающие в рынки LMIC, должны партнёрствовать подлинно и локализовать честно, потому что инструмент, сброшенный с парашютом без местного владения, редко переживает контакт с реальной инфраструктурой.

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

Устоявшийся малый поставщик — общая практика, общинная аптека, дом ухода, клиника на одной площадке или небольшой поставщик технологий здравоохранения за стадией стартапа — несёт те же трансграничные обязанности и обязанности по стандартам, что национальный орган, но с долей способности их выполнять. У него редко есть выделенный персонал ИТ или управления информацией, но он всё же может использовать облачный продукт, данные которого лежат в другой юрисдикции, или диагностический инструмент на модели, валидированной в другом месте. Практическая защита — опереться на стандарты и дисциплину «самый строгий режим как пол», а не пытаться рассуждать по каждому случаю с нуля: просите у поставщиков показать поддержку FHIR и SNOMED CT, местонахождение данных в регионе и документированное правовое основание до подписания и считайте переносимость данных вопросом выживания, потому что вы не можете позволить себе быть привязанным к вендору, который потерпит неудачу. Заимствование проверенных паттернов offline-first и низкой пропускной способности здесь часто лучше подходит, чем погоня за отполированным корпоративным продуктом, потому что устойчивость важнее функций, когда некому звонить при падении сети. Где национальный профиль или цифровое общественное благо уже существует, принимайте его, а не заказывайте нечто индивидуальное, что вы никогда не сможете поддерживать.

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

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

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

Национальный или наднациональный орган задаёт правила, внутри которых работают все остальные, так что его выбор по стандартам, суверенитету и открытости отзывается десятилетие. Правительствам следует вменять международные стандарты (FHIR, SNOMED CT, МКБ-11), инвестировать в цифровые общественные блага и вносить в них вклад как вопрос устойчивости и ценности и законодательно закреплять ясные, работоспособные режимы для трансграничных данных и ИИ, а не оставлять их индивидуальным переговорам. Они также держат дипломатическую роль: согласование с Глобальной стратегией ВОЗ по цифровому здравоохранению, поддержка систем LMIC как партнёров, а не получателей, и продвижение всеобщего охвата услугами здравоохранения как общей цели. Подотчётность публична и международна, так что решения должны быть прозрачными и защитимыми, а не просто целесообразными. (См. тему 9.1 — Работа с местными и национальными правительствами.)

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

  • Поднять и перенести. Копирование модели другой страны без её правовых лесов, лесов идентичности и доверия. Исправление: принимайте паттерн, перестраивайте реализацию под свой контекст.
  • Изобретение местных стандартов. Построение индивидуальных систем кодов вместо FHIR, SNOMED CT и МКБ-11. Исправление: сначала принимайте глобальные стандарты и используйте национальные профили, где они есть.
  • Тихая трансграничная утечка данных. Данные идут через зарубежные облачные регионы или службы поддержки без механизма передачи. Исправление: нанесите режим на карту и запишите правовое основание до перемещения любых данных.
  • Проприетарная привязка под видом удобства. Покупка закрытой платформы, которой вы не можете владеть, которую не можете аудировать и из которой не можете выйти. Исправление: взвешивайте цифровые общественные блага и вменяйте переносимость данных.
  • Благотворительная рамка работы с LMIC. Отношение к партнёрам с более низким доходом как к получателям, а не источникам проверенного проектирования. Исправление: партнёрствуйте взаимно и принимайте их устойчивые паттерны offline-first.
  • Допущение, что алгоритм путешествует. Внедрение модели, валидированной на другой популяции. Исправление: повторно валидируйте на своей популяции и управляйте по самому строгому применимому режиму.
  • Проектирование только под демонстрацию. Допущение быстрой связи, современных устройств и высокой грамотности. Исправление: проектируйте offline-first с изящной деградацией и измеряйте принятие по группам.

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

Измерение Инициация Развитие Стандартизация Управление Оркестрация
Принятие стандартов Индивидуальные местные форматы Некоторое использование FHIR/SNOMED FHIR, SNOMED CT, МКБ-11 вменены с национальными профилями Соответствие проверяется и отслеживается; соответствие профилям отчитывается Активно вносит вклад в глобальные стандарты
Открытость Проприетарно, привязка Статьи о переносимости существуют Цифровые общественные блага предпочитаются; выход заложен проектом Выход отрабатывается, переносимость обеспечивается по измеренным критериям Совместно поддерживает общие открытые ядра с партнёрами
Трансграничный правовой контроль Не нанесено на карту, ситуативно Режим известен по проекту Правовое основание, размещение, механизм передачи записаны Контроли передачи измеряются и активно управляются по целям Самый строгий режим как пол, рутинно аудируется
Международное обучение Анекдотично, туризм Эпизодические учебные поездки Названные владельцы, честное разделение переносимого/специфичного Результаты обучения отслеживаются и по ним действуют по целям Взаимные партнёрства; система и учит, и учится
Равенство и устойчивость Допущения только для демонстрации Некоторая обработка офлайн Offline-first, принятие по группам измеряется Метрики исключения управляются по целям равенства Проектируется для самого трудного пользователя по умолчанию

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

  • Обмен, терминология и классификация используют HL7 FHIR, SNOMED CT и МКБ-11 с национальными профилями, где они есть.
  • Варианты цифровых общественных благ и открытых стандартов сильно взвешивались в решениях «строить или покупать».
  • Каждый контракт на продукт и поставщика гарантирует переносимость данных и документированный выход.
  • Правовое основание, размещение данных и механизм передачи записаны до пересечения границы любыми данными о здоровье.
  • Применимые режимы (UK/EU GDPR, HIPAA, Закон ЕС об ИИ, Регламент ЕС о медицинских изделиях) определены, самый строгий принят как пол.
  • Любая модель ИИ валидирована на вашей популяции и управляется по высочайшей применимой международной планке.
  • У международного обучения есть названный владелец, отделяющий переносимые принципы от непереносимых специфик.
  • Ни одна национальная модель не копировалась целиком без перестройки реализации под местный контекст.
  • Услуги изящно деградируют — offline-first, низкая пропускная способность, резервные каналы — под самые тяжёлые реалистичные условия.
  • Принятие и результаты измеряются по группам для выявления исключения, ради всеобщего охвата и равенства.

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

  • Всемирная организация здравоохранения — Global Strategy on Digital Health 2020–2025 (who.int).
  • Всемирная организация здравоохранения — Classification of digital health interventions и МКБ-11 (who.int).
  • Digital Public Goods Alliance — DPG Standard и реестр (digitalpublicgoods.net).
  • HL7 International — спецификация FHIR (hl7.org/fhir); SNOMED International — SNOMED CT (snomed.org).
  • Эстония — e-Estonia и X-Road / Nordic Institute for Interoperability Solutions (e-estonia.com; niis.org).
  • Ministry of Health & Family Welfare / National Health Authority (Индия) — Ayushman Bharat Digital Mission (abdm.gov.in).
  • Европейская комиссия — Regulation (EU) 2017/745 о медицинских изделиях; Regulation (EU) 2024/1689 (Закон об искусственном интеллекте).
  • Information Commissioner's Office — руководство по международным передачам по UK GDPR (ico.org.uk).
  • The Lancet & Financial Times Commission — Governing health futures 2030 (thelancet.com).

Литература#

  1. Global health — Wikipedia — https://en.wikipedia.org/wiki/Global_health
  2. Digital health — Wikipedia — https://en.wikipedia.org/wiki/Digital_health
  3. World Health Organization — Wikipedia — https://en.wikipedia.org/wiki/World_Health_Organization
  4. Digital public goods — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_goods
  5. Universal health care — Wikipedia — https://en.wikipedia.org/wiki/Universal_health_care
  6. Fast Healthcare Interoperability Resources (FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
  7. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
  8. ICD-11 — Wikipedia — https://en.wikipedia.org/wiki/ICD-11
  9. mHealth — Wikipedia — https://en.wikipedia.org/wiki/MHealth
  10. Leapfrogging — Wikipedia — https://en.wikipedia.org/wiki/Leapfrogging
  11. Data sovereignty — Wikipedia — https://en.wikipedia.org/wiki/Data_sovereignty
  12. Artificial Intelligence Act — Wikipedia — https://en.wikipedia.org/wiki/Artificial_Intelligence_Act
  13. Regulation (EU) 2017/745 (EU Medical Device Regulation) — Wikipedia — https://en.wikipedia.org/wiki/Regulation_(EU)_2017/745
  14. Health Insurance Portability and Accountability Act (HIPAA) — Wikipedia — https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act
  15. General Data Protection Regulation — Wikipedia — https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
  16. Global Strategy on Digital Health 2020–2025 — World Health Organization — https://www.who.int/publications/i/item/9789240020924
  17. The DPG Standard — Digital Public Goods Alliance — https://www.digitalpublicgoods.net/standard
  18. Ayushman Bharat Digital Mission — National Health Authority, Government of India — https://abdm.gov.in/

Редактировать эту страницу на GitHub — источник истины — книга; этот сайт лишь отображает её.