의료 데이터 솔루션의 DICOM 데이터 변환에 대한 사용 고려 사항
이 문서에서는 DICOM 데이터 변환 기능을 사용하기 전에 검토해야 할 주요 고려 사항을 간략하게 설명합니다. 이러한 요소를 이해하면 의료 데이터 솔루션 환경 내에서 원활하게 통합하고 운영할 수 있습니다. 또한 이 리소스는 기능과 관련된 몇 가지 잠재적인 과제와 제한 사항을 효과적으로 탐색하는 데 도움이 됩니다.
수집 파일 크기
현재 ZIP 파일의 논리적 크기 제한은 8GB이고, 기본 DCM 파일의 경우 최대 4GB입니다. 파일이 이러한 제한을 초과하면 실행 시간이 길어지거나 수집이 실패할 수 있습니다. 성공적인 실행을 보장하기 위해 ZIP 파일을 더 작은 세그먼트(4GB 미만)로 분할하는 것이 좋습니다. 4GB보다 큰 네이티브 DCM 파일의 경우 필요에 맞게 Spark 노드(실행자)를 확장해야 합니다.
DICOM 태그 추출
우리는 다음 두 가지 이유로 청동 레이크하우스 ImagingDicom 델타 테이블 에 있는 29개 태그를 홍보하는 것을 우선시합니다.
- 이 29개 태그는 모달리티, 측면성과 같은 DICOM 데이터의 일반적인 쿼리와 탐색에 필수적입니다.
- 이러한 태그는 후속 실행 단계에서 실버(FHIR) 및 골드(OMOP) 델타 테이블을 생성하고 채우는 데 필요합니다.
관심 있는 다른 DICOM 태그를 확장하고 승격할 수 있습니다. 그러나 DICOM 데이터 변환 노트북은 청동 레이크하우스의 ImagingDicom 델타 테이블에 추가한 DICOM 태그의 다른 열을 자동으로 인식하거나 처리하지 않습니다. 추가 열을 독립적으로 처리해야 합니다.
브론즈 레이크하우스에 패턴 추가
새로 수집된 모든 DCM(또는 ZIP) 파일은 청동 레이크하우스의 ImagingDicom 델타 테이블에 추가됩니다. 성공적으로 수집된 모든 DCM 파일에 대해 ImagingDicom 델타 테이블에 새 레코드 항목을 생성합니다. 브론즈 레이크하우스 수준에서 병합 또는 업데이트 작업을 위한 비즈니스 논리는 없습니다.
ImagingDicom 델타 테이블은 DICOM 인스턴스 수준에서 수집된 모든 DCM 파일을 반영하므로 그에 따라 간주되어야 합니다. 동일한 DCM 파일이 Ingest 폴더로 다시 수집되면 동일한 파일에 대한 ImagingDicom 델타 테이블에 다른 항목이 추가됩니다. 그러나 Unix 접두사 타임스탬프로 인해 파일 이름이 다릅니다. 수집 날짜에 따라 해당 파일은 다른 YYYY\MM\DD 폴더에 저장될 수 있습니다.
OMOP 버전 및 이미징 확장
골드 레이크하우스의 현재 구현은 Observational Medical Outcomes Partnership(OMOP) Common Data Model 버전 5.4를 기반으로 합니다. OMOP에는 아직 이미징 데이터를 지원하는 규범적 확장이 없습니다. 따라서 이 기능은 이미징 기반 관찰 연구를 위한 의료 이미징 데이터 표준화 개발: OMOP Common Data Model 확장에서 제안된 확장을 구현합니다. 이 확장은 2024년 2월 5일에 발표된 이미징 연구 분야의 최신 제안입니다. DICOM 데이터 변환 기능의 현재 릴리스는 골드 레이크하우스의 Image_Occurrence 테이블로 제한됩니다.
Spark의 구조적 스트리밍
구조적 스트리밍은 Spark SQL 엔진을 기반으로 하는 확장 가능하고 내결함성이 있는 스트림 처리 엔진입니다. 정적 데이터에 대한 일괄 처리 계산을 표현하는 것과 같은 방식으로 스트리밍 계산을 표현할 수 있습니다. 이 시스템은 체크포인트와 Write-Ahead 로그를 통해 종단 간 장애 내구성을 보장합니다. 구조적 스트리밍에 대해 자세히 알아보려면 구조적 스트리밍 프로그래밍 가이드(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 아래의 Bronze 레이크하우스에 있습니다. |
| 실버 레이크하우스 ImagingStudy 델타 테이블에 데이터 수집 | healthcare#.HealthDataManager\DMHCheckpoint\<silverlakehouse>\ImagingStudy |
브론즈 레이크하우스의 델타 테이블 ImagingStudy. |
팁
OneLake 파일 탐색기를 사용하면 표에 나열된 파일 및 폴더의 내용을 볼 수 있습니다. 자세한 내용은 OneLake 파일 탐색기 사용을 참조하세요.
브론즈 레이크하우스의 그룹 패턴
그룹 패턴은 청동 레이크하우스의 ImagingDicom 델타 테이블에서 청동 레이크하우스의 ImagingStudy 델타 테이블로 새 레코드를 수집할 때 적용됩니다. DICOM 데이터 변환 기능은 ImagingDicom 델타 테이블의 모든 인스턴스 수준 레코드를 연구 수준별로 그룹화합니다. DICOM 연구당 ImagingStudy 레코드를 하나씩 생성한 다음 해당 레코드를 브론즈 레이크하우스의 ImagingStudy 델타 테이블에 삽입합니다.
실버 레이크하우스의 Upsert 패턴
upsert 작업은 다음을 기반으로 청동 및 실버 레이크하우스 간의 FHIR 델타 테이블을 비교합니다. {FHIRResource}.id
- 일치하는 항목이 식별되면 실버 레코드가 새로운 브론즈 레코드로 업데이트됩니다.
- 일치하는 항목이 확인되지 않으면 브론즈 레코드가 실버 레이크하우스에 새 레코드로 삽입됩니다.
이 패턴을 사용하면 실버 레이크하우스 ImagingStudy 테이블에 리소스를 생성할 수 있습니다.
ImagingStudy 제한 사항
upsert 작업은 동일한 일괄 처리 실행에서 동일한 DICOM 스터디의 DCM 파일을 수집할 때 예상대로 작동합니다. 그러나 나중에 동일한 DICOM 연구에 속하는 다른 배치의 더 많은 DCM 파일을 수집하여 이전에 실버 레이크하우스로 수집하는 경우 수집으로 인해 삽입 작업이 발생합니다. 해당 프로세스는 업데이트 작업을 수행하지 않습니다.
이 Insert 작업은 노트북이 각 배치 실행 시 새로운 {FHIRResource}.id for ImagingStudy 를 생성하기 때문에 발생합니다. 이 새 ID는 이전 일괄 처리의 ID와 일치하지 않습니다. 결과적으로 실버 테이블에 서로 다른 ImagingStudy.id 값을 갖는 두 개의 ImagingStudy 레코드가 표시됩니다. 이러한 ID는 해당 일괄 처리 실행과 관련이 있지만 동일한 DICOM 연구에 속합니다.
이 문제를 해결하려면 일괄 처리를 완료하고 고유 ID의 조합을 기반으로 실버 레이크하우스에 있는 두 개의 ImagingStudy 레코드를 병합합니다. 그러나 병합에는 ImagingStudy.id를 사용하지 마세요. 대신 [studyInstanceUid (0020,000D)] 및 [patientId (0010,0020)] 와 같은 다른 ID를 사용하여 레코드를 병합할 수 있습니다.
OMOP 추적 접근 방식
healthcare#_msft_omop_silver_gold_transformation 노트북은 OMOP API를 사용하여 실버 레이크하우스 델타 테이블의 변경 사항을 모니터링합니다. 골드 레이크하우스 델타 테이블로 upsert해야 하는 새로 수정되거나 추가된 레코드를 식별합니다. 이 과정은 워터마킹이라고 합니다.
OMOP API는 {Silver.FHIRDeltatable.modified_date}와 {Gold.OMOPDeltatable.SourceModifiedOn} 사이의 날짜 및 시간 값을 비교하여 마지막 Notebook 실행 이후 수정되거나 추가된 증분 레코드를 확인합니다. 그러나 이 OMOP 추적 접근 방식이 골드 레이크하우스의 모든 델타 테이블에 적용되는 것은 아닙니다. 다음 테이블은 실버 레이크하우스의 델타 테이블에서 수집되지 않습니다.
- 개념
- concept_ancestor
- concept_class
- concept_relationship
- concept_synonym
- fhir_system_to_omop_vocab_mapping
- 어휘
이러한 골드 델타 테이블은 OMOP 샘플 데이터 배포에 포함된 어휘 데이터를 사용하여 채워집니다. 이 폴더의 어휘 데이터 세트는 Spark의 구조적 스트리밍을 사용하여 관리됩니다.
골드 레이크하우스의 Upsert 패턴
골드 레이크하우스의 upsert 패턴은 실버 레이크하우스와 다릅니다. OMOP healthcare#_msft_omop_silver_gold_transformation 노트북에서 사용하는 API는 gold 레이크하우스의 델타 테이블에 있는 각 항목에 대한 새로운 ID를 생성합니다. API는 실버 레이크하우스에서 골드 레이크하우스로 새 레코드를 수집하거나 변환할 때 이러한 ID를 생성합니다. 또한 OMOP API는 새로 생성된 ID와 실버 레이크하우스 델타 테이블의 해당 내부 ID 간의 내부 매핑을 유지 관리합니다.
API는 다음과 같이 작동합니다.
레코드를 실버에서 골드 델타 테이블로 처음 변환하는 경우 OMOP 골드 레이크하우스에 새 ID가 생성되고 실버 레이크하우스의 원래 새 ID에 매핑됩니다. 그런 다음 새로 생성된 ID를 사용하여 골드 델타 테이블에 레코드를 삽입합니다.
실버 레이크하우스의 동일한 레코드가 일부 수정을 거쳐 골드 레이크하우스로 다시 수집되는 경우 OMOP API는 매핑 정보를 사용하여 골드 레이크하우스의 기존 레코드를 인식합니다. 그런 다음 이전에 생성한 것과 동일한 ID로 골드 레이크하우스의 레코드를 업데이트합니다.
골드 레이크하우스에서 새로 생성된 ID(ADRM_ID)와 각 OMOP 델타 테이블의 원래 ID(INTERNAL_ID) 간의 매핑은 OneLake Parquet 파일에 저장됩니다. 다음 파일 경로에서 Parquet 파일을 찾을 수 있습니다.
[OneLakePath]\[workspace]\healthcare#.HealthDataManager\DMHCheckpoint\dtt\dtt_state_db\KEY_MAPPING\[OMOPTableName]_ID_MAPPING
Spark Notebook에서 Parquet 파일을 쿼리하여 매핑을 볼 수도 있습니다.
실버 레이크하우스의 ImagingMetastore 디자인
단일 DICOM 파일에는 최대 5,000개의 고유 태그가 포함될 수 있으므로 이 모든 태그에 대한 필드를 실버 레이크하우스에 매핑하고 생성하는 것은 비효율적이고 리소스가 많이 필요합니다. 그러나 데이터 손실을 방지하고 유연성을 유지하려면 전체 태그 세트에 대한 액세스를 유지하는 것이 필수적이며, 특히 데이터 모델에서 추출되어 표현된 29개 이상의 태그가 필요한 경우 더욱 그렇습니다. 이 문제를 해결하기 위해 실버 레이크하우스 ImagingMetastore 델타 테이블은 모든 DICOM 태그를 metadata_string 열에 저장합니다. 이러한 태그는 문자열화된 JSON 형식의 키-값 쌍으로 표현되므로 SQL 분석 끝점를 통한 효율적인 쿼리가 가능합니다. 이러한 접근 방식은 레이크하우스 실버의 모든 필드에서 복잡한 JSON 데이터를 관리하기 위한 표준 관행과 일치합니다.
청동 레이크하우스의 ImagingDicom 테이블에서 실버 레이크하우스의 ImagingMetastore 테이블로의 변환은 어떤 그룹화도 수행하지 않습니다. 리소스는 두 테이블 모두에서 인스턴스 수준으로 표현됩니다. 하지만 {FHIRResource}.id ImagingMetastore 테이블에 포함됩니다. 이 값을 사용하면 고유 ID를 참조하여 특정 연구와 연관된 모든 인스턴스 수준 아티팩트를 쿼리할 수 있습니다.
DICOM 서비스와 통합
DICOM 데이터 변환 기능과 Azure Health Data Services DICOM 서비스 간의 현재 통합은 만들기 및 업데이트 이벤트만 지원합니다. 새로운 이미징 연구, 시리즈 및 인스턴스를 만들거나 기존 연구, 시리즈 및 인스턴스를 업데이트할 수도 있습니다. 하지만 통합 기능은 아직 삭제 이벤트를 지원하지 않습니다. DICOM 서비스에서 연구, 계열 또는 인스턴스를 삭제하는 경우 DICOM 데이터 변환 기능에 이 변경 내용이 반영되지 않습니다. 이미징 데이터는 변경되지 않고 삭제되지 않습니다.
테이블 경고
각 레이크하우스의 모든 테이블에 대해 하나 이상의 열이 복잡한 객체 지향 데이터 유형을 사용하여 데이터를 나타낼 때 경고가 나타납니다. ImagingDicom 및 ImagingMetastore 테이블에서 metadata_string 열은 JSON 구조를 사용하여 DICOM 태그를 키-값 쌍으로 매핑합니다. 이 디자인은 구조체, 배열, 맵과 같은 복잡한 데이터 유형을 지원하지 않는 Fabric SQL 엔드포인트의 제한 사항을 수용합니다. SQL 끝점(T-SQL)를 사용하여 이러한 열을 문자열로 쿼리하거나 Spark를 사용하여 기본 유형(구조체, 배열, 맵)으로 작업할 수 있습니다.
