대부분의 임상 데이터 엔지니어들이 즉각적으로 인지하는 특정한 순간이 있습니다.

데이터베이스 잠금 (Database lock)까지 3주가 남았습니다. 분석 파이프라인 (Analysis pipeline)은 스테이징 (Staging) 환경에서 두 달 동안 문제없이 실행되었습니다. QA (Quality Assurance) 승인도 완료되었습니다. 생물 통계 (Biostatistics) 팀도 준비를 마쳤습니다.

그런데 프로덕션 (Production) 데이터로 전환하는 순간, 무언가 깨집니다. 합성 환경 (Synthetic environment)에서는 절대 생성되지 않았던 시간적 순서 (Temporal sequence)가 나타납니다. 스키마 제약 조건 (Schema constraints)이 전혀 강제하지 않았던 14개의 중복 처방을 가진 환자가 나타납니다. 아무도 엣지 케이스 (Edge case)를 만들 생각을 하지 않았기에 테스트 픽스처 (Test fixtures)에 포함되지 않았던, 연결된 진단명이 없는 진료 기록 (Encounter record)이 나타납니다.

사후 분석 (Post-mortem)은 항상 동일한 결론에 도달합니다: 합성 환경이 프로덕션처럼 동작하지 않았다는 것입니다.

이 글은 왜 그런 일이 발생하는지, 그 비용은 얼마인지, 그리고 정말 중요한 순간에 견뎌낼 수 있는 임상 테스트 데이터베이스를 어떻게 구축하는지에 관한 것입니다.

아무도 인정하고 싶지 않은 근본 원인

대부분의 임상 엔지니어링 팀은 10년 전 팀들이 데이터를 생성했던 방식과 동일한 방식으로 테스트 데이터를 생성합니다.

하나의 파이썬 (Python) 스크립트. 몇 번의 페이커 (Faker) 호출. 몇몇 하드코딩된 환자 ID. 어쩌면 2019년에 종료된 연구에서 가져온 비식별화된 기록의 CSV 임포트 (Import) 정도일 것입니다.

단일 테이블을 쿼리 (Query)할 때는 데이터가 괜찮아 보입니다. 하지만 애플리케이션이 실제적인 작업을 수행하는 순간 무너집니다: 환자와 진료 기록 (Encounters) 간의 조인 (Join), 진단명과 처방 간의 시간적 쿼리 (Temporal query), 연결된 검사 결과 (Lab results)를 요구하는 코호트 필터 (Cohort filter) 등이 그것입니다.

이유는 구조적입니다. 대부분의 테스트 데이터 생성 방식은 테이블을 독립적인 것으로 취급합니다. 전체 스키마 (Schema)에 걸쳐 값들 사이의 관계를 모델링하지 않은 채, 컬럼 (Column)들을 그럴듯한 값들로 채울 뿐입니다. 혈압 수치는 연령이나 진단 부담 (Diagnosis burden)과 상관관계가 없습니다. 처방 기록은 환자 테이블에는 존재하지만, 그보다 앞서 있어야 할 진료 기록 (Encounter) 테이블에는 존재하지 않는 환자 ID를 참조합니다. 결과 날짜 (Outcome dates)가 치료 날짜 (Treatment dates)보다 앞섭니다. 사망한 환자에게 추적 진료 (Follow-up encounters) 기록이 있습니다.

당신의 애플리케이션은 실제 실행될 세상과 다르게 동작하는 세상을 대상으로 테스트되고 있는 것입니다.

임상 데이터베이스가 실제로 포함하고 있는 것

문제를 해결하기에 앞서, 무엇이 임상 데이터를 구조적으로 복잡하게 만드는지 정확히 정의하는 것이 도움이 됩니다.

운영 환경의 임상 데이터베이스 (production clinical database)는 단순히 그럴듯한 값들이 담긴 테이블들의 집합이 아닙니다. 그것은 제약 조건이 있고, 시간 순서로 정렬되며, 도메인에 의해 관리되는 관계들의 네트워크입니다.

환자는 동반 질환 (comorbidity) 부담과 상관관계가 있는 인구통계학적 정보 (demographics)를 가집니다. 제2형 당뇨병 (Type 2 diabetes) 진단 기록이 있는 72세 환자는 표준 치료 경로 (standard treatment pathways)를 반영하는 약물 복용 이력, 해당 상태와 일치하는 범위 내에 머무는 검사 수치 (lab values), 그리고 해당 인구 집단의 전형적인 관리 패턴을 반영하는 진료 횟수 (encounter frequency)를 가져야 합니다.

