Re: [請益] 醫療相管產業

看板Soft_Job作者 (leoace)時間11年前 (2013/04/02 05:03), 編輯推噓7(7037)
留言44則, 9人參與, 最新討論串4/5 (看更多)
我研究醫學資訊11年,目前在某機構從事電子病歷標準研究,有一項工作是某醫資開放 原始碼工具的維護以及新工具研發。在研究所期間,接了一些業界、政府以及醫院的 專案。並有穩固的人脈以及國內外訊息。如果對電子病歷有興趣的,歡迎指教。 ※ 引述《Clementtang (劍客唐唐‧光明)》之銘言: : 大至 HIS 或 EMR/EHR,其他還有各種醫療領域 domain know how 的流程系統, : 隨便舉例如醫生開診斷處方用到的 CPOE (Computerized Physician Order Entry), : 或者是藥師配藥的處方系統、藥物辨識系統、結合條碼的藥袋檢核系統, : 或者是跟住院有關的住院藥車系統,前幾年還流行導入 RFID 做藥物辨識、血袋辨識等。 : 其實說真的,技術面不難,也不大需要 UX/UI 設計,但是像前輩說的, : 光是談需求就會搞死人 XD...。 不難是因為台灣的醫院與業界並未導入真正的核心技術面,而核心技術很類似軟工的 Semantic Web的概念。意思是系統跟系統之間的溝通與訊息解析採用的技術與語法皆為 可機讀的(Machine-readable),而制定標準的目的就是在於讓醫學資訊系統能隨插即用。 因此排除掉使用者需求以及UI設計以外的技術,如何讓聽懂臨床人員的需求,而將需求 將這些技術轉化成如何結合標準與格式來達到隨插即用的目的,這是PM再跟臨床進行 顧客訪談時所必備的技能。 然而在台灣,學術界跟業界的解決方式只有前半段,缺少後段轉化技術的能力。 舉例來說:一個要進行CPOE的設計與整合需要知道使用者的使用習慣,以及各醫院 的作業流程。所以這一部份需要由工程師跟專案去了解並進行面談,這一部份我相信 大部分跟其他客戶端訪談的工作性質差不多。但真正難且為核心技術的是將這個實際 的Work flow Model 轉化成一個隨插即用的模型(Model),並且在資料的組成上轉化 成許多國際標準的醫學辭彙編碼以及一個模組化的物件形式。這部分可參考 http://ppt.cc/u0Xg,Figure 4.1-1。即為一個CPOE的欄位轉化成Scheduled Workflow 的一個模型。 當然除了CPOE以外,各式各樣的系統與法則皆可使用這樣的概念。 所以這種資訊系統的設計方法,就技術面來說,難不難各位軟體人心裡有數。當然,這種 做法可以快速地達到系統複製的效果,賣到醫院去只要根據使用者端跟UI修改符合當地 的流程與需求,在溝通與資料模組上其實是一氣呵成的。 而台灣學校的教育只有教到前半段,而後半段再根據學生以及廠商的能力來決定到底要用 哪些技術來開發與實現。台灣的教授又大部分沒有這樣的概念,所以教出來的學生認為 就是這樣,因此才會在那邊改來改去,加上又被灌輸標準很簡單,套用就好。殊不知國外 薪水最高的軟體工作就是寫標準的。一碰到問題的大絕就是我們只要照標準就好。因此 台灣的解決流程是: 訪談->開規格->開專案->建資料庫->測試->交貨->上線->擴充規格->資料庫加開Table-> 改規格(無限循環)。因此造成每家醫院的一個資訊系統都是Project-based。一堆資料庫。 用的人永遠都是在拉資料庫跟客戶訪談的軟體工程師。 所以我改一下某中原醫工教授的經典台詞。 國外希望能做到Plug-and-play,而台灣是一直在Plug-and-pray。 : 這種事情大概有一大籮筐可以說,而台灣很有趣的是各醫院都愛玩自己的技術團隊, : 所以光經驗複製就很沒有效率因為大家都不大一樣,因此若想要把系統產品化來推, : 不見得能像歐美一樣賺到多少錢,可以看看 IBM 或飛利浦就知道 IBM有很強的團隊在進行這種模組的開發並結合他們的硬體以及系統,這樣local的系統 整合商可以用他們的工具來快速地製造產品。台灣的各醫院都有自己的技術團隊,是沒錯 國際上也是這樣,但是最大的不同是我們懂這種核心技術的人太少。我遇過的資訊室跟 廠商,都是想用現有的工具來開發就好,所以永遠不會有那種 真。Plug-and-Pray產品 。加上醫院也一直不斷洗腦,認為標準照做就好了,非常少人了解後半段的專業。 : 至於 EMR/EHR 其實就是一種標準,標準訂好,大家照表填資料而已, : 有興趣的可以看看衛生署電子病歷推動專區的網頁,有完整說明電子病歷製作規範, : 熟 HL7 以及 CDA R2 格式大概就差不多了。 這部分台灣對不起你,沒傳授你真正的觀念以及電子病歷技術。導致大多數的人的想法 都是如此。 台灣推動的電子病歷標準,其實有一個致命的缺失。就是把電子病歷當成紙張病歷一樣 (表單形式)。當初提這個想法的人(博士論文有,大家可以去查)是想收集全台的各 大醫院的病歷表單,然後統計一下有哪些資料是相同的(例如姓名欄位),根據田野 調查來制訂出大家共通的 "欄位"。剛開始訂出來的,被大量的批評說沒照國際標準, 後來在第二次改革的時候才修改成CDA的編碼格式。之後衛生署從振興經濟方案裡面拿出 經費鼓勵各大醫院使用這個台灣版的電子病歷標準,只要你通過審查,醫院就可以宣稱 自家的醫院已經完成 "電子病歷"。所以這三四年來新聞偶爾會有XX總醫院完成電子 無紙化等新聞。 但說實話,這樣的電子病歷充其量只是一個數位化過後的 "紙" 本病歷,對於電子病歷 會將醫院的資訊系統升級到更新更好的架構一點幫助都沒有。而造成革命性的改變卻是 多媒體式的電子病歷(請問只能發文字訊息的FB能賺到錢?)。 最後,醫院資訊室只會把這一堆CDA放到一台Server,等評鑑時再說,我們有做到,但是 實際的查詢使用以及調閱,都不用這台電子病歷伺服器。這就很像連長都把裝備鎖在倉庫 理,等裝檢的時候在搬出來,一樣的道理。 : 題外話,小弟當年在做苦命研究生有參與過制訂跟格式說明撰寫, : 老實說當年沒有真的很懂一直到寫了幾篇文章才知道整個全貌在幹嘛 Orz : 還有最近我們公司在試圖把一些 reference 資料庫導入流程,做決策支援系統, : 但是動作很慢就是了,醫院大家都很忙且難以改變習慣的模式,所以...。 辛苦你了,台灣真的對不起你,沒傳授好的觀念給你。有了後半段的能力後,我相信 貴公司的決策支援系統應該會有很強大的改善。 : 2. 儀器商的整合型醫療資訊 : 醫院裡面有很多的大型醫療儀器,諸如 CT、MRI 或生理監視等等, : 而這些檢查結果的資料,都需要有一個系統來讓醫院收集、呈現給相關醫療人員瀏覽。 : 由於跟儀器介接,所以這種系統多半是由硬體商包辦,台灣知名的就有飛利浦、 : GE、西門子,或韓國商 Infinitt (英飛特) 近幾年也吃下不少台灣市場,              收起來了 : 目前衛生署也搞了個全國醫療影像交換中心 (IEC),我的了解是弄了個大 INDEX, : 而不是做資料集中,好像透過 IEC 可以查到在哪間醫院,然後提供影像交換, : 但網路速度悲劇導致... 效率... 恩 XD : IEC 跟電子病歷交換中心 (EEC) 都是商之器承接的,這裡面就很有趣了, : 據聞幾間外商好像有點意見,不過小弟不在這產業沒啥內幕能提供。 這有一個最大的問題是,政府標案寫要採用IHE XDS技術,但最後實際出來卻不是。IEC 自己訂了一個上傳索引的標準格式,叫全台醫院都要用這個的格式。因為國際上的廠商 針對電子病歷跨院交換的方式都採用IHE XDS(Cross-Enterprise Document Sharing)的 技術。全球都採用同樣的標準跟技術再開發產品,唯獨他硬要搞一個 "類XDS"。不倫 不類,然後只給API,不公布病歷索引的格式,讓所有的PACS產品硬是要用他的API。 如果你是其他公司,你會允許競爭對手給的不明API硬是要放到你的系統內嗎? 我是很質疑為何標案內容是要符合IHE XDS,但實際出來卻是類XDS,你說其他廠商不 氣的跳腳嗎?難怪很多外商都想要退出台灣市場。因為現在國際主流是XDS市場。 : 政府部門的案子通常都不大好做,除了攻案時會亂屁而承諾的奇怪功能外, : 往往需求單位自己沒有好好搞清楚,若碰到接案方沒做好 SA SD 就很痛苦。 主要是政府的承辦人員不了解電子病歷,因此很多資訊都是來自於廠商,加上一碰到標準 就認為不是他們的事情。 : 做個結論,做這行要面對的就是若跟業務端有關,往往非常僵化且固守成規, : 對於新技術的接受度很慢,我猜大概跟銀行業、航空業差不多, 我覺得學術界要負很大的責任。希望台灣的學術界能跟上時代,不論是純資工或醫資 老師最好每兩三年都要進行一個技術upgrade。 例如:國內的跨平台程式設計課程不能只是教Java,應該要教一些真正跨平台新的技術跟 軟體概念:例如CMAKE、GIT等。因為這樣只會造成學校的訓練都認為跨平台程式設計 只有Java,而真正實務上C/C++有很多地方都有跨平台的精神存在。 嵌入式系統設計也不能只有Linux, gcc等之類的東西,這樣只讓學生學 "工具"而沒有辦 法了解到嵌入式系統的精隨。 : 因為牽涉到大量的既定業務流程跟最重要的病人安全,導致非常保守。 : 再來就是台灣的醫院大部分都各玩各的,而除非牽涉到評鑑,不然能不改變最好。 : 看看某幾間大醫院那精美的超過 10 年的老系統,甚至某醫院還有終端機型態的系統, : 就知道要推一些新東西有多難。 因為老舊的東西要配合老舊的儀器,等老舊儀器淘汰掉自然也就會消失。 建議貴公司派人去RSNA去考察,希望能為貴公司帶來很多的收穫(每年都在芝加哥) http://www.rsna.org/Technical_Exhibits.aspx Technical Exibits會展示全球最新 的產品以及概念軟體。我想台灣的公司花點錢投資員工,應該是一個很的選擇。台灣 的老闆太小氣了,應該把格局做大一點。 PS: RSNA是國際上一年一度對大的醫學資訊與儀器的最大展會。所有全世界最新的醫學 資訊技術與產品都會在此發表。由這裡可以看出每年哪一間公司賺錢,那一家的攤位就 特別大。台灣很多醫院的醫生都去那邊看新機器以及新軟體還有未來Medical IT的趨勢。 如果你看過新東西,你就會了解為何歐巴馬花了八十幾億台幣蓋一個電子病歷辦公室。 因為美國的想法是,今天花八十幾億,5年後要回收500億回來。台灣的想法是能省多少錢 PS:不是在戰你,只是提供一個正確的觀念與資訊而已。希望台灣這領域能進步。 另外也希望對這個領域有興趣的軟體人,再進入之前能有一番認識。 PS:這一行每年全世界都會舉辦一個IHE Connectathon活動,即是將全世界的廠商每年幾 次聚在一起一個禮拜,然後彼此系統用網路互接來測試許多醫院資訊系統是否能正常運 作,以達到Play-and-play的境界。通過測試的廠商,每年都會列出一個清單說明哪些 系統彼此之間能互通。醫院也可以根據每年的清單來尋找適合的廠商,過濾沒能力的廠商 。我想國內醫院招標時,應該要參考這樣的資訊才不會讓以後的整合上的困難。政府也 過濾一些技術不成熟或是突然成立的公司來搶標案。 近三年中國也開始舉辦IHE Cina Connectathon,每年的結果都會公布提供中國的醫院做 為參考。台灣在2003年的時候有舉辦過一個簡單的Connectathon。不料政府不重視,台灣 也錯過了亞太地區醫學資訊產業的最好的龍頭地位的時間點。另外,IHE可以Taiwan的名義 加入。如果在不趕快到時候又會變成Chinese Taipei。 IHE (Integrating the Healthcare Enterprise)http://www.ihe.net/ 以上就個人的見解以及說明。 -- -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 77.188.186.43 ※ 編輯: leoace 來自: 77.188.186.43 (04/02 05:08) ※ 編輯: leoace 來自: 77.188.186.43 (04/02 05:10)

