티스토리 뷰

[아키텍트 스토리]

아키텍처와 이노베이터

소프트웨어 아키텍처 정의를 위한

단계, 그리고 설계 (표준화, 상호운용성)

소프트웨어 아키텍처는 현재 상상하는 미래의 시스템과 그 발전방향, 그리고. 개발에 필요한 많은 표준안과 개발의 방향성 등에 대해서 서술하게 된다. 물론, 이러한 '영역'을 하나의 문서로만 모두 표현할 수는 없을 것이다. 이번에서는 소프트웨어 아키텍처를 정의하는 중요한 문서인 소프트웨어 아키텍처 정의서와 기타 개발에 필요한 표준안을 만드는 방법에 대해 알아보도록 하자.

 

----------------------<필자 사진>------------

신현묵 supims@gmail.com zetlos.tistory.com | 현재 명지병원 대학병원 정보통신팀 팀장과 헬스로그 이사로 재직하고 있다. 제약, 의료기기 생산업체의 정보시스템 개발 경험과 온라인 게임개발, 대형 SI에 이르기까지 경험이 풍부한 자칭 '삽질의 대가'. 현재 기존의 소프트웨어 삽질을 아키텍트로 승화시키려 노력하고 있다. 또한 현재 한국전자정보통신산업진흥회(KEA) '전자의료산업센터'의 디지털병원관련 실무추진위원장으로도 활동 중이며, 새롭게 모델을 개발하는 IT의료융합센터의 기획위원장으로도 활동 중이다. 또한, 독자들과 트위터(@zetlos)를 통한 소통을 즐기고 있다.

----------------------------------------------

 

상호운용성에 대한 중요한 이야기

 

상호운용성은 소프트웨어 설계자와 관리자의 입장에서 가장 중요한 것 중 하나다. 또한 이 개념없이는 향후에 만들어질 시스템과 소프트웨어, 서비스 부분에서는 발전 가능성 자체가 없다고 볼 수 없으며, 향후 중요한 시스템의 판단 근거가 된다.

이를 쉽게 설명하면 상호운용성이라는 것은 시스템이나 제품이 '고객'의 특별한 노력 없이도 다른 시스템이나 다른 제품과 함께 잘 동작하는 것을 의미한다.

특히 현재 필자의 경우에는 의료정보시스템간의 연계와 상호운용성에 대해서 많은 작업들을 해왔다. 이처럼 상호운용성에 대한 것은 '소프트웨어 아키텍처'에 있어서 가장 중요하고도 확고한 개념이기 때문에 이에 대해서 좀 더 많은 것을 이야기해보겠다.

 

'상호운용성은 네트워크가 곧 컴퓨터인 클라우드 시대에서 가장 중요한 개념 중 하나다'

 

보통 상호운용성을 획득하기 위해서는 첫째, 공표된 표준 인터페이스를 지지하고 지원하는 것인가와 둘째, 한 제품의 인터페이스를 즉각 다른 제품의 인터페이스로 변경할 수 있는 DLT는 브로커 서비스를 제공하는 것이라는 가장 큰 두가지 개념이 사용된다.

이 두가지의 접근방법들은 우리 주변에서 무수히 많이 볼 수 있다. 전자는 TCP/IP, HTTP 그리고 HTML과 같은 표준들이며, 후자의 상호운용성 접근방식은 CORBA와 ORB에 의해서 예증되었고, 그 방법들에 대해서 많은 곳에서 활용되고 있다.

비슷한 말로 '호환성'이라는 단어가 있지만 호환성은 표준과 양립할 수 있는 형태이더라도, 동일한 표준에 부합되는 다른 제품들과의 공동이용이 가능하다는 말로 좁은 의미의 상호운용성을 가진다고 하겠다.

이처럼 상호운용성안 다양한 측면으로 해석된다. 대표적으로 클라우드 시스템을 디자인하게 되는 경우에도 다양한 디바이스를 고려한다는 측면이 될 수 있을 것이며, 내부 시스템과 외부 시스템의 연계측면으로도 해석될 수도 있다. 이러한 상호운용성을 의료정보시스템 측면에서 한번 고려해보자.

 

