健保於2010年開始實施診斷關係群制度(Diagnosis Related Group, DRG)，在此之前，數萬條的疾病分類編碼單純用來記錄疾病；在DRG實施之後，疾病分類碼與健保費用直接相關，開始依病例嚴重程度計算健保支付標準，取代過去依服務計酬的制度，成為醫院經營管理的關鍵，因而衍生出使用電腦輔助編碼的需求，像是DRG編審軟體、病例組合指標管理，或是應用於臨床路徑最佳化管理。

這類系統工具多為半自動化，仍須仰賴編碼人員或醫生花費許多精力與時間解讀一本又一本病歷、來回查找疾病分類碼，才能研判主診斷項目，也就是引起病人這次住院醫治的主要原因，以及合併症或併發症(Comorbidity and Complication, CC)項目。

數萬個與主診斷相關的疾病碼與手術碼，以及上千個CC碼，在不同排列組合下，代表著不同的病例複雜程度。然而人工判讀一直以來最大的缺點，就是編碼品質受經驗、習慣、時間與人力等眾多因素影響，不容易精確管控。越複雜或記錄越不完整的病歷，越可能被同時解讀出有或沒有CC兩種截然不同的結果，影響的保險金額差距可能高達數萬元。

市面上已有些AI能夠自動分析臨床數據所代表的意義，據此推薦疾病分類碼，例如執行DRG編審作業時，可以推薦主診斷與CC 。其中，推薦CC的方法，主要運用過去診斷與常用CC為基礎，再用幾個條件加以篩選。較為進階者，則是以文字探勘或自然語言處理技術，分析病歷中非結構化的文字(Free Text)。

對比歐美常用的方法，則是將臨床診斷指引數位化，根據重要的生理參數推薦疾病編碼，如腎臟醫學會的急性腎衰竭診斷指引，是依據不同時間的血清肌酸酐狀態，推薦相關的疾病診斷碼。此方法雖然客觀，但仍有所侷限，因為指引中通常只收錄最常發生，或是會影響醫療成本的疾病，造成實務應用相當有限。

TW-DRG已經演進到第四版，接下來所有住院病例必須全部採用DRG計價，同時健保給付原則也將同步併重住院與門診的診斷正確性，並且將慢性病與先天疾病納入病例複雜度與給付評估。種種改變將使編碼人員工作增加3-5倍，對管理與資訊科技的負擔亦將更加沈重，讓原本就已吃緊的人力面臨潰堤。

醫守的「DxPrime好完診」診斷推薦系統，幫助醫院為TW-DRG 4.0上線做好準備。DxPrime以32億筆來自台灣與美國的臨床數據建立AI模型，其強大的演算能力，即使遇到病歷中有遺漏的診斷，甚至是內容未填寫完全的狀況下，也能充分發揮應用。

不同於市面常見分析Free Text等非結構化資料的做法，DxPrime採全面性綜合分析用藥、檢驗檢查、處置﹐與手術項目等結構型資料，因此能夠更加精確分析病例複雜度，推薦適當的診斷項目，具體改善編碼品質，有助入院編審及最佳臨床路徑管理。

醫守不僅將DxPrime演算模型發表在Healthcare期刊 ，實際導入醫院後發現，演算法能在病人入院第三天之病情發展尚未完全明朗前，即達到七成以上的主診斷預測準確率，出院時更可達到九成準確率，並且改善整體營收5%-10%。

唯有解決醫師與編碼人員如何在有限時間下正確解讀繁瑣病歷細節的需求，並同時兼顧如何在編碼上精確反應病例複雜程度的要求，才能真正幫助醫院改善保險帳務品質與經營績效。

醫療AI新創公司醫守科技很榮幸宣佈，新產品RxPrime即日起可在全球最大醫療軟體市集EPIC App Orchard平台直接下載。RxPrime是全球第一套以AI預防住院用藥之「型音相似（look-alike、sound-alike）錯誤」的系統，供平台內3,000家醫院用戶快速導入使用。

