虎年最后一周，一直比較“囂張”的我最終還是陽了，靜養期間看到幾篇關于新一代醫院信息系統的文章，甚是興奮。20多年的HIS歷程比較曲折，當我在40歲準備徹底離開這個行業時，是研發新一代醫院信息系統的機會讓我重新燃起對HIS的希望，對新一代HIS的追求也成為余生的執念。臨近年末，也想寫點什么，遂成此文。

　　一 醫院HIS的歷史

　　要說HIS的未來，得講HIS的歷史;所謂知歷史而明興替、知過往而鑒未來。

　　醫院HIS有兩種理解：一種是狹義HIS，泛指掛號、收費、藥品、醫囑、材料等功能;另一種是廣義HIS，泛指整個醫院的信息系統，即醫院信息系統(Hospital Infomation System)。但行業內還是遵循傳統，無論是方案還是報價，都將HIS單獨開來，與電子病歷、檢驗LIS、影像PACS并稱四大系統。為什么會有狹義和廣義之分，這與醫院信息化發展歷史有關，與當時的信息化基礎、行業廠商、產品生態等多種因素有關。

　　1.最開始是收費結算系統，主要是為了解決收費員手工開發票巨大的工作量，特別是當醫保改革需要聯網結算后，收費結算系統成了剛需，這也是醫院信息系統的開山鼻祖。

　　2.當就診患者越來越多后，先藥房劃價、后收費結算、再藥房發藥，要排三次隊。所以為了減少一次排隊，就上了藥庫和藥房的藥品管理系統，劃價結算一體化，收費員劃價得判斷藥房是否有庫存，所以網絡版的財務和藥品系統就出來了。這時候各個廠商給起了個英文名字：Hospital Infomation System，簡稱HIS，這就是狹義HIS的起源。劃價收費一體化，收費窗口工作量明顯增加、工作壓力很大。20年前一家三甲醫院上線HIS，我親眼目睹一個年輕力壯的小伙子搞得滿頭大汗，因為處方上的藥品不認識，并且經常出現藥品庫存不足需要回去找醫生修改處方尷尬情況。而醫生手寫處方，怎么可能知道哪些藥有庫存、哪些藥沒庫存，所以需要打電話問。這一來二去，“三長一短”的現象就成為經典了。

　　3.要解決“三長一短”問題，必須解決醫生電子化這個源頭。電子處方、電子醫囑，與藥品、財務聯動，有效提高了當時的服務效率。這是一段艱難的時期，是史上最痛苦、最無奈的信息化歷程。醫生總是對系統不滿意，但崩潰的是誰也不清楚、不明確醫生到底想要啥。面對現在各個醫院差不多都是100%的電子處方和醫囑，你總是會想，為什么呢?

　　4.其實真正困擾醫生和護士的難題，并不是醫囑和費用的處理，而是病歷和文書。醫生手寫一份病歷大約2小時，加班寫病歷成為一種常態，就像寫作文一樣，一行一行、一段一段地寫，不小心寫錯了就崩潰了。所以大部分科室都在用Word辦公軟件來制作病歷模板，那個年代的電子病歷一般都叫記事本病歷，或Word病歷。而護理文書又跟Word長得不一樣，大多數都是表格、表單。所以為什么臨床醫護對信息系統一直都是處于不滿意的狀態，就是因為信息化并未完全覆蓋他們的診療行為。

　　5.記事本病歷、Word病歷有一個巨大的缺陷，就是質量不好控制。有一句話說得好：質量管理最好的辦法就是，當按錯誤的操作方式、系統就走不下去。這就是結構化電子病歷的開始，在專業性的病歷編輯器、護理表單編輯器的支撐下，統一元素管理，結構化平衡設計--既能有效提高病歷和文書的書寫效率，又得兼顧病歷質量的控制。就是在這個時候，臨床醫護才逐步平息了內心的焦躁。

　　6.解決臨床醫護這個信息化瓶頸持續了較長周期，原來的HIS廠商深陷醫囑、藥品、費用的三角泥潭，受限于業務知識和理解瓶頸、受限于技術架構和設計瓶頸，無力再拓展其他業務產品。導致從電子病歷開始，檢驗、放射、超聲、內鏡、病理、手麻、心電、重癥、康復、介入、血透、藥事、院感、運營等業務領域的信息產品自成體系，這種信息的割裂給醫院信息化建設歷史留下了一道深深的傷痕。后續應運而生的信息集成平臺，正是為了彌補醫院信息化歷史缺憾。