두 시스템의 연동과 연계에 필요한 설계와 디자인을 한다면

 

필자는 국내의 특정도메인의 시스템들을 통합하고 정보들이 교류될 수 있는 시스템에 대한 자문을 의뢰받았었고, 그 부분에 대해서 상당부분 오랫동안 연구하고 실제 구현하려 애써왔다. 이러한 시스템을 통합하고 운용하는 것에는 상당한 표준안에 대한 이야기와 업체, 정부, 특정 도메인의 지식을 가진 집단들, 그 지식을 운용하는 단체들과의 많은 이해충돌이 발생하게 된다.

이러한 시스템을 구성하기 위한 방법들은 어떤 방법들이 있을까? 정보를 전달하고 교류하고 그 정확성을 보장하기 위한 가장 훌룡한 방법들은 어떠한 것들이 있을까? 물론 이러한 기준과 표준화에 대해서는 전통적인 방법과 이론으로 많은 것을 해결할 수 있겠지만, 소프트웨어 아키텍처를 정의하는데 있어서 가장 심각한 문제를 초래하는 것은 다음과 같은 '표준안'과 '표준'에 대한 선택이 가장 큰 문제이다.

그렇다. 가장 문제가 되는 것은 '전통적으로 오래된 표준'과 '새롭게 만들어져서 제안되는 표준'에 대한 고민이 소프트웨어 아키텍트들에게 가장 큰 고민이 된다. 과연 소프트웨어 아키텍트들은 어떤 선택을 해야할까?

의료정보시스템에 있어서 대표적으로 존재하는 기존의 표준안은 HL7(Health Level 7)인데, HL7은 정말 거대하고 잘 만들어진, 말 그대로 클라우드와 같은 표준안이라고 할 수 있다.

 

HL7

 

의료정보 시스템간의 인터페이스에는 입원, 퇴원, 진료의뢰 등과 관련된 환자 정보나 의사의 지시를 입력, 취소, 수정하는 의사지시 정보, 보고서를 생성하기 위한 보고서 정보, 기타 환자의 진료이력이나 연구소의 시험결과, 심전도 결과, 병리학 결과 등이 있다.

특히 HL7은 서로 다른 의료정보시스템 소프트웨어 애플리케이션 간에 정보가 호환될 수 있도록 하는 규칙의 집합으로, 현재 북아메리카에서는 의료정보의 전자적 교환을 위한 사실상의 표준으로 이용되고 있다.

또한 이기종 정보시스템 통합과 의료정보 교환을 위한 구현수단으로서 국가나 지역, 의료기관 모두의 요구사항을 충족하며 전 세계에서 가장 널리 쓰이는 전송표준이라고 말할 수 있으며, 국제표준화기구(ISO) 및 의료정보화분과(TC215)와의 긴밀한 협조로 의료기관 종사자, 정보시스템 개발자 등의 관련자들이 공동으로 참여하여 개발된 개방형 표준이며 사실상의 국제 표준으로 이용되고 있다.

다기종 컴퓨터에 분산된 의료정보의 대용량 정보처리라는 병원전산화의 본질적 문제 해결을 위해 현재 미국에서 의료정보 표준화에 가장 활발한 역할을 하고 있는 것이 HL7인데, HL7의 1차 목적은 서로 다른 전산시스템간의 자료전송을 최대한 효율적으로 수행하며, 그에 발생하는 전송오류를 최소로 할 수 있는 표준안의 정립에 있다.

HL7의 적용분야는 의료서비스 공급자(병원, 장기요양기관, 건강클리닉 등), 약국, 정부의 의료 관련 기관과 부서, 검사실, 의료분야 소프트웨어 벤더, 의료정보 컨설턴트 등이다.

 

 

이외에도 HL7이란 의료정보 시스템 사이에서 의료정보의 전자적 교환을 위한 표준으로 분류되고 있다.

HL7은 프로토콜의 설계 및 개발을 담당하고 서로 다른 의료 분야 소프트웨어와의 정보 호환이 가능하도록 하는 표준 제정을 위해 조직된 국제 비영리 표준화 기구로도 지칭된다. 특히 의료정보시스템 및 의료 장비 접속에 관한 표준을 제정하는 표준기관으로서 1994년 설립 이후 현재 한국을 포함한 29개국 지부를 두고 있으며, 의료정보의 전자적 교환을 위한 사실상의 ANSI 표준이라고 말할 수 있다.