04/02 05:19, , 1F
講到最後~還是人的問題啊?我倒不覺得是技術不純熟~之前有
04/02 05:19, 1F

04/02 05:21, , 2F
幸把三間醫院的系統整合起來時~最大的問題在於如何統一流
04/02 05:21, 2F

04/02 05:23, , 3F
程~有的醫院是先做再送單~有的是先送單再做~這個流程不統
04/02 05:23, 3F

04/02 05:24, , 4F
一~系統要怎麼做才能滿意?
04/02 05:24, 4F

04/02 05:30, , 5F
理想中當然是模組化後經過設定就可以到各家醫院上線~但是
04/02 05:30, 5F

04/02 05:31, , 6F
...各家醫院的客制化程度~似乎沒有想像中那麼簡單啊啊啊!
04/02 05:31, 6F

04/02 06:40, , 7F
所以我說,台灣只會殺豬公,想做哪塊才談哪塊...
04/02 06:40, 7F

04/02 06:56, , 8F
Infinitt沒收起來喔,我待過的二家醫學中心還有在用Y
04/02 06:56, 8F
謝謝,之前有一家倒了,但忘了是哪一家。

04/02 09:37, , 9F
plug-and-play?
04/02 09:37, 9F

04/02 10:11, , 10F
推(Y)
04/02 10:11, 10F

