Microsoft Fabric의 의료 데이터 솔루션에서 데이터 아키텍처 및 관리

의료 데이터 솔루션 프레임워크는 특수한 메달리온 아키텍처를 사용하여 데이터 구성 및 처리를 간소화합니다. 이 설계는 데이터 품질 및 구조의 지속적인 개선을 보장하여 의료 데이터를 보다 효과적으로 관리할 수 있도록 합니다. 이 문서에서는 이 아키텍처의 주요 기능과 이점을 살펴보고 이 프레임워크 내에서 데이터를 관리하는 방법에 대한 포괄적인 개요를 제공합니다.

메달리온 레이크하우스 디자인

솔루션 아키텍처에서 설명한 대로, 의료 데이터 솔루션은 메달리온 레이크하우스 아키텍처를 사용하여 여러 계층에 걸쳐 데이터를 구성하고 처리합니다. 데이터가 각 계층을 통과함에 따라 구조와 품질이 지속적으로 개선됩니다. 의료 데이터 솔루션의 메달리온 레이크하우스 설계의 핵심은 다음과 같은 주요 레이크하우스로 구성됩니다.

• 브론즈 레이크하우스: raw 영역이라고도 불리는 브론즈 레이크하우스는 원본 데이터를 원본 파일 형식으로 구성하는 첫 번째 레이어입니다. 원본 파일을 OneLake로 수집하거나 기본 스토리지 원본에서 바로 가기를 만듭니다. 또한 소스의 구조화되고 반구조화된 데이터를 델타 테이블(스테이징 테이블이라고도 함)에 저장합니다. 이러한 테이블은 효율적인 변환 및 데이터 처리를 지원하기 위해 압축되고 열 형식으로 인덱싱됩니다. 이 계층의 데이터는 일반적으로 추가 전용이며 변경할 수 없습니다.

  브론즈 레이크하우스의 파일(영구 또는 바로 가기)은 진실의 원천 역할을 합니다. 의료 데이터 솔루션의 전체 데이터 자산에 걸쳐 데이터 계보의 기반을 마련합니다. 브론즈 레이어의 스테이징 테이블은 일반적으로 몇 개의 열로 구성되며 각 데이터 모달리티와 형식을 단일 테이블(예: ClinicalFhir 및 ImagingDicom 테이블)에 보관하도록 설계되었습니다. 다음과 같은 이유로 브론즈 레이크하우스에서 이러한 스테이징 테이블에 대한 종속성을 확장, 사용자 지정 또는 빌드해서는 안 됩니다.

  • 내부 구현: 스테이징 테이블은 Microsoft Fabric의 의료 데이터 솔루션과 관련하여 내부적으로 구현됩니다. 해당 스키마는 의료 데이터 솔루션을 위해 특별히 빌드되었으며 업계 또는 커뮤니티 데이터 표준을 따르지 않습니다.
  • 임시 저장소: 데이터가 처리되어 브론즈 레이크하우스 스테이징 테이블에서 실버 레이크하우스의 평면화되고 정규화된 델타 테이블로 변환된 후 브론즈 스테이징 테이블 데이터는 제거할 준비가 된 것으로 간주됩니다. 이 모델은 비용 및 스토리지 효율성을 보장하고 브론즈 레이크하우스의 원본 파일과 스테이징 테이블 간의 데이터 중복을 줄입니다.

• 실버 레이크하우스: enriched 영역이라고도 불리는 실버 레이크하우스는 브론즈 레이크하우스의 데이터를 정제합니다. 여기에는 다운스트림 분석의 데이터 정확도를 개선하기 위한 유효성 검사 및 보강 기술이 포함됩니다. 브론즈 레이어와 달리 실버 레이크하우스 데이터는 결정적 ID 및 수정 타임스탬프를 기반으로 하는 규칙을 사용하여 레코드 삽입 및 업데이트를 관리합니다.

