Архитектуру данных и управление в решениях для данных здравоохранения в Microsoft Fabric
Платформа решений для данных здравоохранения использует специализированную архитектуру медальона для оптимизации организации и обработки данных. Такая конструкция обеспечивает постоянное улучшение качества и структуры данных, позволяя более эффективно управлять данными здравоохранения. В этой статье рассматриваются ключевые особенности и преимущества этой архитектуры, а также дается всесторонний обзор того, как осуществляется управление данными в рамках этой платформы.
Дизайн хранилища озера данных медальона
Как поясняется в архитектуре решения, решения для данных здравоохранения используют архитектуру озера данных медальона для организации и обработки данных на нескольких уровнях. По мере того, как данные проходят через каждый слой, их структура и качество постоянно улучшаются. По своей сути дизайн хранилища озера данных медальона в решениях для данных здравоохранения состоит из следующих хранилищ озера данных:
Бронзовое хранилище озера данных: также называемый необработанной зоной, бронзовый хранилище озера данных является первым слоем, который организует исходные данные в исходном формате файла. Он принимает исходные файлы в OneLake и/или создает ярлыки из собственных источников хранилища. Кроме того, структурированные и полуструктурированные данные из источника хранятся в разностных таблицах, называемых промежуточными таблицами. Эти таблицы сжаты и индексированы по столбцам для поддержки эффективных преобразований и обработки данных. Данные на этом уровне, как правило, доступны только для добавления и являются неизменяемыми.
Файлы в бронзовом хранилище озера данных (как сохраненные, так и ярлыки) служат источником истинных данных. Они закладывают основу для происхождение данных по всему пространству данных в решениях для данных здравоохранения. Промежуточные таблицы в бронзовом слое обычно состоят из нескольких столбцов и предназначены для хранения данных каждого типа и формата в одной таблице (например, таблиц ClinicalFhir и ImagingDicom). Не следует расширять, настраивать или создавать зависимости на этих промежуточных таблицах в бронзовом хранилище озера данных по следующим причинам:
- Внутренняя реализация: промежуточные таблицы реализуются специально для решений для данных здравоохранения в Microsoft Fabric. Их схема специально разработана для решений для данных здравоохранения и не соответствует какому-либо отраслевому или общественному стандарту данных.
- Временное хранилище: после обработки данных и преобразования их из промежуточных таблиц бронзового хранилища озера данных в плоскую и нормализованную структуру разностных таблиц в серебряном хранилище озера данных данные бронзовой промежуточной таблицы считаются готовыми к очистке. Эта модель обеспечивает экономичность и эффективность хранения, а также снижает избыточность данных между исходными файлами и промежуточными таблицами в бронзовом хранилище озера данных.
Серебряное хранилище озера данных: также называемый обогащенной зоной, серебряный хранилище озера данных очищает данные из бронзового хранилища озера данных. Он включает в себя проверки и методы обогащения для повышения точности данных для последующей аналитики. В отличие от бронзового хранилища озера данных, данные серебряного хранилища озера данных используют правила, основанные на детерминированных идентификаторах и метках времени модификаций, для управления вставками и обновлениями записей.
Золотое хранилище озера данных: также называемый отобранной зоной, золотой хранилище озера данных дополнительно уточняет данные из серебряного хранилища озера данных в соответствии с конкретными деловыми и аналитическими требованиями. Этот слой служит основным источником высококачественных агрегированных наборов данных, готовых к всестороннему анализу и извлечению информации. В то время как решения для данных здравоохранения развертывают один бронзовый и один серебряный хранилище озера данных для каждого развертывания, вы можете использовать несколько золотых хранилищ озера данных для обслуживания различных подразделений и пользователей.
Хранилище озера данных администратора: хранилище озера данных администратора содержит файлы для управления данными и отслеживаемости на уровнях озера данных, включая ошибки глобальной конфигурации и проверки, хранящиеся в таблице BusinessEvent. Чтобы узнать больше, см. раздел хранилище озера данных администратора.
Единая структура папок
Клиенты из сферы здравоохранения и медико-биологических наук имеют дело с огромными объемами данных из различных исходных систем, в различных модальностях данных и форматах файлов, включая следующие форматы файлов:
- Клиническая модальность: файлы FHIR NDJSON, пакеты FHIR и HL7.
- Методы визуализации: DICOM, NIFTI и NDPI.
- Модальность геномики: BAM, BCL, FASTQ и VCF.
- Требования: CCLF и CSV-файл.
Где:
- FHIR: ресурсы быстрого взаимодействия в сфере здравоохранения
- HL7: седьмой уровень здоровья международный
- DICOM: цифровая визуализация и коммуникации в медицине
- NIFTI: технологическая инициатива в области нейровизуализации информатики
- NDPI: визуализация наноразмерной патологии
- BAM: двоичный карта выравнивания
- BCL: базовый вызов
- FASTQ: текстовый формат для хранения биологической последовательности и соответствующих ей оценок качества
- VCF: формат определения варианта
- CCLF: требование и перевод строки требования
- CSV: значения с разделителями-запятыми
OneLake в Microsoft Fabric предлагает логическое хранилище озера данных для вашей организации. Решения для данных здравоохранения в Microsoft Fabric обеспечивают единую структуру папок, которая помогает упорядочивать данные в различных модальностях и форматах. Эта структура оптимизирует прием и обработку данных, сохраняя при этом происхождение данных на уровнях исходного файла и исходной системы в бронзовом хранилище озера данных.
Шесть папок верхнего уровня включают в себя:
- Внешняя.
- Отклонено
- Прием
- Обработка
- ReferenceData
- SampleData
Вложенные папки организованы следующим образом:
Files\Ingest\[DataModality]\[DataFormat]\[Namespace]Files\External\[DataModality]\[DataFormat]\[Namespace]\[BYOSShortcutname]\Files\SampleData\[DataModality]\[DataFormat]\[Namespace]\Files\ReferenceData\[DataModality]\[DataFormat]\[Namespace]\Files\Failed\[DataModality]\[DataFormat]\[Namespace]\YYYY\MM\DDFiles\Process\[DataModality]\[DataFormat]\[Namespace]\YYYY\MM\DD
Описания папки
Пространство имен (обязательный): определяет исходную систему для полученных файлов, что имеет решающее значение для обеспечения уникальности идентификатора для каждой исходной системы.
Папка приема: функционирует как папка перетаскивания или очереди. Эта папка позволяет перетаскивать файлы для приема в соответствующие вложенные папки модальности и форматирования. После начала приема файлы передаются в соответствующую папку Процесс или в папку Отклонено для сбоев.
Папка обработки: конечный пункт назначения для всех успешно обработанных файлов в каждой комбинации модальностей и форматов. Эта папка соответствует шаблону
YYYY/MM/DD, основанному на дате обработки. Секционирование папок соответствует рекомендациям по использованию Azure Data Lake Storage для улучшения организации, фильтрации поиска, автоматизации и возможной параллельной обработки.Внешняя папка: служит родительской папкой для папок ярлыков BYOS (Использовать собственное хранилище). Развертывание по умолчанию обеспечивает предлагаемую структуру папок для требований, клинических, геномных и визуализационных модальностей. Визуализационные и клинические модальности имеют форматы и пространства имен по умолчанию, настроенные для поддержки служб DICOM и FHIR в Службы Azure для данных здравоохранения. Этот формат применяется только в том случае, если вы собираетесь быстро передавать данные в OneLake. Решения для данных здравоохранения в Microsoft Fabric имеют доступ только для чтения к файлам в этих папках ярлыков.
Папка "Отклонено": в случае сбоя при перемещении или обработке файлов в папках Прием или Обработка затронутые файлы перемещаются в папку Отклонено в соответствии с их модальностью и сочетанием форматов. Ошибка регистрируется в таблице BusinessEvent в хранилище озера данных администратора. Эта папка использует шаблон
YYYY/MM/DD, основанному на дате обработки/сбоя. Файлы в этой папке не удаляются и остаются здесь до тех пор, пока вы не исправите и не повторите их прием, используя тот же исходный шаблон приема.Папка "Демонстрационные данные": содержит синтетические, справочные и/или общедоступные наборы данных. Развертывание по умолчанию предоставляет демонстрационные данные для нескольких комбинаций модальностей и форматов, чтобы упростить немедленное выполнение записных книжек и конвейеров после развертывания. В этой папке не создаются вложенные папки
YYYY/MM/DD.Папка "Справочные данные": содержит справочные и родительские наборы данных из общедоступных или пользовательских источников. В этой папке не создаются вложенные папки
YYYY/MM/DD. Развертывание по умолчанию предоставляет предлагаемую структуру папок для OMOP словарей (Сообщество по наблюдению за медицинскими результатами).
Шаблоны приема данных
Основываясь на единой структуре папок, описанной ранее, решения Microsoft Fabric для данных здравоохранения поддерживают два различных шаблона приема. В обоих случаях решения используют структурированную потоковую передачу в Spark для обработки входящих файлов в соответствующих папках.
Шаблон приема
Этот шаблон представляет собой простой подход, при котором файлы для приема перетаскиваются в папку Прием с соответствующей модальностью, форматом и пространством имен. Конвейеры приема отслеживают в этой папке новые файлы и перемещают их в соответствующую папку Обработка для обработки. Если прием данных файла в промежуточную таблицу бронзового хранилища озера данных прошел успешно, файл сжимается и сохраняется с префиксом метки времени в папке Обработка в соответствии с шаблоном YYYY/MM/DD, основанным на времени обработки. Этот префикс обеспечивает уникальные имена файлов. При необходимости сжатие можно настроить или отключить.
Если обработка файлов завершается сбоем, файлы, завершившиеся сбоем, перемещаются из папки Прием в папку Отклонено для каждой комбинации модальности и формата, а ошибка регистрируется в таблице BusinessEvent в хранилище озера данных администратора.
Этот шаблон приема идеально подходит для ежедневных добавочных приемов или при физическом перемещении данных в Azure Data Lake Storage или OneLake.
Шаблон "Использовать собственное хранилище данных" (BYOS)
Иногда данные и файлы уже присутствуют в Azure или других облачных хранилищах с существующими последующими реализациями и зависимостями от этих файлов. В сферы здравоохранения и медико-биологических наук объемы данных могут достигать нескольких терабайт или даже петабайт, особенно для медицинской визуализации и геномики. По этим причинам шаблон прямого приема может оказаться невыполнимым.
Мы рекомендуем использовать шаблон BYOS для приема исторических данных, если у вас уже есть значительные объемы данных, доступные в Azure или другом облачном и локальном хранилище, поддерживающем протокол S3. Этот шаблон использует сочетания клавиш OneLake в Fabric и папку Внешние в бронзовом хранилище озера данных для обработки исходных файлов на месте. Это устраняет необходимость перемещать или копировать файлы, а также позволяет избежать платы за исходящий трафик и дублирования данных.
Несмотря на эффективность, обеспечиваемую шаблоном приема BYOS, следует учитывать следующие моменты.
- Обновления файлов на месте (обновления содержимого в файле) не отслеживаются. Ожидается, что вы создадите новый файл (с другим именем) для всех обновлений, так как конвейер приема отслеживает только новые файлы. Это ограничение связано со структурированной потоковой передачей в Spark.
- Сжатие данных не применяется.
- Шаблон BYOS не создает какой-либо оптимизированной структуры папок на основе шаблона
YYYY/MM/DD. - Если обработка файла завершается сбоем, файлы, завершившиеся сбоем, не перемещаются в папку Отклонено. Однако ошибка регистрируется в таблице BusinessEvent в хранилище озера данных администратора.
- Предполагается, что исходные данные доступны только для чтения.
- Нет никакого контроля над происхождением или доступностью исходных данных после приема.
Сжатие данных
Решения для данных здравоохранения в Microsoft Fabric поддерживают сжатие по проекту во всем дизайне озера данных медальона. Данные, поступающие в разностные таблицы по всему хранилищу озера данных медальона, хранятся в сжатом столбчатом формате с использованием файлов .parquet. В шаблоне приема, когда файлы перемещаются из папки Прием в папку Обработка, они по умолчанию сжимаются после успешной обработки. При необходимости сжатие можно настроить или отключить. Что касается возможностей создания образов и утверждений, конвейеры приема также могут обрабатывать необработанные файлы в сжатом формате ZIP.
Модель данных здравоохранения
Как описано в дизайн хранилища озера данных медальона, промежуточные таблицы бронзового хранилища озера данных реализуют специально созданные таблицы для решений для данных здравоохранения и не соответствуют каким-либо отраслевым или общественным стандартам данных.
Модель данных здравоохранения в серебряном хранилище озера данных основана на стандарте FHIR R4. Он предоставляет аналитикам данных, специалистам по обработке и анализу данных и разработчикам общий язык данных для совместной работы и создания решений на основе данных, которые улучшают результаты лечения пациентов и эффективность бизнеса. Он поддерживает данные из различных областей здравоохранения, таких как клиническая, административная, финансовая и социальная. Модель данных здравоохранения собирает данные, определенные стандартом FHIR, и упорядочивает ресурсы FHIR с помощью таблиц и столбцов в хранилище озера данных.
Путем сведения данных FHIR в разностные паркетные таблицы можно использовать знакомые инструменты, такие как T-SQL и Spark SQL для исследования и анализа данных. Для доклинических данных, выходящих за рамки FHIR, мы используем схемы из шаблонов баз данных Azure Synapse. Эта реализация позволяет интегрировать неклиническую информацию, такую как данные о взаимодействии с пациентами, в профиль пациента.
Модель данных здравоохранения в серебряном хранилище озера данных предназначена для представления комплексного представления корпоративных данных здравоохранения в бизнес-подразделениях и исследовательских областях.
Происхождение данных и прослеживаемость
Чтобы обеспечить происхождение и прослеживаемость на уровне записей и файлов, таблицы модели данных здравоохранения включают следующие столбцы:
| Столбец | Описание |
|---|---|
msftCreatedDatetime |
Метка времени, когда запись была впервые создана в серебряном хранилище озера данных. |
msftModifiedDatetime |
Метка времени последнего изменения записи. |
msftFilePath |
Полный путь к исходному файлу в бронзовом хранилище озера данных, включая ярлыки. |
msftSourceSystem |
Исходная система записи, соответствующая Namespace указанной в единой структуре папок. |
Если поле нормализовано, сведено или изменено, исходное значение сохраняется в {columnName}Orig столбце. Например, в таблице серебряного хранилища озера данных Пациент можно найти следующие столбцы:
| Столбец | Описание |
|---|---|
meta_lastUpdatedOrig |
Сохраняет исходное значение в необработанном формате (строка или дата) и сохраняет его как дату и время. |
idOrig и identifierOrig |
Коды и идентификаторы гармонизированы в серебряном хранилище озера данных. |
birthdateOrig и deceasedDateTimeOrig |
Сохраняет исходные значения даты с другим форматированием меток времени. |
Если столбец сводится (например, meta_lastUpdated) или преобразуется в строку (например, meta_string), мы обозначаем его с помощью суффикса, начинающегося с подчеркивания (_).
Обработка обновления
При приеме новых данных из бронзового в серебряный хранилище озера данных операция обновления сравнивает входящие записи с целевыми таблицами в серебряном хранилище озера данных для каждого ресурса и типа таблицы. Для таблиц FHIR в серебряном хранилище озера данных это сравнение сверяет оба значения {FHIRResource}.id и {FHIRResource}.meta_lastUpdated со столбцами id и lastUpdated в промежуточной таблице бронзового хранилища озера данных ClinicalFhir.
- Если совпадение обнаружено и входящая запись новая, серебряная запись обновляется.
- Если входящая запись устарела, серебряная запись игнорируется.
- Если совпадений не найдено, новая запись вставляется в серебряный хранилище озера данных.
Хранилище озера данных администратора
Хранилище озера данных администратора управляет конфигурацией между озерами данных, глобальной конфигурацией, отчетами о состоянии и отслеживанием решений для данных здравоохранения в Microsoft Fabric.
Глобальная конфигурация
Папка system-configurations озера данных администратора централизует параметры глобальной конфигурации. Три файла конфигурации содержат предварительно настроенные значения для развертывания по умолчанию всех возможностей решений для данных здравоохранения. Вам не нужно перенастраивать какие-либо из этих значений для запуска демонстрационных данных или конвейеров данных для любой возможности.
Файл deploymentParametersConfiguration.json содержит глобальные параметры в разделе activitiesGlobalParameters и параметры для конкретных действий для записных книжек и конвейеров в activities. В руководстве по соответствующим возможностям содержатся конкретные сведения о конфигурации каждой возможности. Параметры файла validation_config.json описаны в разделе Проверка данных.
В следующей таблице перечислены все параметры глобальной конфигурации.
| Раздел | Параметры конфигурации |
|---|---|
activitiesGlobalParameters |
•administration_lakehouse_id: идентификатор озера данных администратора.• bronze_lakehouse_id: идентификатор бронзового хранилища озера данных.• silver_lakehouse_id: идентификатор серебряного хранилища озера данных.• keyvault_name: значение Azure Key Vault при развертывании с предложением Azure Marketplace.• enable_hds_logs: включение ведения журнала; значение по умолчанию установлено в значение true.• movement_config_path: путь к файлу file_orchestration_config.• bronze_imaging_delta_table_path: путь к структуре для таблицы модальностей визуализации (если она развернута).• bronze_imaging_table_schema_path: путь к структуре для схемы модальностей визуализации (если она развернута).• omop_lakehouse_id: идентификатор золотого хранилища озера данных (если развернута). |
| Мероприятия для healthcare#_msft_fhir_ndjson_bronze_ingestion | •source_path_pattern: путь OneLake к папке Обработка.• move_failed_files_enabled: установите флажок, определяющий, следует ли переместить файл, в котором произошел сбой, из папки Прием в папку Отклонено.• compression_enabled: флаг, определяющий, будут ли необработанные файлы NDJSON сжаты после обработки.• target_table_name: название таблицы приема клинических данных в бронзовом хранилище озера данных.• target_tables_path: путь OneLake для всех разностных таблиц в бронзовом хранилище озера данных.• max_files_per_trigger: количество файлов, обрабатываемых при каждом запуске.• max_structured_streaming_queries: количество запросов к обработке, которые могут выполняться параллельно.• checkpoint_path: путь OneLake к папке контрольной точки.• schema_dir_path: путь OneLake к папке бронзовой схемы.• validation_config_key: конфигурация проверки родительского уровня. Дополнительные сведения см. в разделе Проверка данных.• file_extension: расширение принимаемого необработанного файла. |
| Мероприятия для healthcare#_msft_bronze_silver_flatten | •source_table_name: название таблицы приема клинических данных в бронзовом хранилище озера данных.• config_path: путь OneLake к сведенному файл конфигурации.• source_tables_path: путь OneLake к исходным разностным таблицам в бронзовом хранилище озера данных.• target_tables_path: путь OneLake к целевым разностным таблицам в серебряном хранилище озера данных.• checkpoint_path: путь OneLake к папке контрольной точки.• schema_dir_path: путь OneLake к папке бронзовой схемы.• max_files_per_trigger: количество файлов, обрабатываемых при каждом запуске.• max_bytes_per_trigger: количество байтов, обрабатываемых при каждом запуске.• max_structured_streaming_queries: количество запросов к обработке, которые могут выполняться параллельно. |
| Мероприятия для healthcare#_msft_imaging_dicom_extract_bronze_ingestion | •byos_enabled: флаг, определяющий, является ли принимаемый набор данных визуализации DICOM в бронзовом хранилище озера данных из внешнего хранилища с помощью ярлыков OneLake. В этом случае файлы не перемещаются в папку Обработка, как это было бы в противном случае.• external_source_path: путь OneLake для папки ярлыков Внешняя в бронзовом хранилище озера данных.• process_source_path: путь OneLake для папки ярлыков Обработка в бронзовом хранилище озера данных.• checkpoint_path: путь OneLake к папке контрольной точки.• move_failed_files: флаг, определяющий, если файл, в котором произошел сбой, перемещается из папки Прием в папку Отклонено.• compression_enabled: флаг, определяющий, если необработанные файлы NDJSON сжимаются после обработки.• max_files_per_trigger: количество файлов, обрабатываемых при каждом запуске.• num_retries: количество повторных попыток для каждой обработки файла до возникновения ошибки. |
| Мероприятия для healthcare#_msft_imaging_dicom_fhir_conversion | •fhir_ndjson_files_root_path: путь OneLake к папке Обработка.• avro_schema_path: путь OneLake к папке серебряной схемы.• dicom_to_fhir_config_path: путь OneLake для конфигурации сопоставления от метатегов DICOM к ресурсу FHIR ImagingStudy.• checkpoint_path: путь OneLake к папке контрольной точки.• max_records_per_ndjson: количество записей, обработанных в одном файле NDJSON за один запуск.• subject_id_type_code: код значения медицинского номера пациента в метаданных DICOM. По умолчанию установлено значение MR, что соответствует Medical Record Number в FHIR.• subject_id_type_code_system: система кода для медицинского номера пациента в метаданных DICOM.• subject_id_system: ИД объекта для системы кода для медицинского номера пациента в метаданных DICOM. |
| Мероприятия для healthcare#_msft_omop_silver_gold_transformation | •vocab_path: путь OneLake к папке справочных данных в бронзовом хранилище озера данных, где хранятся наборы данных словаря OMOP.• vocab_checkpoint_path: путь OneLake к папке контрольной точки.• omop_config_path: путь OneLake для конфигурации сопоставления от серебряного хранилища озера данных к золотому хранилищу озера данных OMOP. |
Таблица BusinessEvents
В разностной таблице BusinessEvents фиксируются все ошибки проверки, предупреждения и другие уведомления или исключения, которые могут возникнуть во время процессов приема и преобразования. Используйте эту таблицу для отслеживания хода выполнения приема как на уровне пользователя, так и на функциональном уровне, а не только на уровне системного журнала. Например, он определяет, какие необработанные файлы привели к ошибкам проверки или предупреждениям во время приема. Для ведения журналов системного уровня и мониторинга Apache Spark действий во всех озерах данных можно использовать центр мониторинга структуры с возможностью интеграции Azure Log Analytics.
В следующей таблице перечислены столбцы таблицы BusinessEvent:
| Столбец | Описание |
|---|---|
id |
Уникальный идентификатор (GUID) каждой строки в таблице. |
activityName |
Имя действия/записной книжки, вызвавшей сбой и/или ошибку проверки или предупреждение. |
targetTableName |
Целевая таблица для действия данных, создавшего событие. |
targetFilePath |
Путь для целевого файла для действия данных, создавшего событие. |
sourceTableName |
Исходная таблица для действия данных, создавшего событие. |
sourceLakehouseName |
Исходная хранилище озера данных для действия данных, создавшего событие. |
targetLakehouseName |
Целевое хранилище озера данных для действия данных, создавшего событие. |
sourceFilePath |
Путь для исходного файла для действия данных, создавшего событие. |
runId |
ИД выполнения для действия данных, создавшего событие. |
severity |
Уровень серьезности события, который может иметь одно из следующих двух значений: Error или Warning. Error означает, что необходимо разрешить это событие, прежде чем продолжить действие с данными. Warning служит пассивным уведомлением, как правило, не требующим немедленных действий. |
eventType |
Проводит различие между событиями, сгенерированными механизмом проверки, и общими событиями, сгенерированными пользователями или необработанными/системные исключения, которые пользователи хотят отображать в таблице BusinessEvent. |
recordIdentifier |
Идентификатор исходной записи. Этот столбец отличается от предыдущего id тем, что представляет собой новый и уникальный идентификатор для каждого события в таблице BusinessEvents. |
recordIdentifierSource |
Исходная система для идентификатора исходной записи. Например, если исходной системой является EMR, то в качестве источника используется имя или URL-адрес EMR. |
active |
Флаг, указывающий, разрешено ли событие (ошибка или предупреждение). |
message |
Описательное сообщение об ошибке или предупреждении о событии. |
exception |
Сообщение о необработанном/системном исключении. |
customDimensions |
Применяется, когда исходные данные проверки или исключения не являются дискретным столбцом в таблице. Например, если исходные данные являются атрибутом в объекте JSON, сохраненным в виде строки в одном столбце, в качестве пользовательского измерения предоставляется полный объект JSON. |
eventDateTime |
Метка времени, с которой создается событие или исключение. |
Проверка данных
Механизм проверки данных в решениях для данных здравоохранения в Microsoft Fabric гарантирует, что необработанные данные соответствуют заранее определенным критериям перед их приемом в бронзовый хранилище озера данных. Вы можете настроить правила проверки на уровне таблицы и столбцов в бронзовом хранилище озера данных. В настоящее время эти правила реализуются исключительно в процессе приема, от необработанных файлов до разностных таблиц в бронзовом хранилище озера данных.
При обработке необработанного файла правила проверки применяются на уровне приема. Существует два уровня серьезности для проверки: Error и Warning. Если для правила проверки задано значение Error, конвейер останавливается при нарушении правила, а неисправный файл перемещается в папку Отклонено. Если задано Warning значение серьезности, конвейер продолжает обработку, и файл перемещается в папку Обработка. В обоих случаях записи, отражающие ошибки или предупреждения, создаются в таблице BusinessEvents в хранилище озера данных администратора.
В таблице BusinessEvents хранятся журналы и события бизнес-уровня по всем озерам для любого действия, записной книжки или конвейера данных в решениях для данных здравоохранения. Однако текущая конфигурация применяет правила проверки только во время приема, что может привести к тому, что некоторые столбцы в таблице BusinessEvents останутся незаполненными из-за ошибок и предупреждений проверки.
Вы можете настроить правила проверки данных в файле validation_config.json в хранилище озера данных администратора. По умолчанию столбцы meta.lastUpdated и id в таблице ClinicalFhir бронзового хранилища озера данных установлены так, как требуется. Эти столбцы имеют решающее значение для определения того, как осуществляется управление обновлениями и вставками в серебряном хранилище озера данных, как описано в разделе Обработка обновлений.
В следующей таблице перечислены параметры конфигурации для проверки данных:
| Тип конфигурации | Параметры |
|---|---|
| Уровень озера данных | bronze: область проверок и узлов идентификатора записей. В этом случае значение устанавливается на бронзовое хранилище озера данных. |
| Проверки | •validationType: тип проверки exists проверяет, указано ли значение настроенного атрибута в необработанном файле (исходных данных).• attributeName: имя проверяемого атрибута.• validationMessage: сообщение с описанием ошибки проверки или предупреждения.• severity: указывает уровень проблемы, который может быть Error или Warning.• tableName: имя проверяемой таблицы. Звездочка (*) означает, что это правило применяется ко всем таблицам в области этого озера данных. |
recordIdentifier |
•attributeName: идентификатор записи исходного/необработанного файла, помещенный в recordIdentifier столбец таблицы BusinessEvent.• jsonPath: необязательное значение, представляющее путь JSON к столбцу или атрибуту для значения, которое будет помещено recordIdentifier столбец в таблице BusinessEvent. Это значение применяется, когда исходные данные для проверки не являются дискретным столбцом в таблице. Например, если исходные данные являются атрибутом в объекте JSON, хранящемся в виде строки в одном столбце, путь JSON ведет к определенному атрибуту, который служит идентификатором записи. |