04/02 11:56, , 11F
很有用的業內資訊,若以接案角度看這個產業根本搞錯方向
04/02 11:56, 11F

04/02 11:56, , 12F
套一句俗語,人家已經上太空了,我們還在殺豬公
04/02 11:56, 12F

04/02 11:58, , 13F
只用 需求訪談-系統分析-實作 模式,再怎麼搞也打不到核心
04/02 11:58, 13F

04/02 12:49, , 14F
核心?不懂...當醫生和護理人員堅持要他們心中所想的流程和
04/02 12:49, 14F

04/02 12:50, , 15F
資料時~不客製化還有什麼解法?
04/02 12:50, 15F

04/02 12:51, , 16F
一樣是吃飯~有人吃自動化生產的炸雞塊就滿意了~但有人偏要
04/02 12:51, 16F

04/02 12:53, , 17F
吃到五星級主廚做的才滿意~價格和需求都不同~能怎麼做?
04/02 12:53, 17F

04/02 12:56, , 18F
其實台灣也不乏模組化產品的廠商~但往往因為無法滿足客戶
04/02 12:56, 18F

04/02 12:56, , 19F
最後還是只能客製化...
04/02 12:56, 19F

04/02 13:28, , 20F
推前輩 我想那篇博士論文應該是簡老師的 TMT ?
04/02 13:28, 20F
內行的