• 골드 레이크하우스: curated 영역이라고도 불리는 골드 레이크하우스는 실버 레이크하우스의 데이터를 더욱 정제하여 특정 비즈니스 및 분석 요구 사항을 충족합니다. 이 레이어는 포괄적인 분석 및 인사이트 추출을 위해 준비된 집계된 고품질 데이터 세트의 기본 원본 역할을 합니다. 의료 데이터 솔루션은 배포당 하나의 브론즈 레이크하우스와 하나의 실버 레이크하우스를 배포하지만, 다양한 사업부와 가상 사용자에 서비스를 제공하기 위해 여러 개의 골드 레이크하우스를 보유할 수 있습니다.

• 관리 레이크하우스: 관리 레이크하우스에는 BusinessEvent 테이블에 저장된 전역 구성 및 검증 오류를 포함하여 레이크하우스 레이어 전반의 데이터 거버넌스 및 추적성을 위한 파일이 포함되어 있습니다. 자세한 내용은 관리 레이크하우스를 참조하십시오.

통합 폴더 구조

의료 및 생명 과학 고객은 다음 파일 형식을 포함하여 여러 데이터 형식 및 파일 형식에 걸쳐 다양한 원본 시스템의 방대한 양의 데이터를 처리합니다.

• 임상 양식: FHIR NDJSON 파일, FHIR 번들 및 HL7.
• 이미징 양식: DICOM, NIFTI 및 NDPI.
• 유전체학 양식: BAM, BCL, FASTQ 및 VCF.
• 청구: CCLF 및 CSV.

여기서

• FHIR: 전자 의료 기록 교환
• HL7: Health Level Seven International
• DICOM: Digital Imaging and Communications in Medicine
• NIFTI: Neuroimaging Informatics Technology Initiative
• NDPI: Nano-dimensional Pathology Imaging
• BAM: Binary Alignment Map
• BCL: Base Call
• FASTQ: 생물학적 염기서열 및 해당 품질 점수를 저장하기 위한 텍스트 기반 형식
• VCF: Variant Call Format
• CCLF: Claim and Claim Line Feed
• CSV: 쉼표로 구분된 값

Microsoft Fabric의 OneLake는 조직에 논리적 데이터 레이크를 제공합니다. Microsoft Fabric의 의료 서비스 데이터 솔루션은 다양한 양식 및 형식으로 데이터를 구성하는 데 도움이 되는 통합 폴더 구조를 제공합니다. 이 구조는 데이터 수집 및 처리를 간소화하는 동시에 브론즈 레이크하우스의 원본 파일 및 원본 시스템 수준에서 데이터 계보를 유지합니다.

6개의 최상위 폴더는 다음과 같습니다.

• 외부
• 실패
• 수집
• 프로세스
• 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\DD
• Files\Process\[DataModality]\[DataFormat]\[Namespace]\YYYY\MM\DD

폴더 설명

• 네임스페이스(필수): 수신된 파일의 원본 시스템을 식별하며, 원본 시스템별 ID 고유성을 보장하는 데 중요합니다.

• Ingest 폴더: 드롭 또는 큐 폴더로 작동합니다. 이 폴더를 사용하면 적절한 양식 및 형식 하위 폴더에 수집할 파일을 삭제할 수 있습니다. 수집이 시작되면 파일은 해당 Process 폴더로 전송되고, 실패 시에는 Failed 폴더로 전송됩니다.

• Process 폴더: 각 양식 및 형식 조합 내에서 성공적으로 처리된 모든 파일의 최종 대상입니다. 이 폴더는 처리 날짜를 기준으로 YYYY/MM/DD 패턴을 따릅니다. 폴더 분할은 향상된 구성, 필터링된 검색, 자동화 및 잠재적인 병렬 처리를 위해 Azure Data Lake Storage 사용에 대한 모범 사례를 준수합니다.