　　7.在20多年醫院信息化歷史中，最受詬病、最受質疑、最受批評的無疑是狹義HIS系統，以及那群HIS工程師。有一年我去貴陽，組織當地團隊搞了一次團建，吃火鍋、喝酒，正好有一個下屬的妹妹也參加，我開玩笑對她說，找對象得找像你哥這樣的：打不還手、罵不還口、積極主動、樂觀進取、吃苦耐勞、勇于挑戰，HIS工程師未來必成大器。后來我聽說她真找了貴陽團隊另一個HIS工程師。我回憶了一下，20多年來我直接或間接促成的大約有10來對。作為HIS主管，我歷來都是政治思想溝通第一、知識技能培訓第二。我原本沉默寡言、呆板木訥，慢慢變成口若懸河、能言善辯，這都是HIS給逼的。世間最痛苦的事情，莫過于你明明知道客戶說得非常在理，然而你卻必須想方設法說服對方改不了。

　　10年前我任一家醫院的項目經理，一名醫生向信息科主任提了一個問題：每次界面上只能處理一個患者的業務，每天不停的在打開、關閉、打開、關閉中進行患者切換。比如我正在寫8床的入院記錄、正寫一半;這時10床來咨詢病情，我得保存8床入院記錄、關閉窗口，重新打開10床界面，咨詢完10分鐘左右過去了;假設這時15床又來咨詢、也約10分鐘;這時候要重新回到8床寫入院記錄，之前寫到哪兒已經不記得了。建議這樣設計：像上網一樣，我管10個患者，上班時全部打開10個標簽，每個患者就是一個上網標簽。每個患者標簽下，醫囑、入院記錄、病程、各種報告等又像上網一樣再起一層標簽。這樣每天操作界面都不用動，像剛才描述的場景，入院記錄寫一半兒也不用保存，來回切換標簽就行了。

　　當我主導新HIS系統研發時，第一個要實現的設計目標就是這個需求。6年后，我找到那家醫院的信息科主任，告訴他當年那位醫生提的需求我實現了......

　　8.當醫院信息系統出現問題時，大家總有一種下意識的行為，是不是HIS又出問題了?為解決這個問題，行業內大部分采取的是切香腸的辦法。把醫生站、護士站切了，與電子病歷、臨床路徑合稱CIS。把人事薪酬、物資材料、設備資產等切了，并入綜合運營。把排班、預約、支付切了，統一號源池、多渠道預約和支付等切了，并入互聯網+醫療。這時候我們會發現狹義HIS只余藥品管理，藥品零加成、外包切了，終于狹義HIS切完了。但問題的本質并沒有得到有效解決，圍繞醫療服務和管理，信息化其實也就那點東西，到底是哪兒出了問題?到底醫院信息系統該如何設計?這就引出醫院HIS的后世。

　　二 醫院HIS的未來

　　醫療IT行業的根本矛盾是：系統架構設計的落后，無法適應、滿足醫院日益變化和增長的需求。這句話不是我的原創，但記不得作者是誰了，對于原創作者表達一下歉意，在此引用一下，我個人覺得這個觀點真是一針見血。很多問題是表象，本質是技術落后，跟不上了。

　　“什么系統是好系統?少讓我加班的系統就是好系統”，這是一名醫生的原話。多么樸實的語言，多么簡單的道理，同時也意味著HIT是多么有挑戰的工作，因為定義一個好系統很難，但少加班卻很好入手。假設一個醫院信息化全是白板，也不受限于行業任何廠商和任何產品，我們來梳理一下。

　　1.早期狹義HIS系統的設計和開發，談不上有什么架構，更沒有多少設計模式和開發方法。做什么東西都是圖快、圖省事，開發出的系統就是夠用，但很難精進。代碼復用率低，技術成本高，響應慢、質量低，系統越用越重。系統重新翻寫，猶如把一屋子的東西打亂、重新整理一下，不能解決根本問題。這種產品，項目上的越多，問題越突出，因為無法做到版本統一。所以早期狹義HIS便有定制化開發、電視機產品之說，要么啥需求都在修改，要么啥需求直接都不修改。而醫療IT行業最為突出的典型特點，就是年年、月月、天天都有需求變化和增長，這讓其他行業的IT工程師很難想象，只要修改程序，難免就會有缺陷。所以醫療IT的架構和設計要特別注重避免反復修改程序代碼。

　　2.系統架構包括業務架構、功能架構、技術架構、數據架構、應用架構等。借用汽車工業的說法，醫療信息化建設是一個高度標準化的系統工程，系統架構設計是一種高度的系統思維。系統業務架構系統性的描述了業務領域中業務構成、組織結構和業務關系，為產品規劃和產品功能架構設計提供業務模型依據。系統功能架構系統性的描述了組織中業務關系所涉及的產品功能分類、結構和聯系，是系統功能的整體藍圖。猶如每棟房屋所涉及基石、磚墻、梁柱等材料構件，通過關聯和集成形成有機的整體。系統技術架構系統性的描述了系統整體功能實現所采用的技術方法、技術路線和技術標準，為各個產品的設計研發提供技術基礎支撐。猶如房屋材料構件的生產和組合的技術方法、工藝和手段。系統數據架構系統性的描述了系統數據結構、數據關系和數據標準，數據是系統內部關系的表現形式，數據從哪里來、到哪里去是依據業務關系來定義的。系統部署架構系統性的描述了系統部署運行所涉及的物理和邏輯關系，為系統的設計開發、數據存儲、安裝部署、運維管理等提供依據。