2019年甫正式成立的醫守科技，不因近兩年新冠病毒肆虐而打亂拓展美國市場的腳步，持續針對門診到住院的不同使用需求積極佈局。2020 年以支援門診用藥決策的MedGuard 成功上架EPIC App Orchard，當時創下兩岸三地第一個、也是唯一一個與國際級電子病歷系統整合的醫療新創。時隔一年，再推出應用於住院用藥決策的RxPrime，讓用藥安全解決方案更彈性多元。

目前所有商業用藥安全系統僅能針對一般藥品的「禁忌症(Contraindication)」、或高危險藥品的「非適應症(non-indication)」提供警示，其做法主要依據藥品仿單上的使用指示，建立與診斷之間的數千個邏輯判斷法則。隨著科技進步不斷產生新藥、新適應症及仿單標示外使用(off-Label Use)，面對日益複雜的「藥名型音相似」問題，必須發展出百萬條以上的邏輯法則才有可能準確處理。醫守長期鑽研用藥與診斷的關係，運用32億筆國際病歷資料，以機器學習發展出RxPrime的獨家演算法，不僅可有效捕捉型音相似用藥錯誤，還能直接反餽相關診斷和用藥建議。

RxPrime側邊欄（圖中右側）在EPIC住院系統上運作，可即時動態分析患者住院期間所有用藥，轉換成一目瞭然的結構型資訊呈現，並提供以大數據為導向的用藥安全改善建議

​此外，相較於門診，住院患者病情通常較為複雜，醫師必須隨病情變化經常調整用藥，甚至涵蓋跨科別治療，因而需要更好的監控管理工具。RxPrime像是一個用藥管理小桌面，能在EPIC住院系統上以側邊欄形式同步運作，可以即時動態分析患者住院期間所有用藥，轉換成一目瞭然的結構型資訊呈現。

在醫師開出住院藥囑的當下，即可針對無法解釋的用藥、可能遺漏的用藥，甚至是具有交互作用的用藥問題，提供以大數據為導向的改善建議，並可直接在其控制面板上「一鍵勾選」修改有問題的藥囑，幫助醫師快速掌握與管理複雜的住院用藥安全。

App Orchard醫療軟體市集隸屬於電子病歷系統龍頭廠商EPIC，市集平台運作概念類似手機應用程式市集——使用iOS或Android等不同作業系統，有著不同的軟體設計架構與整合規範，在各自的軟體市集上架，供系統用戶下載使用。

「EPIC App Orchard技術整合門檻相當高，除了要求所有研發必須在美國境內進行，還必須符合一系列嚴謹的國際醫療資訊交換標準（如FHIR: Fast Healthcare Interoperability Resources、CDS Hooks、SMART on FHIR），並且必須遵守國際編碼標準（如SNOMED、RXNORM、LOINC）。這些技術在台灣幾乎沒有實作機會，能夠正式獲准上架，證明了醫守的技術整合能力，以及對於美國醫療資訊系統的掌握度。」醫守執行長龍安靖表示。

美國是全世界最大醫療資訊市場，2021年市值達686億美金 ，預估2026年將成長到1,451億美金。而EPIC在全美市佔率將近40％，醫守與EPIC的多元整合，不僅增加在美國市場的品牌能見度，更有助快速規模化擴散。2022年，醫守科技將加快產品與市場適配（product-market fit）修正，亦將陸續推出新產品，滿足更多臨床決策支援需求。

一般公司都會依產、銷、人、發、財五大功能部門定期召開管理追蹤會議，在醫守還有個其他公司不常見的會議，叫做「臨床會議」。
 
臨床會議通常發生在醫院裡，主要討論臨床治療案例，與會者多為第一線醫療照護團隊。像我們這樣的醫療資訊公司，怎麼會開這種會？
 
另外一個我們產業特有的場景，多數人可能都曾置身其中，只是從來沒有發現：那些和你一樣在診間外等待的人群當中，不見得每個都是患者或陪同家屬，其中可能有一、兩個是廠商，他們也在等醫生，只不過不是為了給醫生看病，而是要看剛做好的產品。
 

產品開發Step 1 : 探索使用者需求
 