• 외부 폴더: BYOS(Bring Your Own Storage) 바로 가기 폴더의 상위 폴더 역할을 합니다. 기본 배포는 청구, 임상, 유전체학 및 이미징 양식에 대한 암시적인 폴더 구조를 제공합니다. 이미징 및 임상 양식에는 Azure Health Data Services에서 DICOM 및 FHIR 서비스를 지원하도록 구성된 기본 형식과 네임스페이스가 있습니다. 이 형식은 데이터를 OneLake로 바로 가기하려는 경우에만 적용됩니다. Microsoft Fabric의 의료 서비스 데이터 솔루션에는 이러한 바로 가기 폴더 내의 파일에 대한 읽기 전용 액세스 권한이 있습니다.

• Failed 폴더: Ingest 또는 Process 폴더에서 파일을 이동하거나 처리하는 동안 오류가 발생하면, 영향을 받은 파일은 해당 양식 및 포맷 조합에 해당하는 Failed 폴더로 이동됩니다. 오류는 관리 레이크하우스의 BusinessEvent 테이블에 기록됩니다. 이 폴더는 처리/실패 날짜를 기준으로 YYYY/MM/DD 패턴을 사용합니다. 이 폴더의 파일은 제거되지 않으며 동일한 초기 수집 패턴을 사용하여 수정하고 다시 수집할 때까지 여기에 계속 남아 있습니다.

• 샘플 데이터 폴더: 합성, 참조 및/또는 공개 데이터 세트를 포함합니다. 기본 배포는 배포 후 Notebook 및 파이프라인을 즉시 실행할 수 있도록 여러 양식 및 형식 조합에 대한 샘플 데이터를 제공합니다. 이 폴더는 YYYY/MM/DD 하위 폴더를 생성하지 않습니다.

• 참조 데이터 폴더: 공개 또는 사용자별 원본의 참조 및 상위 데이터 세트를 포함합니다. 이 폴더는 YYYY/MM/DD 하위 폴더를 생성하지 않습니다. 기본 배포는 OMOP(Observational Medical Outcomes Partnership) 어휘에 대해 제안된 폴더 구조를 제공합니다.

데이터 수집 패턴

앞에서 설명한 통합 폴더 구조를 기반으로 Microsoft Fabric의 의료 데이터 솔루션은 두 가지 고유한 수집 패턴을 지원합니다. 두 경우 모두 솔루션은 Spark의 구조적 스트리밍을 사용하여 해당 폴더에서 들어오는 파일을 처리합니다.

수집 패턴

이 패턴은 수집할 파일을 적절한 양식, 형식 및 네임스페이스 아래의 Ingest 폴더에 놓는 간단한 접근 방식입니다. 수집 파이프라인은 이 폴더에서 새로 삭제된 파일을 모니터링하고 처리를 위해 해당 Process 폴더로 이동합니다. 파일 데이터가 브론즈 레이크하우스 스테이징 테이블에 성공적으로 수집되면, 해당 파일은 압축되어 처리가 발생하는 시점을 기준으로 YYYY/MM/DD 패턴에 따라 타임스탬프 접두사와 함께 Process 폴더에 저장됩니다. 이 접두사는 고유한 파일 이름을 보장합니다. 필요에 따라 압축을 구성하거나 비활성화할 수 있습니다.

파일 처리에 실패하면, 실패한 파일은 각 양식 및 형식 조합에 대한 Ingest 폴더에서 Failed 폴더로 이동되고, 오류는 관리 레이크하우스의 BusinessEvent 테이블에 기록됩니다.

이 수집 패턴은 매일 증분 수집하거나 데이터를 Azure Data Lake Storage 또는 OneLake로 물리적으로 이동할 때 이상적입니다.

BYOS(Bring Your Own Key) 패턴