진료 (Encounters)는 시간 순서대로 이루어집니다. 진료에는 유효한 처치 코드 (procedure codes)를 제한하는 입원 유형 (admission types)이 있습니다. 또한 후속 진료 유형을 제한하는 퇴원 처분 (discharge dispositions)이 있습니다. 호스피스 (hospice)로 퇴원한 환자가 일반 외래 진료 (routine outpatient visit)를 위해 다시 돌아오지는 않습니다.

진단 (Diagnoses)은 치료 패턴을 제한하는 중증도 분류 (severity classifications)를 수반합니다. 치명적인 이상 사례 (fatal adverse event)가 경미함 (mild)으로 표시되지는 않습니다. 해결된 급성 질환 (resolved acute condition)은 새로운 진단 이벤트 없이 후속 진료에서 활성 상태 (active)로 나타나지 않습니다.

처방 (Prescriptions)은 진단과 치료적 관계 (therapeutic relationships)를 가집니다. 투여량 (Dosing)은 환자의 체중, 연령, 신장 기능 (renal function)과 상관관계가 있습니다. 투여 기간 (Duration)은 질환 유형과 상관관계가 있습니다. 처방 갱신 (Renewals)은 임상적으로 타당한 타임라인을 따릅니다.

검사 결과 (Lab results)에는 인구 집단에 따라 달라지는 참조 범위 (reference ranges)가 있습니다. 해당 범위를 벗어난 값은 문서화된 임상 이벤트와 일치해야 합니다. 연결된 후속 진료 없이 나타나는 비정상적인 결과는 운영 데이터 (production data)에서 위험 신호 (red flag)이며, 합성 데이터 (synthetic data)에서도 위험 신호여야 합니다.

이러한 관계 중 그 어느 것도 Faker 스크립트에 의해 모델링되지 않습니다. 이 모든 것들은 운영 환경에서 강제됩니다. 이 두 현실 사이의 간극이 바로 당신의 테스트 환경이 당신에게 거짓말을 하는 지점입니다.

임상 엔지니어가 가장 자주 맞닥뜨리는 세 가지 실패 패턴

패턴 1: 조용한 참조 무결성 파괴 (The Silent Referential Break)

귀하의 애플리케이션은 encounter(진료 접점)와 diagnosis(진단) 간의 join(조인)을 수행합니다. 귀하의 합성 데이터베이스(synthetic database)에서는 테스트 데이터 생성기가 이들을 독립적으로 생성했기 때문에, encounter 레코드의 3%가 연결된 diagnosis가 없습니다. 운영 환경(production)에서는 시스템이 데이터 수집(ingestion) 단계에서 제약 조건(constraint)을 강제하므로 해당 비율이 0%입니다.

귀하의 join은 스테이징(staging) 환경에서 약간 잘못된 결과를 반환합니다. 귀하가 이를 테스트하지 않았기 때문에 알아차리지 못합니다. 그러다 운영 환경에서 코호트 쿼리(cohort query) 결과가 사이트 코디네이터(site coordinator)의 보고서와 일치하지 않는 것을 발견하고 나서야 비로소 알아차리게 됩니다.

패턴 2: 시간적 역전 (The Temporal Inversion)

귀하의 파이프라인(pipeline)은 time-to-event(사건 발생 시간) 지표를 계산합니다. 귀하의 합성 데이터베이스에서는 생성기가 테이블 간의 시간적 순서(temporal ordering)를 강제하지 않고 각 테이블을 독립적으로 채웠기 때문에, 소수의 레코드에서 치료 날짜가 진단 날짜보다 앞서는 현상이 발생합니다.

귀하의 파이프라인은 스테이징 환경에서 깨끗하게 작동합니다. 하지만 운영 환경에서는 제약 조건이 적용되는 첫 번째 레코드를 만나는 순간 time-to-event 계산에서 예외(exception)가 발생합니다. 귀하는 실제 데이터에 대해 제대로 테스트된 적도 없는 파이프라인을 디버깅(debugging)하는 데 이틀을 허비하게 됩니다.

패턴 3: 누락된 엣지 케이스 (The Missing Edge Case)

귀하의 애플리케이션은 의료 환경 간의 환자 전원(patient transfers)을 처리합니다. 귀하의 합성 데이터베이스에서는 테스트 픽스처(test fixtures)가 happy-path(정상 경로) 시나리오를 바탕으로 구축되었기 때문에, 모든 환자가 표준적인 입원 후 외래 진료 경로를 따릅니다.

운영 환경에서는 환자의 8%가 보장 공백(gap in coverage)이 있는 전원 기록을 가지고 있으며, 귀하의 애플리케이션은 이에 대해 한 번도 테스트된 적이 없습니다. 스테이징 환경에서는 아무도 해당 엣지 케이스(edge case)를 생성하지 않았고, Faker는 그것이 존재해야 한다는 사실을 알지 못하기 때문에 이 문제가 결코 드러나지 않았습니다.