我們都期待使用者或客戶可以直接告訴我們想要什麼，最好是連規格都開出來。一旦有了規格，要滿足使用者需求，在技術上都不是問題！
 
如果技術上都可以做到，為什麼產品還是賣不出去？可曾想過，有時候連使用者自己也不知道真正的核心需求是什麼？甚至連自己有什麼樣的需求都不知道，又如何能真正定義需求？
 
身為醫療資訊開發者，我們必須一再提醒自己擁抱使用者的需求，而不是擁抱自己的技術與產品，必須做好隨時推翻自己、隨時被批到體無完膚的準備，因為醫療產業本質是非常保守謹慎的，當我們企圖大膽創新時，就是在挑戰本質。
 
 
離開巴黎，就能描寫巴黎（from海明威）
 
醫守臨床會議，是由我們團隊中本身也兼具使用者身分的醫師、藥師成員來主導。會議上，我們從各種臨床案例出發，從中解構可能的需求，再從需求中找問題、從問題回頭看我們的產品，試著跳脫習以為常的「從技術找問題」，這樣才有機會看見自己一廂情願式的產品開發盲點。
 
當產品發展到一個程度，就必須從市場上找到早期客戶，進而逐步朝向更好的Product-Market Fit。早期客戶是早期產品的使用者，願意付費、願意分享使用故事，更重要的是，願意指出產品究竟哪裡難用，幫助你探索更具體、更核心的需求，加速產品改版修正。
 
隨著市場佈局越大，競爭者愈來愈多，我們在探索市場與使用者的同時，也在探索自己，越來越清楚自己和別人有何不同。醫守正在經歷階段性蛻變，過程很痛苦，但期待蛻變後的新容貌，和看見客戶因爲有了醫守而變得哪裡不同。
 
經營管理最簡單的部分就是「用說的」，我們已經做完最輕鬆的部分，接下來要面對的都是硬仗。

美國曾有機構統計，將近80％的醫療帳單都是錯的(*1,2)！聯邦醫療保險和補助服務中心（Centers for Medicare and Medicaid Services; CMS）2020年底也曾發出警訊表示，現行聯邦保險方案中，有高達9億（Medicare Part D）至865億美金 ( Medicaid ) 的不當支付(*3)。嚴重的醫療浪費、濫用與詐欺等問題，造成病人、醫院、政府三輸的破局。

所謂不當支付，包括多付或少付。形成的原因很多，包括申報文件不夠周全、跟不上法規政策、管理疏漏和醫療編碼錯誤(medical coding)等。前三項相對容易理解，但第四項醫療編碼是什麼？和醫療保險給付又有什麼關係？


醫療資訊化，方便了管理者卻苦了醫生

早期醫院推動資訊化的目的，是為了會計帳務與營運管理，並不是為了臨床治療而開發，用來服務病人或臨床工作人員。醫療編碼，是將醫療過程中醫生所開立的各項診斷或處置項目、提供或使用的各種醫療行為與設備器材，各別轉譯成一個個由英文字母與數字組成的代碼，這些代碼具有標準化與通用性，不僅代表每個患者就醫歷程的連續性紀錄，更是醫療保險計價的重要依據，幫助保險業者評估被保險人得了什麼病、治療必要性與複雜程度、哪些原因會影響治療結果等。

有品質的醫療編碼，必須結合醫師與疾病分類人員的經驗與智慧才有可能做到。醫生做的每個診斷、處置都必須紀錄在病歷中，再由疾分人員根據解剖學、生理學、治療照護細節與各種保險給付規範，負責為這些診斷與處置分配相對應的代碼，並確保所有代碼的正確性。

在過去手寫病歷的年代，疾分人員還必須具備慧眼，並了解每位醫師的書寫習慣，從醫師潦草又充滿縮寫的字跡中一一判讀轉譯、來回確認。隨著科技與知識發展，治療技術、疾病分類方式與科技資訊化複雜度遽增，讓醫師與疾分人員因為各自專業與立場不同，產生新的醫療編碼轉譯挑戰。

