争鸣 | 医疗信息化软件的产品梦、平台梦，究竟能否实现？

无花果的归宿坡

【编者按】

产品化、平台化、生态化，是许多IT企业践行的梦想。但为何医疗软件的产品梦、平台梦这么难？北京云开盛景科技有限公司市场部总经理付海撰文对这一问题进行了剖析与展望。

真理越辩越明，认识越辩越清。欢迎医疗信息化同仁们就此继续一起探讨，系统分析问题症结，共同求解行业难题。投稿邮箱：gong_chen@HIT180.com。

近年来，互联网大厂推出的，以阿里钉钉、腾讯企业微信为代表的，针对TO B市场的互联网办公管理OA软件，逐渐从自主开发的一款产品，发展成为围绕着企业办公需求主线的开发者生态、货架式应用产品提供的平台，由不同厂家和个人贡献各种功能的App，搭载在钉钉或企业微信的底座和架构上运行，用户和买家可以根据自己的需要，各取所需、自由组合，形成了日臻丰富活跃的平台生态。

在医疗信息化领域，虽然“生态”一词不绝于耳，许多厂商推出了中台、微服务等概念，并付诸自身软件的升级改造，为平台模式的搭建提供了技术可行性，但迄今仍未出现“让天下生意更好做”的、真正意义上的医疗信息化平台商业模式。

是何原因？笔者从医疗信息化的业务特点、产品形态、技术要求分析开来，对未来可能出现的医信行业平台模式是什么、长什么样、应具备哪些条件，试做推演和畅想。以此反观现状，可对当前的空位和短板有更深切的认识，其中也许就蕴藏着巨大的改进空间和商业机会。

项目型业态阻碍平台形成

平台之所以为平台，应具有以下特征。

第一，提供产品的厂商品牌多样性。平台的生命力，在于广大的厂商和用户都可以参与其中。供选择的卖方越多，买方就越愿意参与，反之亦然。彼此激励、相互促进，平台的使用流量和商业价值在相互作用中迅速增长。

第二，用户需求与产品规格可以高效匹配。在平台为买卖双方提供的各种服务中，最基本、最核心的功能，就是买方需求与卖方产品规格的匹配。而当互联网和数字技术出现之后，平台更是极大降低了匹配的成本和难度。平台为了能更好地促成匹配，需要花大量精力，合理地设置和调整产品信息门类、关键字搜索，提供智能化、个性化的预测和推送功能，这些努力都是为了提高匹配的效率和效果。

第三，产品有清晰的规格、服务有清晰的边界。TO C的消费者虽然不一定对自己的需求很清晰、很固化，但当看到产品规格、服务界定信息时，其清晰程度足以让他做出购买决策，平台促成交易的目的才得以达成。而TO B的采购者则更加慎重，对需求则常常需要做出清晰、完整、精确的描述，甚至准备一套量化评价的体系，才能规避遴选失误的巨大风险。

对比医疗信息化行业的现状，可以看到明显的差异。医疗信息化的建设规划、方案设计、产品选型、厂家遴选，到建设实施、售后服务等一系列工作，都是高度项目型的。而项目型业态也构成了平台模式的障碍。

其一，难以允许品牌多样性存在。即便迫不得已，建设过程中需要多厂商配合、系统对接、项目管理、任务协调等，对于买方都是极为头疼的事。

其二，即使信息化项目建设完成，系统交付运行，厂商也不一定能完整、准确地把交付软件的规格说清楚，很多用户更是稀里糊涂，给不出完整的需求规格，更不用说在建设前的选型依据。一个系统适不适用、好不好用，通常没有成为信息匹配和交易达成的核心考量，取而代之的是“厂家实力是不是雄厚、口碑怎么样、案例够不够硬”这些表面评估；建设之后也是以“提的需求实现了没有、服务响应及不及时、工程师叫不叫得动、现场保障投入够不够”来评价，也几乎和产品规格与需求匹配没有什么关系。

其三，在这种环境下，每个厂商都趋向于把精力放在售前阶段的包装上，确保赢单，后期则专注在提高服务响应、维护客户关系上，并没有拿出足够的精力去梳理、分类共性需求，规划、设计、升级自己的产品线，界定产品服务的内容和边界。久而久之，形成了“用户需求理不清、软件功能说不清、服务内容划不清、配合边界定不清”的局面。一个项目的成交过程，通常是甲乙双方蒙着眼纵身一跃、以身试错的过程。幸运的结局，是互相成就，彼此多了成功案例；更多的情况，则是彼此都付出巨大代价后，进入长久的“不好用又换不掉”的僵持状态。