경우에 따라 Azure 또는 기타 클라우드 스토리지 서비스에 이미 데이터와 파일이 있을 수 있으며 기존 다운스트림 구현 및 해당 파일에 대한 종속성이 있을 수 있습니다. 의료 및 생명 과학 분야에서 데이터 볼륨은 특히 의료 영상 및 유전체학의 경우 수 테라바이트 또는 페타바이트에 달할 수 있습니다. 이러한 이유로 직접 수집 패턴은 실현 가능하지 않을 수 있습니다.

Azure 또는 S3 프로토콜을 지원하는 다른 클라우드 및 온-프레미스 스토리지에서 이미 상당한 양의 데이터를 사용할 수 있는 경우 기록 데이터 수집에 BYOS 패턴을 사용하는 것이 좋습니다. 이 패턴은 Fabric의 OneLake 바로 가기와 브론즈 레이크하우스의 외부 폴더를 사용하여 원본 파일을 그 자리에서 처리할 수 있도록 합니다. 파일을 이동하거나 복사할 필요가 없으며 송신 요금 및 데이터 중복을 방지할 수 있습니다.

BYOS 수집 패턴이 제공하는 효율성에도 불구하고 다음 고려 사항에 유의해야 합니다.

• 현재 위치 파일 업데이트(파일 내의 콘텐츠 업데이트)는 모니터링되지 않습니다. 수집 파이프라인은 새 파일만 모니터링하므로 모든 업데이트에 대해 새 파일(다른 이름)을 만들어야 합니다. 이 제한은 Spark의 구조적 스트리밍과 관련이 있습니다.
• 데이터 압축은 적용되지 않습니다.
• BYOS 패턴은 YYYY/MM/DD 패턴을 기반으로 최적화된 폴더 구조를 생성하지 않습니다.
• 파일 처리에 실패하면 실패한 파일이 Failed 폴더로 이동되지 않습니다. 하지만, 오류는 관리 레이크하우스의 BusinessEvent 테이블에 기록됩니다.
• 원본 데이터는 읽기 전용으로 간주됩니다.
• 수집 후 원본 데이터의 계보 또는 가용성을 제어할 수 없습니다.

데이터 압축

Microsoft Fabric의 의료 데이터 솔루션은 메달리온 레이크하우스 설계 전반에 걸쳐 설계별 압축을 지원합니다. 메달리온 레이크하우스의 델타 테이블에 수집된 데이터는 Parquet 파일을 사용하여 압축된 열 형식으로 저장됩니다. 수집 패턴에서 파일이 Ingest 폴더에서 Process 폴더로 이동하면 처리가 성공적으로 완료된 후 기본적으로 압축됩니다. 필요에 따라 압축을 구성하거나 비활성화할 수 있습니다. 이미징 및 청구 기능의 경우 수집 파이프라인은 ZIP 압축 형식의 원시 파일을 처리할 수도 있습니다.

Healthcare Data Model

메달리온 레이크하우스 설계에서 설명한 대로, 브론즈 레이크하우스 스테이징 테이블은 내부적으로 의료 데이터 솔루션을 위해 특별히 제작된 테이블을 구현했으며, 어떠한 업계나 커뮤니티 데이터 표준도 따르지 않습니다.

실버 레이크하우스의 의료 데이터 모델은 FHIR R4 표준을 기반으로 합니다. 데이터 분석가, 데이터 과학자 및 개발자가 협업하고 환자 결과와 비즈니스 성과를 개선하는 데이터 기반 솔루션을 구축할 수 있는 공통 데이터 언어를 제공합니다. 임상, 행정, 재무 및 사회와 같은 다양한 의료 영역의 데이터를 지원합니다. 의료 데이터 모델은 FHIR 표준으로 정의된 데이터를 캡처하고 레이크하우스 내의 테이블 및 열을 사용하여 FHIR 리소스를 구성합니다.