04/02 13:29, , 21F
套 CDA 無法變成真的 EMR 這點我也知道
04/02 13:29, 21F

04/02 13:29, , 22F
因為當時寫標準指引書的我們 我承認 我自己都搞不懂
04/02 13:29, 22F

04/02 13:30, , 23F
EMR/EHR 一路走來變成這樣 其實學界也是在不斷妥協
04/02 13:30, 23F
一開始學界的方向就弄錯了,所以才會被一直被糾正。但TMT還是硬幹,後來接手的劉老師 算是有拉回來一點,但已經來不及了,因為全台灣都認為電子病歷就是衛生署推的那些。 個人覺得最大的收穫就是,把全台的病歷表單做了一個很好的整理,以後在標準化時, 速度應該加快很多。

04/02 13:37, , 24F
去年衛署有撥款進行先期研究 有興趣的可以參與
04/02 13:37, 24F

04/02 14:43, , 25F
好文…推一下…不過我覺的這是理想中的理想…在台灣不
04/02 14:43, 25F

04/02 14:45, , 26F
適用…總歸一句都是人和政策問題…光健保制度就可以改
04/02 14:45, 26F

04/02 14:45, , 27F
來改去的…記得以前健保局有針對特定藥品給予的補助額
04/02 14:45, 27F

