CDM: Common Data Model
카테고리: Clinical Informatics
📂들어가며
원래 CDSS를 먼저 작성하려 하였는데, “CDW랑 달라? 그럼 CDM은 뭔데!” 하는 갈증이 많으시다고 하여 CDM을 먼저 작성하기로 하였습니다. CDW는 DW의 정신(?)을 계승한 위치이지만, clinical practice, medicine의 지식공학적인 독보적인 독특함(Q: medicine은 science일까요, 아닐까요?)에 맞물려 완전히 새로운 전문성을 필요로 하는 도메인이 되었습니다.
CDM은 이와는 좀 다르게, secondary use of clinical data 라는 분야에서 interoperability와 privacy 문제를 해결해보자!는 __quick and dirty approach__의 연장선에서 이해할 수 있습니다. (여기서 quick and dirty는 heuristic problem solving에서의 가치중립적인 표현으로 사용되었습니다.) 그래서 CDM은 오히려 CDW에 가깝다기보다는 **ontology(세상 모든것을 명료한 축들로 이해해버리겠어! **) 의 반대 방향에서 들어오는 접근법입니다.
📂CDM이 해결하려는 문제: Clinical Big Data era와 interoperability
interoperability(상호운용성)은 다양한 층위와 관점에서 논해질 수 있습니다. CDM과 관련하여 등장하는 interoperability 개념은 data level integration이 될 수 있느냐! 가 중심이라고 볼 수 있습니다. 쉽게 말해서 기존 연구방법들에서 하던 data merge처럼 하고 싶은 것이지요.
한 개인의 건강은 N 수로는 1이지만 완결성있게 데이터를 수집한다는 것은 사실상 거의 불가능합니다. 의료와 관련된 주요 event, 병원에 가서 진단/치료 받은 내역만 모아도 주요 병력을 재구성할 수는 있을텐데요, 환자는 한 병원만, 하나의 보험체계안에서만 움직이지 않습니다.
EHR의 보급과 전산보험청구의 안착으로 자연스럽게 발생되는 clinical big data는 digitalized data의 형태로서 기존 물리적 기록(종이 차트, 영상 필름 등)에 비해 시간/공간의 제약을 거의 받지 않으므로 효과적이고 효율적으로 쏴줄 수 있을 것 같았습니다(!!)
간략히 기저질환이 없는 20대 청년 P라는 한 환자의 병원방문일자/키/체중/진단코드를 모아본다고 생각해볼까요? 다행히 기본 필드라 데이터를 모으고자 하는 모든 병원의 데이터 항목에 이 컬럼들이 있었습니다.
merge해 놓으니 다음과 같이 되었네요. 차트도 그려봅시다.
| 병원 | 방문일자 | 키 | 체중 | 진단코드 |
|---|---|---|---|---|
| OO의원 | 2021/01/07 | 173 | 75 | R51.9 |
| XX상급종합병원 | 2021/01/09 | 17.3 | 77 | G03.9 |
| ZZ hospital (USA) | 2022/05/13 | 5.7 | 171 | N11.9 |
| OO의원 | 2022/08/15 | 76 | R50.9 |
무엇이 문제일까요? 여기서 발생한 문제가 semantic interoperability의 간략한 예시입니다.
- Semantic interoperability(의미론적 상호운용성)
“Semantic interoperability is the ability of computer systems to exchange data with unambiguous, shared meaning. Semantic interoperability is a requirement to enable machine computable logic, inferencing, knowledge discovery, and data federation between information systems.”
-wikipedia (https://en.wikipedia.org/wiki/Semantic_interoperability)
주어진 정보만을 가지고 생각해 봤을때, 위 데이터 테이블(표)에서 “ambiguous(모호한)” 데이터는 무엇인가요? data modeler로서는 “전부 다! meta data를 내놔!” 라고 말하고 싶지만 명백히 모호한 데이터는 키, 체중, 진단코드(!) 일 것입니다. (YYYY/MM/DD와 고유명사일 병원 이름은 비표준화 된 데이터이더라도 통상적으로 이해될 여지가 있으니까 ‘명백히’에서 뺐습니다.)
먼저 키/체중을 봅시다.
XX상급종합병원이 한국의 병원이라고 생각했을 때, 또 직전 측정치를 봤을 떄 2021년 1월 9일에 기록된 키 17.3은 error data일 확률이 커 보입니다. 그렇다면 2022년 5월 13일 ZZ hospital 기록인 키/체중 = 5.7, 171은 뭘까요? 5.7은 error data이고 171은 키를 체중 값에 넣은 것인지, 5.7 feet__에 171 __pound 인지 확실하지 않습니다. 이 경우는 키/체중 이라는 ‘측정값’ 항목에 대해서 ‘단위’라는 meta-data가 고려되지 않고 항목명이라는 data structure만 보고 값을 이어붙여서 생긴 문제로, 이렇게 semantic interoperability를 고려하지 않고 이어붙인 데이터는 “무용”함을 알 수 있습니다.
데이터 구조의 차이(Synthetic interporability)만 극복하기도 힘든데, semantic interoperability 까지 고려하면서 데이터를 교류하거나, 연구용 데이터를 여러 기관에서 모아서 다기관 연구 또는 life-time long data관련 연구를 할 방법은 없을까요? 이것은 clinical informatics 분야의 하나의 큰 화두라고 할 수 있겠습니다. (다시 말씀드리지만 크게는 ‘secondary use of clinical data’ domain에 속합니다.)
그래도 “의료”라는 것이, “병원 practice”라는 것이 언어나 표현이나 workflow는 달라도 공통의 큰 틀은 있지 않나? 그렇다면 공통의 틀을 먼저 데이터 모델링을 하고, 거기에 맞춰서 각 병원 데이터를 넣으면(ETL, extract/transform/load, 추출/변환/적재) 하면 되지 않나?!
하는 것이 CDM(common data model) approach의 출발입니다.
즉, CDM은 CDW처럼 “데이터가 적재되어있는 분석계 또는 분석계의 기반이 되는 정보시스템”을 말하는 것은 아니고 CRF나 설문조사의 coding book처럼 DB에 데이터를 모을 그릇(data table and its meta-data)의 설계를 말합니다.
📂 CDM의 예시
“아, 그렇다면 CDM도 EHR이나 CDW, ‘자동차’처럼, 어떤 하나의 특정 개체를 지칭하는 말은 아니고 한 단계 위의 추상명사라는 것이지요? “ 라고 생각해 주신 분이 계시다면 정말 블로그를 작성하는 보람이 뿜뿜 할 것 같습니다. :)
우리나라에서 가장 유명한 CDM은 단연코 OMOP CDM이고, 이 외에도 PCORNet CDM, Sentinel CDM, K-CDM 등이 있습니다. (TMI: 저는 K-CDM의 고향 SNUBI에서 학위를 했고 100만례 정도 data가 ETL 된 환경에서 전술한 모델 네가지를 모두 다루어 봤습니다.. thanks to 지도교수님)
<Example: CDM의 구성 - OMOP CDM v5.4, reference:https://ohdsi.github.io/CommonDataModel/)
즉 CDM은 data interoperability 극복 방안의 하나로서, __하나의 데이터 저장 형태의 표준의 제안__이며, 이를 “공통데이터모델” 이라고 이름붙인 것입니다.
위의 3개 병원 데이터를 모은 P 환자의 예시로 돌아가봅시다.
키/체중과 같은 기본적인 항목을 OMOP CDM에서는 “Observation” (좌측 Standatdized clinical data 영역의 아래서 6번째 line) 의 하나로 보고 있습니다. 여기에 위 표와 같은 형태로 데이터를 넣는다면, meta data(키의 단위, 체중의 단위 등)는 어떻게 하느냐? 이를 OMOP CDM에서는 Standardized vocabulary 파트를 선언해서 운용하고 있습니다. 의미를 완성하는 메타데이터의 일부를 concept으로 선언하고 이를 모든 관찰치에 할당한 다음, 각각의 concept ID별로 세부 정보를 Standardized vocabulary (가운데 하단 주황색 네모 영역) 에서 소화하는 방식입니다.
Standardized derived element는 맨 좌측 + 가운데 영역만으로 분석을 하려니 후향적 재구성이 어려운 것들을 변환/재구성하는 방안을 부가적으로 제안한 것으로, 비교적 후반 version에서 등장하였습니다.
그러면 궁극적으로 의미론적인 상호운용성은 Standardized vocabulary 에서 담당하게 되는데, CDM은 원래 data value가 저장되지 않은 data model(schema)의 성격이 강하다고 했을 때 문제가 됩니다. 서로 다른 vocabulary(code system)을 쓰고 있다면 synonym은? code mapping은? 여기에 또 informatics에 대한 총체적인 이해기반이 필요해집니다.
그래서 이 변환된 용어체계 data를 제공해 주기도 하고, ETL 자체의 code를 open souce로 주기도 하며, 각자 visualization tool이라든가 이 CDM을 활용하는데 필요한 다양한 층위의 리소스와 인프라를 여러 연구자들이 열린 모임인 OHDSI 에 참여하면서 publish하고 share하면서 생태계를 키워나가고 있다고 할 수 있습니다.
가장 유사한 성격의 (연구목적 데이터 수집) PCORNet을 보면, national이라고 일단 scope을 못박고 있고 data model의 layer가 엄밀한 대신 __code system을 도메인별로 하나씩 지정__해 버립니다. 그러면 표현의 자율성은 줄어들고 각 기관에서의 ETL부담은 발생될 수 있지만, 예를 들어 KCD 9 code와 ICD 10 등 code를 어떻게 변환할지의 문제를 CDM 운용하는 단계에서 고민하지 않아도 되고 unambiguity의 chance는 비약적으로 줄어들게 될 것입니다.
📂 CDM과 CDW의 관계
다시 초반의 궁금증으로 돌아가서, CDM과 CDW를 왜 혼동하게 되느냐?
한 기관에서 CDM을 도입합니다. 그 말은 즉, 전술한 여러개의 CDM들 중에서 하나의 CDM type을 선택해서 그것으로 해당 기관의 data를 ETL해서 CDM DB를 구축한다는 것입니다. 그러면 최소 구성의 연구용 data storage가 생기게 됩니다.
이 DB에 사용자를 직접 붙어서 작업하게 해 줄 수도 있고, 분석계(user interface, analytics platform)를 붙여서 정보시스템을 구축해서 CDW의 백본(DB)으로 쓸 수 있습니다. CDM을 활용한 미니멈한 분석계의 구축은 CDW라는 대대적인 비용과 설계가 필요한 공사를 하지 않아도 되고 data circulation의 경험과 역량을 축적하거나 다기관연구 참여 등의 여러 이점을 가지고 있습니다. 반면 data model 백본을 기관특이성을 반영해서 설계하거나 ETL할 수는 없으며 (공동의 협의에 의해서 선정된 모델과 ETL을 사용) 접근 권한관리, ETL quality 관리, 보안 등의 설계는 별도로 기관내에서 고려, 수행되어야 합니다.
CDM =/ CDW, but CDM < one database design level option for CDW
물론 CDM이 원래 해결하고자 했던 문제인 interoperability 부분에서는 통상적인 institutional CDW가 그 기능을 할 수 없으므로, CDM만의 고유한 장점과 기능은 분명하다고 할 수 있겠습니다.
📂 사족: 결국은 informatician의 태부족
그러면 각 기관/연구자가 secondary use of clinical informatics(= RWD, RWE 포괄) 를 하기 위해서 가장 중요한 game changer는 무엇인가?
역설적이게도 informatician의 확보입니다. Science를 하는데 있어서 방법은 한가지가 아니고 무궁무진에 가깝겠지만, data science를 clinical data를 가지고 하려면 clinical informatician의 역할이 반드시 필요합니다. 전술한 환자 P씨의 어이없는 키/체중 데이터를 받았다면, 어떤 연구자라도 “이 데이터로 연구 못한다”고 할 것입니다. 그런데 record가 10만이 넘어간다면 data quality는 어떻게 확인하여 신뢰할 수 있을까요? 연구자는 “이건 아니야”하고 시스템 구축자는 “왜요?” 합니다.
원인이 ‘뭔가 상식적으로 이게 아니지 않나’를 넘어서, 무엇이 문제이며, 어떻게 해결하고, 그것을 지속가능한 정보체계로 안착시킬지는 또 하나의 전문성이 필요하며 그것이 informatics의 한 분야입니다.
그럼 왜 우리 기관에서는 확보를 안하나?? 없어서 못합니다. IT-Clinical practice-data science에다가 research까지 이해해야 CDW를 설계할 수 있습니다.. (요즘은 그래서 단순한게 아니었어! 하는 깨달음의 연장선상에서 CRDW 라고 일컬어지는 차세대 디자인에 대한 수요가 높습니다. 이건 누가 잘하고 못하고 잘 알고 모르고가 아니라 미지의 영역을 개척해나가는 분야라서 너무나 당연한 전세계적인 시행착오와 전진의 과정입니다 물론 쇠다리를 두드릴 필요는 없…)
informatics는 논리와 기술의 최전선에서 창발된 학문이자 실무로서, 성찰적이면서도 실천적인 인력의 확보가 매우 필수적입니다. 같이 일 할 사람을 많이 만들고 싶다! 그것이 저의 열망의 하나이며, 그래서 아직은 학교에 남아보고자 노력중입니다. :) 또 한가지는 연구자로서 아주 조금씩 성장해나가는 기쁨이 있는데요, 이 부분도 존경하는 선생님, 선배, 동료, 연구원분들을 만나 아직까지는 행복하게(?) 해나가고 있습니다. (인복으로 살아가는 인생!)
📂 RWD, RWE 연구를 하시는 분들이라면…
누구나 악…에 받친 데이터 클렌징과.. 무한차트리뷰.. 익명화와 암호화에 따른 답답함.. programming과 statistics의 장벽에 대한 응어리(?)가 있으실 것입니다.. 이 글에서 호불호가 느껴지셨다면 전적으로 저의 부족함임을 밝히며 CDM의 개념에 대한 기본적인 내용을 갈음합니다.
수요조사: CDM model들을 해설과 함께 읽어보고 싶은 분들이 있으시다면 어떻게든(페이스북 메세지? 여기 댓글기능? 등등..) 의사표시를 제게 전달해주시면.. OMOP/PCORnet/Sentinal CDM을 하나씩 한 번 뜯어보겠습니다.(K-CDM은 구조를 공개하신건 아닌 것 같아서. 본 블로그는 블로그에 충실하게 online 또는 학회 publish된 자료만 사용하고 있습니다.) 아니면 사실 개별 CDM구조가 굳이 도움이 될까 잘 모르겠어서 (100% 제 소견) 아주 추상적인 수준에서 IS(information system)의 구조적 이해와 data model이란 무엇인가를 한 번 설명하는 것으로 다음 2주간 포스팅을 이어갈 까 합니다. (CDSS는 다음으로 밀리겠네요.. 사실 EHR의 꽃은!)
댓글 남기기