HL7의 7은 ISO/OSI 통신 계층의 최상위인 7계층의 애플리케이션을 의미하며, 분산된 의료정보의 대용량 정보처리를 위해 시스템간의 자료전송을 최대한 효율적으로 수행하고, 전송중 발생하는 오류를 최소화할 수 있는 표준의 정립을 목표로 하고 있다.

1987년에 표준화 작업이 시작되어 1990년에 첫 번째 표준 버전 2.1이 발표된 이후 2001년에 버전 3 초안이 발표되어 현재 진행 중이다.

현재 개발 중인 표준으로는 보건의료정보 메시지 표준과 HL7 데이터 모델인 참조정보모델(RIM: Reference Information Model), 의사결정과 지식지원을 위한 의학논리구문(MLM. Medical Logic Module)에 관한 표준, 온라인상에서 임상정보를 교류할 수 있도록 하는 XML 타입의 데이터 구조 모델을 제시하는 임상데이터구조(CDA. Clinical Document Architecture)와 사용자 관점에서의 이기종간 산재된 독립된 애플리케이션 및 개인 정보의 통합에 관한 표준(CCOW. Clinical Context Object Working Group) 등이 있다.

HL7 메시지 표준은 메시지의 구조를 담고 있는 추상적 메시지 구조, 메시지를 전송하는 방법을 담고 있는 메시지 인코딩 규칙, 시스템 간의 데이터 교환을 위해 메시지를 발생시키는 애플리케이션 이벤트인 트리거 이벤트에 관한 명세를 기술하고 있다.

예를 들면, 한 시스템에서 트리거 이벤트가 발생하면 이 시스템에서 HL7 메시지가 송신되고 네트워크를 통해 다른 시스템에 전달되어 그 시스템에서 HL7 메시지를 수신한 후 수령했음을 나타내는 신호를 되돌려주게 되고 원래의 시스템이 이 신호를 수신함으로써 시스템간 메시지 전송이 완성되는 형태를 보여주는 것이다. HL7의 CDA는 HL7 참조정보모델에 기반해 방사선 기록지, 경과 기록지, 임상 요약, 입/퇴원 요약지 등의 많은 종류의 의료문서유형을 지원하기 위한 통합 정보 모델로 이용되기도 하는데, XML을 사용하여 기계 및 사람이 읽을 수 있도록 한 것이 특징으로 현재 2.0 버전이 ANSI에 승인되어 있다.

 

 

그동안 HL7 구현에 필요한 도구들이 많이 개발돼 있으나, 매우 복잡하기 때문에 구현하기 어렵다는 문제점이 있다. 그리고 한국의 의료환경에 근거한 구체적인 각 분야별 임상데이터구조(CDA. Clinical Document Architecture)의 제안이 시급한 부분이 있다.

여기에서 HL7의 전통적인 문제의 핵심은 는 그 동안 너무 많이 개발되어서 매우 복잡하고 구현하기 어렵게 되었다는 부분이 가장 큰 문제다. 과연 이러한 방향으로 메시징을 교환하는 시스템을 구현하는 것이 합당한 것일까?

 

의료정보표 중에 'CCR 표준' 있다

 

CCR(Continuity of Care Record)은 ASTM(American Society for Testing and Materials) International, MMS(Massachusetts Medical Society), HIMSS(Health Information Management and Systems Society), AAFP(American Academy of Family Physicians)가 처음으로 연합해서 공동개발을 시작한 표준사양이다.

현재는 앞서 언급한 기구 외에도 수많은 단체들이 공동으로 표준개발에 참여하고 있다. 이것은 환자관리의 연속성을 촉진 및 향상시키고 의료과실을 감소시키며, 환자를 다른 병원으로 보내거나 다른 의료서비스 제공자가 환자를 맡았을 때 의료정보의 이동성에 대하여 보장하기 위한 최소한의 표준이다.

 

<그림 > CCR기반의 환자 정보 교환 예

 

