헬스 데이터 애그리게이터(Health Data Aggregator) 앱 구축은 겉보기보다 훨씬 어렵습니다

새로운 의사 앞에 앉아 이미 어딘가에 존재하는 의료 기록을 15분 동안 다시 설명해 본 사람이라면, 이런 종류의 소프트웨어가 해결하려는 문제가 무엇인지 이해할 것입니다. 기록은 이미 존재합니다. 단지 하나로 모여 있지 않을 뿐입니다.

그 기록들을 하나로 모으는 과정에서 상황이 복잡해집니다.

애그리게이터(Aggregator)를 구축하는 대부분의 팀은 처음 몇 달 안에 동일한 벽에 부딪힙니다. 예산보다 세 배나 더 오래 걸리는 벤더 통합(Vendor integrations), 잘 작동하다가 어느 순간 문제가 생기는 환자 매칭(Patient matching), 그리고 그 자체로 하나의 엔지니어링 프로젝트가 되어버리는 컴플라이언스(Compliance) 계층 등이 그것입니다. 아이디어는 단순합니다. 하지만 구현은 그렇지 않습니다.

실제 상황에서의 EHR 통합 문제

FHIR가 도움이 되었습니다. FHIR 이전에는 새로운 의료 시스템에 연결하는 것이 매번 상당 부분 맞춤형 작업이었습니다. 서로 다른 API, 서로 다른 데이터 구조, 서로 다른 인증 흐름(Auth flows), 모든 것이 달랐습니다. FHIR는 업계에 충분히 공통적인 API 패턴을 제공하여 재사용 가능한 커넥터(Connectors)를 구축하는 것을 현실적으로 만들어 주었습니다.

문제는 "FHIR 인증"이라는 말이 매우 광범위한 범위를 포괄한다는 점입니다. 실제로 서로 다른 두 개의 EHR 벤더를 통합하는 데 시간을 써보면, 그들이 표준을 구현하는 방식에서 서로 다른 선택을 했다는 것을 알게 될 것입니다. 문서화되지 않은 속도 제한(Rate limits), 실제 환자 데이터가 흐르기 시작할 때서야 비로소 발견하게 되는 운영 환경(Production)과 다르게 동작하는 샌드박스(Sandbox) 환경, 그리고 문서에 명시된 것과 일치하지 않는 에러 응답 등이 있습니다.

그리고 이는 FHIR로 전혀 전환하지 않은 시스템들을 고려하기 전의 이야기입니다. 많은 임상 데이터(Clinical data) — 검사 결과(Labs), 영상(Imaging), 오래된 병원 시스템 — 가 여전히 HL7 v2 인터페이스 뒤에 머물러 있습니다. 이를 건너뛴다는 것은 임상의들이 실제로 필요로 하는 실제 환자 기록을 건너뛰는 것과 같습니다. 이는 진지한 애그리게이터를 구축하는 사람이라면 두 가지를 모두 처리해야 하며, 벤더들이 각자의 일정에 따라 변경 사항을 밀어붙임에 따라 해당 커넥터들을 지속적으로 유지 관리해야 함을 의미합니다.

환자 매칭: 항상 더 많은 시간이 소요되는 부분

여러 시스템 간의 레코드 매칭(Matching records) — 즉, 동일한 환자가 여러 EHR(전자 건강 기록)에 나타나는지 확인하는 작업 — 은 이미 해결된 문제처럼 들립니다. 하지만 그렇지 않습니다.

합성 테스트 데이터(Synthetic test data)는 다루기 쉽습니다. 하지만 실제 등록 데이터는 수년에 걸쳐 여러 시설의 직원들이 일관되지 않은 검증 방식과 일관되지 않은 필수 필드(mandatory fields)를 사용하여 입력한 것입니다. 세 개의 서로 다른 시스템에서 세 가지 다른 방식으로 철자가 표기된 이름, 한 병원에서 잘못 입력되어 수정되지 않은 생년월일, 법적으로 이름을 변경했지만 일부 시스템만 업데이트되고 나머지는 업데이트되지 않은 환자 등이 이에 해당합니다.

확률적 매칭(Probabilistic matching)을 사용하면 어느 정도 해결은 됩니다. 정확한 일치(exact hits)를 요구하는 대신 여러 필드에 걸쳐 가능성을 점수화하는 방식입니다. 하지만 여전히 신뢰 임계값(confidence threshold)을 선택해야 하며, 의료 환경에서 적절한 임계값은 거의 다른 어떤 도메인과도 다릅니다. 임계값이 너무 엄격하면 실제 매칭을 놓쳐 환자의 기록이 파편화됩니다. 반대로 너무 느슨하면 서로 다른 사람의 레코드를 연결하기 시작하는데, 이는 임상 환경에서 단순한 데이터 품질 문제가 아니라 환자 안전(patient safety)의 문제입니다.

이 작업을 처음 수행하는 대부분의 팀은 테스트에서 작동했던 것을 기준으로 임계값을 설정했다가, 운영 환경(production)에서는 작동하지 않는다는 것을 발견하고 이후 몇 달 동안 이를 조정하는 데 시간을 보냅니다. 더 잘 버텨내는 팀은 출시 후에가 아니라, 출시 전에 실제로 지저분한 실제 데이터를 대상으로 스트레스 테스트(stress-tested)를 수행한 팀들입니다.

과소평가되는 컴플라이언스(Compliance) 작업