有句老派又耳熟能詳的廣告詞說「斯斯有兩種」，在現代醫療編碼的世界裡，疾病有6萬8千種，處置則約有9萬種，而醫生習慣使用的編碼項目平均只有幾百種，這中間的落差就可能造成後續編碼轉譯結果不夠完善、不夠精確，而衍生保險帳務問題，更影響延續照護品質。


醫院試著從編碼源頭改善，結果卻治標不治本

以外科常見的車禍受傷住院來說，醫生必須在傷者出院後72小時內，將其住院期間接受過的​​所有診斷、處置等醫療過程紀錄到電腦中，形成一份重要的出院病歷。依據臨床經驗與個人習慣，醫師總結其出院診斷為「左小腿挫傷伴隨細胞壞死（Left lower leg crushing injury with necrosis）」，輸入後卻陷入窘境，系統跳出警示：找不到可以直接對應的標準疾病分類碼！進一步搜尋後發現，necrosis細胞壞死有418個選項、crushing injury壓挫傷有231種選項；而手術碼則另有兩個乍看分不出差別的「左小腿組織皮膚切除術（Excision of left lower leg subcutaneous tissue）」與「左小腿組織皮膚拔除術（Extraction of left lower leg subcutaneous tissue）」可以選。

正在評估著該怎麼選時，腦中又浮現院方叮嚀病歷書寫品質與保險給付、營收的關係。面對手邊還有一堆消化不完的病歷要記錄，醫師該如何在臨床合理性與保險給付間取得平衡、避免迷失在過多的選擇中？


醫師的養成訓練是為了治療疾病，不是為了編碼轉譯

為了讓醫生能夠更專注在臨床實務上，醫守科技開發出「DxPrime」，以機器學習深入分析台灣與美國住院及門診資料，打造涵蓋45億筆醫療數據的知識庫，淬煉醫師與疾分人員的智慧結晶，發展出獨家模型。並運用ＡＩ擅長的多重分析，幫助醫師彙整出院診斷，透過分析入院診斷、跨科別問題列表、用藥、檢驗、檢查、處置及手術等結構性資料，提供前5項最佳出院診斷建議組合，包含手術、併發症項目。醫師只須評估DxPrime彙整過的建議，確保臨床合理性，從中做出決策後，DxPrime會自動無痛轉換內建的住院診斷關聯群分析(DGRs)，大幅改善醫療編碼轉換品質與成本，提升保險申報作業效率與成效。


唯有讓醫療AI發揮Facilitator般相輔相成的角色，補足人類與制度的種種限制與盲點，使醫生有效運用大數據中的智慧，才能在醫療決策流程中創造價值，做到真正的data-driven clinical decision support。

***
1. Medical billing errors growing, says Medical Billing Advocates of America
2. Billing Errors Everywhere!
3.2020 Estimated Improper Payment Rates for Centers for Medicare & Medicaid Services (CMS) Programs

​身為用藥安全AI業者，我們必須盡可能保持理性和科學態度，討論我們在醫院端偵測到的用藥錯誤案例與改進方法，但每次只要想到那個9歲的小妹妹，情緒總會有點hold不住。

這個小妹妹當時因為鼻子過敏和下背疼痛不舒服到小兒科就醫，醫師開了三種藥給她，其中卻不小心包含精神疾病 — 思覺失調症 ( 俗稱精神分裂症 ) 的用藥 : 首利安 ( Solian )，而且還是危險等級的超高劑量！好險，就在醫生要送出處方箋時，我們的藥御守成功擋住了這張問題處方，讓醫師有機會把不小心開錯的首利安改回原本想開的舒肉筋 ( Solaxin )，用來紓解下背不適的肌肉鬆弛劑。

針對這個例子，我們進一步分析發現，開立肌肉鬆弛劑是台灣特有的用藥習慣，不管是落枕、腰痛、肌肉痠痛或關節發炎，醫生都很常開舒肉筋 ( Solaxin )。可怕的是，舒肉筋 ( Solaxin ) 不僅常開錯成藥名很像的首利安  ( Solian )，也常開錯成心血管用藥心耐糖 ( Solantin )，這類錯誤每年平均發生多達一千多次。首利安和心耐糖都屬於高警訊藥品，也就是萬一不小心吃錯，可能會對病人造成嚴重傷害，而且同樣吃錯藥，小孩或老人吃錯，其傷害會比青、壯年人還要嚴重許多。