의료서비스제공자가 환자를 처음 맡게 되는 초기에 쉽게 환자에 대한 정보를 알 수 있게 해주고, 환자가 다른 의료서비스제공자에게 갈 때 쉽게 정보를 갱신할 수 있게 해줌으로써 안전성과 의료품질 그리고 환자진료의 연속성을 지원하는 것이 CCR의 목표다.

이를 통해 CCR은 의료제공자, 의료기관 또는 서로 다른 기관들 사이에서 임상정보를 교환할 수 있는 매개체가 될 것이다.

또한 이것은 최근의 진료에 대한 간단한 요약 정보로 환자들이 사용할 수 있게 되면서 환자진료의뢰, 환자이송, 퇴원 또는 환자가 다른 의료서비스제공자에게 가게 될 때에 의료종사자들이 관련 정보를 찾는 어려움을 겪지 않아도 될 것이고, Lab 실험과 평가 등의 반복을 줄여줄 수 있게 됨으로써 진료효율을 증대시키고 진료비용을 감소시킬 잠재력을 가지고 있다.

투약정보나 알레르기 정보와 같은 중대한 데이터를 쉽게 얻을 수 있게 함으로써 환자의 안전을 지원하고 의료사고를 줄여줄 수 있다.

환자에게 초점이 맞춰져 있고, 환자가 자신의 의료정보를 쉽게 알 수 있게 해주고, 환자의 의료정보를 계속해서 반복적으로 의료기관에게 제공해야 할 필요가 없어진다.

개인의 의료정보와 자가관리정보를 통합적으로 관리할 수 있는 개인건강기록(PHR)을 정착시키는 것을 도와줄 것이고, 환자가 자신의 의료정보에 더 관여하고 잘 알 수 있도록 해줄 것이고, 환자가 자신의 의료정보 전송에 관여하게 함으로써, 환자의 참여를 장려하고 의료제공자와 환자의 관계를 개선시켜 줄 것이며, 더 나아가 연구나 공공 건강활동 등에서도 다양한 활용이 가능하다.

간단히 말하면 이 표준에는 환자정보와 의료서비스제공자 정보, 보험정보, 환자의 건강상태정보(예를 들면 알레르기, 투약, 맥박, 호흡, 체온, 혈압, 진단, 최근의 처치 등)나 사전의료지시, 미래의 진료 계획에 대한 조언, 환자진료의뢰의 이유 등의 정보가 들어있다. 이러한 최소한의 데이터는 환자에 대한 가장 관련성 깊은 정보를 주고받는 방법을 제공해줌으로써 진료의 연속성을 향상시켜 줄 것이다.

환자가 외래환자이건 입원환자이건 의료진이 다른 의료진으로 바뀔 때 의사, 간호사, 그리고 의료보조서비스 제공자들이 CCR을 작성할 것이다. CCR은 XML 표준 문서이기 때문에 기계와 사람이 읽을 수 있으며, 데이터 내용이 여러가지 형식(웹 브라우저, PDF 리더, 문서작성기 등)으로 표시되거나 인쇄될 수 있다.

특히 CCR은 환자의 건강관리와 관련해서 가장 관련성이 높은 사실들을 모아놓은 핵심 데이터를 시간에 따른 스냅샷으로 저장한 것으로 의사가 의료행위를 마치면 기록이 되고 다음 의사가 쉽게 그 정보를 알 수 있도록 해준다. 종이나 전자적인 방법으로 만들어지고 표시되고 전달될 수 있다.

이외에도 CCR은 적절하고 간결하게 구조화된 최신의 정보를 제공하며 지정된 XML 코드를 통해 시스템 사이에서 상호 운용될 수 있고, 환자에 대해서 거의 모르고 있는 의사가 있는 완전히 다른 환경으로의 중개역할을 하고 있으며 장기요양, 급성치료, 질병관리, 개인건강기록 등의 특정 영역에 대한 내용은 확장장치(Extensions)를 통해 처리할 수 있다.

CCR의 표준 개발 활동은 ASTM International, MMS(Massachusetts Medical Society), HIMSS(Health Information Management and Systems Society) 등과 같은 후원단체들의 컨소시엄으로 진행되고 있다.

