互联网预约挂号从零散分割的状态逐渐迭代成规模化和标准化，是医院医疗信息化和智慧化的标杆应用。互联网预约挂号的出现，很好的解决了医院就医压力的问题。那么，互联网预约挂号涵盖了什么业务呢？

疫情加强了民众的健康意识，更加验证了互联网医疗的实用性。

在疫情影响下，互联网医疗，俨然成为现代人生活的一部分，目前为止互联网医疗服务预约挂号应用用户渗透率排行第一。

目前我国互联网医疗的用户规模已达到4.12亿人，渗透率为52.7%。通过对部分用户在互联网+医疗产品中各功能的使用率调查发现，目前用户使用率最高的仍是网上预约挂号。

其次是网上交流平台，咨询问诊、医疗信息的查询能让用户清楚自己的健康问题，提前预防或合理的慢性疾病管理。

互联网预约挂号从零散分割的状态逐渐迭代成规模化和标准化，是医院医疗信息化和智慧化的标杆应用。

背景

互联网预约挂号的出现，很好的解决了医院就医压力的问题。

那么，互联网预约挂号涵盖了什么业务呢？

互联网预约挂号服务是指运用互联网和移动互联网技术，由医院/第三方服务机构向患者提供的挂号、手术、住院、专家团队和合作机构的预约服务。

同时，在预约挂号的同时，提供医院的健康宣教、医院品牌宣传、医生查询、医院特色科室和专家擅长领域等介绍信息。

• 从政策角度分析，互联网预约挂号可以保证公立医院的公益性，减少恶意减号、加号、插号等问题。还有整合全社会医疗资料并合理配置。
• 从医院角度来说，可以合理化、规划医院医疗资源。有效地规范就医秩序以及环境。
• 从患者角度出发，利用互联网预约挂号可以避免在医院排队浪费的时间和不必要的麻烦，并且普惠的医疗服务价格透明是患者看病重视的关键点。

通过医生介绍还有一些服务评价，患者可以得到对症专家/医生的诊疗服务，从而获得良好的就医服务体验。

从医生角度来看，可以提高个人IP知名度的同时，收入提升。但中国的大部分成功的互联网医疗企业，都是紧跟着政策需求去赚了第一桶金，才开展其他衍生业务的。

所以，互联网预约挂号同样也是政策需求的产物。

业务模式

关于互联网预约挂号业务模式类型，大体可以分为几类：垂直类互联网挂号平台、医院自建互联网挂号平台、地域性互联网预约挂号平台。

垂直类互联网挂号平台主要是以提供预约挂号，并包含电话咨询、绿色就医通道等多种服务的第三方移动医疗服务商。

其典型的服务商代表有：微医、就医160、好大夫在线、趣医院等。

医院自建互联网挂号平台是指由具备资金、人员、技术投入和医疗资源整合优势的医院自主建立的为患者提供包括预约挂号、等服务的互联网平台。

其典型的服务商代表有：远大心胸医院、掌上浙一等。

地域性互联网挂号平台是指由省级/市级卫生和计划生育委员会或移动通信公司主办，提供与医院挂号平台的对接为某一特定地域范围患者提供便捷就医服务的地域性预约挂号平台。

其典型的服务商代表有：114挂号网、深圳预约挂号网等。

无论是哪一类预约挂号平台，主要业务是提供分诊导诊、预约挂号、医疗支付等服务，将医院的“挂号窗口外移”。

对于企业来说预约挂号服务是获取流量的渠道。而并非产生盈利的重点。

随着预约挂号服务逐步延伸至就医全流程，合理分配医疗资源。通过与患者的诊前沟通，合理匹配医患资源，承担部分分诊导诊职责。

服务逐步丰富、深入、扩充陪诊、候诊进度查询，诊间支付，手机查看检查报告、健康档案建立、诊后随访、院外康复等服务。

免费服务积累患者和医疗机构资源， 付费增值服务成互联网预约挂号服务商核心收入方式这些才是主要的盈利路径。

• 盈利路径一：是通过提升患者就医便利性，以获取用户资源后，通过陪诊、中医理疗、海外就医、护工护理等方式获得增值服务收入。
• 盈利路径二：提升医生管理患者的效率，以平台通过医生为患者提供电话/视频咨询等服务，获得增值服务收入。
• 盈利路径三：通过对接医院HIS系统的方式获得挂号资源，辅助医院提升医院运营效率和提升用户就医体验从而获得医院的认可，开始深度合作，为医院提供医院信息化等增值服务。
• 盈利路径四：通过用户流量的导入直接获得流量变现收入；通过与平台的广告/品牌推广合作，获得间接流量变现收入；通过与保险公司的合作，直接获得产品销售分成收入。

产品设计

互联网预约挂号，主要的挂号业务实现方式有几种：医院走API中台管理模式，院内集成平台HIE模式，对接通过直连平台模式、内联平台与外联平台交互模式。

一般的，互联网预约挂号流程是患者登录相关应用成功后，经过选择医院、选择专家/专科、选择预约时间，确认号源（挂号）预约信息，完成支付，即可完成预约挂号。

如果在选择银联支付或者必须银联支付，则会转到银联支付的界面要求输入银行账号信息。预约成功后会返回预约信息及验证码，患者凭注册登记的证件及取号密码，即可在规定时间到指定医院进行预约取号。

