HL7 FHIR! 불타오르네~
산골짜기 의료정보학 이야기 번외편 #4
이번 번외편에서는 2019년 헬스케어 IT 분야의 핫 이슈중 하나인 HL7 FHIR를 다뤄보겠습니다.
본편의 제목에는 BTS 히트송에 묻어서 어떻게든 조회수를 올려보려는 불순한 의도가 있습니다HL7 표준의 역사와 FHIR의 탄생 배경
FHIR란 Fast Healthcare Interoperable Resources의 약자로서 HL7의 최신 진료정보교류 표준 규약입니다. 일단 HL7이 무엇인지부터 얘기하자면 미국을 중심으로 1987년에 설립된 국제적인 의료정보표준 개발 및 추진 단체입니다. 의료정보 표준화를 추진하는 단체는 HL7뿐이 아니고 다른 곳도 많습니다만, 일단 의료정보쪽 학계든 업계든 발을 담근 사람이라면 한번씩은 들어봤을 유명한 단체이고 영향력도 그만큼 크다고 할 수 있습니다.
HL7에 대해 잘못 알려진 인식으로 여기가 일종의 정부기관이다, 또는 HL7의 표준 규약은 꼭 지켜야하는 강제성이 있다라는 것인데 둘 다 아닙니다. HL7의 표준을 "Non-standard standard"라고 종종 부르는데 이는 강제성이 없으면서도 사실상 표준으로 활용되는 실정을 반영하고 있습니다. 사실 HL7의 문화는 꽤나 컴덕스러워서 거기 사람들은 규제나 통제, 영리추구같은 개념들을 싫어하고 오픈소스, 개방성, 공유, 커뮤니티 이런 개념들을 좋아하는 경향이 있습니다. 애초에 HL7이라는 단체명 자체가 컴공분야에서는 익숙한 OSI 7 레벨 개념에서 따왔을 정도이니 소프트웨어 엔지니어링 색깔이 강한 것도 자연스러운 일입니다.
HL7은 여러 표준들을 개발 및 보급해 왔는데, 개발된 순서대로 잘 알려진 규약만 정리하자면 v2, v3, CDA, FHIR가 있습니다. 즉 FHIR가 가장 막내이자 최신 규약이며 2014년에 시험 버전이 (DSTU) 나왔으니 아직도 따끈따근한 표준입니다. HL7의 표준들이 어떻게 진화해왔는지 이해하면 FHIR가 어떤 철학을 바탕으로 개발되었는지 알수 있는데, 일단 가장 오래되었으면서 지금까지도 많이 쓰이는 것은 v2입니다. v2는 아래 그림에서 보듯이 특수기호가 많이 들어가 있어 처음보면 전자공학스러운 메세지 프로토콜처럼 생겼습니다. 그러나 자세히 살펴보면 매우 직관적이라 이해하기 쉽습니다. 예제에서 19720812는 딱봐도 생년월일로 보이고 (444)677-7777은 전화번호 또는 팩스번호로 보입니다. 사실 v2에는 메세지 내부의 정보의 종류에 따라 순서를 매겨서 어느 자리에 어느 정보가 들어갈지 아예 정해 놓고 있습니다. 예를 들어 환자의 이름정보는 PID 섹션의 5번 칸에 항상 들어있어야 하며 이런 식으로 하면 보내는 사람도 받는 사람도 헷갈릴 일이 없습니다.
v2의 메세지 구조 예제 (Ref: Stan Huff)v2의 구조를 밥상에 비유하자면 식판에 담아 먹는 것과 비슷해서 밥은 아래쪽 왼쪽, 국종류는 오른쪽 아래, 메인 사이드 디시는 왼쪽 오른쪽 위, 김치는 가운데 위에 놓는다는 것을 직관적으로 알수 있습니다. 또한 정형화된 구조이기 때문에 데이터 항목의 수가 정해진 슬롯의 숫자만큼만 넣을수 있다는 것도 비슷합니다. 즉 5칸짜리 식판에는 칠첩반상을 담을 수 없으며 국을 두 종류 담을수도 없습니다. 또한 한식이 아닌 양식이나 일식을 담기에도 부적합합니다.
안 궁금해요v3는 이런 유연성과 확장성 문제를 해결하고자 개발되었는데, 일단 포맷이 기존 v2의 텍스트 스트링을 버리고 XML을 도입함으로써 구조화된 문서를 지향하게 되었고 애플리케이션 개발시에 객체지향 언어와의 궁합도 잘 맞게 되었습니다. 아래 그림은 v3 메세지의 예제입니다. 여기까지만 보면 메세지 포맷이 XML로 바뀐 것이 가장 큰 변화인 것 같지만 실제로는 XML은 전체 업그레이드의 5% 정도라고 보면 되고 진정한 변화는 Reference Information Model (RIM)이라고 할 수 있습니다.
RIM이란 의료정보가 생성되는 원천인 clinical process를 이벤트 단위로 쪼개어 Concept 과 relationship으로 표현한 것입니다. 아래 예제의 RIM 코어 모델의 엔터티들을 살펴보면 환자, 장소, 의료인 (Person)을 비롯해 Act, Participation등의 행위도 있고 심지어 디바이스, 서플라이 같은 엔터티도 있습니다. 좀 과장하면 환자가 병원에 와서 치료받는 모든 과정에서 발생하는 정보를 이 RIM 모델로 표현할 수 있습니다. 게다가 하나의 메세지에 한 항목을 하나만 담을 수 있는 v2에 비해 v3는 여러개를 담을 수도 있습니다. 데이터베이스 수업을 들으신 독자분이라면 아래의 다이어그램에서 복수의 엔터티를 생성할 수 있는 Cardinality가 정의된 것을 알아차리셨으리라 생각합니다.
RIM Core class diagramv3는 의료정보 전체를 포괄하는 광범위한 표현력, 표준용어체계와 이벤트 기반 정보 모델을 차용하고 확장성이 좋기에 비유하자면 무제한으로 다양한 음식을 담아 먹을수 있는 뷔페라고 할 만합니다. 이러한 개발철학은 v3가 개발된 2000년대의 전반적인 소프트웨어 엔지니어링 분야의 분위기를 반영하기도 하는데, 이때는 Java와 SmallTalk 등의 객체지향언어 전성시대로서 추상화된 정보 모델을 개발하고 이를 시스템에 녹여내는 주제에 관심이 많은 시기였습니다. 또한 2000년대 초반 HL7 조직은 국제적으로 규모로 갑자기 커지면서 비즈니스 관점에서도 성공을 거두게 되었고 이래저래 맞물려 v3는 기대를 한 몸에 모았습니다. 그러나.........
숨어있는 3.0 점유율을 찾아보세요릴리즈할 당시에만 해도 v2를 너무 빨리 완전 대체하게 되면 호환성 문제를 어떻게 하냐는 별 쓸데없는 걱정까지 했던 v3는 결국 참담한 실패를 맛보게 됩니다. 2009년에 나온 보고서를 바탕으로 위의 도표를 보면 v3의 도입율은 실로 미미하며 10년이 지난 지금도 별반 다르지 않고 사실상 v3로 뭘 했다는 프로젝트를 찾아보기 힘들 정도입니다.
많은 장점을 지닌 v3가 어째서 실패했는지에 대해서는 여러 보고서와 분석 아티클이 있습니다. 필자도 2013년도에 보스턴 사람들과 함께 웹서비스 기반 Genetic risk assessment를 v3로 구현하는 프로젝트하려다가 시원하게 말아먹은 전력이 있습니다. 그 경험을 바탕으로 본 v3의 문제점은, RIM은 잘 정의된 의료정보모델이지만 내용이 너무 추상적이고 개발하는 입장에서는 구체적인 "How to" 가 부족합니다. 예를 들어 두 병원간에 Family history 데이터를 v3로 송수신하는 인터페이스를 개발하는 프로젝트를 한다고 칩시다. 일단 제일먼저 RIM Clinical genomics그룹 내에는 아래 그림처럼 Family History를 정의한 RIM 모델이 있으니 여기서부터 시작해야 합니다. 그런데 이 모델은 상당히 추상적인 Conceptual Data Model 이라 어지간히 도메인 지식이 있지 않고는 여기서부터 바로 Logical data model을 만들어내기가 쉽지 않습니다. 게다가 메세지 하나 보내려면 Patient, Encounter, Provider 등의 다른 정보도 함께 보내야하는데 그러려면 다른 RIM 모델도 함께 봐야하고 이것들을 어떻게 하나의 메세지에 포함시킬지도 애매하고 등등..
RIM: The FamilyHistory ModelRIM의 추상성과 XML의 유연함으로 인해 오히려 개발자들의 학습곡선이 가팔라지고 프로젝트 기간이 늘어나고 개발 비용이 치솟아 올라갔습니다. 평균적인 v3 프로젝트 기간은 3년(!!!)이라는 연구가 있을 정도입니다. 결국 일찌감치 v3는 싹수가 노랗다는 얘기가 나오게 되면서 슬그머니 사라지게 되고 HL7은 그나마 CDA로 겨우 체면은 유지하게 되었습니다.
FHIR는 이러한 v3의 단점을 보완하고 이전의 다른 성공한 표준들, v2, CDA등의 장점을 흡수하여 개발되어 2012년부터 배포되었습니다. FHIR는 의료정보를 리소스(Resource)라고 하는 단위로 쪼개어서 어떤 의료정보메세지든지 리소스의 조합으로 만들수 있도록 되어 있습니다. 예를 들어 한명의 환자의 정보가 개인인적사항, 두번의 내원, 두번의 진단, 하나의 처방으로 이루어져있다고 하면 메세지는 다음과 같은 리소스로 구성할 수 있습니다.
* Patient 리소스 한개
* Encounter 리소스 두개
* Diagnostic report 리소스 두개
* Medication 리소스 하나
각 리소스의 항목들을 어떻게 채울지는 미리 정해진 스펙을 보고 따라하면 됩니다. 또한 Structured definition 라는 리소스를 통해 여러 개의 리소스를 구조화된 형태로 조합할수도 있습니다. 이런 특징을 보면 한정식의 상차림과 비슷한데, 밥그릇, 국그릇, 반찬그릇, 종짓잔 등 어느 용기에 뭘 담을지에 대한 개념이 어느정도 정해져 있으면서 오첩이든 칠첩이든 추가로 항목을 늘리거나 줄이는 것이 가능하고, 반찬 접시도 길거나 넙적한 것을 써도 되는 등 어느정도 유연성이 있기 때문입니다.
출처: 아워홈 블로그 - 놀러와 우리집결국 FHIR의 장점은 정확하게 이전 표준들의 단점을 보완 개선한 것이라 보면 됩니다. 예를 들어
1. 구현이 쉽고 빠르다 -> v3의 높은 개발 난이도와 긴 프로젝트 기간 문제를 해결
2. 정보의 기본단위를 명확히 구분된 리소스로 정의한다 -> RIM 의 지나치게 포괄적인 정보 범위 문제를 해결
3. 리소스를 조립, 재구성 할수 있고 Extension을 통해 보완 수정 가능하다 -> v2와 CDA의 한계점인 낮은 유연성을 보완
4. Profile이라는 것을 제공함으로써 의료 및 연구 기관들의 맞춤화된 표준 생성과 보급을 유도한다 -> 표준화의 일정 역할과 권한을 기관에게도 부여함으로서 손 안대고 코 풀수 있다 자율성과 동기를 부여한다
표준이란 것이 원래 확산되는데 일이년만 걸리는 건 아니지만 많은 장점을 지닌 FHIR도 초반 2~3년은 반응이 뜨뜨미지근한 편이었습니다. 일단 FHIR는 이름 자체가 딱 봤을때 뭐가 FHIR다 라는 느낌이 확 오지 않습니다. 예를 들어 FHIR를 풀어쓰면 Fast Healthcare Interoperablity Resources인데 Fast라는게 이게 뭐가 빠르다는 건지, 예를 들어 개발속도가 빠르다는 건지 아니면 메세지 송수신이 빠르다는 건지, 그럼 대체 무슨 특징이 있길래 빠른 건지 그렇게 와닿지 않습니다. 그냥 발음을 파이어로 맞추려고 F를 앞에 갖다붙인 같은데 아무튼 HL7은 긴 호흡으로 DSTU버전을 점점 개선하면서 FHIR를 몇년간 밀었는데, 그러다가 마침내 그 "때"가 오게 됩니다.
Interoperability의 시대와 물만난 FHIR
지금까지 FHIR와 이전 표준들에 대해서 얘기했는데 잠깐 상호운용성 (Interoperability)이야기를 해보겠습니다. 블로그 예전 챕터에서도 얘기했듯이 상호운용성이란 원래는 군의 무기체계에서 유래한 용어입니다. 예를 들어 한국군이 차세대 전투기로 서방 세계 제품이 아닌 러시아산을 도입한다고 합시다. 이때 전투기 자체의 제원과 성능도 중요하지만 그보다도 새로운 무기가 기존의 시스템에 잘 맞물려 돌아가는지 반드시 고려해야 합니다. 만약 러시아 수호이 전투기가 성능 좋다고 아무 생각없이 기체만 들여와 공중에 띄우면 수호이는 북한에서도 쓰고 있기에 우리나라의 방공체계는 이 비행체를 가상적기로 인식하고 공격할 수 있기 때문입니다. 마찬가지로 Epic EMR이 돌아가고 있는 어떤 병원에 IBM 왓슨을 CDSS로 설치하면 Epic은 이 이질적인 모듈을 적으로 알고 공격.. 아 이건 그냥 농담입니다. 농담 아닌것 같은데?
상호운용성이 최근에 각광받는 이유는 크게 두가지 정도라고 생각됩니다. 하나는 그것이 의료시스템의 비용을 절감할 수 있는 방법중 하나이기 때문입니다. 미국의 의료비가 국가재난 수준으로 높다는 것은 워낙 유명한 사실입니다. 재미있게도 의료정보시스템은 의료비를 줄이는 중요한 도구로서 인식되면서 한편으로 의료비를 올리는 요인이기도 합니다. 상용 EMR시스템의 설치 및 유지보수비는 어마어마하게 비쌉니다. 한 예로 Cerner가 작년에 재향군인병원과 맺은 가계약 금액은 $10 billon, 무려 11조원입니다. 의료정보시스템의 상호운용성이 개선되면 하나의 모듈을 한번 개발하여 다수의 사용처에서 사용할 수 있기에 규모의 경제에 의해 시스템 개발 비용이 줄어들게 됩니다. 또한 중복개발이 줄어들고 의료정보 자체의 표준화 역시 자연스럽게 이루어지는 장점이 있습니다.
또다른 이유는 상호운용성이 Physician Burnout을 해결하는 방법으로 기대되기 때문입니다. 그게 이거랑 무슨 상관이냐 할수 있는데, 일단 논리는 이렇습니다. EMR시스템이 전미에 도입되면서 의료정보가 전자화되고 표준화된 것 까지는 좋았는데 반대급부로 의사들은 시스템에 입력해야 할 정보가 너무 많아 이제는 EMR이라면 치를 떨게 되었습니다. 이게 의료비 지불시스템 및 성과와 연동되다 보니 안 할수도 없어서 환자 보면서도 넣고 보내고 나서도 방에 남아서 넣고 그외 시간 되는대로 넣고 MA 고용해서 넣고 그것도 모자라서 집에 가서도 넣는 짓을 하다보니 지쳐버리게 되었고 Burnout의 가장 큰 이유 중 하나가 됩니다. 그런데 데이터 입력문제의 많은 부분은 사실 시스템에 환자 데이터가 없어서 새로 넣는게 아니라 어딘가에 이미 있는데 그걸 불러올 수 없어서이기도 합니다. 결국 중복 입력 문제인것인데, 이를 정리하자면 상호운용성 증대 -> 기 입력된 데이터나 문서의 재활용성 증가 -> 의료인 데이터 입력 감소 -> Burnout 감소라는 선수환 개선이 이루어질 것으로 기대하고 있습니다.
여러분 저희가 EMR이 이렇게 싫어요 이렇게 중요한 상호운용성이지만 현실은 갈길이 멉니다. 일단 표준을 확산한다는 것이 고양이 목에 방울 매달기와 같아서 다들 좋은 생각이라고 말은 하지만 누군가 총대매고 돈과 시간을 써서 하지는 않으려는 경향이 있습니다. 특히 헬스케어처럼 Stakeholder가 많고 이익이 복잡하게 갈리는 분야에서는 더욱 풀기 어려운 문제입니다. 이 분야의 Stakeholder들의 상호운용성에 대한 입장을 풀어써보자면:
1. 병원/의료인: 상호운용성이 올라가면 좋지만 딱히 "내가 먼저" 거기에 돈 쓸 이유는 없습니다. 만약 우리 병원이나 내 환자가 다른 곳에서 한 진단검사를 들고 나한테 온다면 결과적으로 우리쪽의 수입이 줄어들기 때문입니다. 상호운용성이 좋은 EMR시스템을 구입하는 경우에도 그 개발비용이 도입단가에 이미 포함되어 있을테니 (결과적으로 비싸진다는 의미이니) 좋아할 리가 없습니다. 다만 인터마운틴이나 몇 군데 표준으로 유명한 기관들은 이 분야의 Leading institute라는 평판을 유지하는 것도 중요하기에 어느 정도 리서치에 투자하는 비용을 경영진 차원에서 감수하고 있습니다.
2. 보험회사: Provider와 마찬가지로 의료비용이 감소 자체는 반기지만 "내가 먼저" 돈 쓸 이유는 없습니다. 사실 의료기관과는 달리 보험회사는 100% 비즈니스를 하는 곳이기에 이들은 "우리 가입자 네트워크의 의료비용"은 감소하길 원하지만 "남의 네트워크의 의료비용"은 오히려 올라가길 바랍니다. 그래야 경쟁 보험사가 망하고 자기들이 그 고객을 쓸어담을수 있으니까요.
3. 정부: 상호운용성에 그나마 관심과 의지가 있고 돈을 쓸수도 있는 유일한 주체라고 보입니다. 문제는 미국의 헬스케어 시스템은 파악도 안될 정도로 방대하며 복잡하게 얽혀있고 운용되는지라 연방정부 차원에서 높은 수준의 통제를 하는 것은 매우 어렵습니다. 이건 단순히 돈과 제도의 문제 뿐 아니라 미국사람들은 원래 역사적으로도 연방정부가 뭘 하라고 간섭하는 걸 싫어하는 기질이 있습니다. 그러나 트럼프 정부에 들어서 상호운용성을 팍팍 밀어주려는 움직임은 매우 구체적이고 실제적입니다.
상호운용성 추진의 선봉에 선 CMS의 수장 시마 버마와 정치적 후원자 자레드 큐슈너 (트럼프의 사위)4. 개발사: 사실상 상호운용성을 시스템에 구현할 수 있는 주체이면서 입장은 2번 보험회사와 비슷합니다. 특히 메이저 EMR 개발사에게 상호운용성을 탑재하자는 얘기는 애플에게 다른 컴퓨터에서도 호환되는 커넥터와 케이블, 이어폰 만들자는 소리와 똑같습니다. 어차피 충성고객들이 사주고 비싸게 팔아서 부수입까지 되는데 그렇게 할 이유가 전혀 없습니다. 마찬가지로 메이저 EMR 회사들은 전체 마켓의 상호운용성 수준이 낮을수록 병의원들이 그나마 "자사 제품내에서의 상호운용성"이 확보된 메이저 벤더들을 더 선호할테니 그 쪽을 더 반길 가능성이 높습니다. 대표적으로 Epic의 Judy Faulkner는 상호운용성에 비협조적인 발언을 하는 것으로 유명합니다. (그러다가 일이년새 말을 확 바꿨는데 그 이유는 좀 있다가 밑에...)
우리 그냥 다같이 Epic 쓰면 상호운용성 문제같은거 없지 않겠어요 호호호 (.....)이런 상황에서 메이저 EMR개발사들, 특히 Epic과 Cerner는 2010년부터 2017년에 이르기까지 카이저, 파트너스, 인터마운틴, 메이요 등 전미 대부분의 거대 헬스케어 시스템들을 거의 쓸어담는 수준으로 접수합니다. 남은 것은 공공시장인데, 미국 헬스케어 시장의 대어인 보훈병원과 국방병원은 Cerner가 10조가 넘는 계약을 터뜨리면서 가져갔습니다. 그런데 이 여파는 좀 엉뚱한 곳으로 튀게 되었는데, 바로 구글, MS, IBM처럼 전통적인 테크 자이언트들이면서 하나같이 헬스케어 분야에서는 물먹은 회사들이 이 계약을 보고 충격을 받은 것입니다. 바로 이런 느낌인데..
우와 Healthcare IT 엄청 돈되는구나
쪼그맣다고 얕봤던 EMR 회사들은 도저히 건들수 없고 다른데서 먹거리를 찾아야겠다
게다가 공공분야는 한번 빨대 꽂으면 3대가 먹고 살수 있는데
이런 분위기를 더 고조시킨 것은 IBM왓슨이 민간 대형병원들로부터 욕먹고 퇴출된 것과 그 전에 보수적인 공공분야에서 아마존 웹 서비스가 CIA의 계약을 성사시킨 것과도 연관이 있습니다. 결국 IBM, 구글, 아마존, 세일즈포스, MS, 오라클의 6개 업체는 2018년 8월 Blue Button 2.0 Developer Conference를 계기로 백악관에 모여 상호운용성을 발전시키자는 상호 협의서를 체결하게 됩니다. 혹시 내용이 궁금하신 분들은 아래 링크를 참조하세요.
저희가 이렇게 정부돈에.. 아니 표준에 관심이 많습니다. 믿어주세요 허허허이러한 테크 자이언트의 움직임은 나름대로 합리적이고 전략적이라고 볼수 있는 것이, 이미 미국에서는 EMR시장은 완전히 포화되었고 Epic과 Cerner의 양강구도를 깰 방법은 현실적으로 없어보입니다. 하지만 그외의 헬스케어 IT 마켓, 즉 빅데이터 애널리틱스, 인공지능, 의료 클라우드, 지불시스템, 리서치 등의 시장은 이제 막 시작단계에 있어 발전 가능성이 무궁무진하며 결정적으로 테크 자이언트들의 핵심 경쟁력을 살릴 수 있는 분야입니다. 그렇다면 기존의 의료정보시스템을 굳이 건드리지 않으면서 자기들의 핵심 솔루션을 거기에 연결하는 방법이 필요한데 그것이 바로 FHIR인 것입니다. 즉 정치적, 기술적, 비즈니스 측면에서 아주 보기 좋은 그림이 그려지는데 정리하면 다음과 같습니다.
1. 우리는 우리 배만 불리기 위해 배타적인 비즈니스를 하지 않을거고요, 의료비를 낮추고 세상을 널리 이롭게 하고 싶습니다.
2. 이렇게 좋은 일 하고 싶으니 정부 계약 저희 좀 주세요. 아 그리고 인공지능은 구글, 클라우드는 아마존이 짱인거 아시죠?
3. FHIR를 써서 상호운용성 개선하는 좋은 일 꼭 하고 싶은데 저희만으로는 안되고요, 공공부문에서 국민의 세금 많이 가져가는 에픽써너도 좀 동참해야하지 않을까요? 이참에 EMR에 저희 솔루션 붙일수 있게 FHIR 인터페이스 열어주면 참 좋을 것 같은데...
그리하여 졸지에 FHIR는 거대 테크 기업들이 확 밀어주는 형국이 되어 버립니다... 이번에는 말만 하는 것이 아니라 곧이어 마이크로소프트의 Azure와 구글 헬스 클라우드에 FHIR 인터페이스를 탑재하기 시작하는 등 행동에 나섭니다. 이 분위기가 얼마가 갈지는 모르는 일이지만, 현실적으로 거대 헬스케어 IT 시스템과 솔루션들을 연결하는 방법은 FHIR 이외에 별다른 대안도 없어보이며 향후 한동안 FHIR는 날개를 달고 확산될 것으로 예상됩니다.
이 긴 이야기가 주는 교훈은 여러가지가 있습니다. HL7은 40여년의 역사를 통해 많은 성공과 더불어 많은 실패도 겪었습니다. 그러나 실패하는 경우에는 반드시 그 이유를 분석하고 단점을 보완하여 표준을 진화시켜 왔습니다. 또한 복잡하고 이익이 첨예하게 갈리는 헬스케어 생태계에서 무리하게 푸시하지 않고 언젠가 때를 만나게 될 때까지 꾸준히 지속적으로 표준을 확산시키는 노력을 해 온 결과 드디어 빛을 본 것이라 봅니다. 마찬가지로 이 분야에서 폼 안나고 티 안나지만 꼭 필요한 수많은 일들은 하고 있는 분들도 언젠가 크게 대박나시기를 기대해봅니다.
Reference
The HL7 Evolution Comparing HL7 Version 2 to Version 3, Including a History of Version 2, available at: https://corepointhealth.com/resource-center/white-papers/evolution-hl7/
Stanford Medicine Whitepaper, The Future of Electronic Health Records, available at: http://med.stanford.edu/content/dam/sm/ehr/documents/SM-EHR-White-Papers_v12.pdf
https://m.blog.naver.com/PostView.nhn?blogId=blogourhome&logNo=70174683562