암호화(Encryption), 액세스 제어(access controls), 감사 로그(audit logging) — 의료 분야에서 작업하는 사람이라면 누구나 시작 단계부터 이를 알고 있습니다. 하지만 범위가 너무 좁게 설정되는 경향이 있는 컴플라이언스 작업은 그 상위에 있는 것들입니다. 바로 동의 추적(consent tracking)과 데이터 사용 거버넌스(data use governance)입니다.

환자들은 목적에 따라 서로 다른 동의 상태(consent statuses)를 가집니다. 어떤 이들은 연구를 위한 데이터 공유를 거부(opted out)했습니다. 행동 건강(behavioral health), 약물 사용(substance use), 생식 보건(reproductive care) 관련 기록은 표준 HIPAA 요구 사항을 넘어서는 추가적인 법적 보호를 받습니다. 이 모든 데이터를 수집(ingest)한 뒤, 데이터 수집(ingestion) 시점뿐만 아니라 쿼리(query) 시점에도 동의 규칙을 강제하지 않고 데이터를 노출하는 애그리게이터(aggregator)는 실제로는 유의미한 방식으로 규정을 준수(compliant)하고 있다고 볼 수 없습니다.

이를 제대로 수행하려면 누가, 어떤 데이터를, 왜 쿼리할 것인지를 초기에 이해해야 합니다. 이는 단순히 기술적인 문제일 뿐만 아니라 부분적으로는 제품(product)의 문제이며, 아키텍처(architecture)를 구축하기 전에 결정되어야 합니다. 설계 단계부터 고려되지 않은 시스템에 동의 계층(consent layer)을 사후에 끼워 넣는 것은 비용이 많이 들고 매우 복잡합니다.

이를 제대로 구축하는 데 필요한 구체적인 기술적 결정 사항은 헬스 데이터 애그리게이터의 과제 및 모범 사례에 관한 가이드에서 자세히 다루고 있습니다. 여기에는 대규모 환경에서 거버넌스(governance)를 다룰 수 있도록 아키텍처를 어떻게 구조화해야 하는지에 대한 내용도 포함되어 있습니다.

ROI(투자 대비 수익) 사례 만들기

헬스 데이터 애그리게이션(aggregation)에 대한 내부적인 정당화는 대개 임상적 결과(clinical outcomes)에 초점을 맞춥니다. 즉, 약물 상호작용 포착, 중복 검사 감소, 케어 조정(care coordination) 개선 등이 그것입니다. 이것들은 실제적인 혜택이며 매우 의미가 있습니다. 하지만 이러한 결과는 측정하는 데 시간이 오래 걸리고, 애그리게이션 계층(aggregation layer) 덕분이라고 직접적으로 귀속시키기 어렵기 때문에 예산 검토 시점에 다시 정당성을 입증하기가 까다롭습니다.

실무에서 더 잘 통하는 ROI 논거는 운영(operational) 측면입니다. 수동 기록 요청에 소요되는 시간 감소, 완전한 임상 정보(clinical picture)를 활용한 빠른 사전 승인(prior authorization), 아무도 확인하지 않았던 시스템의 결과를 자동으로 노출함으로써 더 일찍 발견되는 케어 격차(care gaps) 등이 있습니다. 이러한 요소들은 더 구체적이고 귀속시키기 쉬우며, 구축 첫날부터 이를 위한 측정 프레임워크(measurement framework)를 만들어 두면 비즈니스 케이스(business case)를 더욱 견고하게 만들 수 있습니다.

실제로 구축을 성공시키는 요소

임상적 신뢰(clinical trust)를 얻는 애그리게이터(aggregators)들은 제품 사양서(product spec)에는 나타나지 않는 몇 가지 공통된 특징을 공유합니다.

이들은 초기 단계부터 합성 데이터(synthetic records)가 아닌, 실제 환자의 지저분한 데이터(messy patient data)를 시스템에 투입했습니다. 그리고 출시 후가 아니라 출시 전에 이를 활용하여 매칭(matching) 및 정규화(normalization) 과정을 스트레스 테스트(stress-test)했습니다. 이렇게 실행한 팀들은 발견된 내용을 바탕으로 매칭 로직의 일부를 다시 작성했습니다. 반면, 그렇게 하지 않은 팀들은 운영 환경(production)에서 동일한 문제들을 발견했습니다.

이들은 정규화(normalization)를 메인 파이프라인(pipeline) 작업과는 별개의 자체적인 타임라인과 반복 주기(iteration cycle)를 가진 독립적인 엔지니어링 과제로 범위를 설정했습니다. 정규화를 다른 모든 것과 함께 구축해야 할 하나의 모듈로 취급한 팀들은, 출시 후에 소스(source) 간의 쿼리 결과(query results)가 서로 비교 불가능하다는 사실을 발견했으며, 이는 데이터에 대한 임상적 신뢰를 손상시키는 결과를 초래했습니다.

또한 이들은 처음부터 운영 도구(operational tooling)를 구축했습니다. 소스 시스템의 동작이 변경될 때 이를 감지하는 모니터링(monitoring), 매칭률(match rates)이 예상치 못하게 변할 때 보내는 알림(alerts), 그리고 사용을 위해 전체 재배포(redeploy)가 필요하지 않은 조사 도구(investigation tools) 등이 이에 해당합니다.

아키텍처 결정(architecture decisions)을 진행 중인 팀이라면, 구축을 시작하기 전에 헬스 데이터 애그리게이터 앱의 과제, 솔루션 및 모범 사례(health data aggregator app challenges, solutions, and best practices)에 대한 상세한 분석 내용을 읽어볼 가치가 있습니다.