医疗软件成功要素

医疗软件开发现状      

       相比互联网的一套运行代码,医疗是各个医院/区域分别部署,且都附带着很强的个性化要求,整体表现为业务复杂、个性化突出、体量不大。主要矛盾体现在:

        1)个性化冲击。各个现场的个性化需求融合会造成代码冗余、业务紊乱,大大抬高了测试、交付风险,不融合又将降低复用性及产品价值。版本升级过程无法向下兼顾,各个现场实际运行的项目无法统一升级造成多版本管理。

        2)技术定位过高。医疗的项目化部署需要解决的是稳定、易交付、易维护。互联网的高标准架构大大抬高了研发水平、交付难度、维护成本。

        3)研发专业度不够。传统医疗研发业务精湛、技术薄弱,主要是项目化模式下几乎无高并发、大数据需求,互联网研发相对技术方案先进、缺乏行业经验。明显对冲的矛盾下,大家往往忽视了行业研发的重要性,实际交付时感受到了风险、感受到了压力却难以调头。这也是普遍表现出来的医疗产品烂的核心原因。

实践讲解

1)模块过于细分

        某公司HIS系统模块划分时由阿里架构师执行,60多个细碎模块,放在互联网行业是正常逻辑,放在医疗无论是从模块开发还是模块交互、现场实施、硬件资源、个性化服务等任何层面都大大抬高了研发的周期与成本。链路过长、技术门槛过高又造成了现场研发支持不足、问题定位慢、个性化响应效率低。HIS要的是24小时稳定,它的切分只能从大范围切分比如按领域的医生站、护士站、收费、药房,大HIS会包含病历、影像、检验、病案、手麻,且尽量确保模块的独立性,减少交互。

2)技术方案过于理想

       有些公司制定方案时就采用了分库分表、框架支持所有数据库的技术方案,恨不得把互联网技术系数应用于医疗。

       本人作为甲方专家评测系统时,一旦涉及分库分表就相对慎重,理由一是医院数据的量级还不需要那么复杂的方案,理由二是后期数据利用只能采用接口形式会受制于厂商,医院的数据需要独立的自我管理否则难以发挥数据资产价值。

        不同数据库有自己不同的特性、不同的函数,高业务系统少不了集成性sql的出现,另外不同数据库环境搭建、测试、研发都需要付出额外的很多成本,基于oracle或sqlserver其中之一能把系统做到易用、已交已为不易。

3)个性化与产品化混用

        现场提出的很多需求,研发人员业务经验不足时无法判断是标准产品的一部分还是现场个性化,甚至企业自身也没区分个性化意识,一股脑的管理了各个现场的所有代码,造成了新上项目的各种不稳定、功能冗余。业务系统重骨轻肉、产品+个性化两条腿走路。

4)版本迭代

        产品的版本迭代是为了消除前期开发过程因不理解业务、时间匆忙应用了一些临时手段等问题,从而实现产品的精简、规整。有效的版本迭代是产品逐步向好的标志,随着团队的稳定、业务的推广,标准版本迭代的速度会逐步下降。

破局之道

     (一)项目介绍

      10多年医疗老兵,7年架构师经验,经历了这个行业研发与交付的各类困境。数据平台是我参与度最高的一个垂类项目,以此为例简单介绍下一套系统的成功步骤及失败教训。早年的数据中心设计处于探索期,用业务思维处理数据问题,导致实施难度大,可复制性几乎没有。随着数据中台、业务中台概念的明晰,OLAP思想逐步成熟化,数据中台的建设开始陆续出现各类规则与标准,历经三版,打造出了一款极致性价比的医疗专业数据平台。

       最初作为一名纯粹的技术架构师,主要解决公司技术难题及工具模块研发。后基于产品的难交付性,现场调研时发现仅熟悉医院数据、展开业务功能就耗时半年之多,最终实用性表30张左右。时间损耗主要体现在交付人员对医院业务系统颗粒度不了解、统计标准不明确、产品自身设计过于复杂。基于调研需求,本人第一次提出一个战略目标,产品快推、变个性化负担为利润。

       标准数据应用比如“公立医院绩效考核”要根据考核要求识别数据来源及颗粒度,财务系统、病案系统是标准度最高的统计但无法细分,初期只需提供标准值让客户看到结果,并为开发确定数据提取规范,勿将各类医院数据混成一锅粥。成果初现可由3个月压缩为半个月左右。

        个性化类数据应用在医疗中表现的尤其明显,传统BI解决模式耗时耗力且很多场景无法满足,不仅客户体验度差、也大大拖延了项目交付周期及价值。突围需要满足两个条件:专业的平台、资深行业研发。将整个数据的梳理周期压缩到1个月,且数据准确、业务流程清晰。

   (二)版本介绍

         基于行业实际,医院数据平台研发历经三次版本迭代,做到行业标杆。实现了区域70多家社康需求的今日提明日用的高效服务、实现了专科经营业务的低成本高价值落地。

         版本一)基于springbatch+sqlserver的流式批处理,采用阿里数据中台思维,做为第一次探索,在维度处理、数据清洗等方面考虑过多导致数据处理效率不理想,但标准化查询、缓存的使用性探索还是让平台的价值得到了客户充分的肯定。它基于事实维度策略及标准化查询,封装了统一的数据出入标准,替代了传统BI工具,彻底解决了个性化交付的周期与成本,为标准产品设定了接口规范。数据提取方案已做开源,可参考学习讨论,地址:https://gitee.com/liujl1990/etl-platform

         版本二)为解决数据效率问题,基于区域数据实践,技术方案采用datax+doris及内部stream-load数据流转方案。实现了数据提取效率秒化、数据查询效率提升5倍有余。细化ods层、dw层标准接口封装,结合doris的分布式特性、物化特性,大大提升了响应效率,解决了区域数据统计需求。数据提取方案已做开源,可参考学习讨论,地址:https://gitee.com/liujl1990/data-platform-2.0

         版本三) 随着AI的发展及对产品应用场景的深度了解,为了融合AI特性,第三版方案采用了seatunnel-mcp,借助AI特性实现了工具的独立、数仓查询的独立、现场个性化展现的三重独立。不单单是应用于医疗,工具与数仓查询可作为标准,适配任何行业的个性化展现。系统内测中暂未开源。

总结

          通过现象看本质医疗业务系统也好,数据系统也罢。客户需求点主要表现为响应速度、业务完整度。

         整体要素体现为:

         1)标准产品设计上勿好高骛远,一步步深化。 

         2)角色选用上需要一名业务扎实的行业架构师,能充分吸收互联网思维并屏蔽其给行业带来的冲击。

         3)一生、二熟、三成功的宝典。产品的成败在代码,代码的成败在研发,研发架构师在对某个细分领域及产品完全融汇贯通前需要经历几次版本的迭代,才能做出行业的标杆产品,切勿追求一次形成。

       医疗公司普遍表现为重产品、轻研发,表现出来的是思想的巨人行动的矮子。当一个公司表现为各类角色都能指点研发必须怎么干,无视研发忠告的时候,研发开始默默干活不在发表观点时,一堆堆坑就开始残留了。

         

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

JAVA老刘

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值