2021년을 보내며
산골짜기 의료정보학 이야기 단상 모음
지난 몇년간 블로그를 재미있게 읽어주시는 분들 덕분에 많은 글들을 열심히 써왔는데 최근에는 너무 힘들어서 페이스북 중심으로 짤막하게만 글을 쓰게 되었었습니다. 이 포스트는 올해 페이스북에 올렸던 짧은 글들을 모아서 저장하기 위해 만들었습니다.
----------------------------------------------------------
Amazon Health Lake (2021년 1월)
아마존의 새로운 빅데이터 플랫폼 HealthLake의 Preview 버전이 나왔길래 살짝 리뷰해봅니다.
1. HealthLake란?
쉽게 생각해서 AWS 클라우드 상에서 동작하는 통합형 헬스케어 데이터 리파지터리라고 생각하시면 됩니다. Lake라고 하니 예전에 잠깐 떴다가 말았던 Data Lake 생각나시는 분들 있으실텐데 개념 자체는 비슷합니다. 여러 형식과 소스로부터 나온 데이터를 어느정도 분석을 위해 모으고 정제하기 위해 일단 한곳에 가둬두는 개념입니다.
최신 기술이 뭔가 좀 노래방 감성같지만 넘어갑시다2. 뭐가 다른가?
요새 핫한 기술과 트렌드인 클라우드, HIPPA compliant, 머신러닝, NLP, FHIR 등의 개념을 모두 탑재했습니다. 이것들은 경쟁사인 Microsoft Azure 클라우드나 Google HealthAPI에서도 제공되며 완전히 새로운 내용은 없지만 FHIR의 Analytics 관련 최신 기술을 도입한 것이 눈에 띕니다.
미국에서는 지난 3월에 21세기 치유법의 일환으로 ONC의 Interoperability rule이 공표된 후 클라우드 업체들이 자사 서비스에 FHIR 관련 기능들을 보강하고 의료정보 분야에서 적극적으로 홍보해왔습니다. 그런데 실제로 프로젝트에 들어가보면 두 가지 현실적인 문제를 해결해야 하는데, 하나는 Data import 문제로서 병의원이나 모바일에 있는 원 데이터를 어떻게든 FHIR로 변환하여 클라우드에 올려야한다는 것과, 일단 저장된 FHIR 형태의 데이터를 ML등에서 돌릴수 있도록 Analytics관련 기능이 제공되어야 한다는 것입니다. 여태까지 MS나 구글은 FHIR API 자체만 강조했지 실제로 데이터를 어떻게 넣고 뺄것인가 등의 얘기가 빠져있었는데 HealthLake는 Bulk 데이터 송수신, Import, mapping, FHIR query 등의 기능이 많이 보강되었습니다.
3. 왜 FHIR를 중점적으로 보강했나
코로나때문에 6개월 연장되긴 했으나 미국의 의료기관 및 EMR벤더들은 2022년까지 ONC Interoperability rule 기준을 충족하는 오픈 API를 만들어서 제공해야 벌금을 피할 수 있습니다. 오픈 API는 크게 세가지 형태로 구현할 수 있는데, 하나는 오픈 API가 탑재되어 제공되는 EMR을 도입해서 쓰는 방법 (Epic, Cerner, AllScripts 빅3는 이미 작업을 다 끝냈습니다), Intersystems, Firely, Interoperion 등 FHIR 관련 컨설팅 회사의 지원을 받아 병원 자체적으로 FHIR 레이어를 구축하는 방법, 마지막으로 오픈 API를 제공하는 Healthcare cloud에 의료기관의 시스템을 통째로 올리는 방법입니다. 세 번째 방법이 클라우드 업체들이 쌍수 들어 환영할 비즈니스 모델입니다. 이들은 그동안 보수적인 의료 분야의 특성상 데이터를 의료기관 밖으로 빼서 자사의 시스템으로 끌어오는데 애를 먹었는데 마침 딱 좋은 계기가 생겼습니다.
4. 가격 및 성능
아름답습니다. 명불허전 AWS 세글자로 더 말이 필요업...
5. 전망
지난 2018년 백악관의 Blue button 컨퍼런스 이후 여기에 참석했던 6대 테크 자이언트 (아마존, IBM, 구글, 세일즈포스, MS, 오라클)들의 FHIR 관련 행보를 보면 일단 IBM, 오라클, 세일즈포스는 일찌감치 손 놓았고, 나머지 셋 중에 가장 빠른 행보를 보인 것은 MS로서 2019년 AZURE for FHIR API 서비스를 내놓으면서 먼저 치고 나갔습니다. 그런데 잘 만들어 놓기는 했으나 그걸로 뭘 했다는 얘기는 안 나오고 있습니다. 구글은 구글답게 머신러닝에 붙일수 있는 Analytics에 특화된 FHIR 저장소와 개발자 친화적인 서비스를 만들어놨는데, 헬스케어 분야가 그렇듯이 메이저 병원이나 의료정보시스템과 같이 뭘 하지 않으면 아무리 좋은 물건이라도 제대로 된 레퍼런스가 나오지 않습니다. 그래서 애플은 AppleHealth 초기부터 Mayo와 협력했으며 Google은 레퍼런스가 업계 1위인 Epic과 파트너십을 맺으려했으나 결과는..
그런 반면 Cerner는 착실히 자사의 EMR을 다른 벤더들과 연결하여 Telehealth는 암웰, Visualization은 Tableau, 클라우드는 아마존으로 연결된 수평계열화가 거의 완성단계에 이르렀습니다. 의료기관 입장에서는 위의 오픈 API 구현방법 중 첫번째와 세번째를 통합한 방법이 생기는 셈인데, "우리 클라우드에 EMR을 올리면 비용도 확 줄어들 뿐 아니라 골치아픈 Interoperability rule도 한번에 대응 가능함"이라는 상호 윈윈하는 매력적인 솔루션이 되었습니다. 이번 HealthLake의 파트너사 목록에도 Cerner가 1번으로 올라와 있고, 이는 미국 30%의 환자 데이터를 쥐고 있는 Cerner EMR의 AWS 이전을 완성한 후 HealthLake에 저장된 데이터를 바탕으로 FHIR API를 제공하여 써드파티들로 하여금 앱을 개발하게 하면 장기적으로 애플 앱스토어같은 생태계 구축까지 노려볼 수 있게 되었습니다. Cerner는 자사의 (있으나마나한) HealthEIntent나 HealthEAnalytics같은 구색맞추기용 Analytics는 갖다버리고 아마존의 강려크한 빅데이터 파워의 덕을 볼 수 있게 되었습니다. HealthLake가 Preview 끝나고 Production 으로 가면 앞으로 어떻게 발전할지 기대됩니다.
미국 병원들의 M&A와 상호운용성의 가능성 (2021년 2월)
아는 사람들은 아는 이야기인데 필자는 원래 학부 졸업 후에 바로 취업해서 현대차에 2년 다녔었습니다. 입사 후 신입사원 연수를 갔더니 어느날 본사에서 나온 상품기획팀장이 자동차 산업의 미래에 대해 굉장히 인상깊은 프리젠테이션을 했는데, 그분이 첫머리에서 아래와 같은 책을 소개했습니다.
The End of Detroit: How the Big Three Lost Their Grip on the American Car Market
정확한 내용은 기억 안나지만 얼개는 디트로이트의 공룡같은 거대 자동차기업 BIG 3가 조만간 망하고 전체 자동차업계가 인수합병을 거듭하여 TOP 5정도로 뭉치게 될 것이다. 이 전쟁에서 중립국따위는 있을 수 없고 오직 남한테 먹히느냐 내가 먹느냐의 사활을 건 싸움이 시작될 것이며 회사가 승리하기 위해서는 앞으로 신입사원 너희들을 사정없이 갈아넣겠... (...) 아무튼 그게 벌써 20년 전의 이야기인데 이 책의 예측은 그대로 실현되어서 한때 일반인들이 알만한 이름만 50개 남짓했던 자동차 메이커는 현재 대부분 "폭스바겐 그룹" "BMW 그룹" "현대기아차 그룹" 등의 초거대 기업집단으로 남았습니다. 지금 생각하면 참 선견지명 있었던 책이었습니다.
하지만 그 책의 저자도 이 사람이 나타날 줄은 몰랐겠지최근의 미국 의료계는 20년전 자동차업계에서 벌어졌던 일이 똑같이 반복되는 것 같은데, 해마다 각 지역의 대형 헬스케어 시스템들이 서로 인수합병하는 속도가 점점 빨라지고 규모도 커지고 있습니다. 유타주에서만 45년을 서비스했던 인터마운틴 헬스케어도 최근 3년간 밑으로는 네바다 위로는 아이다호로 인수합병을 통해 확장했고 결국 깨지기는 했지만 작년에는 사우스다코타 기반의 샌포드를 인수하여 중서부 전체로 확장하려는 시도도 했습니다. Beckers hospital등 뉴스에서 보면 요새 한번 인수합병하면 몇십개 병원과 종업원 몇만명 정도는 우습게 합쳐지는 수준이고 이대로 가면 저희 병원에서도 앞으로 십년쯤 뒤에는 전미에서 Top 10 정도만 남게 될 것이라는 얘기가 공공연하게 나옵니다.
이런 움직임의 이면에는 여러 이유가 있지만 기본적으로 의료기관의 리더들은 인수합병을 자신들의 생존의 문제로 보고 있다고 합니다. 이는 즉 외부로부터의 강력한 위협이 있다는 뜻인데, 아이러니하게도 이 위협의 근원은 같은 의료계 내부에 있지 않습니다. 즉 의료기관의 미래의 적은 라이벌 의료기관이 아니고 그동안 적이라고 생각하지 않았던 다른 분야의 비즈니스들과 기업들입니다. 이들은 Primary care, Urgent care, Telehealth, Online pharmacy, Behavioral health등에서 전방위적으로 기존 의료 분야 영역을 침범해 들어오고 있습니다. 물론 아무리 비의료영역에서의 헬스케어 사업 범위가 커진다고 해도 핵심 의료인 Acute care, Critical care, Oncology 등을 아마존이나 텔라닥 따위가 넘볼 수 없다는 것이 지배적인 생각입니다. 그럼에도 불구하고 이것이 생존의 문제인 이유는 두 가지인데, 하나는 미국 기준으로 헬스케어 분야에서 Primary care의 비중이 매년 급격히 커지고 있기 때문이며 둘째는 헬스케어가 다른 사업과 마찬가지로 급격히 플랫폼 비즈니스화되어가고 있기 때문입니다. 결국 전체 파이가 급격히 커지는 와중에는 의료기관이 핵심의료 영역을 수성한다고 해도 본전치기도 되지 못하며 궁극적으로는 헬스케어 플랫폼을 차지하는 승자 플레이어의 컴포넌트로 전락할 가능성도 충분히 있는 것입니다.
이에 대응하기 위한 의료기관의 전략은 첫째는 인수합병이며 둘째는 수평계열화입니다. 실은 둘다 결국은 (의료기관이 중심이 된) 플랫폼 구축을 지향하고 있습니다. 일단 병원수와 Provider수를 늘려서 규모의 경제를 확보하고, 보험사, 의료기기 회사, 의료정보 회사, 심지어 부동산 회사 등까지 단순한 판매/구매의 관계가 아니라 파트너십으로 승격시키며, 언제 뒤통수 칠지 모르는 파트너십보다도 스핀오프를 통해 자회사를 발족시키는 등의 적극적인 비즈니스까지도 과감히 실행하고 있습니다. 최근 10년간 만들어진 정밀의료나 인공지능 스타트업 중의 많은 경우 이렇게 의료기관의 자본과 파트너십, 기 확보된 테스트 베드 (그리고 잘 아는 의대교수님???)를 등에 업고 폭풍성장했다고 보면 됩니다. 이러니 요새 대형 헬스케어 시스템의 CEO는 기본적으로 비즈니스 마인드와 성공 경험이 탑재된 사람이 아니면 그 자리에 가기 힘들어 보입니다.
아무튼 배경은 이렇고 저는 의료경영이나 관리 쪽은 문외한인지라 이러한 움직임이 의료정보에 어떤 영향을 가져올지가 관심입니다. 예를 들어 대형 헬스케어 시스템들이 인수합병을 하면 의료정보 관점에서 서로 다른 EMR 시스템과 프로세스가 어떻게 통합되어야 하는가의 문제가 생깁니다. 만약 인터마운틴처럼 Cerner를 쓰는 시스템과 샌포드처럼 Epic을 쓰는 시스템이 합병한다면 세가지 시나리오가 있을 수 있습니다.
1. 인터마운틴이 Cerner 버리고 Epic으로 갈아탄다. (Epic 승리)
2. 샌포드가 Epic 버리고 Cerner로 갈아탄다. (Cerner 승리)
3. 두 EMR을 유지하고 FHIR 인터페이스를 운용한다. (FHIR 승리)
이러한 비즈니스 의사결정은 복합적인 요인들이 고려되기 때문에 하나의 정답은 없지만 문제를 비용 관점으로만 좁히면 3번은 선택되기 힘듭니다. 왜냐하면 1,2번에서 어떻게든 현재보다 EMR 비용이 줄어들 가능성이 높기 때문입니다. Epic과 Cerner는 서로 자기네 EMR로 갈아타라고 마케팅을 펼칠것이고 필연적으로 가격을 깎아주려 할 것입니다. Epic의 단가 자체는 Cerner에 비해 훨씬 비싸지만 시장지배력과 프리미엄 브랜드 (??) 파워가 있기에 Cerner가 더 살벌하게 자기 살을 깎을 가능성이 높습니다. 문제는 그렇게 깎으면 오히려 싸구려 덤핑 EMR이라는 이미지가 생겨서 보수적인 의료계는 결과적으로 더 Epic을 선호할 가능성이 높아집니다. 3번 가능성이 낮은 이유는 두 EMR의 유지 비용은 그대로면서 인터페이스 개발 비용이 추가로 들기 때문입니다. 물론 EMR을 교체하지 않으면서 할 것처럼 희망고문만 해서 단가 후려치기하는 방법도 있긴 합니다 (....)
그래서 저는 1번 가능성이 가장 높다고 봅니다. 이런 일들이 반복되다 보면 결과적으로 마켓 1위의 점유율과 시장지배력은 당분간 더 커질것이라고 예상할 수 있겠습니다. PC나 스마트폰 시장이 포화되고 제품의 스펙이 상향평준화되어도 애플의 깡패력은 더 세지는 것과 비슷합니다. 그럼 이 시점에서 Epic의 주식을 사야하는가 하면 그건 알 수 없습니다. 왜냐하면 스마트폰의 경우 일반인 고객이 애플과 경쟁하지는 않지만 EMR의 경우 의료기관 역시 강력한 자본과 동기를 가진 플랫폼 비즈니스의 경쟁자이기 때문입니다. 따라서 일정 시점에서는 고객들이 Epic에 대한 선호도와 의존도를 줄이려 할 가능성이 높습니다.
그래서 상호운용성의 근미래는 이 균형이 어떻게 이루어지는 가에 따라 달렸다고 보는데, 제 개인적인 생각은 30% 정도의 Epic 기반 프리미엄 벤더 플랫폼 (예를 들어 애플 제품군)과 70% 정도의 FHIR로 통합한 멀티 시스템 기반 범용/저가 호환성 높은 플랫폼 (IBM PC 제품군)가 되지 않을까 생각합니다..
애플의 새로운 PHR 시도와 의료정보 Backflow의 가능성 (2021년 7월)
애플이 자사 제품의 PHR, 구체적으로는 아이폰 내부의 Health앱에 있는 정보를 역으로 의료기관의 EMR이 읽을 수 있도록 하는 기능을 FHIR기반으로 제공한다고 합니다. 이 서비스를 위해 EMR회사 및 의료기관들과 적극적으로 협업하고 있다고 합니다. 말이 좀 어려운데 이게 뭔 뜻인가 하면 아래와 같은 시나리오가 가능하게 될 수 있습니다.
1. 현재 아이폰 사용자는 애플 Health와 연동된 의료기관 (현재로서는 사실상 대부분의 미국 대형병원)에 있는 자신의 의료정보를 조회할 수 있습니다. Authentication만 되면 복수의 의료기관의 자기 정보를 아무 문제없이 끌어와서 하나의 아이폰에서 볼 수 있습니다.
2. 근데 여기엔 몇가지 한계점이 있는데 예를 들어 지난 달에 A병원에 다녀왔고 어제는 B병원에 갔다왔다고 하면 나는 내 폰에서 A와 B병원의 정보를 모두 볼 수 있지만 A병원과 B병원의 의사는 타병원의 정보를 서로 볼수 없습니다. 이 경우 방법은 내가 의사한테 폰을 꺼내서 직접 보여주던지 A와 B병원 사이에 진료정보 교류가 이뤄지던지 해야합니다.
3. 애플이 하고자 하는 것은 사용자가 아이폰에서 공유하고자 하는 정보의 종류와 의료기관을 지정하면 그쪽에서 아예 내 정보를 끌어갈 수 있도록 만드는 것입니다. 예를 들어 내가 B병원에 A병원에서 받은 Lab정보를 가져갈 수 있도록 허용해주면 그때부터 B병원 (의 EMR)은 애플에 저장된 내 PHR의 정보를 주기적으로 읽어서 EMR에 저장합니다. 그렇게 해서 나중에 B병원에 갈때 그 병원 의사는 A와 B병원의 양쪽 의료정보를 동시에 활용할 수 있게 됩니다.
4. 허용해주는 정보의 종류는 의료정보 이외에도 활동(Activity) 정보 등도 가능합니다.
5. 이게 가능하게 되면 상당히 의미있는 일이라고 생각됩니다. 지금까지 의료정보는 기술적, 제도적 이유로 의료기관의 시스템 안에 머물렀는데(혹은 갇혀있다고도 표현하는데) 이를 끄집어내서 환자에게 Control을 넘겨주는 것이 정책적/비즈니스적 방향이었기 때문입니다. 그런데 애플의 새 서비스는 역으로 환자가 갖고 있는 정보를 의료기관에게 다시 돌려주어 활용할수 있도록 하는 일종의 "정보의 Backflow" 같은 것이 될수 있습니다.
6. 그런데 이런 의미와는 별개로 이게 실제로 가능할지 여부는 앞으로 여러 난관을 넘을 수 있느냐에 따라 달려 있습니다. 몇가지 생각나는대로 적어보면,
a. 기술적으로 이걸 구현하려면 먼저 애플과 의료기관이 이런 형태의 의료정보 프로세스 구현에 동의해야합니다. 이런 경우 의료기관의 의사결정은 조직에 속한 Physician들이 얼마나 임상적 필요성을 어필하느냐에 달렸습니다.
b. 그러고 난 후에는 (해당 의료기관의) EMR회사가 이걸 구현해야하는데, 애플 PHR에서 정보가 pull되는 것은 FHIR API가 이미 다 있으니 어려울 것 없지만 EMR 시스템 내부에 끌어온 환자정보를 띄우거나 기존 앱과 연결하기 위해서는 SMART on FHIR 앱을 개발해야 합니다. SMART on FHIR를 어느 Workflow안에 어느 Component에 어떻게 구현할지는 a항목에서 Physician들이 어떤 임상적 필요성을 요구하냐에 따라 달렸습니다.
c. 그런데 의료기관이 할 맘이 있어도 EMR회사가 안한다고 하면 (혹은 반대도 마찬가지) 안됩니다. 문제는 이 기사에서 보면 Epic은 Supporting vendor에서 빠져있습니다. 여윽시 상호운용성계의 삐딱선 Epic.. 그 말은 미국 기준으로 약 40%의 의료기관은 현재로서는 이 서비스에서 아웃이라는...
d. 다 잘 만들어 놔도 환자가 허용 안해주면 안쓰는 서비스가 될 가능성이 있습니다. ONC의 Interoperability rule은 이 경우에 해당이 안되며 환자로서는 특별한 이유 (만성질환 환자처럼 주치의와 정기적으로 만나고 친해져서 미주알 고주알 터놓는 경우)가 없는 한 일반인이 굳이 내가 내 정보를 어디서 어떻게 쓰일지도 모르는데 그렇게 해주려고 번거롭게 "미리" 동의를 눌러놓기는 쉽지 않을 것 같습니다.
그럼에도 불구하고 이번 애플의 새 서비스는 의미있는 시도라고 보이며 저런 구구절절한 난관 따위는 됐고 뭐 애플이 한다면 그냥 다 될거라고 믿쑵니.....
이 차트 한번 보면 없던 믿음도 생깁니다구글 헬스 사업부 해체 (2021년 8월)
구글이 헬스 사업부를 해체한다는 뉴스가 떴는데 몇달 전부터 부서를 조각조각 썰어서 다른 데로 보내고 있어서 새로운 뉴스는 아니라고 봅니다. 오히려 이 내용을 살펴보면 뉴스거리는 수장이었던 David Feinberg가 Cerner의 CEO로 옮겼다는 것으로 보입니다.
EMR 시스템 시장은 Meaningful Use 프로젝트가 끝나며 성장을 멈추고 수익성은 매년 계단식으로 내려오고 있었는데, 내부를 보면 Epic은 그 와중에 다른 EMR 특히 2위인 Cerner의 기존 고객을 빼앗아오며 위치를 더 공고히 하고 반대로 나머지 회사들은 생존위기에 몰리게 되었습니다. 특히 올해초 Epic은 대어 Advent Health로 하여금 기존 Cerner시스템을 빼고 자사의 제품으로 갈아타게 하는데 성공하며 본사에서 파티열고 난리를 쳐서 Cerner에 씻을수 없는 굴욕감을 선사하였습니다. EMR시스템은 한번 깔면 Overhaul하기 가장 어려운 IT 시스템 중의 하나이니 Cerner가 느낄 위기의식을 짐작할 수 있습니다. 게다가 Cerner의 창업자 Patterson은 몇년전 암으로 작고하여 어려운 시기에 리더십이 비었는데 비슷한 나이의 라이벌 그분은 내후년이 팔순인데 은퇴같은거 할 생각이 없어보이....
그래서 이번 조직개편은 "이대로는 안되겠어"라는 구글과 "이대로는 안되겠어"라는 Cerner의 합작으로서 왠지 멀지않은 미래에 구글이 결국 Cerner를 어떤형태로든 인수하게 되고 그 트로이 목마가 Feinberg인 것인가라는 나름의 뇌피셜을 풀어보았습니다...
(이 포스트를 올린 12월 시점에 정작 뚜껑을 열어보니 인수합병한 상대는 바로!!!!)
Epic의 코로나 모듈 장착 (2021년 10월)
Epic (게임회사 아님....)이 발빠르게 코로나 백신 접종 정보 공유 모듈을 자사의 MyChart (환자용 모바일 앱)에 장착했다는 뉴스입니다.
Epic은 MyChart라는 환자용 모바일 앱을 제품군으로 갖고 있는데 이 앱에 VCI Initiative라는 곳에서 개발한 SMART Health Card를 구현하여 백신 접종 정보를 요청/저장/공유할수 있다고 합니다. SMART Health Card는 이름만 봐도 딱 감이 오는데 SMART on FHIR기반의 기술입니다. 즉 어느 병원의 EMR에 저장된 코로나 관련정보를 FHIR API를 통해 일단 꺼낸다음 적절한 개인정보+표준화된 임상 정보의 조합으로 생성해 줍니다. 여기서 핵심은 이걸 대체 어떻게 공유할 것인가인데 여기서 쓰인 기술이 W3C Verifiable Credentials입니다. SMART Health Card의 스펙을 들여다 보면 생성한 정보를 일단 Bundle리소스로 죄다 바인딩한 다음 이를 JWS 밑의 credentialSubject에 밀어넣는 예제를 볼 수 있습니다. 자세한 설명은 생략
이 뉴스에서 재미있는 점은,
1. Epic이 도입한 SMART Health Card라는 기술은 원래 이름부터 보면 알 수 있듯이 SMART 그룹이 개발한 것입니다. SMART는 보스턴 칠드런 병원과 하버드 (Kenneth Mandl 등)이 주도하고 있고 자체적인 SMART on FHIR 샌드박스 등도 운용하고 있습니다. 그런데 Epic이 SMART Health Card를 구현했을 때는 VCI Initiative라는 곳에서 만든 배포본을 썼다고 하는데 이 VCI라는 곳은 들어가보면 public+private이 모인 곳이고 Epic, Cerner, MITRE, MS, Amazon, 뉴욕주, 메이요 클리닉 등 기관이 주도한 것으로 보입니다. 즉 SMART라는 연구그룹이 만든 기술을 이런 기관들이 모여서 같이 도입 및 구현하자라고 하는 걸로 보이는데, 제일 밑에 Contact을 보면 VCI의 연락처는 MITRE로 되어 있습니다. MITRE는 유명한 Synthea 가상 환자 데이터 생성기를 만든 곳인데 주로 연방정부의 (FHIR를 포함한) IT 연구개발 용역을 맡는 곳입니다. 결국 결론은 이 SMART Health Card를 쓰라고 등떠미는 곳은 연방정부라고 할 수 있습니다.
2. 그런데 사실 다시 찾아보니 제일 먼저 SMART Health Card를 구현한 곳은 Epic이 아니고 Apple입니다. Epic보다 일주일 먼저 기사가 나갔는데 https://www.healthcareitnews.com/.../apples-health-data... 역시나 자사의 Apple Health안에 포함할 예정입니다. 포인트는 다음 iOS인 15버전때 사용자에게 이걸 포함할지 안할지 물어보도록 한다고 하는데 원래 웬만한 기능은 OS 업데이트때 별 말없이 조용히 낑겨넣어도 되는데 이렇게 하는 것은 Apple이 백신여권에 대한 사용자의 민감한 반응을 조심하기 때문이라고 생각할 수 있습니다. 사실 백신여권 S/W를 받아봐야 어차피 의료기관의 인증을 하나하나 거치지 않으면 실제 그 안에는 아무 정보도 있을 수 없는데요 (그러나 백신 맞은 사람 옆에 가면 불임이 된다고 믿는 미국인들에게 그런걸 이해시킬 수가...;;;;)
3. SMART Health Card는 (FHIR도 그렇듯이) 기술적으로 그렇게 어려운 것도 아니고 앞으로 다른 앱개발사들도 앞다투어, 또는 조용히 도입할 것으로 보입니다. 백신접종정보 자체는 사실 의료기관에서 환자 동의받은 것을 꺼내오는 것에 불과하며 중요한 건 이걸 공항이나 비행기 탑승시, 출입국시 주와 연방정부, 국토안보부 시스템에 어떻게 연계하는 것인가인데, 딱 그림을 보면 미국 연방 정부가 뒤에서 열심히 등떠미는 것으로 보이니 조만간 진척이 될 것으로 보입니다.
4. 같은 기술 구현하는 것 놓고도 각 벤더들이 어떻게 판을 짜고 누가 먼저 총대 매느냐 뒤에서 묻어가느냐 머리를 굴리는 것을 보는 것이 재미있는데 Epic이 제일 먼저 치고 나갈줄은 몰랐습니다. 여윽시 비즈니스의 세계는 한치 앞을 알 수 없네요 ㅎㅎㅎ
의료정보학 교육의 미래에 대한 생각: 대학원 졸업자는 어디로 갈 것인가 (2021년 10월)
이번 학기에도 작년에 이어 Clinical Database Design이라는 대학원 과목을 가르치고 있는데 어제 오피스아워 (일종의 수업 고충처리시간)에 다소 쇼킹한 질문을 받았습니다. 그 전에 배경을 좀 설명하자면 이 수업은 한 학기에 보통 30명 정도 듣는 수업인데 제목을 보면 알겠지만 보통 컴퓨터 사이언스 전공에서 배우는 데이터베이스 이론 및 관계형 앨지브라 SQL등의 기본에다 EHR스키마, 용어체계 등을 섞어서 가르칩니다. 당연히 실습도 해야하는데, 컴싸전공자만큼의 난이도를 맞출수는 없어서 보통은 Oracle SQL Lite나 XE를 설치해서 기본 SQL을 연습하도록 시키고 숙제는 보통 사용한 쿼리를 텍스트 파일 형태로 제출하면 되는 것이었는데 어제 오피스아워에서 나온 질문은...
"Oracle에서 테이블 만드는데 쓴 쿼리들을 숙제로 제출할때 텍스트파일로 어떻게 만들어요?"
이게 한두명도 아니고 여러 학생들이 어려워하는 문제였습니다. 당연히 Save as를 한 다음 .txt나 .sql로 밀어내던가 그도저도 안되면 빈 노트 하나 만든다음 copy & paste로 뚝딱하면 되는거 아닌가인데... 아무튼 심히 당황스러웠습니다. 그래서 결국 "시연"까지 해줬습니다. ;;;;
근데 이게 수업 듣는 학생들의 코호트를 보면 이런 현상이 이해가 가는데 현재 학교의 의생명정보학과 학생은 50%이상이 백그라운드가 바이오이며 나머지는 데이터 사이언스, Clinician등으로 구성되어 있습니다. 즉 최소한 언더에서 컴싸를 했거나 전현직 IT분야인 학생은 거의 전무하다시피 합니다. (10년전에 제가 유타에 왔을때는 50%정도의 컴싸 전공자 또는 IT 업계 사람 + Clinician 였던 것으로 기억합니다) 그러니 현재 대부분의 학생은 "Hello World!" 프로그래밍도 해본적이 없고 그 상태에서 데이터베이스 이론부터 들어가면 바로 멘탈이 붕괴되는...
아무튼 이래저래 의료정보학 교육은 뭔가 변화 + 도전의 시기를 맞고 있다고 느껴집니다. 그 결과로 나타나는 것은 사실 인력의 공급과 수요의 심각한 불일치인데.. 한쪽에서는 의료정보 할줄 아는 전문인력 좀 찾아주세요 사람이 너무 없어요라고 하고 다른 한쪽에선 의료정보학과 나와서 취업이 안되요라는 얘기를 동시에 듣게 되는 것입니다. 이게 일이년도 아니고 계속 듣는 얘기인데 얼핏 보면 이해가 안가도 자세히 속을 살펴보면 결국 서로 원하는 것이 다르기 때문에 생기는 현상입니다. 사람을 원하는 쪽은 "SNOMED, 용어체계, 아키텍처, EHR 설계/구현, 인터페이싱, HL7, CDS, 프로세스 통합" 같은거 할줄 아는 전문가 필요해요라고 하는 것이고 다른쪽은 "우리는 학과에서 그런거 안 배웠거나 배웠어도 제 전문분야 아니에요"라고 하는 것입니다. 그럼 대체 대학원에서 뭘 전공했나요라고 물어보면 대답은 "인공지능, 머신러닝 딥러닝, 모바일 헬스, 바이오, 정밀의료, 등등이요"라는 대답이 돌아옵니다.
아무튼 이런 고민들을 요새 많이들 하고 있는데, 그럼 어떻게 하냐를 따지기 전에 잠깐 예전에는 의료정보학을 어떻게 가르쳤는지 역사를 살펴보자면, 원래 의료정보학은 의과대학 내의 부설과목로 시작했었습니다. 학교나 병원마다 다르지만 유타대학교의 예를 들면 의료정보학의 창시자 중 한명인 Homer Warner는 1960년대에 의과대학내에 일종의 선택과목으로 "Computer based Medical Decision Making"이라는 수업을 개설했는데 당연히 대부분의 학생들은 핵노관심...이었으나 다행히 두명이 듣겠다고 와서 수업은 폐강되지 않았답니다 (두명 데리고 수업하는 것도 대단한). 그 두명이 누구였냐하면 하나는 인터마운틴 전 CEO였던 Charles Sorenson이라는 Uro 서전이고 다른 한명이 제 은사이신 Stanley Huff... (그리고 Stan은 나중에 집에다가 앞으로 임상의사를 하지 않고 컴퓨터를 하겠다고 선언해서 어머님이 이틀동안 우셨다는 전설이 있습니다)
시간이 흘러 점차 의료정보학 지식이 방대해지고 과목이 늘어남에 따라 대학원 수준에서의 석박사과정도 생기고 전문적인 학위를 지닌 의료정보학 전문인력이 배출되게 됩니다. 이들의 구성을 살펴보면 1980년대부터 2000년대 초반까지 꽤 안정적이고 균일한 패턴을 보이는데, 대부분 학부에서 컴싸 또는 엔지니어링을 전공한 학생들이 대학원에서 메디컬 도메인을 추가로 공부하거나 반대로 clinician들이 대학원에서 정보학 관련 기술을 추가로 배우는 경우가 대부분이었고 졸업 후에는 의료기관/연구소/기업 등으로 진출했습니다. 이때까지만 해도 의료정보학 전공자들은 일종의 도제식 교육을 받기도 했고 병원에서 데이터를 뽑거나 시스템을 구현해야했기 때문에 임상현장 가까이에서 수련을 받았고 취업후에도 그렇게 하는 것을 당연히 여겼습니다. 따라서 몇년 같이 굴르다 보면 자연스레 서로 도메인 지식을 익히게 되었고 커뮤니케이션 문제도 적고 관계도 끈끈하기 마련이었습니다.
그런데 점차 이 분야가 커지면서 임상에서의 응용보다는 학문 자체를 깊이 연구하는 분야 예를 들어 Research informatics(최근에는 인공지능/빅데이터)등이 발전하면서 임상을 거치지 않고 연구를 하는 커리어들이 생겨나게 됩니다. 특히 이쪽으로는 MD가 아닌 고학력자들이 선호하는 현상이 강한데 이들이 원하는 커리어는 "탑스쿨 나와서 박사까지 Informatics 전공한 다음 NIH/AHRQ 펀딩을 많이 받아 의대 소속 대학원에서 교수의 길을 걷는 것"이 됩니다. 그런데 이렇게 훈련된 인력들에 대해서 의료기관 입장에서는 PhD까지 공부한 정보학 전문인력이 기본적인 임상 프로세스를 이해못해서 현업에서 다시 가르쳐야한다는 불만이 나오게 됩니다. (왠지 어디서 많이 들어본 불만인데 어느 분야나 공통인듯) 그 와중에 배출되는 의료정보학 인력의 수요를 감당한 것은 미국 기준으로 2009년부터 10년동안 진행된 Meaningful Use 프로젝트였습니다. 이 프로젝트에 참여하기 위해 의료기관들은 대학원 이상의 의료정보학 전문 인력들을 고용했고 상용 EHR 시스템을 도입하는 경우에도 Leidos등의 컨설팅 회사에서 의료정보학 전문가들의 수요가 많았었습니다. 그러나 마켓에서 EHR시스템이 포화된 지금 그 수요는 없어졌으며 나중에 따로 다룰 예정이지만 EHR 개발회사는 의료정보학 고급인력이 필요없는 구조로 돌아가는 조직입니다. 따라서 "엔지니어링 백그라운드에 PhD Informatics까지 공부했는데 임상 경험이 없는" 인력은 이 분야에서 커리어 개발이 상당히 애매해지게 됩니다.
다시 의료정보학 교육을 어떻게 해야 하는가에 대한 얘기로 돌아와서, 일단 전통적인 의료정보학의 역할인 EHR(및 대부분의 Clinical application)은 모두 IT회사들의 영역에 들어갈 것으로 보입니다. 다시말해 의료기관이나 연구기관에서는 실험용을 제외하면 의료정보시스템을 개발하지 않거나 해도 경쟁력이 없다고 봅니다. 그렇게 되면 아마 미래에 대학원 수준의 의료정보학 인력은 크게 세 분야에서 활용될 것 같다고 조심스럽게 예측해 봅니다. 첫째는 프로세스 통합분야인데 의사/간호사/약사 등의 Clinician중에서 정보학의 석사급 내지는 Certification 정도의 훈련을 받은 인력들이 주도할 것으로 보입니다. 이유는 임상에 대한 이해도가 높으며 어차피 겸업이 많아 고용유연성 또한 높고 컨설턴트들과 협업했을 때의 케미도 좋고 결론적으로 가성비가 높기 때문입니다. 둘째는 현재의 Research informatics와 Data science등 일단 저장한 백엔드의 데이터를 2차 활용하는 분석/연구 분야입니다. 마지막으로 의료정보의 Governance 분야인데 상호운용성/인터페이스/아키텍처/표준/규제 등을 다루며 전통적인 의미의 의료정보학의 역할에 가장 들어맞는 역할이고 수요 자체는 많지 않지만 앞으로 헬스케어 데이터의 영역이 크게 확장됨에 따라 발전이 예상됩니다.
아 그래서 결론적으로 데이터베이스 수업에서 Oracle SQL Lite에서 dump명령어로 Script 뱉어내게 한 후 그걸로 제출하라고 아예 가이드라인을 줬더니 한 학생이 텍스트 파일로 일단 제출은 했는데 자기 컴이 맥북이라서 문자열이 깨졌을지도 모르니 잘 열리는지 확인 좀 해달라고..... 참아야 한다...
Zoom 과 Cerner의 원격진료 파트너십 (2021년 12월)
Zoom이 Cerner EHR과 시스템 통합을 시도하고 있으며 2022년 1분기에는 재미있는 기능들이 구현될 것이라고 합니다. 누가 봐도 대놓고 원격진료를 노린듯한 이 통합으로 여러가지가 가능하게 될 것으로 예상되는데 예를 들어,
- EMR 차트 안에서 환자와의 미팅 예약
- 환자가 Zoom에서 대기하고 있으면 EMR 차트에 알림을 보내줌
- Zoom 미팅 내부에서 검사결과나 노트를 적고 공유 / 전송
- 환자 가족, 통역사, 다른 프로바이더를 초대해서 불러오기 (흥미롭네요)
등이 가능해질 것이라고 합니다.
이 기사에 배경을 조금 더 하자면, 미국에서는 원격진료를 어느 플랫폼에다가 구겨넣을 것인가를 놓고 각 진영이 한참 힘겨루기 하는 중입니다. 이건 컨텐츠 플랫폼처럼 순전히 규모의 경제 싸움이 될 가능성이 높은데, 이유는 원격진료가 별로 돈 안되는 사업이기 때문입니다. 기술적으로 특별히 차별화되지 않았고 자체적으로 캐시플로를 만들 능력이 없기에 (21세기 법 2.0으로 지원은 더 받는다 쳐도 진료비가 워낙 뻔한 수준이라) 다른 플랫폼에 결합해 사용자 규모를 시너지시키거나, 아예 클리니컬 웍플로에 통합하거나, 부가적인 (특히 행동치료 쪽) 추천 서비스나 연결로 부수입을 벌어야 비즈니스의 존속이 가능하기에 어느 플랫폼에 통합될지 구체적인 그림이 그려지는데 오래 걸리지 않을 것이라 생각됩니다.
그런데 EMR회사 입장에서 생각해보면 자체적인 대규모 사용자군을 거느린 텔라닥같은 회사는 다루기가 껄끄러울테고 상대편도 마찬가지입니다. 그래서 Zoom처럼 아예 비디오 솔루션만 제공하는 회사가 파트너로서 편하고 Zoom의 입장에서도 Cerner뿐 아니라 다른 EMR회사들도 같이 걸쳐도 되니 (기사에 Zoom과 Epic과의 협업 얘기도 있습니다) 좋은 기회인 것 같습니다. Zoom내부에서 차팅이나 메세지 전송을 할때 HIPAA를 어떻게 맞춰서 구현할지 정보학 연구 차원에서 관심 갈만한 주제이기도 합니다.
그런데 개인적인 의견으로 원격진료 분야에서 히든 플레이어는 마이크로소프트가 아닐까 합니다. 원격진료를 클리니컬 웍플로의 연장선에서 보는 관점에서는 어떻게 하던지 EMR과 통합하는 것을 최종 목적지라고 생각합니다. 하지만 미국에서는 현실적으로 원격진료를 사용자가 (회사들) 고용인(직원)에게 제공하는 베네핏의 한 종류라고 생각하는 경향이 강합니다. 직원들이 원격진료를 활용해 건강을 증진하거나 의료비를 절감할수록 기업의 고용인에 대한 재정적 부담이 직접적으로 줄어들기 때문입니다. 결국 기업 입장에서는 최대한 직원에게 원격진료에 대한 접근성을 높여주고 싶은데, 개인의 모바일에 새로운 앱을 깔고 일일이 설정하는 번거로움을 겪게 하느니 아예 기존의 업무환경에 통합된 원격진료를 쓰라고 권장하는게 더 좋습니다. 즉 기업이 좋아할 원격진료 솔루션은
1. 업무환경 자체에 통합되어 있어서 접근성이 좋고
2. 진료, 커뮤니케이션, 청구 및 의료비 결제까지 회사 시스템에 연계되어 일일이 감시하기.... 아 이건 아니고 관리하기 좋고 (^^)
3. 이왕이면 메가 플랫폼에 속해서 의료 서비스 제공자에 대한 가격 협상력이 높고 선택권이 많으면 좋고
이런 것들을 충족시킬만한 회사와 솔루션은 마이크로소프트 Teams밖에 잘 떠오르지 않네요. 마이크로소프트도 이쪽에 욕심이 있는지 지난 7월부터 텔라닥 솔루션과의 통합을 도모하고 있다고 합니다. 잘 생각해보면 Zoom과 써너의 조합처럼 서로 도메인이 겹치지 않아 껄그럽지 않으면서 시너지가 나올수 있기에 둘은 궁합이 잘 맞을 것 같습니다.
여담으로 한국은 어떤지 모르겠으나 미국에서 회사 다니면 Teams의 성장이 무서울 정도라는 것을 체감할 수 있는데, 코로나 시대에 엔터프라이즈 환경에서 필요한 모든 걸 다 제공하는데다가 앱생태계도 폭발적으로 성장하고 있어 그야말로 제 2의 윈도우와 오피스가 되지 않을까 할 정도입니다. 앞으로 메타버스 시대가 오더라도 가장 강력한 플랫폼이 되지 않을까 기대됩니다. 근데 이 생각을 올해 내내 했는데 주식을 왜 안샀을까 ㅠㅠ
짧은 글들이라도 올해 나온 것을 다 모아보니 나름대로 한 해를 종합하는 소식지가 되는 것 같아 이렇게 정리하는 방법도 괜찮은 것 같습니다.
올해의 마지막 단상은 왜 주식을 안 샀을까라는 아쉬움으로 남았네요 ㅋㅋㅋ 내년에도 디지털 헬스케어의 가능성을 많이 기대해주시고 재미있는 이야기 종종 올리도록 하겠습니다.
이건 웃자고 만든 짤인가 울라고 만든 짤인가