有幾次醫生坦言，過去當發現自己開錯藥的時候也都嚇了一大跳，一邊自責怎麼會發生這種事、一邊擔心病人怎麼辦。希望未來能夠多聽到「好險藥御守擋住了！」，而不再是「怎麼會發生這種事？！」

​去年醫守剛成立時，我們團隊曾前往美國哈佛醫院拜訪病人安全教父David Bates醫師，我們的創辦人李友專教授與David Bates醫師是結識多年的金蘭之交，兩個思緒明快又熱衷醫療資訊科技的人，好不容易親自碰上一面，話匣子根本停不下來，互相更新正在執行的專案，並且隨即交換合作資源，其他成員們跟在旁邊，一方面因為親眼見到我們這個領域兩位中西方教父碰頭，興奮緊張到說不出話；另一方面也幾乎跟不上兩位大師熱力四射的交流速度和不斷冒出來的交辦事項。
 
正當我們低頭忙著做筆記的時候，Dr. Bates突然停了下來，語重心長地開始說著最近的一個故事……

主角是一位年邁9旬的老爺爺，不僅患有糖尿病，還同時患有多重慢性病，當時因為食道出血而住院。但由於他的年紀非常不適合開刀，住院醫師只好先開立Pitressin ( 學名Vasopressin，台灣稱必壓生，用於治療食道靜脈曲張出血 ) 來減少出血，但是萬萬沒想到他卻不小心開成Pitocin ( 學名Oxytocin，台灣稱歐利生，能夠增強子宮收縮力，用於治療女性產後出血 )，導致老爺爺原本該被處理的食道出血沒被即時止住，隔天就因出血過多死亡。
​

​
​
​為了避免類似憾事一再發生，所有醫院都積極導入各項病安機制、增加多道把關確認的程序。然而無論科技再進步，只要有人的地方就有犯錯的可能。下回如果遇到醫護人員、藥師一再詢問你的名字、出生年月日、哪裡不舒服、做什麼檢查、或是花很多時間準備給藥作業時，別誤會他們不會自己看病歷、不用心或是經驗不足，這些看似沒有效率但又急不得的繁瑣程序，都是為了確認病人安全與品質。這個重要的任務，需要病人自己和醫護人員雙方共同維護，我們鼓勵病人多問，也請多點體諒、多點耐心。
 
那天離開哈佛會議室之後，Pitocin的故事也在我們心裡萌了芽，逐步轉化成新產品功能。

光是止痛藥誤開成青光眼用藥，每年發生3千多次！

臨床常用的止痛藥，化學成分名 ( 學名 ) 為乙醯胺酚 ( Acetaminophen )，健保用藥裡有53家製造藥廠，所推出的商品名稱多達百餘種，藥局能買到的更多，族繁不及備載。
 
由於可以選擇的商品實在太多，醫院常因成本、療效、效期等因素換藥，醫生在診間開藥如果第一時間用商品名稱找不到藥，就會改用學名重新找。在目前的醫療資訊系統條件下，醫師找不到想開的藥又有這麼多病人在等候時，很容易會不小心選成學名非常相似的青光眼藥：乙醯偶氮胺(Acetazolamide)。
​

乙醯偶氮胺除了用於青光眼治療，也可用於高山症的預防，其他科別的醫師也會開這顆藥。儘管後續還有藥師把關，但藥師同時需要調劑大量處方，缺乏足夠的時間與訊息判斷適用性，藥就讓病人拿回去了。
 
止痛藥和青光眼藥的顏色、外型接近，一般人難以透過外觀辨識差別，建議民眾多詢問醫師或藥師自己拿到的是什麼藥、服用時要多注意什麼。關心自己的用藥安全，多一點就多很多。