의료 환경(경영/진료)은 급변하고 있다. 병원 규모는 커지고 특정 분야의 전문 병원들이 곳곳에 등장하고 있다. 이 같은 의료 환경에서 다음과 같은 질문의 답을 더 이상 주먹구구식 일회성 자료에서 찾다가는 생존하기 어렵다.

● 임상연구에 필요한 기초 데이터 현황은?
● 상병별, 지역 분포에 따른 남여 성비는?
● 당뇨 환자 추이(예측)는?
● 환자 규모 추세에 따른 필요 자원의 수준은?

체계적이고 일관성을 유지하도록 잘 정리된 정보 저장소가 필요한 이유이다. 우리 건국대학교 병원 역시 2002년 병원신축이 현실화되면서, Top 5 병원으로 진입하기 위해서는 보다 체계적인 정보의 관리가 중요한 이슈로 대두되었다. 

이에 의료정보팀에서는 전사적 데이터 통합/정보화를 통한 신속하고 정확한 분석 인프라를 제공하고, 경영층의 전략적 의사결정을 위한 양질의 일원화된 분석 정보를 제공하며, 의료서비스의 질 향상을 위한 진료/연구 활동에 활용하여 의료업무의 생산성 향상 및 차별화된 의료 서비스 기반을 제공할 수 있는 DW(Data Warehouse) 구축을 계획하게 되었다.

2004년 3월 운영 시스템(EMR, OCS, ERP, LIS 등)의 개발이 시작되어, 거의 완성단계에 이를 무렵인 2005년 3월초, DW 시스템 역시 그 틀을 그려나가기 시작했다. 경험과 능력을 보유한 구성원에 의한 신속한 의사결정을 위해 태스크포스 팀을 구성했고, 중요도와 활용도가 높은 부문의 선택과 집중을 통한 성공적인 가동을 목표로 프로젝트를 시작했다. 전체 구축 기간은 2005년 3월에서 2005년 12월까지 10개월이다.

약 2개월간 이루어진 분석단계에서는 사용자의 요구사항을 정의/분석, 운영 시스템 분석 등으로 요구사항 정의서, 요구사항 분석서, 현행 운영 시스템 분석서 등의 산출물이 나오기 시작했다. 물론 이 단계에서 운영 시스템에 대한 수정은 불가피했다. 그러나 다른 구축사례들과는 달리 우리 병원은, 운영 시스템이 이미 가동중인 상황이 아닌 개발 마무리 단계였으므로 수정에 그다지 큰 어려움은 없었다.

계속되는 수정요구로 운영 시스템 개발자는 괴로울 수밖에 없었고에 틀림없다. 하지만 가능한 한 분석/설계 단계에서 사용자 요구사항을 확정하여 안정적인 개, 또한 태스크포스 팀 역시 계속된 자료 요구와 몇 시간씩 진행된 회의는 힘든 여정이었다. 하지만 가능한 한 분석/설계 단계에서 사용자 요구사항을 확정하여 안정적인 개발 진행을 유도하기 위해서 모두들 끝까지 잘 참아 주었다.

이후 3개월간 진행된 설계단계 역시 매달 평균 7~10명 이상의 개발자들이 밤낮 구별 없이 아키텍처 설계서, ETCL 설계서, OLAP 설계서 등의 산출물을 쏟아냈으며, 9월말 드디어 구현이 거의 마무리 되면서, 10월초 개발자 통합테스트, 10월말 사용자시험 및 교육을 거처 11월 드디어 시범운영에 들어갔다. 이때도 역시 TFT는 운영 시스템의 데이터와 DW 보고서의 수치를 맞춰보느라 2005년이 어떻게 저물어 가는지 알 수 없었다. 한편 DW 개발팀 역시 12월까지 모든 주제영역의 가동을 목표로 박차를 가하였다.

사용자 그룹의 DW 시스템에 대한 관심과 활용 의지가 프로젝트 성공의 주요 요인으로 보고, 이를 북돋우기 위해 수차례에 걸쳐 교육과 Q&A를 실시하였고, 사용자들의 반응 또한 처음 구축해보는 DW에 대해 많은 기대와 열의가 있었다.

