OHDSI를 처음 접할 때 많은 사람은 보통 이렇게 이해합니다. “아, OMOP Common Data Model을 관리하는 커뮤니티구나.” 물론 맞는 말입니다. 하지만 그렇게만 이해하면 실제로 중요한 부분을 놓치게 됩니다. 제게 OHDSI는 단순히 데이터 구조를 통일하는 기술 문서 모음이 아닙니다. 현실의 의료 데이터를 연구 가능한 언어로 번역하는 방법을 집요하게 다듬어 온 집단에 더 가깝습니다.

RWE 이야기를 하다 보면 대개 인과추론, target trial emulation, comparator design, time-varying confounding 같은 개념에 먼저 시선이 갑니다. 저 역시 그런 질문을 좋아합니다. 하지만 실무에서는 종종 더 앞단에서 발이 걸립니다. 같은 질환이라도 병원마다 코드가 다르고, 같은 약물이라도 노출 정의가 제각각이며, 코호트 추출 기준이 분석가마다 달라집니다. 이 상태에서는 아무리 좋은 인과 질문을 던져도, 분석은 반복 가능하지 않고 비교 가능하지도 않습니다.

그래서 저는 OHDSI를 “화려한 방법론을 하기 전에 연구를 같은 문법으로 말하게 만드는 기반”으로 읽습니다.

1. OHDSI를 읽는다는 것은 결국 재현 가능한 분석을 읽는다는 뜻이다

RWE를 하다 보면 팀마다 이런 차이가 생깁니다.

  • 어떤 팀은 질병 정의를 진단코드 한 줄로 끝냅니다.
  • 어떤 팀은 약물 노출을 처방일만으로 정의합니다.
  • 어떤 팀은 세부 exclusion criteria를 코드로 남기지 않습니다.

겉으로는 모두 “실세계 데이터 분석”을 한다고 말하지만, 실제로는 같은 질문에 대해 서로 다른 연구를 하고 있는 셈입니다. OHDSI가 중요한 이유는, 이런 혼선을 줄이기 위해 데이터 구조, 용어 체계, 코호트 정의, 분석 실행 흐름을 최대한 명시적으로 남기는 문화를 밀어붙였기 때문입니다.

즉 OHDSI를 본다는 것은 단순히 CDM 테이블을 외운다는 뜻이 아닙니다. “이 연구를 다른 사람이 다시 돌릴 수 있는가?”, “다른 데이터베이스에서도 같은 정의가 유지되는가?”, “질문과 코드 사이의 거리가 얼마나 줄어들었는가?”를 보는 것입니다.

저는 이 점이 규제기관 문서를 읽는 태도와도 닮아 있다고 생각합니다. 좋은 규제 문서는 허용 여부만 말하지 않고, 무엇이 재현 가능하고 설명 가능한 근거인지를 묻습니다. OHDSI 역시 결국 같은 질문을 다른 언어로 던집니다.

2. OMOP CDM의 가치는 표준화 그 자체보다 비교 가능성에 있다

OMOP CDM을 설명할 때 흔히 “데이터를 표준 테이블에 맞춘다”는 말이 먼저 나옵니다. 물론 맞습니다. 하지만 그 설명만으로는 왜 그렇게 많은 기관이 시간을 들여 CDM 전환을 하는지 충분히 납득하기 어렵습니다.

진짜 가치는 표준화 자체가 아니라, 여러 기관과 데이터베이스 사이에서 같은 질문을 비교 가능한 형태로 던질 수 있게 된다는 점에 있습니다.

예를 들어 고혈압 환자에서 특정 약물의 장기 안전성을 보려 한다고 합시다. 원자료(raw data) 상태에서는 병원마다 테이블 구조가 다르고, 코드 체계가 다르고, 노출/결과 정의를 저장하는 방식도 다를 수 있습니다. 이 상태에서는 분석 코드보다 전처리와 해석 차이가 더 커집니다. 그런데 CDM 위에서는 적어도 “어떤 개념을 어떤 방식으로 추적할지”를 공통 문법 위에 올려둘 수 있습니다.

이게 왜 중요하냐면, RWE는 단일 데이터셋 안에서만 예쁘게 돌아가는 분석보다 다른 환경에서도 비슷한 결론이 나오는지 확인하는 과정이 더 중요해지기 때문입니다. 특히 규제, 안전성, post-marketing, external validation 같은 문맥에서는 더욱 그렇습니다.

그래서 OMOP은 단지 tidy한 데이터 모델이 아니라, 연구의 이동성(portability)과 재현성(reproducibility)을 높이는 운영 인프라로 읽어야 합니다.

3. OHDSI가 던지는 진짜 질문은 “무슨 모델을 쓸까”보다 “질문을 어떻게 operationalize할까”에 가깝다

요즘 연구 이야기를 하면 사람들의 관심은 금방 모델로 이동합니다. 어떤 causal model을 쓸지, 어떤 learner를 붙일지, high-dimensional adjustment를 할지, 혹은 AI를 어디에 얹을지 같은 문제들 말입니다.

그런데 OHDSI 자료를 보다 보면 사고의 순서가 다릅니다. 훨씬 먼저 묻는 건 이런 질문입니다.

  • 이 노출은 어떤 concept set으로 정의되는가?
  • washout period는 어떻게 둘 것인가?
  • target cohort와 comparator cohort는 어떤 inclusion/exclusion criteria를 따르는가?
  • outcome definition은 얼마나 transportable한가?
  • 이 분석을 다른 데이터베이스에서 다시 돌렸을 때 해석이 유지되는가?