FHIR 데이터를 델타 Parquet 테이블로 평면화하면 데이터 탐색 및 분석을 위해 T-SQL 및 Spark SQL와 같은 친숙한 도구를 사용할 수 있습니다. FHIR 범위를 벗어난 비임상 데이터의 경우 Azure Synapse 데이터베이스 템플릿의 스키마를 사용합니다. 이 구현을 통해 환자 참여 데이터와 같은 비임상 정보를 환자 프로필에 통합할 수 있습니다.

실버 레이크하우스의 의료 데이터 모델은 사업부 및 연구 도메인 전반의 의료 데이터에 대한 엔드투엔드 엔터프라이즈 보기를 나타내도록 설계되었습니다.

데이터 계보 및 추적성

레코드 및 파일 수준에서 계보 및 추적성을 보장하기 위해 의료 데이터 모델 테이블에는 다음 열이 포함됩니다.

Column	설명
msftCreatedDatetime	실버 레이크하우스에서 레코드가 처음 생성된 타임스탬프입니다.
msftModifiedDatetime	레코드에 대한 마지막 수정 사항의 타임스탬프입니다.
msftFilePath	바로 가기를 포함하여 브론즈 레이크하우스의 원본 파일에 대한 전체 경로입니다.
msftSourceSystem	통합 폴더 구조에 지정된 Namespace에 해당하는 레코드의 소스 시스템입니다.

필드가 정규화, 평면화 또는 수정되는 경우 원본 값은 {columnName}Orig 열에 유지됩니다. 예를 들어 실버 레이크하우스 환자 테이블에서 다음과 같은 열을 찾을 수 있습니다.

Column	설명
meta_lastUpdatedOrig	원본 값을 원시 형식(문자열 또는 날짜)으로 유지하고 날짜/시간으로 저장합니다.
idOrig 및 identifierOrig	ID와 식별자는 실버 레이크하우스에서 조화를 이뤘습니다.
birthdateOrig 및 deceasedDateTimeOrig	다른 타임스탬프 서식을 사용하여 원래 날짜 값을 유지합니다.

열이 평면화되거나(예: meta_lastUpdated) 문자열로 변환되는 경우(예: meta_string) 밑줄(_)로 시작하는 접미사를 사용하여 이를 표시합니다.

업데이트 처리

새 데이터가 브론즈에서 실버 레이크하우스로 수집되면 업데이트 작업은 들어오는 레코드를 각 리소스 및 테이블 유형에 대해 실버 레이크하우스의 대상 테이블과 비교합니다. 실버 레이크하우스의 FHIR 테이블의 경우 이 비교는 {FHIRResource}.id와 {FHIRResource}.meta_lastUpdated 값을 ClinicalFhir 브론즈 레이크하우스 스테이징 테이블의 id 및 lastUpdated 열과 비교합니다.

• 일치하는 항목이 식별되고 들어오는 레코드가 새 레코드인 경우 실버 레코드가 업데이트됩니다.
• 들어오는 레코드가 오래된 경우 실버 레코드는 무시됩니다.
• 일치하는 항목이 없으면 새 레코드가 실버 레이크하우스에 삽입됩니다.

관리 레이크하우스

관리 레이크하우스는 Microsoft Fabric에서 의료 데이터 솔루션에 대한 레이크하우스 간 구성, 전역 구성, 상태 보고 및 추적을 관리합니다.

전역 구성

관리 레이크하우스 system-configurations 폴더는 전역 구성 매개 변수를 중앙 집중화합니다. 세 개의 구성 파일에는 모든 의료 데이터 솔루션 기능의 기본 배포에 대해 미리 구성된 값이 포함되어 있습니다. 모든 기능에 대해 샘플 데이터 또는 데이터 파이프라인을 실행하기 위해 이러한 값을 다시 구성할 필요가 없습니다.

