Рекомендации по использованию преобразования данных DICOM в решениях для обработки данных здравоохранения
В этой статье описываются основные моменты, с которыми следует ознакомиться перед использованием возможности преобразования данных DICOM. Понимание этих факторов обеспечивает бесперебойную интеграцию и работу в среде решений для данных здравоохранения. Этот ресурс также поможет вам эффективно ориентироваться в некоторых потенциальных проблемах и ограничениях, связанных с этой возможностью.
Размер файла приема
В настоящее время логический размер файла ZIP ограничен 8 ГБ, а для файлов DCM — 4 ГБ. Если файлы превышают эти ограничения, время выполнения может увеличиться или произойти сбой приема. Мы рекомендуем разбивать ZIP-файлы на более мелкие сегменты (до 4 ГБ), чтобы обеспечить успешное выполнение. Для собственных файлов DCM размером более 4 ГБ обязательно масштабируйте узлы Spark (исполнители) по мере необходимости.
Извлечение тега DICOM
Мы отдаем приоритет продвижению 29 тегов, присутствующих в бронзовой таблице дельта хранилище и озеро данных ImagingDicom по следующим двум причинам:
- Эти 29 тегов имеют решающее значение для общего запроса и исследования данных DICOM, таких как модальность и латеральность.
- Эти теги необходимы для создания и заполнения разностных таблиц серебряного (FHIR) и золотого (OMOP) хранилищ озера данных на последующих этапах выполнения.
Вы можете расширять и продвигать другие интересующие вас теги DICOM. Однако блокноты преобразования данных DICOM не распознают и не обрабатывают автоматически никакие другие столбцы тегов DICOM, которые вы добавляете в дельта-таблицу ImagingDicom в бронзовом хранилище и озеро данных. Дополнительные столбцы нужно обрабатывать самостоятельно.
Присоединение шаблона в бронзовом хранилище озера данных
Все вновь загруженные файлы DCM (или ZIP) добавляются в дельта-таблицу ImagingDicom в бронзовом хранилище и озеро данных. Для каждого успешно принятого файла DCM мы создаем новую запись в дельта-таблице ImagingDicom . Бизнес-логика для операций слияния или обновления на уровне бронзового хранилища озера данных отсутствует.
Таблица изменений ImagingDicom отражает каждый загруженный файл DCM на уровне экземпляра DICOM и должна рассматриваться как таковая. Если тот же файл DCM снова загружается в папку Ingest , мы добавляем еще одну запись в таблицу ImagingDicom delta для того же файла. Однако имена файлов различаются из-за метки времени префикса Unix. В зависимости от даты загрузки файл может быть помещен в другую YYYY\MM\DD папку.
Версия и расширения визуализации OMOP
Текущая реализация золотого хранилища озера данных основана на общей модели данных Сообщества по наблюдению за медицинскими результатами (OMOP) версии 5.4. OMOP пока не имеет нормативного расширения для поддержки данных визуализации. Таким образом, эта возможность реализует расширение, предложенное в Разработка стандартизации данных медицинской визуализации для наблюдательных исследований на основе визуализации: расширение общей модели данных OMOP. Это расширение является последним предложением в области исследований в области визуализации, опубликованным 5 февраля 2024 года. Текущая версия возможности преобразования данных DICOM ограничена таблицей Image_Occurrence в золотом хранилище озера данных.
Структурированная потоковая передача в Spark
Структурированная потоковая передача — это масштабируемый и отказоустойчивый движок потоковой обработки, построенный на движке Spark SQL. Потоковые вычисления можно выразить так же, как пакетные вычисления для статических данных. Система обеспечивает сквозные гарантии отказоустойчивости с помощью контрольных точек и журналов упреждающей записи. Дополнительные сведения о структурированной потоковой передаче см. в руководстве по программированию структурированной потоковой передачи (v3.5.1).
Мы используем ForeachBatch для обработки добавочных данных. Этот метод применяет произвольные операции и записывает логику на выходе потокового запроса. Запрос выполняется для выходных данных каждого микропакета потокового запроса. В возможности преобразования данных DICOM структурированная потоковая передача используется на следующих этапах выполнения:
| Этап выполнения | Расположение папки контрольной точки | Отслеживаемые объекты |
|---|---|---|
| Извлечение метаданных DICOM в бронзовый хранилище озера данных | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_metadata_extraction |
Файлы DCM в бронзе хранилище и озеро данных под Files\Process\Imaging\DICOM\YYYY\MM\DD. |
| Преобразуйте метаданных DICOM в формат FHIR | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Дельта-таблица ImagingDicom в бронзе хранилище и озеро данных. |
| Прием данных в разностную таблицу ImagingStudy в бронзовом хранилище озера данных | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
Файлы FHIR NDJSON отмечены бронзовым хранилище и озеро данных под Files\Process\Clinical\FHIR NDJSON\YYYY\MM\DD\ImagingStudy. |
| Прием данных в разностную таблицу ImagingStudy в серебряном хранилище озера данных | healthcare#.HealthDataManager\DMHCheckpoint\<silverlakehouse>\ImagingStudy |
Разностная таблица ImagingStudy в бронзовом хранилище озера данных. |
Совет
Вы можете использовать проводник OneLake для просмотра содержимого файлов и папок, перечисленных в таблице. Дополнительные сведения см. в разделе Использование проводника OneLake.
Групповой шаблон в бронзовом хранилище озера данных
Групповые шаблоны применяются при загрузке новых записей из дельта-таблицы ImagingDicom в бронзовом хранилище и озеро данных в дельта-таблицу ImagingStudy в бронзовом хранилище и озеро данных. Возможность преобразования данных DICOM группирует все записи уровня экземпляра в дельта-таблице ImagingDicom по уровню исследования. Он создает одну запись для каждого исследования DICOM в качестве ImagingStudy, а затем вставляет запись в разностную таблицу ImagingStudy в бронзовом хранилище озера данных.
Шаблон upsert в серебряном хранилище озера данных
Операция upsert сравнивает таблицы дельта FHIR между бронзовыми и серебряными домами на основе {FHIRResource}.id:
- Если совпадение обнаружено, серебряная запись обновляется новой бронзовой записью.
- Если совпадений не обнаружено, бронзовая запись вставляется как новая запись в серебряный хранилище озера данных.
Мы используем этот шаблон для создания ресурсов в серебряной таблице хранилище и озеро данных ImagingStudy .
Ограничения ImagingStudy
Операция upsert работает должным образом, когда вы принимаете файлы DCM из одного и того же исследования DICOM в одном пакетном выполнении. Однако если вы позже добавите больше файлов DCM (из другого пакета), которые относятся к тому же исследованию DICOM, которое ранее было добавлено в серебряный файл хранилище и озеро данных, добавление приведет к операции Вставки . Процесс не выполняет операцию Обновления .
Эта операция вставки выполняется, поскольку блокнот создает новый {FHIRResource}.id для ImagingStudy при каждом выполнении пакета. Этот новый ИД не совпадает с ИД в предыдущем пакете. В результате вы увидите две записи ImagingStudy в серебряной таблице с разными ImagingStudy.id значениями. Эти ИД связаны с соответствующими пакетными выполнениями, но принадлежат к одному и тому же исследованию DICOM.
В качестве обходного пути выполните пакетное выполнение и объедините две записи ImagingStudy в серебряном хранилище озера данных на основе комбинации уникальных идентификаторов. Однако не используйте ImagingStudy.id для слияния. Вместо этого вы можете использовать другие идентификаторы, такие как [studyInstanceUid (0020,000D)] и [patientId (0010,0020)] для объединения записей.
Подход к отслеживанию OMOP
Блокнот healthcare#_msft_omop_silver_gold_transformation использует OMOP API для отслеживания изменений в дельта-таблице серебра хранилище и озеро данных. Он выявляет вновь измененные или добавленные записи, которые требуют обновления в разностных таблицах золотого хранилища озера данных. Этот процесс называется Нанесение водяных знаков.
API OMOP сравнивает значения даты и времени между {Silver.FHIRDeltatable.modified_date} и {Gold.OMOPDeltatable.SourceModifiedOn} для определения добавочных записей, которые были изменены или добавлены с момента последнего выполнения записной книжки. Однако этот OMOP подход к отслеживанию применим не ко всем разностным таблицам в золотом хранилище озера данных. Следующие таблицы не принимаются из разностной таблицы в серебряном хранилище озера данных:
- концепция
- concept_ancestor
- concept_class
- concept_relationship
- concept_synonym
- fhir_system_to_omop_vocab_mapping
- словарь
Эти золотые дельта-таблицы заполняются с использованием словарных данных, включенных в OMOP пример развертывания данных. Управление набором данных словаря в этой папке осуществляется с помощью структурированной потоковой передачи в Spark.
Шаблон upsert в золотом хранилище озера данных
Шаблон upsert в золотом хранилище озера данных отличается от серебряного хранилища озера данных. OMOP API, используемый блокнотом healthcare#_msft_omop_silver_gold_transformation , создает новые идентификаторы для каждой записи в дельта-таблицах золота хранилище и озеро данных. API создает эти ИД при приеме или преобразовании новых записей из серебряного хранилища озера данных в золотое. API OMOP также поддерживает внутренние сопоставления между вновь созданными идентификаторами и соответствующими им внутренними идентификаторами в разностной таблице silver lakehouse.
API работает следующим образом:
При первом преобразовании записи из серебряной разностной таблицы в золотую создается новый идентификатор в OMOP золотом хранилище озера данных и сопоставляется с исходным новым ИД в серебряном хранилище озера данных. Затем он вставляет запись в золотую разностную таблицу с новым сгенерированным ИД.
Если та же запись в серебряном хранилище озера данных претерпевает некоторые изменения и снова принимается в золотое хранилище озера данных, OMOP API распознает существующую запись в золотом хранилище озера данных (используя информацию о сопоставлении). Затем он обновляет записи в золотом хранилище озера данных с тем же ИД, который был сгенерирован ранее.
Сопоставления между вновь созданными ИД (ADRM_ID) в золотом хранилище озера данных и исходными ИД (INTERNAL_ID) для каждой разностные таблицы OMOP хранятся в паркетных файлах OneLake. Файлы .parquet можно найти по следующему пути:
[OneLakePath]\[workspace]\healthcare#.HealthDataManager\DMHCheckpoint\dtt\dtt_state_db\KEY_MAPPING\[OMOPTableName]_ID_MAPPING
Вы также можете запросить файлы .parquet в записной книжке Spark, чтобы просмотреть сопоставление.
Дизайн ImagingMetastore в серебряном цвете хранилище и озеро данных
Один файл DICOM может содержать до 5000 отдельных тегов, что делает неэффективным и ресурсоемким сопоставление и создание полей для всех этих тегов в серебряном файле хранилище и озеро данных. Однако сохранение доступа к полному набору тегов имеет важное значение для предотвращения потери данных и поддержания гибкости, особенно если вам требуются теги, выходящие за рамки 29 извлеченных и представленных в модели данных. Чтобы решить эту проблему, серебряная таблица дельта хранилище и озеро данных ImagingMetastore сохраняет все теги DICOM в столбце metadata_string . Эти теги представлены в виде пар «ключ-значение» в строковом формате JSON, что позволяет эффективно выполнять запросы с помощью аналитики SQL конечная точка. Такой подход соответствует стандартным практикам управления сложными данными JSON во всех полях серебряного хранилище и озеро данных.
Из таблицы ImagingDicom в бронзовом хранилище и озеро данных в таблицу ImagingMetastore в серебряном хранилище и озеро данных преобразование не выполняет никакой группировки. В обеих таблицах ресурсы представлены на уровне экземпляра. Однако {FHIRResource}.id включен в таблицу ImagingMetastore . Это значение позволяет вам запрашивать все артефакты уровня экземпляра, связанные с определенным исследованием, ссылаясь на его уникальный идентификатор.
Интеграция с службой DICOM
Текущая интеграция между возможностью преобразования данных DICOM и службой DICOM Azure для работы с медицинскими данными поддерживает только события Создать и Обновить. Вы можете создавать новые исследования, серии и примеры визуализации или даже обновлять существующие. Однако интеграция пока не поддерживает удаление событий. При удалении исследования, серии или экземпляра в службе DICOM возможность преобразования данных DICOM не отражает это изменение. Данные изображения остаются неизменными и не удаляются.
Предупреждения таблицы
Предупреждения появляются для всех таблиц в каждом хранилище и озеро данных, где один или несколько столбцов используют сложные объектно-ориентированные типы данных для представления данных. В таблицах ImagingDicom и ImagingMetastore столбец metadata_string использует структуру JSON для сопоставления тегов DICOM как пар ключ-значение. Такая конструкция учитывает ограничение конечных точек Fabric SQL, которые не поддерживают сложные типы данных, такие как структуры, массивы и карты. Вы можете запрашивать эти столбцы как строки, используя SQL конечная точка (T-SQL), или работать с их собственными типами (структурами, массивами, картами), используя Spark.