즉 여기서는 “무슨 알고리즘을 얹을까”보다 “연구 질문을 데이터 구조 안에서 어떻게 operationalize할까”가 더 앞섭니다.

저는 이 점이 매우 중요하다고 생각합니다. 실제로 실무에서는 sophisticated한 모델보다 모호한 코호트 정의가 더 많은 혼란을 만듭니다. 그리고 그 모호함은 논문 결과 표보다 늦게 발견됩니다. OHDSI를 진지하게 보는 순간, 분석가는 모델러이기 전에 질문을 명시적으로 정의하는 사람이어야 한다는 사실을 자꾸 마주하게 됩니다.

4. OHDSI는 거대한 자동화 도구라기보다, 좋은 분석 습관을 강제하는 프레임에 가깝다

가끔 OHDSI를 “버튼만 누르면 분석이 나오는 플랫폼”처럼 오해하는 경우가 있습니다. 물론 툴링이 잘 갖춰져 있고, 코호트 빌더나 패키지 기반 실행 환경이 있는 것은 사실입니다. 하지만 그걸 단순 자동화 툴로만 보면 본질을 놓칩니다.

제가 보기엔 OHDSI의 핵심은 편의성보다 분석 절차를 명시적이고 반복 가능하게 만들도록 강제하는 프레임입니다.

예를 들면:

  • 코호트 정의를 텍스트가 아니라 구조화된 규칙으로 남기게 하고
  • concept set과 phenotype 논의를 별도 자산으로 축적하게 하고
  • 결과를 하나의 데이터셋이 아니라 네트워크 전체에서 비교 가능하게 만들며
  • 코드와 설계를 함께 남기도록 유도합니다.

이건 생각보다 큰 차이입니다. 왜냐하면 많은 조직에서 분석은 여전히 “분석가의 개인 노하우”에 많이 의존하기 때문입니다. 누군가 퇴사하면 왜 그렇게 cohort를 만들었는지 사라지고, 어떤 exclusion rule이 왜 들어갔는지 문서가 남지 않는 경우가 흔합니다. OHDSI는 이런 문제를 완전히 해결하지는 못해도, 최소한 개인 기술을 조직 자산으로 바꾸는 방향을 제시합니다.

5. 규제기관 문서와 OHDSI를 같이 보면 보이는 것이 있다

제가 OHDSI를 standards 영역에서 계속 추적하려는 이유는, 규제기관 문서와 나란히 놓고 읽을 때 훨씬 의미가 커지기 때문입니다.

규제기관은 이렇게 묻습니다.

  • 이 데이터는 질문에 적합한가?
  • reliability는 충분한가?
  • bias를 설명하고 통제했는가?
  • outcome, exposure, comparator가 해석 가능한가?

OHDSI는 다른 언어로 비슷한 문제를 다룹니다.

  • 데이터를 공통 구조로 올렸는가?
  • 개념 정의가 반복 가능한가?
  • phenotype이 충분히 명시되었는가?
  • 다른 데이터베이스에서도 같은 설계를 실행할 수 있는가?

둘은 역할이 다르지만, 결국 연구 품질을 지탱하는 질문은 크게 다르지 않습니다. 그래서 저는 regulatory watch와 standards watch를 분리해 두면서도, 실제로는 같이 읽어야 한다고 생각합니다. 규제기관 문서는 “무엇을 설득해야 하는가”를 알려주고, OHDSI는 “그 설득을 반복 가능한 구조로 만들려면 무엇이 필요한가”를 보여주기 때문입니다.

6. 그래서 OHDSI를 보는 사람은 결국 methods와 operations를 함께 보게 된다

OHDSI를 계속 보다 보면 흥미로운 변화가 생깁니다. 처음에는 표준 테이블이나 vocabulary mapping 같은 기술 문제로 시작했는데, 시간이 지나면 결국 methods와 operations를 동시에 보게 됩니다.

왜냐하면 현실의 RWE는 좋은 설계만으로 끝나지 않기 때문입니다. 좋은 설계가 실제 데이터 파이프라인과 연결되어야 하고, 다른 팀이 다시 실행할 수 있어야 하며, 정의가 문서로 남아야 하고, 네트워크 전체에서 비교 가능해야 합니다.

이쯤 되면 OHDSI는 단순 데이터 모델 관리 조직이 아니라, RWE를 반복 가능한 생산 체계로 만들기 위해 무엇이 필요한지 축적해 온 집단처럼 보입니다. 저는 이 점 때문에 OHDSI를 계속 보게 됩니다. 최신 causal paper를 읽는 것과는 다른 차원에서, “좋은 연구를 지속적으로 생산하려면 어떤 운영 구조가 필요한가”를 생각하게 만들기 때문입니다.

마무리

OHDSI를 읽는 이유를 한 문장으로 줄이면 이렇습니다.

RWE가 커질수록 좋은 질문만으로는 부족하고, 그 질문을 반복 가능한 분석 구조로 옮기는 운영 언어가 필요하기 때문입니다.

저는 앞으로도 OHDSI 문서를 단순 표준 업데이트로 보지 않으려 합니다. 오히려 규제기관 문서, 방법론 논문, 실제 분석 설계 사이를 이어 주는 중간 언어로 읽으려 합니다. 그리고 그 관점이 있어야만, 우리가 쓰는 RWE라는 말이 단지 대형 데이터 분석이 아니라 재현 가능하고 설명 가능한 연구 체계에 가까워질 수 있다고 생각합니다.

참고 링크

[OHDSI Home](https://www.ohdsi.org/)