이러한 활동은 환자 중심적(시스템이 무엇을 해야 하는가가 아니라 어떤 환자정보가 가장 관련이 깊은가에 대한 것)이고 한편으로는 의료제공자 중심적(어떤 정보가 가장 관련이 깊은가를 의사가 결정하는 것), 콘텐츠 중심적(훌륭한 환자관리서비스를 하기 위해서 의료제공자가 무엇을 알아야 하는가에 중점을 두는 것) 이다.

이러한 활동은 또한 ASTM과 HL7과 같은 기구들과 의료전문 기관들과 의료 종사자들, 의료서비스 제공기관, 의료장비 및 의료정보시스템 개발사들의 상호 협조를 이끌어내도록 하는 등, 다양한 그룹들이 CCR을 개발 및 구현하고 상호 운용성을 확인하며 데모 프로젝트를 개발하는데 함께 일하고 있다.

CCR은환자의 일생에 걸친 건강상태와 건강관리 정보를 전자적으로 저장하는 EHR과 같은 완전한 의료기록이 아니며 유일한 값을 갖는 환자 식별자(ID)를 가지고 있지도 않다. CCR은 경과에 대한 기록이나 퇴원요약정보나 진찰상담 자료가 아니다.

이러한 자료들은 핵심적인 데이터를 지정된 XML 코드로 표현하여 정의한 것일 뿐, 한명의 의사로부터 나온 정보에 국한되어 있지 않으며, 자유로운 텍스트 기반으로 작성된 것도 아니다.

CCR은 환자의 문제 목록, 알레르기 등 환자의 건강상태와 보험, 처방문서 및 처치계획 추천 등 진료의 연속성에 필요한 필수적인 요소만 포함하여 환자에 대한 요약정보를 지원할 수 있는 구현이 용이한 정보모델이다. (CCR에는 환자의 건강문제, 투약, 알레르기와 보험, 사전의료지시, 진료 문서, 환자 진료 계획과 같은 건강상태정보가 기본적으로 요약돼 있다.)

CCR을 전자적으로 교환하는 것을 보장하기 위해서 CCR을 생성할 때 XML 형식을 사용한다. 이 지정된 XML 형식을 사용함으로써 다양한 방법으로 CCR을 만들고 전송하고 확인할 수 있다.

예를 들어 HL7의 CDA와 호환되는 문서로서 브라우저로 확인할 수 있고, PDF 파일이나 HTML 파일이나 또는 문서작성기의 문서로서 보안메일에 들어갈 수도 있다. 또한 CCR에 들어있는 필드들은 다양한 형식으로 표시해 줄 수 있을 것이다.

이외에도 CCR은 환자와 관련된 인적 사항과 특정한 한 시점에서의 진료정보를 나타낸다. ASTM과 다른 표준개발기구와의 협력으로 확립된 XML 스키마를 사용하게 되면, 적절히 설계된 전자의무기록시스템은 모든 CCR 데이터를 임포트/익스포트 할 수 있게 되어 의료종사자들의 업무에 혼란을 최소화하면서도 진료정보 전달을 가능하게 할 것이다. 그리고 서로 호환되지 않았던 전자의무기록시스템들 간의 CCR 데이터의 교환도 가능해질 것이다. 미리 지정된 XML 코드를 사용함으로써 CCR은 상호운용성을 확보할 수 있기 때문에 서로 호환되지 않았던 서로 다른 전자의무기록시스템들 사이에 CCR을 교환할 수 있게 되어 전자의무기록시스템의 확산에 기여하게 될 것으로 보인다. XML을 사용함으로써 CCR은 브라우저나 HL7의 CDA 호환 문서나 이메일, 기타 XML 기능을 갖춘 문서작성 소프트웨어 문서 등 다양한 형태로 만들어져 전송되고 확인할 수 있기 때문이다.

또한 CCR은 종이문서로 인쇄될 수 있고, 이동식저장장치에 저장되어 개인건강기록으로 사용할 수 있다. CCR에 들어있는 데이터는 환자 데이터이며 만일 그러한 데이터로 환자를 식별 가능하다면 CCR 문서의 보전성과 비밀성을 End-to-End로 유지/제공해야 하고 규정이나 기타 안전, 보안 또는 개인정보 보호 기준을 따라야 하는데, CCR의 구조와 필수적인 핵심요소는 다음과 같다.

 