04/02 14:46, , 28F
度各不相同,某些藥在固定的期限內也只能開多少量…
04/02 14:46, 28F

04/02 14:46, , 29F
當我們按制度開發系統,醫生的一句話…為啥這種藥不能
04/02 14:46, 29F

04/02 14:48, , 30F
開?之後系統的設計就全翻盤了…
04/02 14:48, 30F

04/02 14:49, , 31F
總之一切都重點都是"人".....
04/02 14:49, 31F

04/02 14:58, , 32F
美國朝這方向在走,醫院也有“人”一樣問題,但重點是廠商
04/02 14:58, 32F

04/02 15:00, , 33F
差很多,台灣醫生很多以為這也是他們的專業,所以就變成這
04/02 15:00, 33F

04/02 15:03, , 34F
樣,以整合角度看,台灣模式會造成永遠是專案,但產品才是
04/02 15:03, 34F

04/02 15:05, , 35F
一家醫軟公司最正常的發展
04/02 15:05, 35F

04/02 15:48, , 36F
雖然不是在醫療產業,但敝公司有在某個產業參與規格的制定
04/02 15:48, 36F

04/02 15:50, , 37F
玩過一輪之後,贊同leoace兄的觀點,只玩專案是成不了氣候
04/02 15:50, 37F

04/02 15:52, , 38F
規格化最大的用意是把產業由垂直分工轉為水平分工
04/02 15:52, 38F

04/02 15:53, , 39F
只要專注在某一塊的專業,並在產業鍊站住腳,大家都能獲益
04/02 15:53, 39F

04/02 15:55, , 40F
但要成這個局,也賴領域內的參與者有這樣的共同認知
04/02 15:55, 40F
※ 編輯: leoace 來自: 77.10.134.145 (04/03 04:51)

04/03 04:47, , 41F
要找到對的人才有用~大家都知道~但問題往往沒那麼單純~還
04/03 04:47, 41F

04/03 04:47, , 42F
有派系鬥爭呢!改朝換代的時候~理所當然連主任和組長都被拉
04/03 04:47, 42F

04/03 04:48, , 43F
下來~而原來合作的系統...
04/03 04:48, 43F

04/03 04:49, , 44F
我是離開那個世界了~如果有人能推得動~當然是樂見其成...
04/03 04:49, 44F
文章代碼(AID): #1HMVOCdy (Soft_Job)
文章代碼(AID): #1HMVOCdy (Soft_Job)