平台模式需要“货架”作为基础

那么，医疗信息化行业是否永远无法脱胎换骨，进化出厂商与用户、规格与需求，多对多自由选择、高效匹配的平台模式呢？

笔者认为，随着技术发展，软件架构升级，买卖双方认知的提高、习惯的改变，乃至商业环境的“风清气正”，在具备一定条件时，是可能出现更经济、更高效的医疗信息化TO B平台的。

能够撮合买卖双方高效匹配的平台，其中一个显著标志是“货架”的形成：买家能够从最符合需求的货架单元上挑选和获得即取即用（off-the-shelf）的产品，省心；卖家能够把产品摆放在目标客户最为显眼的位置，省力。因此，货架的合理设置和高效运营，就成为了这一模式能否成功的关键。

软件产品以货架形式提供，使用户即取即用，需要一个重要的技术前提，就是软件共同的运行环境和技术底座。支撑苹果AppStore的技术底座是iOS，支撑安卓智能移动设备应用商店的是Android。移动终端设备的操作系统，为所有App的软件开发和运行提供服务，同时平台运营方为了形成生态和拓展平台价值，鼓励各类开发者、厂商参与，提供产品上架服务。iOS和安卓，不单单作为一种操作系统软件存在，同时还要作为支撑平台模式的技术体系，配套大量的开发环境、工具、资源，开放给开发者使用。

平台货架的种类齐全、产品丰富、厂家多样，需要在软件架构上把底层服务和上层应用分开，把应用和应用边界划分清楚，将各种App共用的资源、协同交互沉淀在底层服务，形成清晰的系统关系和标准化交互。这样一来，每种应用才可以由不同的开发者独立研发，他们可以专注于自己的设计，而不必担心应用产品与底层之间、与其他应用之间，在拼装组合在一个用户现场后，能不能顺利运行。只有在这样技术底座基础上开发和实施的产品，用户才能达到从货架上即取即用的效果。

医疗信息化系统，是具有领域属性的应用软件。要实现平台模式下的货架式提供，在通用操作系统之上，还需要构建医疗行业专用技术底座，提供与业务相关的共有服务，例如基于医疗业务模型数据存储、数据转换、数据治理的能力；衔接驱动各类医疗业务流程的规则引擎；实现各类医疗业务功能要求的页面展现等。

仅仅在通用操作系统底座上开发应用，仍然无法确保在同一用户现场环境实施中，仅通过拼装组合就可以运行的效果。

医疗信息化平台模式的价值与挑战

医疗信息化领域的应用软件，相对于通用的企业OA，虽然市场领域更为狭窄、应用范围更为有限，但涉及到业务、管理、运营、监管等众多功能场景，涉及到各类医学专业学科，涉及到患者、医护、职能、科室管理者、医院管理者、医保支付等不同用户角色，还涉及到专业属性很强的药品、耗材、设备等特殊物品对象，其广度深度、庞大复杂，足以让其他任何领域的TO B应用开发者望而却步。

而领域内也远非几家实力强的大厂商，仅依靠产品线齐全、案例多，就可以满足市场上所有用户的要求。大量的未满足需求，为具有创新性、专业性、专注力的企业开发者、个人开发者，甚至医院的维护开发团队提供了改进和创新的广阔空间。

此外，医疗信息化软件中还蕴含了大量来自使用者的专业知识、实践经验，包括功能、流程、页面设计、专科模板、规则库、知识库等。

这些本可以随着软件产品被推广、借鉴、移植、共享的价值，受限于用户与厂商的项目型绑定关系、定制化开发的实现方式，被隐没在某个厂商的某个版本、某个项目的程序或配置中，无法将其独立出来，被更多的用户所了解、获取，发挥更大的作用，软件产品的商业价值也大打折扣。

当软件系统可以化整为零，细分成一个个模块化的产品，采用货架的方式提供给用户时，以上这些承载知识内涵的设计，才可能单独呈现，成为供选择购买的上架产品。

最后，笔者想要强调的是：平台模式、货架思维的实现，让平台运营方、买方用户、卖方开发者从新模式下真正获益，面临的挑战不仅仅是技术创新和研发投入，更是对医疗信息化传统开发方式、作业习惯、管理体制的颠覆，需要经过漫长的过程。