===박스 | CCR 구조 및 필수핵심요소 =======

 

 

Header or Document Identifying Information

- 진료의뢰를 하는 즉, "from" 임상의 에 대한 정보

- 진료의뢰를 받는 즉, "to" 임상의 에 대한 정보

- 문서의 일자

- 문서를 작성한 목적과 진료를 의뢰하는 이유

 

Patient Identifying Information

- 진료를 의뢰하는 프로세스와 병원, 개인병원, 가정 등 어떠한 종류이건 진료 환경에서 환자를 이송하는 과정 중 환자를 식별하고 구별하기 위해 필요한 정보. 중앙집중식의 시스템이나 국가적인 환자 식별자가 아니라, 연합된 형태나 분산된 형태의 환자식별 시스템에서 사용되는 식별정보를 담고 있다.

 

Patient Insurance and Financial Information

- 의료보험 관련 정보.

- 보험의 보장범위에 대한 환자의 자격을 알 수 있는 최소한의 기본 정보.

 

Advance Directives

- 사전 의료 지시.

- 소생술을 허용할 것인지 또는 제한할 것인지를 의미.

 

Patient's Health Status

- 진단/문제/질병 정보를 중요성 순서대로 또는 시간 순서로, 보통의 언어로 또는 선택된 코드체계에 기반한 코드로 묘사.

- 발병일, 가장 최근의 해결일, 상태, 질병을 환자가 인식하고 있는지 여부, 가족력 등

- 부작용 / 알레르기

- 최근의 투약

- 면역조치

- 맥박, 키, 몸무게, 혈압, 체온, 호흡 등

- Lab 테스트 결과

- 처치 / 평가

 

Care Documentation

- 환자가 임상의를 만난 상세 기록

 

Care Plan Recommendation

- 계획되어 있는 테스트, 절차, 투약계획

 

Practitioners

- 환자 관리에 참여했던 건강관리 의료종사자에 대한 정보

- Conditions / Diagnoses / Problems 와 Care Documentation 접촉정보에 대한 링크

 

============ 박스 끝=================

 

 

 

특정 의료기관에 특화된 정보, 임상 전공분야에 특화된 정보, 특정 질병에 특화된 정보 또는 질병관리지침 등, 의료비 지불인에 대한 정보, 환자가 입력한 개인건강기록(PHR) 등의 내용을 기록하기 위해 추가적으로 확장할 수 있다.

환자와 관련된 어떠한 정보라도 수용할 수 있는 유연성을 가진 CCR은 Top-Down의 접근방식이 아니라 최종사용자 즉, 의료종사자들이 설계에 참여해왔다. 최종사용자들을 대표하는 기관(직접 종사하거나, 조언하거나 지원하는)에서 지원을 받고 있다. 따라서 의료종사자, 의료서비스 제공기관, 환자, 벤더, 그리고 다른 이해관계자들이 CCR을 당면한 문제에 관련하여 적절히 운용할 수 있는 매우 유익한 것으로 인식하고 있다.

전자의무기록의 데이터 구조에 관한 다른 표준으로는 호주의 openEHR 시스템을 참조해 개발한 13606 표준인 Archetype 표준이 있다. 13606 표준은 EHR 커뮤니케이션을 위해 5개 부분으로 나눠 개발이 진행되고 있다.

EHR을 전송하는 기본단위를 EHR Extract라고 정의하고, EHR Extract를 효과적으로 만들어내기 위해 Reference Model과 Archetype Interchange Specification을 제안하고 있다.

또한 이 두 모델에서 사용되는 속성과 타 표준이나 명세와의 호환성을 위해 Reference Archetype and Term Lists를 제시하고 있다.

 

HL7, CCR 과연 어떤 표준안을 선택할 것인가

 

필자는 단언한다. 실제 사용이 가능한 방식은 무엇이며, 표준화라는 것은 얼마나 많은 제약이 존재해야 하는가에 대해서 반문하고 싶다. 마찬가지로, 소프트웨어 아키텍처정의서나 아키텍트들이 개발전반적으로 규정해야할 기준에 대해서 이야기를 한다면, 어느 정도의 표준과 그 방식과 양식을 규정해야하는가 인데, 이 부분은 간단하게 '진료정보전송표준'으로 정리해볼 수 있다.

 