실제 운영 환경과 유사한 임상 데이터베이스에 필요한 사항

실제로 운영 환경처럼 동작하는 합성 임상 데이터베이스를 구축하려면, 대부분의 테스트 데이터 도구가 제공하지 않는 다섯 가지 요소가 필요합니다.

스키마 우선 생성 (Schema-first generation). 데이터베이스 구조가 생성 프로세스를 주도해야 하며, 그 반대가 되어서는 안 됩니다. 참조 무결성 (Referential integrity)은 행 (rows)을 생성한 후에 추가하는 것이 아닙니다. 그것은 애초에 어떤 행이 생성 가능한 유효한 행인지를 결정하는 제약 조건입니다.

도메인 기반 필드 상관관계 (Domain-governed field correlations). 임상 데이터베이스의 값들은 독립적으로 분포하지 않습니다. 운영 환경에서 다른 필드와 상관관계가 있는 모든 필드는 합성 환경에서도 동일한 방향으로 상관관계가 있어야 합니다. 이를 위해서는 단순한 통계적 분포 (statistical distributions)가 아닌, 임상 도메인 규칙을 이해하는 생성 엔진이 필요합니다.

테이블 간 시간적 순서 (Cross-table temporal ordering). 임상 데이터베이스의 이벤트는 실제 세계의 인과 관계를 준수하는 순서로 발생합니다. 테이블을 독립적으로 채우는 생성 엔진은 이러한 순서를 강제할 수 없습니다. 순서는 모든 테이블에 걸쳐 생성 계층 (generation layer)에서 동시에 강제되어야 합니다.

설계에 의한 엣지 케이스 커버리지 (Edge case coverage by design). 운영 환경과 유사한 임상 데이터베이스는 실제 환자군에서 나타나는 엣지 케이스 (edge cases)를 포함해야 합니다: 기록된 진단명이 없는 환자, 비전형적인 퇴원 처분 (discharge dispositions)이 포함된 진료, 기간에 이상이 있는 처방, 위급 상황으로 표시된 검사 결과 등입니다. 이것들은 오류가 아닙니다. 당신의 애플리케이션이 처리해야 하는 시나리오들입니다.

재현성 (Reproducibility). 로컬 환경에서는 재현할 수 없는 버그가 스테이징 (staging) 환경에서 나타난다면, 문제는 대개 두 환경이 서로 다르게 생성되었기 때문입니다. 임상 테스트 데이터베이스는 문서화된 설정으로부터 재현 가능해야 합니다. 동일한 입력값에 대해 매번 동일한 데이터베이스가 생성되어야 합니다.

SyntheholDB가 임상 팀을 위해 이를 해결하는 방법

SyntheholDB는 임상 테스트 환경의 모습과 실제 운영 시스템이 포함하고 있는 내용 사이의 간극을 메우기 위해 특별히 구축되었습니다.

생성 파이프라인 (generation pipeline)은 사용자의 스키마 (schema)로부터 바깥쪽으로 작동합니다. 스키마를 가져오거나, 평이한 언어로 데이터 모델을 설명하거나, 또는 환자, 의료진, 진료 (encounters), 진단 (diagnoses), 처방 (prescriptions), 시술 (procedures), 검사 결과 (lab results), 그리고 결과 (outcomes)를 실제 운영 규모로 다루는 내장된 의료 전자 건강 기록 (Healthcare EHR) 템플릿에서 시작할 수 있습니다. 이 템플릿은 500,000건의 진료, 750,000건의 진단 데이터를 포함하며, 모든 테이블에 걸쳐 완전히 연결되어 있습니다.

엔진은 사후 처리 검증 단계가 아니라, 생성 시점에 참조 무결성 (referential integrity)을 강제합니다. 외래 키 (Foreign keys)는 행이 기록되기 전에 해결됩니다. 복합 고유 키 (Composite unique keys)는 전체 생성 실행 과정 동안 추적됩니다. 시간적 순서 (Temporal sequences)는 테이블별이 아니라 연결된 테이블 전체에 걸쳐 동시에 정렬됩니다.

도메인 인식 상관관계 모델 (Domain-aware correlation models)은 현실적인 임상 데이터와 그럴듯해 보이는 무작위 값 (random values)을 구분 짓는 필드 수준의 관계를 처리합니다. 환자 프로필에는 실제 인구 분포를 반영하는 상관관계가 있는 인구 통계, 동반 질환 부담 (comorbidity burden), 그리고 약물 이력이 포함됩니다. 검사 값은 환자 프로필에 적절한 범위 내에 머뭅니다. 진료 빈도는 질환 관리 패턴을 반영합니다.