2006년 1월 구축사례 발표회 때 다른 병원 직원들로부터 가장 많이 받은 질문은 아무래도 “DB는 뭘 썼느냐?”, “시스템은 사양이 어떻게 되느냐?”, “사용자들은 속도에 만족하느냐?”, “적재 주기는 왜 그렇게 했느냐?” 등 이였다. 그중 단연 1위는 시스템 사양 그중에서도 소프트웨어의 구성을 묻는 질문이었다. 그 답은 <표 1>로 대신할 수 있을 것 같다. 

또한 적재 방식 역시 논리 구성도 <그림>에서 보는 바와 같이 운영 시스템의 DB에서 DW 시스템의 DB로 바로 넘어오는 것이 아니라, ETCL 툴이 운영 시스템에서 데이터를 읽어 파일을 만들어 내고, 이를 DW 시스템내의 사이베이스가 가지고 있는 로드 프로세스를  호출하여 적재되는 방식을 선택하여 운영 시스템의 부하를 최소화 하였다. 현재는 변경적재와 같이 수 초 내에 이루어지는 적재작업(Data Stage 에서 단위 Job)은 업무시간에 수행한다 해도 거의 운영 시스템의 부하를 거의 느끼지 못하고 있다.

적재작업(Job)에 대한 이야기가 나왔으니 집고 넘어가면, 적재되는 데이터의 기간에 의해 분류하면 초기적재와 변경적재로 구분했고, 수행되는 형태에 따라 단위 잡(job)과 배치(Batch) 잡(단위 잡들을 데이터가 형성되는 순서에 맞게 줄을 세워 놓은 형태)으로 구분하여 만들었다. 즉 테이블 한 개를 적재하는 잡이 2개의 형태(초기/변경)가 있고, 이를 실행시켜주는 형태가 2개(단위/Batch)가 있는 셈이다.

그리고 잡을 이루고 있는 형태도 3가지 정도로 구분할 수 있다. 먼저 가장 많은 형태인 Case1(Oracle DB -> SAM-File -> Sybase DB)과, Staging 영역에서 통합영역으로 옮기기 위한 Case2(Sybase DB -> SAM-File -> Sybase DB)와, Stored Procedure를 이용해 마트에 데이터를 쌓는 형태이다.

이 DW 시스템의 논리 계층은 우선 Staging 영역, 통합영역, 마트영역 이렇게 3영역으로 구분할 수 있다. 우선 통합영역으로의 데이터 적재 전 추출 데이터 변환 및 정제를 위한 임시 영역인 Staging 영역(Flat Model)을 두었고, 주제영역별 데이터 통합/관리와 비정형/상세 데이터 분석을 위한 통합영역(Entity Relational Model)과 다차원 분석을 위한 데이터 영역인 마트영역(Multi Dimensional Model : Star/Snow Flake)을 두었다.

우리 병원의 DW 시스템은 적재 주기를 주제영역별로 한 달에 한번 적재(Data Stage에서 월별 Batch Job)하는 것을 기본으로 삼았다. 이것은 무엇보다도 의료 환경/현실을 고려해 경영진/의료진에게 정확한 데이터를 제공하겠다는 팀장의 의지가 담겨있다. 현재 지난해 12월 가동을 위해 초기적재를 시행한 후 현재까지 전면적인 초기 적재는 한 번도 없었다. 물론 감염관리처럼 새롭게 진행 되고 있는 영역들을 위해 일부 테이블에 대한 초기적재는 심심치 않게 이루어지고 있다.

현재 소스 시스템은 위와 같이 이루어져 있으나, 소스 시스템은 현재 진행 중인 2차 개발에서 보다 넓어질 것이다. 2005년 12월까지 진행된 결과물을 보면 <표 3>과 같다. 이중에서 완료된 보고서의 형태를 보면 크게 3종류로 나눌 수 있다. 첫 번째는 OLAP 기능에 가장 충실한 형태의 비정형 보고서로 사용자가 마음대로 Dimension과 Fact를 수시로 바꾸어 가며 볼 수 있도록 만들었으며, 두 번째는 경영자들의 위한 정형보고서는 차트 등의 기능을 구현하는 대신 비정형과 같이 사용자의 구미대로 변경하는 것에는 제한을 두었다. 마지막으로 진료처방 데이터를 검색할 수 있는 진료검색으로 구성되어있다.