==== 박스 | 진료정보전송표준 ==============

 

 

HL7 CDA (Health Level 7 Clinical Document Architecture)

- HL7 Reference Information Model(RIM)에 기반해 방사선 기록지, 경과기록지, 임상요약, 입퇴원 요약지 등의 많은 종류의 의료문서 유형을 지원하기 위한 통합 정보 모델

- 구현하기 어렵고 복잡한 표준모델

 

ASTM CCR(The American Society for Testing and Materials Continuity of Care Record )

- 환자문제리스트, 알러지 등 환자의 건강 상태와 보험, 처방문서 및 처치계획 추천 등 진료의 연속성에 필요한 필수적인 요소만 포함하여 환자 요약을 지원할 수 있는 정보모델

- 구현하기 용이한 정보모델

 

한국EHR 핵심 공통기술연구개발 사업단

- 국내 EHR을 위한 진단검사, 투약, 진료정보요약 진료정보 교류 표준 분석과 구현지침을 최초로 개발하고, use case 연구를 통한 현장 도메인과 다양한 표준과의 gap을 분석

- 모두 HL7을 기반으로한 정보모델을 기반한 표준을 적용.

 

============ 박스 끝 =======================

 

필자는 '한국 EHR핵심 공통기술연구개발 사업단'의 연구 결과물에 대해서는 긍정적인 시선을 가지며, 훌룡한 연구였다고 생각한다. 하지만, 이러한 '학계의 이론'방식에 의한 연구결과물을 실제 의료산업계에 전파하기에는 무리가 있다고 생각한다. 필자가 생각하는 표준화의 방향은 3가지다.

 

1. 표준화의 방향성

2. 상호운용성을 어떻게 획득할 것인가

3. 적극적인 운용테스트는 어떻게 할 것인가

 

분명, '정보시스템'단위의 병원의 각종 진단 코드 및 검사코드 등의 표준화는 매우 중요하다.

하지만, 이러한 '정보'들이 의료정보교환표준화라는 측면으로 접근되게 되면, 실제 구현과 처리를 위해서 정말 많은 이해당사자들과 접하게 되고 그러한 환경에서 표준화의 방향성을 가지고 진행해야 한다.

 

 

소프트웨어 아키텍처 세부 표준화

 

필자는 SA설계의 기초에 대해 먼저 표준화가 이뤄지면 모든 것이 해결되는가를 묻고 싶다. 표준화라는 명세가 존재한다고 해서 실제로 개발이 통제되고, 실제 시스템에 해당 내용들이 반영되는지에 대한 여부를 따져본다면, 그렇지 않다라고 생각하기 때문이다.

소프트웨어 개발은 점진적으로 사람과 사람의 소통 속에서 만들어지는 것이다. 때문에 단순히 표준화의 명세화만을 통해서는 조직과 아키텍트에 스며드는 실제 표준화가 제대로 이뤄질 수 없기 때문이다.

더군다나 고급개념과 이상적인 개념으로 투영된 소프트웨어 아키텍처와 수준 높은 표준안은 어떻게 해도 검증할 방법이 난해한 것이 현실이다.

이 뿐만이 아니다. 단일 소프트웨어 개발의 경우에는 그나마 실제 아키텍트가 해당 개발조직을 통제할 수 있으나, 대표적인 표준안들의 경우에 Paper specification은 누가 구현하고 어떻게 검증할 것인지와 같은 난제가 발생한다. 이에 대해 소프트웨어 아키텍트는 이러한 표준화의 방향에 대해서 테스트와 검증방법까지 제시하고 운용할 방법을 제시할 수 있도록 하는 것이 소프트웨어 아키텍처를 만드는 가장 중요한 개념 중 하나라고 보면 되겠다.

이처럼 표준화를 어떻게 만들어내느냐는 단순한 표준방안을 선택하는 것 이상의 선택의 어려움을 가지게 된다. 다양한 표준화방향에 대해서 고민하고 그것을 시스템에 반영하는 것 그것이 소프트웨어 아키텍트의 임무이다.

 

