匡廷斌：医院HIS随兴杂谈

　　虎年最后一周，一直比较“嚣张”的我最终还是阳了，静养期间看到几篇关于新一代医院信息系统的文章，甚是兴奋。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系统的设计研发。