　　(1)系統業務架構：目的是劃分產品功能邊界，避免各個產品越長越胖，超過了自我邊界和范圍，為產品具體的功能設計提供依據。比如多機構、集團化的醫共體或集團醫院，其業務架構與單體醫院會有較大的不同。

　　(2)系統功能架構：目的是確定產品中各個業務流程、功能節點、數據流向、應用場景，為產品研發車間提供圖紙。這一點其實非常關鍵，目前各個廠商都在努力把自己的產品向外延伸，個個都越來越胖，一個屋子擠不下那么多胖子。

　　(3)系統技術架構：猶如一棵大樹，各產品就像是大樹上生長出來的枝、葉、花、果。統一技術架構體系，為產品研發的生產車間創造技術條件和基礎。SOA、微服務、中臺、組件CBD、云計算、大數據、人工智能、物聯網、移動通信、容器化、分布式、領域驅動、緩存機制、消息機制、gRPC等信息技術的應用并不存在非此即彼，因地制宜的借鑒、引用其思想、方法和工具，打造一顆堅強有力的技術發動機。

　　(4)系統數據架構：統一數據標準，自上而下設計;以數據為驅動和紐帶，把各個業務領域、各個業務產品給聯接起來。醫院信息數據總體分為兩類：收入支出數據，醫療健康數據。醫院每一項診療活動都盡可能地計價、并核算成本，各項診療活動就可以按不同維度、不同方法進行核算和績效管理。醫院每一項目診療活動都涉及以患者為核心的病歷信息，以及每類診療活動所涉及的質量及管理信息。

　　(5)系統部署架構：系統部署取決于系統應用場景的設計，第一層是系統與設備之間的連接和交互;第二層是院內網絡PC、或其他終端;第三層是互聯網訪問，俗稱線上、線下一體化。互聯網+醫療并不是特定的產品定義，而是產品的應用場景定義，本質上業務數據還是一樣的，只是突破了物理空間和時間的限制。所以微信、支付寶等互聯網+智能手機的便民惠民功能，最好是從HIS生長出來的花、果，即傳統業務向互聯網的自然延伸。

　　(6)架構設計總體思路：結構分層、組件分域，通過靈活的組裝和配置，提供多樣化、可伸縮的產品服務。家用汽車生產是一部標準化、車間化、流水線、多樣化的發展歷史。從整車生產到精細化的配件、零件拆分，汽車工業得以蓬勃發展。醫院信息系統猶如一部汽車，拆成發動機、變速箱、導航儀器形成配件，再拆形成螺絲、板件、鉚釘等零件，這些配件和零件輔之以標準化的產品研發車間，效率和質量將大大提升。

　　3.阿基米德說，給我一個支點，我可以撬起地球。給我足夠的資金和人才，我還醫院一個不存在割裂、天然互聯互通、完美數據共享的廣義HIS系統。但這是理想主義下的臆想，實際執行需要長遠的推進和清晰的產品規劃。要實現廠商視角下的一體化比較遙遠，但結構上松散、功能上深度耦合的一體化還是切實可行的。醫院的信息化從形式上說是政策、社會活動推動下的變革，其實本質上是傳統行業向信息時代靠攏的歷程。根本目的是更好地契合當前社會形態，受益于當下的技術增益。從這一點來說，并不存在僅限于互聯網行業的技術或實踐，亦不存在只有互聯網才能創新甚至代表技術前沿之說，一切能使醫患受益的技術理應存在其萌芽的土壤，當然這需要清晰的業務視角和破局的勇氣。大數據也好，物聯網、AI也罷，我們追求的不應是科技感本身而應是其帶來的成本的降低和服務的提升。

　　天下大勢，分久必合，合久必分。歷史的割裂、分離，可能在不久的將來又需要合在一起(至少部分核心業務是可以一體化的)，而合之后、將來又如何分，時間可以見證。

　　4.當然，除了架構設計外，其他售前咨詢、交付實施、運維服務等技術工作也非常重要，相比之下，架構設計才是主要因素。所以作者一直相信，絕大部分HIS工程師都是勤奮學習、踏實肯干的有為青年，力不從心必有難言之隱，地基不牢、何以建高樓大廈?不畏浮云遮望眼，守得云開見月明，醫院信息系統的未來讓人期待。

　　謹以此文獻給那些堅持不懈、勤勞勇敢的HIS工程師們：

　　逢山開路，遇水疊橋，膽氣注全身，志在必得猛先鋒。

　　橫刀立馬，孤身斷后，鮮血透鎧甲，死戰不退貫長虹。

　　以天為幕，以地為席，仗劍行天涯，勇闖東西南北中。

　　作者簡介

　　匡廷斌，1999年畢業于昆明理工大學，20多年醫療IT從業經歷，有豐富的醫療信息化建設實踐，一直致力于新一代HIS系統的設計研發。