咨询:13529513104
    

        大约半年前,我被抽调到一个新成立的部门,开始研究「互联网+」这个热门概念下,互联网与传统行业相结合所产生的各种可能性。我手里的项目,主要在关注医疗这个方向。     

    yiliaoguahaogonnn

    做「互联网+」相关的产品,与之前做纯互联网产品很不一样,因为除了必须了解互联网之外,还必须去比较深入的了解所关注的传统行业,去了解他们的行业中,用户的需求、技术的动向,以及遇到的困难。传统行业本身有深有浅,有的专业性强,有的专业性弱;有的门槛高,有的门槛低;有的相对开放,有的很封闭。而医疗这个行业,偏偏是专业性极强并且相对封闭的行业。

    我为此做了大量的调研,结合国内的现状,互联网公司的特点,以及部门的实际情况,(在现阶段)得出的结论如下:

  •     
  •         

                不要去碰特别深入医学专业的领域(比如互联网医院?)         

        
    
  •         

                关注宏观政策,但最好别去做政策直接倡导的事情(比如三明医改?)         

        
    
  •         

                暂时不要改变医生和患者固有的习惯,暂时不要挑战已经形成的偏见(比如分级诊疗?)         

        
    
  •         

                互联网公司,对于「互联网+」,在现阶段,可以以做连接、提升现有行业的运转效率为切入(比如滴滴,做的是车主和乘客之间的连接,不是买了一堆车出去跟公共交通抢生意;更不是试图让乘客坐火箭出行。)         

        

    所以,排除了各种我认为不靠谱的方向之后,我把主要的研究方向放在了对现有就医流程的优化上面。那段时间,与深圳一些医院的医生、护士,以及信息科的同事交流过多次,详细梳理了病人在就诊过程中遇到的问题,审视这些问题,结合部门的实际情况,我决定从流程的第一步,也即挂号做起。

    提起挂号,看起来实在已经是一片红海了,现在做挂号的app好像比做直播的还多,并且很多都已经很成熟了,比如我们常用的就医160、微医等。现在起步做这个,有戏吗?我当时也面临这个问题的挑战,但是仔细研究市场之后,发现还是可以做的。那么首先,容我先简单介绍一下目前的医疗相关app中,挂号这个功能的实现方式。

    一、前置研究:市面上的app是如何实现「挂号」功能的?

    目前,市面上可以提供挂号服务的app,主要的业务实现方式有两种:

    直连方式

    第一种,叫做「直连方式」。顾名思义,就是医院提供相应的数据接口,平台与医院直接连接。当有用户需要挂号的时候,平台向医院直接请求号源,医院有,就会帮他完成挂号。

    这个业务模型很简单,也是理论上最靠谱的方式,但是它有一个致命的弱点,就是:需要医院提供数据接口!医院并不是专业的IT或者互联网公司,他们的开发、运维能力非常有限,即便可以通过外包的形式实现功能,但是,号源这东西往往很敏感,外包公司做的软件,安全性、稳定性等等,都让人不放心(并且很多医院也并没有付费开发的动力)。其实,医院使用的HIS(注1)系统厂商也可以开发这些接口,但是它们动不动一套接口报价是几百万,即便存在一些有心做这些的医院,也很崩溃。虽然从商业模式层面,挂号平台也可能找到各自各样愿意出这笔钱的机构或者公司来做成这件事情,但实际情况是,在市面上您见过的可以挂号的app里面,只有少部分的医院是采用这种方式进行挂号的。

    号源池方式

    第二种,叫做「号源池方式」。既然直连方式在当前的条件下难以走通,所以很多医院和挂号平台就想出了一个更加简单的方式,就是,医院把一部分号源的「使用权」分配给平台,平台相当于只需要在这部分号源范围内收集用户的挂号需求,然后定期同步给医院即可。这里面的「定期同步」,您别想得太高级,有的医院技术能力比较差,可能是采取平台每天给医院发一封邮件,里面附带一个Excel文档,医院专门找一个护士,手工录入的方式实现的... 您看看,为了能让您挂到号,大家多不容易啊~

    由于「号源池方式」几乎没有成本、安全、无政治风险,所以事实上,我们用的大部分挂号平台都是采取这种方式与医院交互信息的。基于此,您可能已经想到,您遇到过下述这些问题,其实是来源于这个模式的:

  •     
  •         

                为什么大多数挂号app都不能挂当天的号?(因为来不及同步...)         

        
    
  •         

                为什么有些医院的公众号可以挂当天的号?(人家跟自己的系统交互,不需要「同步」...)         

        
    
  •         

                为什么对于很多医院来说,我在app上成功挂号后,还需要再排队走一遍「取号」流程?为什么不能凭短信看病呢?(因为您在app上的行为只是「预约」,相当于占了一个坑而已,这个预约信息并不一定直接到了医院HIS系统中,很有可能还留在上文提到的Excel文档之类的地方呢。您必须拿着「凭证」去领取「用坑券」,人家可能是重新录入一遍,才真正进系统,完成了挂号)         

        

    二、竞品分析:它们和我们各自面临什么问题?

    首先,不同的app其商务拓展能力不一样。可能出现这样的情况:app1拿到了该城市A,B,C,D四家医院的号源;app2拿到了C,D,E,F四家医院的号源。这时候就有一个问题,如果您用app1,就会发现,不能挂E医院的号源;如果用app2,则不支持A医院挂号。另外,作为一个app1的用户,您可能根本不知道有app2存在,这时,如果发现没有E这个医院,没办法,只能去线下排队了。也即:无法最大限度覆盖资源。

    01

    如上图:左侧app可以支持深圳的多家医院,而右侧的app只支持4家。

    其次,不同app对医院的议价能力也不一样。有可能对于同一个医院C,app1拿到了10个号源,app2拿到了50个号源。这样,可能app1上已经没有号了,app2上却还有剩余。如果我每次挂号,需要把所有app打开一遍,实在是太辛苦了。也即:无法最大限度利用资源

    02

    如上图:左右两侧是不同app在同一个医院同一个科室的号源情况(它们UI长得有点儿像,但确实是不同的app...)。但是「张斯为」医生和「龙丰」医生在左侧均显示「约满」,而右侧则显示绿色的可以预约。

    第三,对于当时我所在的团队来说,在挂号这个领域起步是非常晚的。如果我们像竞品一样,派商务同学一家一家医院去谈,不但费时费力,而且可能错过「挂号」这个服务的最佳窗口期。

    三、回归本源:用户最底层的「体验」究竟是什么?

    我们每天都在谈「用户体验」,对于一个挂号平台来说,【最基础】的用户体验是什么?并不是它拥有多么强大的功能,并不是它的UI特别流畅又漂亮,而是它能够「最大可能的帮用户挂到号」。

    基于以上,我希望从最基础的体验做起,不去跟竞品拼功能。基于这个思路,挂号平台(分发模式)诞生了。

    拿一个大家熟悉的产品做类比吧。很多同学喜欢使用类似「去哪儿网」之类搜索机票,去哪儿自身并不产生机票,它其实是一个机票搜索引擎,它的背后连接了各大航空公司,各种代理商的资源。所以,搜索两个城市间的机票资源,在去哪儿上得到的结果,一定比在任何一家航空公司的官方网站上更丰富。

    同样的道理,我们暂时不去拓展医院,而是搭建一个平台,与有号源的其他平台合作,拿到他们的接口,这就相当于把他们的号源资源接入了我们的「联合号源池」,这样理论上可以最大限度帮助用户实现「挂到号」的基础需求。

    这个设想很有趣,但是,作为一个「互联网+」的产品经理,只把这个逻辑走通还不够,同时需要思考的是一个很现实的问题:那些有号源的平台,凭什么把接口给你?「互联网+」相关的产品,除了产品策略,还必须同步思考由产品策略延展出的商业策略,同时,根据商业策略,同步调整产品策略。

    现在面临的问题是:如果只做一个简单的搜索,像百度一样,然后用户跳转到合作方的页面上完成挂号,这样很难保证线上的体验(有一些地方是跟ZF平台合作,您知道,一般都不怎么样),对于我们来说也是一个不划算的生意(号源可没办法做竞价排名变现啊);如果要求合作方对接我们的后台,那凭什么呢?我们可以给他们什么好处?号源这种资源,是没办法直接变现的(不像机票,卖出去就可以获得分成)。我们所熟悉的可以挂号的app,包括就医160、微医、百度医生等等,挂号部分很多都是为其他服务导流用的。如果仅后台跟合作方对接,相当于合作方仅有的用户和流量被截取了,商务层面将很难推进。

    四、我们要如何做?

    经过反复纠结与谈判,我采用了一种折中的方式。

    腾讯架构

    具体是这样的:首先,我们的平台内嵌在微信城市服务中,可以调用微信的一些基础能力。用户挂号的主操作流程依然留着我们的平台上,用户选好医院、科室、日期、医生等(这些步骤看起来,跟一般的挂号平台没什么区别)。然后我们去请求所有合作方,将号源情况展现给用户,并且会给予合作方品牌曝光:

    03

    用户选择某个合作方,点按其后方的「挂号」按钮,会跳转到该合作方的页面上:

    04

    在合作方页面,用户只做两件事:

  1.     
  2.         

                注册/登录合作方的账号(仅一次)该操作只需一次,会要求合作方将该用户的微信OpenID与该用户在合作方的账号绑定,下次挂号,再次使用该合作方,不需要重复登录。并且会要求合作方针对腾讯的流程重新设计登录页面,以保证用户最快速完成挂号。例如上图左侧,是微医为我们设计的注册/登录页面。         

        
    
  •         

                确认挂号信息用户取得合作方登录态后,我们会将用户选择的所有信息(如医院、科室、医生、时间等)传给合作方(要求合作方必须开发接口接收,对于无意愿或者无能力或者接口不稳定的合作方,不予接入),合作方直接显示最后的确认页面,并补充就诊人信息(如果用户是登录了合作方的账号,则可以直接调取用户以往在合作方处留下的就诊人信息)。然后点按「提交」按钮,即可完成挂号。         

        

    而当用户完成挂号后,流程则交给合作方公众号,便于后续的通知、提醒等场景。

    05

    如此,从产品、技术、商务三方面构建了一个基础的可能性,即:将多个合作方的号源池拼合在一起,构建了理论上更大的号源池,优化了用户挂号的最底层体验(最大限度挂到号)。

    哦,对了,挂号平台虽然是用网页形式承载,但是由于使用了https,所以,可以最大限度防止各种运营商的流量劫持(注2)哦~ 跟这种讨厌的球说再见吧~

    06

    五、未来,我们将拥有一个怎样的就医体验?

    挂号只是用户诊疗流程中的第一步。事实上,患者在医院看病的过程,依然是一个水深火热的过程。本文一开始提到,我与医院的同学们梳理了病人在就诊过程中遇到的问题,那么,挂号之后,很长很长的未来,我们还有可能做什么呢?下面,用一个虚拟的故事来跟大家畅(Y)想(Y)一下吧(其实下面您将看到的故事里面的很多步骤在一些医院的公众号里面都已经实现了,只是还不成体系)。

    王小明2天前觉得胃有点儿不舒服,当时他以为喝一点儿热水就好了。可是到了今天晚上,症状依然没有消失。于是他打开挂号平台,预约了南山医院消化内科明天下午3点的医生。此时,他收到了预约成功的消息通知。

    08

    第二天上午,王小明开了一上午的会。下午2点,他收到了一条消息通知,提醒他下午3点预约了医生:

    09

    于是王小明花了20分钟交接好工作,请假前往医院。他于2点50分到达医院门诊部,上3楼找到了「消化内科」,发现分诊台上方大屏幕上已经显示了当前的排队情况,他位于第3位。他点按手机上的排队提醒信息,进入排队列表,发现手机上显示的位置与分诊台大屏幕是一致的:

    10

    王小明决定先去个厕所,当他刚方便完,跨出厕所门的时候,发现手机提示有新消息,原来是轮到他就诊了:

    11

    王小明去往5诊室,见到了医生,简单描述了一下病情。医生做了一些基础检查,告知王小明:「你的情况建议做一下胃镜,这样可以更加精准的确诊。如果胃镜结果没问题,那就是普通的胃炎;如果有问题,可能还要继续做其他检查。」于是按照医生的建议,王小明准备接受胃镜检查。医生在电脑上开完单,王小明的手机上又收到消息:

    12

    王小明离开诊室,来到一楼收费处,看到排队的人群是这样的:

    yiyuan排队

    疯了!这样的队伍,先去一楼收费处排一次缴费;然后去住院处2楼,检验科门口再排一次预约。这没半个小时都搞不定啊。并且这种检查一般约不上当天的。于是王小明拿出手机,点按那条检查信息,进入网上缴费及预约页面:

    13

    使用社保缴费(在深圳已经实现,也即,你可以使用微信支付操作社保卡里面的钱),看一遍注意事项,预约了明天早晨8点的胃镜检查,前后不超过1分钟。王小明又看了一眼排长队的人群,转身离开了医院。

    第二天,王小明按时前往医院,做了检查。第三天上午,他的手机收到提醒,原来检查报告出来了:

    14

    王小明点进去看了一下,有一些数据项看不懂,但是貌似意思是,除了有点儿溃疡之外,没有大的问题。王小明把手机放在一边,想着一会再重新挂个号,去让医生给开点儿药。到了中午,王小明拿起手机,发现有一条未读的消息,打开一看:

    15

    原来是他的医生已经查看过胃镜报告,并已经帮他开好药。王小明点按这条信息,出现了更加详细的医嘱、药品清单及取药选项页面(话说,病例那里,我实在编不好;药和剂量也是编的,您就将就着看一下哈~):

    16

    王小明支付了药费,发现除了亲自前往医院药房取药,还可以使用其他途径:

    17

    于是他选择在公司附近的一家社康取药,下班路上,顺便就把药拿到手了。

    (YY到此结束)

    对了,如果有任何朋友对于「优化现有就医流程」这件事儿有兴趣,不妨我们交流一下。我的微信是 liuhanyusz,加好友请注明:公司、职位

    (注1)HIS系统:HIS即「Hospital Information System」,我们简单将其理解为,医院里面医生、护士等工作人员电脑上用的软件的统称。

    (注2)流量劫持:具体解释清自行搜索。如果遇到流量劫持,可以打电话给运营商客服投诉。台词这么说:「(先描述情况),你们这种行为干扰了我的正常通讯,是违法违约行为。请你们1小时内给我关闭,否则我将向工信部投诉。」亲测有效~ 只是可能过一会会有所谓「客服经理」打电话过来装傻问想「取消」哪个「业务」,告诉他即可。
    挂号平台(分发模式)正在申请腾讯微创新奖,如果您觉得以上内容还是有点儿用的话,欢迎抽空为我们投个票(投票截止到8月7日)。具体:

    【微信】访问下述URL:

    t.cn/RtxAzBK (二维码自动识别)

    找到「挂号平台-分发模式」,点「投票」即可。长这样:

    20160803150602

    #专栏作家#

    刘涵宇,xidea,微信公众号:uxcafe。人人都是产品经理专栏作家。腾讯产品经理,老友记(人人公司离职员工聚会exrr.org)发起人,曾辗转于哈尔滨、北京、深圳3个城市学习、工作和生活。关注互联网产品、用户体验,以及各种行业八卦。 最近正在关注互联网与传统行业结合的各种可能性。

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

    

【责任编辑:(Top) 返回页面顶端