예외 사례 (Edge cases)는 설계 단계부터 생성되도록 만들어졌습니다. 엔진에는 이상하지만 임상적으로 유효한 패턴이 포함되어 있습니다: 진료 공백이 있는 환자, 비전형적인 처치 코드 (disposition codes)가 포함된 진료, 치료 범위의 경계에 있는 처방, 임상 검토 대상으로 표시된 검사 결과 등이 이에 해당합니다. 이러한 데이터는 수동으로 주입되는 것이 아닙니다. 생성 파이프라인에 내장된 도메인 모델로부터 자연스럽게 나타납니다.

모든 내보내기 (export)에는 충실도 점수 (fidelity score), 개인정보 보호 라벨 스캔 (privacy label scan), 그리고 참조 무결성 보고서가 포함됩니다. 귀하의 컴플라이언스 (compliance) 팀이나 규제 감사관이 테스트 환경이 어떻게 검증되었는지 물을 때, 관련 문서가 이미 준비되어 있을 것입니다.

SyntheholDB는 SOC 2 Type II 인증, ISO 27001 인증을 받았으며, HIPAA 및 GDPR을 준수합니다. 엔터프라이즈 배포는 생성 또는 검증 경로에서 외부 네트워크 호출 없이 완전히 온프레미스 (on-premises)로 실행됩니다.

실질적인 마이그레이션 경로

만약 귀하의 팀이 현재 Faker 스크립트, 비식별화된 덤프 (de-identified dumps), 또는 수동으로 관리되는 시드 데이터 (seed data)를 사용하고 있다면, 프로덕션 수준의 현실적인 합성 데이터베이스 (synthetic database)로 전환하는 데 있어 '빅뱅 마이그레이션 (big-bang migration)'이 반드시 필요한 것은 아닙니다.

하나의 서비스부터 시작하십시오. 귀하의 스택 중 데이터 의존성 (data dependencies)이 가장 복잡하거나, 스테이징 (staging) 실패가 가장 빈번하거나, 또는 환경 프로비저닝 (provisioning) 시간이 가장 오래 걸리는 서비스를 선택하십시오. 해당 서비스의 스키마 (schema)를 내보내거나 정의하십시오. SyntheholDB를 사용하여 해당 서비스의 범위에 맞춘 합성 데이터베이스를 생성하십시오. 귀하의 서비스와 테스트를 해당 합성 데이터베이스에 연결하십시오.

다음 세 가지를 측정하십시오: 현재 방식과 비교했을 때 현실적인 환경을 프로비저닝하는 데 걸린 시간, 현재 사용 중인 테스트 픽스처 (test fixtures) 중 삭제할 수 있었던 것의 개수, 그리고 해당 서비스의 스테이징 실패율이 변했는지 여부입니다.

만약 그 결과가 대부분의 임상 엔지니어링 (clinical engineering) 팀이 발견하는 사실, 즉 현실적인 환경이 더 많은 실제 문제를 포착하고 수동 유지보수 요구사항을 줄여준다는 점을 확인해 준다면, 귀하는 이 방식을 전체 스택으로 확장할 수 있는 구체적인 근거를 갖게 된 것입니다.

임상 엔지니어를 위한 결론

프로덕션 (production)처럼 동작하지 않는 합성 데이터베이스는 테스트 환경이 아닙니다. 그것은 신뢰의 함정 (confidence trap)입니다. 그것은 실제 실행될 조건에서 한 번도 테스트되지 않은 기능을 배포하게 만들며, 최악의 타이밍에 실패를 드러냅니다.

임상 데이터 환경의 표준은 귀하가 프로덕션 시스템에 적용하는 표준과 동일해야 합니다: 정확한 스키마 (schemas), 강제된 제약 조건 (enforced constraints), 현실적인 관계 (relationships), 그리고 재현 가능한 구성 (reproducible configurations)입니다.

SyntheholDB는 무료로 시작할 수 있습니다. 신용카드는 필요하지 않습니다. 귀하의 첫 번째 합성 임상 데이터베이스는 60초 이내에 준비됩니다.

여기에서 가입하고 첫 번째 데이터베이스를 생성하십시오: https://db.synthehol.ai/#/login

만약 임상 스키마 (clinical schema)에 이를 적용해 보신다면, 아래에 댓글을 남겨 무엇을 발견했는지 공유해 주세요. 현재의 테스트 환경에서 놓치고 있었던 어떤 엣지 케이스 (edge cases)를 합성 데이터베이스 (synthetic database)가 드러냈나요? 이 커뮤니티의 답변들은 플랫폼에 다음에 구축될 기능들을 지속적으로 형성해 나갑니다.