SA설계란 무엇인가

 

이제 SA설계에 대해 정리해보자. SA 설계는 크게 인터페이스 정의, 요구사항의 우선순위 파악, 고객의 요구사항 파악이라는 3가지 정의로 축약할 수 있다.

시스템적으로서의 주요한 부분은 시스템과 사용자간의 UX도 인터페이스요, 컴포넌트와 컴포넌트사이의 인터페이스, 모듈과 모듈의 인터페이스이며 더욱더 중요한 것은 '요구사항'에 대한 반응이다. '고객의 요구사항을 어떻게 명확하게 파악'할 것이며, 그 요구사항의 '우선순위'를 정확하게 파악하는 것이 정말 중요한 SA설계의 요소인 것이다.

SA설계의 기초단계는 <화면 1>과 같이 사용자들의 요구사항을 수집하고, 리스트를 관리하며, 요구사항 리스트에서의 작업 우선순위를 결정한 뒤 품질 요소를 결정하는 것이다.

또한 이러한 요구사항들을 통해 요구사항의 변경지표 및 시기, 변화의 내용들에 대해서 대응해야 하는 것이다. 사용자의 요구사항들은 중요한 UX와 컴포넌트들간의 연관관계에 지대한 영향을 끼치게 하므로, 사용자의 요구사항을 명확하게 관리하는 것이 최선의 프로젝트 품질요소지표로 작용한다.

해당되는 요구사항들에도 개발의 우선순위, 기능적인 우선순위, UX의 우선순위, 개발비용의 우선순위, 위험요소의 우선순위라는 각각의 우선순위가 있다. 이러한 요소들을 고려해 다양한 프로파일링이 가능하게 되는 것이다.

<화면 2> SA설꼐의 3단계

 

<화면 2>는 SA설계의 3단계를 중요한 지표로서 서술한 그림이다. 가장 중요한 내부적인 SAD(Software Architecture Document)와 설계적 의사결정문을 구성하기 위해서 다음과 같은 중요한 3가지의 단계를 거치는 것을 의미한다.

 

하나. 작업우선순위

둘. 내부/외부 반복 프로세스 수립

셋. 업무 서브 도메인별 반복적인 분석/설계 과정의 대량생산체계수립

 

앞서 언급된 3가지 단계는 기능/비기능과 이에 파생되는 유지보수 단계 및 개발과 테스트, 아키텍처의 구성형태에 영향을 주는 작업의 우선순위에 대한 파악이 그 첫 번째이며, 중요한 요구사항들이 반영될때에 해당 프로세스에 대한 영향을 개발조직 내부와 업무조직 내부의 요구조건, 외부의 법이나 기타 연관관계에 따른 요구사항의 변경들에 대한 영향의 변화에 대한 프로세스들을 수립하는 것이 두 번째다. 또한 실제, 분석/설계시에 대량생산과 수집, 패턴화가 가능한 요소들을 도출하는 것이 그 세 번째가 되겠다.

 

이번 컬럼에서는 SA설계의 기초적인 프로세스의 흐름과, SA설계를 위한 기본적인 생각의 흐름 및 중요 요구사항 등에 대응하는 방법들을 알아봤다.

SA에서 가장 중요한 것은 이 요구사항을 어떻게 아키텍처에 반영하고 이를 어떤 기능/비기능으로 구분하여 관리할 것이며, 그 단계와 분석/설계에 대응하는 실제 개발팀에 대한 통제방법들에 대해서 고민하고, 실제 개발/유지보수 할 조직에 대한 예측을 해야 한다는 것이다.

다만 아키텍트는 이러한 계획을 수립하고 필요 가이드라인을 구성할 때에, '불필요한 절차와 행위'에 대해서 독자적으로 구성하지 말고, 실제 수행할 개발조직과 팀원들과의 대화와 타협에 의해서 이를 구성하는 것이 가장 최선임을 잊어서는 안된다.

언제나처럼 이야기하지만, '형식을 고집하는 삽질을 하는 아키텍트'가 안되기를 기원한다.

 

댓글
댓글쓰기 폼