이런 보고서의 형태는 사용자의 사용형태에 맞게 분류하여 비정형은 주로 해당부서의 실무자들이 사용할 수 있도록 했고, 정형은 주로 경영자 층에서 사용하도록 구성했으며, 진료검색은 당연히 그 주 대상자가 의사에 한하며, 본인이 접근한 권한에 따라 검색의 한계가 존재하며, 접근 권한은 IRB(Institutional Review Board)에서 승인을 받아야 하며, 접근 권한이 주어진 범위 내에서 입력한 진단, 수술, 약물, 검사 및 검사결과를 조건으로 환자기본정보를 검색할 수 있도록 한다. 이런 진료검색은 그동안 논문 및 임상연구를 위해 본인 스스로 따로 정리해야 했던 그동안의 불편을 없애주어 기대이상의 좋은 호응도를 얻고 있다.

현재 활용도 측면에서는 12월까지 적용된 보고서들의 검증은 거의 마무리된 상태이며, 간호부 등 해당부서에서는 교육 및 Q&A를 신청하는 등 적극적인 활용의지에 DW 개발팀은 약간은 행복한 비명을 지르고 있는 것도 현실이다. 시스템 적인 면에서는 12월 1일 정식 가동을 앞두고 여러 차례 데이터를 초기 적재를 반복했고, 이후 현재에 이르기까지 매월 변경 적재를 해오고 있지만 그 속도는 예상했던 것 보다 훨씬 우수했다. 물론 운영 시스템에 쌓인 데이터가 개원 초기라 그 분량이 많지는 않지만, 이를 감안한다고 해도 Data를 추출하는 성능은 만족할만한 수준이다.

보고서 화면 역시 각종 다양한 기능이 지원되고 있어 얼마든지 훌륭한 형태를 구현할 수 있으며, 개발자 입장을 많이 고려한 것 같아 그다지 흠잡을만한 곳이 없지만, 이번 개발에서 한 가지 아쉬운 것은 SybaseIQ 자체가 가지고 있는 메모리에 대한 문제점을 아직 완벽히 해결하지 못했다는 것이다. 필자가 알고 있기로 SybaseIQ를 사용하고 있는 모든 업체에서 안고 있는 문제점인 것으로 파악된다. 하지만 이런 문제점에도 불구하고 SybaseIQ를 선택하는 것에는 그만한 이유가 있다. 바로 컬럼 단위 사상 때문이다.

일반적인 DBMS들이 Row 단위로 처리하는 것에 반해 이 DBMS는 컬럼 단위로 처리한다. 그리고 또 하나 각 컬럼의 성격에 맞는 여러 형태의 인덱스를 지원하고 있다는 것, 그로 인해 검색속도를 만족할 만한 수준으로 낮출 수 있다는 점 역시 뿌리칠 수 없는 장점이기도 하다.

현재 우리 병원에서는 DW 2차 개발을 추진 중이다. 1차 개발 당시 선택과 집중에서 높은 우선순위를 갖지 못했던 감염관리 및 진료지원부서 등의 주제영역이 앞으로 추가될 것 이므로 소스 시스템의 범위도 보다 넓고 다양해질 것으로 보인다.

2차 개발이 끝나는 내년 초쯤, 아직 완벽히 해결하지 못한 몇 가지 문제점만 해결한다면, 인몬이 이야기한 "기업의 의사결정과 계획을 위하여 사용되는 주제 지향적(subject-oriented), 통합적(integrated), 시계열적(time-variant), 비휘발성(non-volatile)인 데이터 저장고”로서의 DW를 넘어선, 가용성이 뛰어나며 변화에 잘 적응된, 그리고 안정적이면서도 빠르면서, 정확한 정보로 경영진의 의사결정 및 진료진의 진료/연구활동과 보다 정제된 의료서비스에 까지 무한한 도움을 줄 수 있는 훌륭한 지능형 DW 시스템이 될 것이라고 자신한다.

필자 ; 장성훈
건국대학교 병원 의료정보팀에서 운영시스템의 데이터베이스 분석 및 데이터웨어하우스 담당자로 근무하고 있다.