deploymentParametersConfiguration.json 파일에는 activitiesGlobalParameters 아래에 전역 매개 변수가 포함되어 있고 activities 아래에 Notebook 및 파이프라인에 대한 활동별 매개 변수가 포함되어 있습니다. 각 기능 지침에서는 각 기능에 대한 특정 구성 세부 정보를 다룹니다. validation_config.json 파일 매개 변수는 데이터 유효성 검사에서 설명합니다.

다음 표에는 모든 전역 구성 매개 변수가 나열되어 있습니다.

섹션	구성 매개 변수
activitiesGlobalParameters	•administration_lakehouse_id: 관리 레이크하우스 식별자입니다. •bronze_lakehouse_id: 브론즈 레이크하우스 식별자입니다. •silver_lakehouse_id: 실버 레이크하우스 식별자입니다. •keyvault_name: Azure Marketplace 제품과 함께 배포된 경우 Azure Key Vault 값입니다. •enable_hds_logs: 로깅을 활성화합니다. 기본값은 true로 설정됩니다. •movement_config_path: file_orchestration_config 파일의 경로입니다. •bronze_imaging_delta_table_path: 이미징 양식 테이블의 Fabric 경로입니다(배포된 경우). •bronze_imaging_table_schema_path: 이미징 양식 스키마의 Fabric 경로입니다(배포된 경우). •omop_lakehouse_id: 골드 레이크하우스 식별자입니다(배포된 경우).
healthcare#_msft_fhir_ndjson_bronze_ingestion을 위한 활동	•source_path_pattern: Process 폴더에 대한 OneLake 경로입니다. •move_failed_files_enabled: 실패한 파일을 Ingest 폴더에서 Failed 폴더로 이동해야 할지 여부를 결정하는 플래그입니다. •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 바로 가기를 통해 외부 저장소 위치에서 제공되는지 여부를 결정하는 플래그입니다. 이 경우 파일은 다른 경우와 마찬가지로 Process 폴더로 이동되지 않습니다. •external_source_path: 브론즈 레이크하우스의 바로 가기 외부 폴더에 대한 OneLake 경로입니다. •process_source_path: 브론즈 레이크하우스의 Process 폴더에 대한 OneLake 경로입니다. •checkpoint_path: 체크포인트 폴더의 OneLake 경로입니다. •move_failed_files: 실패한 파일이 Ingest에서 Failed 폴더로 이동되는지 여부를 결정하는 플래그입니다. •compression_enabled: 원시 NDJSON 파일이 처리 후 압축되는지 결정하는 플래그입니다. •max_files_per_trigger: 각 실행 내에서 처리된 파일 수입니다. •num_retries: 오류가 발생하기 전에 각 파일 처리에 대한 재시도 횟수입니다.
healthcare#_msft_imaging_dicom_fhir_conversion을 위한 활동	•fhir_ndjson_files_root_path: Process 폴더에 대한 OneLake 경로입니다. •avro_schema_path: 실버 스키마 폴더의 OneLake 경로입니다. •dicom_to_fhir_config_path: DICOM 메타태그에서 FHIR ImagingStudy 리소스로 구성을 매핑하기 위한 OneLake 경로입니다. •checkpoint_path: 체크포인트 폴더의 OneLake 경로입니다. •max_records_per_ndjson: 각 실행에서 단일 NDJSON 파일 내에서 처리된 레코드 수입니다. •subject_id_type_code: DICOM 메타데이터에 있는 환자의 의료 번호에 대한 값 코드입니다. 기본값은 FHIR의 Medical Record Number에 해당하는 MR로 설정됩니다. •subject_id_type_code_system: DICOM 메타데이터에 있는 환자의 의료 번호에 대한 코드 시스템입니다. •subject_id_system: DICOM 메타데이터에 있는 환자의 의료 번호에 대한 코드 시스템의 개체 ID입니다.
healthcare#_msft_omop_silver_gold_transformation을 위한 활동	•vocab_path: OMOP 어휘 데이터 세트가 저장되는 브론즈 레이크하우스의 참조 데이터 폴더에 대한 OneLake 경로입니다. •vocab_checkpoint_path: 체크포인트 폴더의 OneLake 경로입니다. •omop_config_path: 실버 레이크하우스에서 골드 OMOP 레이크하우스까지 구성을 매핑하기 위한 OneLake 경로입니다.

