Как включить данные, генерируемые пациентами, в системы Pacs

Понимание PACS и данных визуализации, генерируемых пациентами

Системы архивирования изображений и связи (PACS) уже давно являются основой рабочих процессов медицинской визуализации, позволяя радиологам и клиницистам хранить, извлекать, управлять и делиться цифровыми изображениями в сетях здравоохранения. Традиционно эти системы питаются внутренними модальностями, такими как КТ, МРТ, рентгеновское излучение и ультразвук. Однако ландшафт медицинской визуализации расширяется за пределы радиологического отделения. Данные визуализации, полученные пациентами с помощью смартфонов, камер потребительского класса, носимых устройств или домашних медицинских гаджетов, становятся все более ценным источником клинической информации. Эти данные могут включать в себя фотографии ран, дерматологические поражения, отоскопические изображения, снимки проверки счета таблеток и даже самоуправляемые ультразвуковые клипы. Включение этой визуальной информации, основанной на пациентах, в PACS обогащает медицинскую запись, обеспечивает продольный контекст и дает пациентам возможность играть активную роль в их уходе.

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

Технический фундамент: стандарты и совместимость

Прежде чем погрузиться в этапы интеграции, важно понять техническую среду. PACS построены вокруг стандарта DICOM (Digital Imaging and Communications in Medicine), который определяет не только формат изображения, но и метаданные, сжатие и сетевые протоколы. Образы, генерируемые пациентами, редко поступают в виде родных файлов DICOM. Обычно это изображения JPEG, PNG или HEIC, или MP4-видео со смартфона. Основная задача заключается в преобразовании, проверке и упаковке этих файлов потребительского уровня в совместимые с DICOM объекты, которые могут быть проглочены PACS без потери клинической значимости.

Стандартные и не-DICOM источники

DICOM является универсальным языком медицинской визуализации. Любое изображение, поступающее в PACS, должно быть инкапсулировано в объект DICOM, который несет структурированную демографическую информацию о пациентах, информацию об исследованиях и сериях и параметры приобретения. Сгенерированные пациентом изображения обычно не имеют этих метаданных. Чтобы преодолеть разрыв, организации могут использовать промежуточное ПО, которое либо обертывает изображение потребителя в контейнер DICOM (например, DICOM Secondary Capture) или преобразует его в DICOM-инкапсулированный формат, одновременно вручную побуждая пациента или клинициста предоставлять необходимые метаданные, такие как идентификатор пациента, номер присоединения и часть тела.

Стандарт DICOM предоставляет явные механизмы обработки неродных изображений через IOD «DICOM Secondary Capture» (Определение объекта информации). Это создает объект DICOM, где пиксельные данные хранятся вместе с минимальным набором данных. Это практический подход, но он требует тщательного отображения информации, поставляемой пациентом, в теги DICOM. Многие современные поставщики PACS теперь поддерживают DICOM-Web и RESTful API, которые упрощают прием файлов, не являющихся DICOM, позволяя веб-порталу загрузки, который автоматически обертывает изображение в объект DICOM и выталкивает его в архив.

Форматы, метаданные и конверсия

Не все форматы изображений потребителей приемлемы в клинических рабочих процессах. JPEG с высоким разрешением (базовый уровень) широко поддерживается, но новые форматы, такие как HEIC, могут вызывать проблемы совместимости у старых зрителей PACS. Наилучшая практика заключается в стандартизации JPEG или PNG для неподвижных изображений и H.264 для видео, а также в автоматическом преобразовании любого загруженного файла в эти форматы на краю перед оберткой DICOM. Обогащение метаданных одинаково важно: система должна побуждать пациента или клинициста, захватившего клинициста, ввести латеральность, область тела и краткий клинический комментарий. Эти метаданные могут быть встроены в теги DICOM (например, анализ части тела, комментарии изображений) или сохранены в виде структурированного отчета DICOM, связанного с объектом изображения.

API и решения для Middleware

Промежуточное ПО выступает в качестве переводчика между порталом загрузки, ориентированным на пациента, и сервером PACS. Несколько коммерческих и платформ с открытым исходным кодом (например, Orthanc, Dicoogle или интеграционные движки для конкретных поставщиков) предоставляют API REST, которые принимают изображения с порталов пациентов, преобразуют их в DICOM и направляют их в правильное исследование. Кроме того, некоторые поставщики PACS теперь предлагают собственные возможности загрузки «прямой-к-PACS» через мобильные SDK. При оценке промежуточного ПО приоритеты решений, которые поддерживают:

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