预约挂号的银联支付目前只支持在平台上由患者自己操作完成。挂号流程。

对于预约挂号的流程中需要做一些相关的条件约束，例如：黑名单查询、一个账号在同一天同一家只能挂两次号、不得同一科室在同一天内挂号两次、判断号源，判断预约日期，医生的已挂号数量和限制挂号数据比较。若超过或等于不能挂号。

其次就是退号的流程，患者预约挂号后，在规定的时间内，可以通过多种途径进行退号。

通过平台网进行退号的步骤是：患者登录平台网站后，选择预约挂号的记录，然后选择退号，确认后，即完成退号。如果患者预约挂号时已经支付挂号费，则系统将挂号费退回到患者原支付账户中。

如果患者在规定的时间内没有进行退号，又没有到医院取号，则构成违约。

那么，违约是如何判断的呢？

挂号未取号，如果患者预约挂号并且已经支付了费用，但是没有在规定的时间内退号，又没有到医院取号，则构成违约。系统会在预约当天指定的时间点（银联结账时间点之前）将费用返还到患者原支付账户上。

在退号流程中会有黑名单逻辑设计，在多次退票后列入黑名单。

对于黑名单的收录规则，每家医院可能不一致，医院采用相关的退号次数以及恶意退号来配置收录规则。

设计互联网预约挂号前端逻辑较弱一些，但是对于后台的设计则需要多花点心思。

医疗机构的管理：管理医院，科室，医生信息，排班信息添加，修改，删除。停诊记录维护，预约记录查询，打印。医院管理模块功能同平台管理模块。区别平台查询全区域所有医院。医院管理模块只能本院信息。

用户管理：管理用户预约，用户黑白名单，用户标签分组等。

号源管理：同步HIS排班信息、同步停诊信息。号源池系统后台记录爽约信息，设置爽约次数、爽约时间阈值进行黑名单处理。

预约挂号管理：在进行需要提供接口服务为号源池系统的URL。患者信息ID、医院信息、号源信息等，医院根据信息返回预约挂号单号。并且社保系统提供社保备案接口，号源池系统调用该接口将患者信息传输至新农合或社保系统进行预约挂号备案。

预约挂号也是一种方便患者提前安排就医计划，减小候诊时间，便于医院提升管理水平，提高工作效率和医疗质量，降低医疗安全风险的门诊挂号方式。但是预约患者不可能做到100%应诊，目前国内报道的爽约率10%以上，甚至达50%，国外报道的爽约率为3&~34%。患者会因为各种主客观原因而爽约，造成医疗资源的极大浪费。因此研究这些浪费医疗资源的人特征，对医疗资源的合理分配有重要的意义。

那么，关于后台需要建立对用户的数据清洗、数据分析、用户画像分层。

如：中老年患者如约就诊的人数最多,65岁以后的老年患者如约就诊的可能性最高，青少年患者如约就诊的可能性较低。我们可以通过数据的分析避免医疗资源的浪费。

还有一种情况，也需要我们注意的是通过此次疫情，预约挂号网的并发量突然猛增。

涉及抢号时，为了避免超卖,那么号源数量是有限的，但是如果同时下单人数超过了库存数量，就会导致号源超卖问题。那么我们怎么来解决这个问题呢，思路如下：

这里可使用消息队列，我们常用到Memcacheq、Radis。比如：一个好的医生一天接诊量有100号源可供用户购买，那么就可以把这100个号源放到缓存中，读写时不要加锁。当并发量大的时候，可能有300人在抢这100个号源，这样对于300后面的请求可以直接转到号源购买结束的静态页面。进去的300个人中有200个人是不可能获得号源的。所以可以根据进入队列的先后顺序只能前100个人购买成功。后面400个人就直接转到号源为空页面。

而号源为空页面一定要用静态页面，不要用数据库。这样就减轻了数据库的压力。

还有一种解决方案，就是mysql悲观锁，意思是比如总库存是2，购买事件提交时，立马将库存+1，那么此时库存是3，然后订单生成后，在更新库存前再查询一次库存(因为订单生成理所当然库存-1，但是先不急，再查一次库存返回结果是3)，看看跟预期的库存数量(这里预期的库存是3)是否保持一致，不一致就回滚，提示用户库存不足。

悲观锁与乐观锁是两种常见的资源并发锁设计思路，也是并发编程中一个非常基础的概念。但可以非常巧妙的解决号源购买并发的问题。

未来发展趋势

从2009年到如今，互联网预约挂号网已经走过了十一年。

尽管中国有着万亿级的医疗市场，但却一直做预约挂号网的企业都扩展特别多的其他医疗业务。

不可否认互联网预约挂号已经走到了软件周期的衰退期，有外部环境的制约，但更多的因素还是在自身业务已经成为了医院的基础应用。

如今恰逢互联网医疗关口，做大做强的可能性更是被无限放大，技术加持，数据互通，信息共享。

顺应国家政策，基于预约挂号服务本质深度挖掘分诊服务，互联网预约挂号也终将迎来新的未来。

#专栏作家#

Rolia，微信公众号：pmsummit，人人都是产品经理专栏作家。前海康博士联合创始人兼产品总监，涉及智慧医疗领域需求产品化5年，致力于智慧医疗领域产品体验设计以及新商业模式研究。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Pexels，基于CC0协议。