BusinessEvents 테이블

BusinessEvents 델타 테이블은 수집 및 변환 프로세스 중에 발생할 수 있는 모든 유효성 검사 오류, 경고 및 기타 알림 또는 예외를 캡처합니다. 이 테이블을 사용하여 시스템 로그 수준뿐만 아니라 사용자 수준과 기능 수준 모두에서 수집 실행 진행률을 모니터링합니다. 예를 들어 수집 중에 유효성 검사 오류 또는 경고를 발생시킨 원시 파일을 식별합니다. 시스템 수준 로그를 보고 모든 레이크하우스에서 Apache Spark 활동을 모니터링하려면 Azure Log Analytics를 통합하는 옵션과 함께 Fabric Monitoring 허브를 사용할 수 있습니다.

다음 표에서는 BusinessEvent 테이블의 열을 보여 줍니다.

Column	설명
id	테이블의 각 행에 대한 고유 식별자(GUID)입니다.
activityName	실패 및/또는 유효성 검사 오류 또는 경고를 생성한 활동/Notebook의 이름입니다.
targetTableName	이벤트를 생성한 데이터 활동의 대상 테이블입니다.
targetFilePath	이벤트를 생성한 데이터 활동의 대상 파일 경로입니다.
sourceTableName	이벤트를 생성한 데이터 활동의 원본 테이블입니다.
sourceLakehouseName	이벤트를 생성한 데이터 활동의 원본 레이크하우스입니다.
targetLakehouseName	이벤트를 생성한 데이터 활동의 대상 레이크하우스입니다.
sourceFilePath	이벤트를 생성한 데이터 활동의 원본 파일 경로입니다.
runId	이벤트를 생성한 데이터 활동의 실행 ID입니다.
severity	이벤트의 심각도 수준으로, Error 또는 Warning의 두 값 중 하나를 가질 수 있습니다. Error는 데이터 작업을 계속하기 전에 이 이벤트를 해결해야 함을 나타냅니다. Warning은 일반적으로 즉각적인 조치가 필요하지 않은 수동 알림 역할을 합니다.
eventType	검증 엔진에서 생성된 이벤트와 사용자가 BusinessEvent 테이블에 표시하려는 사용자 또는 처리되지 않은/시스템 예외에서 생성된 일반 이벤트를 구별합니다.
recordIdentifier	원본 레코드의 식별자입니다. 이 열은 BusinessEvents 테이블의 각 이벤트에 대한 최신 고유 식별자를 나타내므로 id 열과 다릅니다.
recordIdentifierSource	원본 레코드의 식별자에 대한 원본 시스템입니다. 예를 들어, 원본 시스템이 EMR인 경우 EMR 이름 또는 URL이 소스 역할을 합니다.
active	이벤트(오류 또는 경고)가 해결되었는지 여부를 나타내는 플래그입니다.
message	이벤트, 오류 또는 경고에 대한 설명 메시지입니다.
exception	처리되지 않은/시스템 예외 메시지입니다.
customDimensions	유효성 검사 또는 예외의 원본 데이터가 테이블의 불연속 열이 아닌 경우에 적용할 수 있습니다. 예를 들어 원본 데이터가 단일 열 내에서 문자열로 저장된 JSON 개체 내의 특성인 경우 전체 JSON 개체가 사용자 지정 차원으로 제공됩니다.
eventDateTime	이벤트 또는 예외가 생성되는 타임스탬프입니다.

데이터 유효성 검사