Пошаговая интеграция Workflow

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

1.Сбор данных и усилие; Посадка пациента

Отправной точкой является безопасный, интуитивно понятный механизм подачи изображений пациентами. Обычно это веб-портал пациента (интегрированный с EHR) или специальное мобильное приложение. Интерфейс сбора данных должен:

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

2. Стандартизация данных и усилие; DICOM Wrapping

При загрузке промежуточное ПО классифицирует тип изображения, проверяет формат и выполняет немедленную конверсию, если это необходимо. Изображение затем обертывается как объект вторичного захвата DICOM. Во время обертки программное обеспечение вводит необходимые теги: идентификатор пациента, имя пациента, UID изучаемой инстанции, UID из серии, UID из SOP класса (для вторичного захвата) и модульность (часто «XC» или «OT»). Когда пациент или ссылающийся врач предоставляет область тела, он отображается в стандартный код DICOM Body Part Examined (например, «CHEST», «ABDOMEN», «SKIN»). Если не существует отображения, используется общий код, такой как «Неизвестный», и тег клинических заметок содержит описание свободного текста.

Стандартизация данных также включает управление сжатием. Потребительские фотографии могут иметь размер в несколько мегабайт. Промежуточное ПО должно опционально сжимать пиксельные данные до клинически приемлемого уровня (например, качество JPEG 90-95) для обеспечения управляемости затрат на хранение без ущерба для диагностической утилиты. Оригинальный файл может храниться в виде DICOM-инкапсулированного PDF или в качестве отдельного производного объекта изображения для целей аудита.

3.Валидация данных и усилие; Контроль качества

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

Эта двухступенчатая проверка предотвращает загромождение архива низкокачественными данными и снижает риск неправильного толкования. Этап проверки также проверяет полноту метаданных: если пациент не предоставил необходимое поле (например, часть тела), изображение может быть помечено для ручного завершения.

4. Безопасная передача

Все передачи изображений должны быть зашифрованы как в пути, так и в покое. Портал загрузки пациента должен обеспечивать соблюдение TLS 1.2 или выше. От промежуточного программного обеспечения до PACS предпочтительным транспортом является DICOM по сравнению с TLS (DICOM-TLS) или HTTPS для DICOM-Web. Если PACS находится в отдельном сегменте сети, рассмотрите VPN или выделенный интерфейс с проверенными средствами управления безопасностью. Кроме того, убедитесь, что конечная точка загрузки защищена от атак типа «отказ в обслуживании» и размера файла (например, ограничьте загрузки до 50 МБ на файл). Журналы аудита должны записывать каждую передачу для соответствия HIPAA и GDPR.

5 Интеграция через интерфейсы

Промежуточное ПО должно говорить на родном языке PACS. Существует три общих интеграционных шаблона:

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

6. Хранение, индексирование и связь с EHR

После того, как изображение, созданное пациентом, должно храниться так же, как и любое другое радиологическое исследование, с той же политикой избыточности, резервного копирования и аварийного восстановления. Многие PACS применяют политику удержания, основанную на дате исследования изображения. Для изображений, созданных пациентом, считают более длительное удержание, потому что они могут быть частью записи мониторинга продольного заболевания (например, уход за хроническими ранами).

Исследование изображений должно быть проиндексировано в базе данных PACS с модальностью, которая четко идентифицирует его происхождение - часто "XC" (внешняя камера) или "OT" (другая). Некоторые объекты используют "GM" (общая микроскопия), но это может сбивать с толку. Идеальное решение - создать специальное или стандартизированное описание исследования "Образ пациента-генерированный образ", которое отличает его от изображений диагностического уровня. Это помогает радиологам и клиницистам фильтровать соответствующий контент.

Наконец, запись изображения должна быть доступна из EHR. Это делается либо через вставку PACS-просмотрщика (через IHE XDS-I или прямой URL-адрес), либо путем хранения веб-ссылки DICOM в клинической записке EHR. В идеале EHR должен отображать уведомление, такое как «2 изображения, представленные пациентом, доступные для просмотра» в диаграмме пациента.

Нормативно-правовые аспекты и вопросы конфиденциальности

