医疗类APP中,挂号功能的实现方式探讨
大约半年前,我被抽调到一个新成立的部门,开始研究「互联网+」这个热门概念下,互联网与传统行业相结合所产生的各种可能性。我手里的项目,主要在关注医疗这个方向。
做「互联网+」相关的产品,与之前做纯互联网产品很不一样,因为除了必须了解互联网之外,还必须去比较深入的了解所关注的传统行业,去了解他们的行业中,用户的需求、技术的动向,以及遇到的困难。传统行业本身有深有浅,有的专业性强,有的专业性弱;有的门槛高,有的门槛低;有的相对开放,有的很封闭。而医疗这个行业,偏偏是专业性极强并且相对封闭的行业。 我为此做了大量的调研,结合国内的现状,互联网公司的特点,以及部门的实际情况,(在现阶段)得出的结论如下: 所以,排除了各种我认为不靠谱的方向之后,我把主要的研究方向放在了对现有就医流程的优化上面。那段时间,与深圳一些医院的医生、护士,以及信息科的同事交流过多次,详细梳理了病人在就诊过程中遇到的问题,审视这些问题,结合部门的实际情况,我决定从流程的第一步,也即挂号做起。 提起挂号,看起来实在已经是一片红海了,现在做挂号的app好像比做直播的还多,并且很多都已经很成熟了,比如我们常用的就医160、微医等。现在起步做这个,有戏吗?我当时也面临这个问题的挑战,但是仔细研究市场之后,发现还是可以做的。那么首先,容我先简单介绍一下目前的医疗相关app中,挂号这个功能的实现方式。 目前,市面上可以提供挂号服务的app,主要的业务实现方式有两种: 第一种,叫做「直连方式」。顾名思义,就是医院提供相应的数据接口,平台与医院直接连接。当有用户需要挂号的时候,平台向医院直接请求号源,医院有,就会帮他完成挂号。 这个业务模型很简单,也是理论上最靠谱的方式,但是它有一个致命的弱点,就是:需要医院提供数据接口!医院并不是专业的IT或者互联网公司,他们的开发、运维能力非常有限,即便可以通过外包的形式实现功能,但是,号源这东西往往很敏感,外包公司做的软件,安全性、稳定性等等,都让人不放心(并且很多医院也并没有付费开发的动力)。其实,医院使用的HIS(注1)系统厂商也可以开发这些接口,但是它们动不动一套接口报价是几百万,即便存在一些有心做这些的医院,也很崩溃。虽然从商业模式层面,挂号平台也可能找到各自各样愿意出这笔钱的机构或者公司来做成这件事情,但实际情况是,在市面上您见过的可以挂号的app里面,只有少部分的医院是采用这种方式进行挂号的。 第二种,叫做「号源池方式」。既然直连方式在当前的条件下难以走通,所以很多医院和挂号平台就想出了一个更加简单的方式,就是,医院把一部分号源的「使用权」分配给平台,平台相当于只需要在这部分号源范围内收集用户的挂号需求,然后定期同步给医院即可。这里面的「定期同步」,您别想得太高级,有的医院技术能力比较差,可能是采取平台每天给医院发一封邮件,里面附带一个Excel文档,医院专门找一个护士,手工录入的方式实现的… 您看看,为了能让您挂到号,大家多不容易啊~ 由于「号源池方式」几乎没有成本、安全、无政治风险,所以事实上,我们用的大部分挂号平台都是采取这种方式与医院交互信息的。基于此,您可能已经想到,您遇到过下述这些问题,其实是来源于这个模式的: 首先,不同的app其商务拓展能力不一样。可能出现这样的情况:app1拿到了该城市A,B,C,D四家医院的号源;app2拿到了C,D,E,F四家医院的号源。这时候就有一个问题,如果您用app1,就会发现,不能挂E医院的号源;如果用app2,则不支持A医院挂号。另外,作为一个app1的用户,您可能根本不知道有app2存在,这时,如果发现没有E这个医院,没办法,只能去线下排队了。也即:无法最大限度覆盖资源。 如上图:左侧app可以支持深圳的多家医院,而右侧的app只支持4家。 其次,不同app对医院的议价能力也不一样。有可能对于同一个医院C,app1拿到了10个号源,app2拿到了50个号源。这样,可能app1上已经没有号了,app2上却还有剩余。如果我每次挂号,需要把所有app打开一遍,实在是太辛苦了。也即:无法最大限度利用资源 如上图:左右两侧是不同app在同一个医院同一个科室的号源情况(它们UI长得有点儿像,但确实是不同的app…)。但是「张斯为」医生和「龙丰」医生在左侧均显示「约满」,而右侧则显示绿色的可以预约。 第三,对于当时我所在的团队来说,在挂号这个领域起步是非常晚的。如果我们像竞品一样,派商务同学一家一家医院去谈,不但费时费力,而且可能错过「挂号」这个服务的最佳窗口期。 我们每天都在谈「用户体验」,对于一个挂号平台来说,【最基础】的用户体验是什么?并不是它拥有多么强大的功能,并不是它的UI特别流畅又漂亮,而是它能够「最大可能的帮用户挂到号」。 基于以上,我希望从最基础的体验做起,不去跟竞品拼功能。基于这个思路,挂号平台(分发模式)诞生了。 拿一个大家熟悉的产品做类比吧。很多同学喜欢使用类似「去哪儿网」之类搜索机票,去哪儿自身并不产生机票,它其实是一个机票搜索引擎,它的背后连接了各大航空公司,各种代理商的资源。所以,搜索两个城市间的机票资源,在去哪儿上得到的结果,一定比在任何一家航空公司的官方网站上更丰富。 同样的道理,我们暂时不去拓展医院,而是搭建一个平台,与有号源的其他平台合作,拿到他们的接口,这就相当于把他们的号源资源接入了我们的「联合号源池」,这样理论上可以最大限度帮助用户实现「挂到号」的基础需求。 这个设想很有趣,但是,作为一个「互联网+」的产品经理,只把这个逻辑走通还不够,同时需要思考的是一个很现实的问题:那些有号源的平台,凭什么把接口给你?「互联网+」相关的产品,除了产品策略,还必须同步思考由产品策略延展出的商业策略,同时,根据商业策略,同步调整产品策略。 现在面临的问题是:如果只做一个简单的搜索,像百度一样,然后用户跳转到合作方的页面上完成挂号,这样很难保证线上的体验(有一些地方是跟ZF平台合作,您知道,一般都不怎么样),对于我们来说也是一个不划算的生意(号源可没办法做竞价排名变现啊);如果要求合作方对接我们的后台,那凭什么呢?我们可以给他们什么好处?号源这种资源,是没办法直接变现的(不像机票,卖出去就可以获得分成)。我们所熟悉的可以挂号的app,包括就医160、微医、百度医生等等,挂号部分很多都是为其他服务导流用的。如果仅后台跟合作方对接,相当于合作方仅有的用户和流量被截取了,商务层面将很难推进。 经过反复纠结与谈判,我采用了一种折中的方式。 具体是这样的:首先,我们的平台内嵌在微信城市服务中,可以调用微信的一些基础能力。用户挂号的主操作流程依然留着我们的平台上,用户选好医院、科室、日期、医生等(这些步骤看起来,跟一般的挂号平台没什么区别)。然后我们去请求所有合作方,将号源情况展现给用户,并且会给予合作方品牌曝光: 用户选择某个合作方,点按其后方的「挂号」按钮,会跳转到该合作方的页面上: 在合作方页面,用户只做两件事: 而当用户完成挂号后,流程则交给合作方公众号,便于后续的通知、提醒等场景。 如此,从产品、技术、商务三方面构建了一个基础的可能性,即:将多个合作方的号源池拼合在一起,构建了理论上更大的号源池,优化了用户挂号的最底层体验(最大限度挂到号)。 哦,对了,挂号平台虽然是用网页形式承载,但是由于使用了https,所以,可以最大限度防止各种运营商的流量劫持(注2)哦~ 跟这种讨厌的球说再见吧~ 五、未来,我们将拥有一个怎样的就医体验? 挂号只是用户诊疗流程中的第一步。事实上,患者在医院看病的过程,依然是一个水深火热的过程。本文一开始提到,我与医院的同学们梳理了病人在就诊过程中遇到的问题,那么,挂号之后,很长很长的未来,我们还有可能做什么呢?下面,用一个虚拟的故事来跟大家畅(Y)想(Y)一下吧(其实下面您将看到的故事里面的很多步骤在一些医院的公众号里面都已经实现了,只是还不成体系)。 王小明2天前觉得胃有点儿不舒服,当时他以为喝一点儿热水就好了。可是到了今天晚上,症状依然没有消失。于是他打开挂号平台,预约了南山医院消化内科明天下午3点的医生。此时,他收到了预约成功的消息通知。 第二天上午,王小明开了一上午的会。下午2点,他收到了一条消息通知,提醒他下午3点预约了医生: 于是王小明花了20分钟交接好工作,请假前往医院。他于2点50分到达医院门诊部,上3楼找到了「消化内科」,发现分诊台上方大屏幕上已经显示了当前的排队情况,他位于第3位。他点按手机上的排队提醒信息,进入排队列表,发现手机上显示的位置与分诊台大屏幕是一致的: 王小明决定先去个厕所,当他刚方便完,跨出厕所门的时候,发现手机提示有新消息,原来是轮到他就诊了: 王小明去往5诊室,见到了医生,简单描述了一下病情。医生做了一些基础检查,告知王小明:「你的情况建议做一下胃镜,这样可以更加精准的确诊。如果胃镜结果没问题,那就是普通的胃炎;如果有问题,可能还要继续做其他检查。」于是按照医生的建议,王小明准备接受胃镜检查。医生在电脑上开完单,王小明的手机上又收到消息: 王小明离开诊室,来到一楼收费处,看到排队的人群是这样的: 疯了!这样的队伍,先去一楼收费处排一次缴费;然后去住院处2楼,检验科门口再排一次预约。这没半个小时都搞不定啊。并且这种检查一般约不上当天的。于是王小明拿出手机,点按那条检查信息,进入网上缴费及预约页面: 使用社保缴费(在深圳已经实现,也即,你可以使用微信支付操作社保卡里面的钱),看一遍注意事项,预约了明天早晨8点的胃镜检查,前后不超过1分钟。王小明又看了一眼排长队的人群,转身离开了医院。 第二天,王小明按时前往医院,做了检查。第三天上午,他的手机收到提醒,原来检查报告出来了: 王小明点进去看了一下,有一些数据项看不懂,但是貌似意思是,除了有点儿溃疡之外,没有大的问题。王小明把手机放在一边,想着一会再重新挂个号,去让医生给开点儿药。到了中午,王小明拿起手机,发现有一条未读的消息,打开一看: 原来是他的医生已经查看过胃镜报告,并已经帮他开好药。王小明点按这条信息,出现了更加详细的医嘱、药品清单及取药选项页面(话说,病例那里,我实在编不好;药和剂量也是编的,您就将就着看一下哈~): 王小明支付了药费,发现除了亲自前往医院药房取药,还可以使用其他途径: 于是他选择在公司附近的一家社康取药,下班路上,顺便就把药拿到手了。 (YY到此结束) 对了,如果有任何朋友对于「优化现有就医流程」这件事儿有兴趣,不妨我们交流一下。我的微信是 liuhanyusz,加好友请注明:公司、职位 (注1)HIS系统:HIS即「Hospital Information System」,我们简单将其理解为,医院里面医生、护士等工作人员电脑上用的软件的统称。 (注2)流量劫持:具体解释清自行搜索。如果遇到流量劫持,可以打电话给运营商客服投诉。台词这么说:「(先描述情况),你们这种行为干扰了我的正常通讯,是违法违约行为。请你们1小时内给我关闭,否则我将向工信部投诉。」亲测有效~ 只是可能过一会会有所谓「客服经理」打电话过来装傻问想「取消」哪个「业务」,告诉他即可。 【微信】访问下述URL:http://t.cn/RtxAzBK (二维码自动识别) 看到「挂号平台-分发模式」,点「投票」即可。长这样: 刘涵宇,xidea,微信公众号:uxcafe。人人都是产品经理专栏作家。腾讯产品经理,老友记(人人公司离职员工聚会exrr.org)发起人,曾辗转于哈尔滨、北京、深圳3个城市学习、工作和生活。关注互联网产品、用户体验,以及各种行业八卦。 最近正在关注互联网与传统行业结合的各种可能性。 本文原创发布于人人都是产品经理。未经许可,禁止转载。
一、前置研究:市面上的app是如何实现「挂号」功能的?
二、竞品分析:它们和我们各自面临什么问题?
三、回归本源:用户最底层的「体验」究竟是什么?
四、我们要如何做?
挂号平台(分发模式)正在申请腾讯微创新奖,如果您觉得以上内容还是有点儿用的话,欢迎抽空为我们投个票(投票截止到8月7日)。具体:#专栏作家#
现在是 2020年了,各个地方各个医院医疗机构,都不一样,仍然是这样挂号难、缴费难、现场排长队、手机挂号的方式对年长者不友好。。。等等问题
2020年也没进展
居然是三年前写的,厉害了
你好想咨询下,公众号通知使用了哪些模板,据我所知只有医疗行业资质的公众号才可以使用医疗相关的推送模板
好的内容跨越时间,从16到19都有人回复,真好。
我看现在城市服务里挂号是直接接的160的页面,为什么会取消掉之前的这套逻辑呢?这套挂号逻辑现在银联云闪付还在用
挂号可以通过平台号源池解决号源问题,用户为之付出的是挂号操作繁琐,体验不流畅,一旦医院有突发情况需要停诊,推送涉及多个环节。比如:医院告知号源商,号源商再告知平台商、平台商再通知用户。任何一个环节出现问题,病人都不会收到停诊通知,会造成病人在医院就诊时,显示该医生已停诊,白跑一趟的尴尬局面。后面的就诊中的环节是很好的设想,目前市面上很多医院都已经做到待缴费、已缴费通知、检验检查结果、处方信息查阅等功能。但要做到这些,跟医院的his系统、lis系统、pacs系统、病历系统等是分不开的。目前还无法像号源池的方式折中解决。虽然我们想不去涉及医院的系统,就能做到这些。但病人一旦进入医院后就诊,就已经被医院绑定,所有的数据、资料信息都在医院系统中,要想获取医院系统中的数据,就不可能不涉及到数据对接,这也回到跟医院系统做接口的层面,又回到医院没有能力做接口或者系统提供商漫天要价等。平台也受制于这些条条框框的限制,无法推进。这也是目前大家都会面对的共性问题。
然而事实上目前有两大问题,一.排队提醒与医院的电子显示屏无法同步,因为很多人网上预约没法按时到,医生叫号会很快空过这些没有准时到的,二.如果你不进行二次挂号找医生,医生是不可能给你开药的。
很实用!干货满满
写的真好,一看就是有实战经验的。有个问题想请教下,谈到微医openid绑定账号那里。
用户在微信中进入微医页面,微医获取用户openid,然后强制用户登录A账号,文中说”将该用户的微信OpenID与该用户在合作方的账号绑定”。我觉得这样逻辑走得通,openid仅起到判断登录哪个账号的作用。
a、一个openid仅关联最新登陆的账号;
b、一个账号可能关联多个openid,也没问题。
————————————————————————————————————————————
1、我们公司产品的账号体系跟你展示的微医登录页一样:创建用户,必须有唯一的手机号,且很多代码调用手机号字段。
在微信公众号中,用户反馈输入手机号+验证码这一步太烦,希望在微信环境下直接操作,他们认为“我的是登录了微信进入你的公众号内,已经登登录状态,怎么还让登录?”。我想请教下:如果仅获取openid,用户就可以预约、支付订单等操作,是否行得通?下面是我遇到的具体问题:
1.1、在openid下操作完之后,当用户登录A账号,把openid跟A账号绑定,openid下所有预约、订单需要和A账号合并(开发说合并预约、订单等等信息工作量很大),但是不合并,用户会懵逼,他登录完账号居然看不见已操作的订单了。。。。还有一个问题是:用户退出A账号登录B账号,此时,openid要不要解绑A,再跟B账号合并?
1.2、在openid下操作完之后,用户登录A账号后,A账号和openid1绑定,用户又在另外一个微信下登录A账号,A账号又和openid2绑定,这样一个账号,对应多个openid,需要合并多次数据。
你看有什么好办法吗?谢谢啦!
1.1的问题,账号合并的时候,可以搭建一层父级ID,单纯注册用户或微信登录的时候,父级ID都是空的,下单预约使用的也只是单纯的账户ID,当发生账户合并时,产生父级ID,和两个账户的账户ID父子级关联,在信息或订单查询的时候,逻辑调整为如果有父级ID就合并查询所有子级ID的信息出来即可。改动的地方不算太大
1.1.2的问题,如果用户操作退出账户,就要解绑原有的绑定关系
1.2的问题,更新绑定关系即可
YY部分模拟了最理想的情况,我们还需要考虑到占大多数的糟心情景:
1.预约成功后第二天的会改在下午三点开,小明在收到预约提醒的同时收到了公司会议通知。小明想把预约时间推迟两小时,发现没找到该功能。小明很有耐心,只好取消预约,重新预约第三天。
2.第三天还是预约了下午三点,他于2点20分在去往医院的高价桥上,由于前面200位病人都是线上预约,都因为公司开会随手取消了,医生提前诊疗完毕,护士喊了半个小时王小明。。。王小明也在五环高架桥上收到2百多条叫号的通知。。。
3.王小明顶住沉重的心理压力不去理会通知,心想老子约的三点,老子到点去就没错。终于王小明在2点59分到达了医院,推门进了诊室发现医生也不傻没有一心一意等他而是直接诊治后面病人。小明表示理解,毕竟不是他私人医生,小明好说歹说医生同意下一个就排到他。于是小明在走廊开始等待,在自己的王者荣耀排位从青铜打到铂金后小明坐不住了,推开诊室门看到他前一位的老头还处于描述病情阶段。与此同时后一位在线预约的患者王金刚到了,并与小明发生肢体冲突。
时间紧,后面流程下次继续探讨。整体流转思路非常好!
我是个产品新人,也做医疗方面,针对这个问题,我有个想法,不知道对不对,想跟您讨论一下:网上的挂号可以定义为预约挂号,只有到了医院取了号以后,才视为到诊,这个时候才会对患者进行看诊的排序,这样是不是可以解决你说的问题呢?
我说说我的看法:这个流程中的核心目的是为了极大缩减用户在医院的等待时间,但是您这个方案,并没有解决这个问题哦。
那么要思考预约时是否选择时间呢,如果不选则时间和挂号的医生那么和去医院再取号排队还有什么区别呢?如果选择时间医生就会出现上述问题。这些小点还好说,毕竟都是人,尤其是消费者用户生病就诊人之常情本就劣势,加上长久的线下恶劣就医体验早就驯化好了,难的在于整体流程把控甚至协调固有利益体系,体检、药品尤甚,医生可以医德医风很高但医院不会医院是个机构要见效益(有形无形都算)。例如问诊,医院医生平台各方如何分成?名医专家整天忙得团团转要不是利益(甚至不是钱)关系会给你耐心线上回复?甚至给你回复的真的是医生吗?出问题责任算哪方?药品更是如此,处方药线下没有处方就真的买不到了?医生不准乱开药就真的不从中获利了?一家医院旁边开着的那堆药房就和医院没半点关系了? 前期做产品很容易理想化,围着搞好用户体验提好供核心服务转,遗憾的是这些很重要但不是全部。。。还望全盘思考不畏浮云遮眼。
刚毅!!!
终于碰到一个没有泛泛而谈的大神了,有干货,力挺
整个模式确实是一个比较理想化的流程,而且我之前也在移动医疗的一个公司做过,从我那段经历认为网上预约挂号其实是个伪需求(目前而言,因为大部分挂号用的是第二种模式),患者网上挂号并不是因为方便,而且是因为网上有号源。移动医疗还有很长的路要走。
不对,个人认为网上预约挂号还是蛮方便的,因为像我这种常年不去医院,不了解医院流程的人大有人在,我原来是那种一进医院先挂号还是直接去找医生都傻傻分不清的人,所以每次去医院基本就是蒙圈状态,还很浪费时间。现在通过朋友知道了预约挂号,所以每次先挂号,到医院之后根据短信提示去取号,即使碰上忙的时候,医院里自助取票口排队的人也是蛮少的。取完票就等着叫号就好了~真的,用户流程体验太重要了,有了短信提醒,就像去电影院里取票一样很方便呐~不过目前还没有发现哪个平台可以直接通过手机查看报告单、取药这些的,还是希望能早日实现up主说的功能呢!
医院自己的公众号可以,我知道的广东省中医院的就可以
好棒!感谢分享
也在做互联网+医疗方向,之前也遇到预约挂号问题。这次深入学习了!
厉害,大神!
感觉Y的很完整,很像样子!
我想这一天也许并不远。
非常不错的实战派文章。讲述整个产品的设计逻辑和故事。