Microsoft Fabric의 의료 데이터 솔루션 내에 있는 데이터 유효성 검사 엔진은 원시 데이터가 브론즈 레이크하우스로 수집되기 전에 미리 정의된 기준을 충족하는지 확인합니다. 브론즈 레이크하우스 내의 테이블 및 열 수준에서 유효성 검사 규칙을 구성할 수 있습니다. 현재 이러한 규칙은 원시 파일에서 브론즈 레이크하우스의 델타 테이블에 이르기까지 수집 프로세스 중에만 구현됩니다.

원시 파일이 처리되면 유효성 검사 규칙이 수집 수준에서 적용됩니다. 유효성 검사에는 Error 및 Warning의 두 가지 심각도 수준이 있습니다. 유효성 검사 규칙이 Error로 설정된 경우, 규칙을 위반하면 파이프라인이 중지되고, 오류가 있는 파일은 Failed 폴더로 이동됩니다. 심각도가 Warning으로 설정된 경우 파이프라인은 처리를 계속하고 파일은 Process 폴더로 이동됩니다. 두 경우 모두, 오류나 경고를 반영하는 항목이 관리 레이크하우스 내의 BusinessEvents 테이블에 생성됩니다.

BusinessEvents 테이블은 의료 데이터 솔루션 내의 모든 활동, Notebook 또는 데이터 파이프라인에 대한 모든 레이크하우스의 비즈니스 수준 로그 및 이벤트를 캡처합니다. 그러나 현재 구성에서는 수집 중에만 유효성 검사 규칙을 적용하므로 유효성 검사 오류 및 경고로 인해 BusinessEvents 테이블의 일부 열이 채워지지 않은 상태로 남을 수 있습니다.

관리 레이크하우스의 validation_config.json 파일에서 데이터 유효성 검사 규칙을 구성할 수 있습니다. 기본적으로, 브론즈 레이크하우스의 ClinicalFhir 테이블에 있는 meta.lastUpdated 및 id 열은 필요에 따라 설정됩니다. 이러한 열은 업데이트 처리에서 설명한 대로 실버 레이크하우스에서 업데이트와 삽입을 관리하는 방법을 결정하는 데 중요합니다.

다음 테이블에는 데이터 유효성 검사를 위한 구성 매개 변수가 나열되어 있습니다.

구성 유형	매개 변수
레이크하우스 수준	bronze: 유효성 검사 및 레코드 식별자 노드의 범위입니다. 이 경우 값은 브론즈 레이크하우스로 설정됩니다.
유효성 검사	•validationType: exists 유효성 검사 유형은 구성된 속성의 값이 원시 파일(원본 데이터)에 제공되는지 여부를 확인합니다. •attributeName: 유효성을 검사할 특성의 이름입니다. •validationMessage: 유효성 검사 오류 또는 경고를 설명하는 메시지입니다. •severity: 문제의 수준을 나타내며, Error 또는 Warning일 수 있습니다. •tableName: 유효성을 검사할 테이블의 이름입니다. 별표(*)는 이 규칙이 해당 레이크하우스의 범위 내에 있는 모든 테이블에 적용됨을 나타냅니다.
recordIdentifier	•attributeName: BusinessEvent 테이블의 recordIdentifier 열에 있는 원본/원시 파일의 레코드 식별자입니다. •jsonPath: BusinessEvent 테이블의 recordIdentifier 열에 배치될 값에 대한 열 또는 특성의 JSON 경로를 나타내는 선택적 값입니다. 이 값은 유효성 검사의 원본 데이터가 테이블의 불연속 열이 아닌 경우에 적용됩니다. 예를 들어, 원본 데이터가 단일 열 내에 문자열로 저장된 JSON 개체 내의 특성인 경우 JSON 경로는 레코드 식별자 역할을 하는 특정 특성으로 연결됩니다.

관련 정보

• Microsoft Fabric의 의료 데이터 솔루션 개요
• Microsoft Fabric 솔루션 아키텍처의 의료 데이터 솔루션 개요