Интеграция данных, полученных пациентом, создает уникальные проблемы регулирования. В соответствии с HIPAA в Соединенных Штатах, данные о здоровье пациента (PGHD) по-прежнему считаются защищенной медицинской информацией (PHI) после того, как она собирается покрытым субъектом. Это означает, что применяются все те же правила конфиденциальности и безопасности: шифрование, контроль доступа, контрольные данные и уведомление о нарушении. Если изображения содержат идентифицируемые функции (лица, отличительные татуировки, метаданные о местоположении), они должны быть деидентифицированы или управляться в соответствии с подписанным согласием пациента, которое разрешает сбор для клинических целей.

В соответствии с GDPR в Европе пациент сохраняет за собой право доступа, исправления и удаления своих собственных данных, включая загруженные изображения. Дизайн системы должен поддерживать легкое удаление исследований, сгенерированных пациентом, не нарушая другие сохраненные изображения. Рекомендуется явное, подробное согласие на сбор изображений (отдельно от общего согласия на лечение).

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

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

Лучшие практики для реализации

Успешное внедрение требует не только технологий, но и организационной готовности и согласования рабочих процессов.

Обучение персонала и корректировка роли

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

Образование пациентов

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

Интеграция рабочего процесса без силоса

Образы, созданные пациентами, не должны жить в отдельной папке «внешние изображения». Они должны появляться вместе с традиционными исследованиями в рабочем списке PACS. Настройте PACS для отображения специальной вкладки или флага для исследований «PGHD». Если изображения являются частью клинического испытания или программы удаленного мониторинга, они могут быть автоматически направлены в определенную очередь чтения. Эта бесшовная видимость гарантирует, что поставщики не упускают из виду данные.

Постоянный мониторинг и повышение качества

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

Проблемы и стратегии смягчения

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

Объем и затраты на хранение.] Даже сжатые изображения потребителей складываются. Одна программа по уходу за ранами может генерировать тысячи изображений в месяц. Mitigate, принимая многоуровневую стратегию хранения: часто доступные изображения на быстром SSD (например, исследования менее 90 дней), старые изображения перемещаются на более дешевое хранилище объектов или холодный архив. Кроме того, рассмотрите возможность хранения только клинически значимого подмножества (например, лучшего единственного изображения за посещение), а не всей серии всплесков.

Ответственность и неправильное толкование.] Низкокачественное изображение может привести к ложноотрицательному или ложноположительному. Мититете путем реализации обязательного отказа от ответственности на интерфейсе обзора: «Это изображение было предоставлено пациентом и не было получено в контролируемых условиях. Рекомендуется клиническая корреляция». Установите политику, согласно которой изображения, созданные пациентом, никогда не должны быть единственной основой для диагноза, если явно не подтверждено клиницистом посредством отдельной встречи.

Совместимость с Legacy PACS. Старые PACS могут не принимать объекты вторичного захвата DICOM, у которых отсутствуют определенные требуемые теги. Работа с поставщиком для создания «виртуального модальности», которая отображает входящие исследования, сгенерированные пациентом, на приемлемую схему. Если поставщик не реагирует, решение промежуточного программного обеспечения, которое предварительно заполняет теги с фиктивными данными (а затем вручную исправляет) может быть временным обходным путем.

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

Будущие направления

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

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

Носимые и непрерывные устройства захвата.] Смарт-часы и домашние носимые камеры (например, для непрерывного дерматологического мониторинга) будут генерировать потоковое видео условий кожи или движений глаз. PACS потребуется обрабатывать видеоклипы и последовательности изображений временны́х серий в качестве объектов DICOM Encapsulated CINE или DICOM Watchdog. Стандартные органы, такие как DICOM, уже работают над расширениями для носимых медицинских устройств.

Федерация и облачные PACS.] По мере перехода здравоохранения к многооблачным архитектурам, генерируемые пациентами изображения могут быть непосредственно введены в облачные PACS без локального промежуточного ПО. Это снижает задержку и капитальные затраты, но вызывает новые опасения по поводу суверенитета данных и экспортного контроля. Организации должны вести переговоры об облачных соглашениях, которые соответствуют юрисдикционным правилам.

Переносимость данных, которой владеет пациент.] С ростом HL7 FHIR и открытых API пациенты могут в конечном итоге иметь возможность напрямую загружать изображения из приложения для медицинских записей своего смартфона в PACS без каких-либо посреднических действий со стороны поставщика. Эта парадигма «пациент как источник-актер» тестируется в нескольких пилотных проектах (например, Apple Health Records с DICOM).

Заключение

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