医疗类APP中，挂号功能的实现方式探讨
做「互联网+」相关的产品，与之前做纯互联网产品很不一样，因为除了必须了解互联网之外，还必须去比较深入的了解所关注的传统行业，去了解他们的行业中，用户的需求、技术的动向，以及遇到的困难。传统行业本身有深有浅，有的专业性强，有的专业性弱；有的门槛高，有的门槛低；有的相对开放，有的很封闭。而医疗这个行业，偏偏是专业性极强并且相对封闭的行业。
我为此做了大量的调研，结合国内的现状，互联网公司的特点，以及部门的实际情况，（在现阶段）得出的结论如下： 不要去碰特别深入医学专业的领域（比如互联网医院？） 关注宏观政策，但最好别去做政策直接倡导的事情（比如三明医改？） 暂时不要改变医生和患者固有的习惯，暂时不要挑战已经形成的偏见（比如分级诊疗？）
互联网公司，对于「互联网+」，在现阶段，可以以做连接、提升现有行业的运转效率为切入（比如滴滴，做的是车主和乘客之间的连接，不是买了一堆车出去跟公共交通抢生意；更不是试图让乘客坐火箭出行。）
所以，排除了各种我认为不靠谱的方向之后，我把主要的研究方向放在了对现有就医流程的优化上面。那段时间，与深圳一些医院的医生、护士，以及信息科的同事交流过多次，详细梳理了病人在就诊过程中遇到的问题，审视这些问题，结合部门的实际情况，我决定从流程的第一步，也即挂号做起。
提起挂号，看起来实在已经是一片红海了，现在做挂号的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这个医院，没办法，只能去线下排队了。也即：无法最大限度覆盖资源。
其次，不同app对医院的议价能力也不一样。有可能对于同一个医院C，app1拿到了10个号源，app2拿到了50个号源。这样，可能app1上已经没有号了，app2上却还有剩余。如果我每次挂号，需要把所有app打开一遍，实在是太辛苦了。也即：无法最大限度利用资源
第三，对于当时我所在的团队来说，在挂号这个领域起步是非常晚的。如果我们像竞品一样，派商务同学一家一家医院去谈，不但费时费力，而且可能错过「挂号」这个服务的最佳窗口期。
三、回归本源：用户最底层的「体验」究竟是什么？
我们每天都在谈「用户体验」，对于一个挂号平台来说，【最基础】的用户体验是什么？并不是它拥有多么强大的功能，并不是它的UI特别流畅又漂亮，而是它能够「最大可能的帮用户挂到号」。
基于以上，我希望从最基础的体验做起，不去跟竞品拼功能。基于这个思路，挂号平台（分发模式）诞生了。
拿一个大家熟悉的产品做类比吧。很多同学喜欢使用类似「去哪儿网」之类搜索机票，去哪儿自身并不产生机票，它其实是一个机票搜索引擎，它的背后连接了各大航空公司，各种代理商的资源。所以，搜索两个城市间的机票资源，在去哪儿上得到的结果，一定比在任何一家航空公司的官方网站上更丰富。
同样的道理，我们暂时不去拓展医院，而是搭建一个平台，与有号源的其他平台合作，拿到他们的接口，这就相当于把他们的号源资源接入了我们的「联合号源池」，这样理论上可以最大限度帮助用户实现「挂到号」的基础需求。
这个设想很有趣，但是，作为一个「互联网+」的产品经理，只把这个逻辑走通还不够，同时需要思考的是一个很现实的问题：那些有号源的平台，凭什么把接口给你？「互联网+」相关的产品，除了产品策略，还必须同步思考由产品策略延展出的商业策略，同时，根据商业策略，同步调整产品策略。
现在面临的问题是：如果只做一个简单的搜索，像百度一样，然后用户跳转到合作方的页面上完成挂号，这样很难保证线上的体验（有一些地方是跟ZF平台合作，您知道，一般都不怎么样），对于我们来说也是一个不划算的生意（号源可没办法做竞价排名变现啊）；如果要求合作方对接我们的后台，那凭什么呢？我们可以给他们什么好处？号源这种资源，是没办法直接变现的（不像机票，卖出去就可以获得分成）。我们所熟悉的可以挂号的app，包括就医160、微医、百度医生等等，挂号部分很多都是为其他服务导流用的。如果仅后台跟合作方对接，相当于合作方仅有的用户和流量被截取了，商务层面将很难推进。
四、我们要如何做？
经过反复纠结与谈判，我采用了一种折中的方式。
具体是这样的：首先，我们的平台内嵌在微信城市服务中，可以调用微信的一些基础能力。用户挂号的主操作流程依然留着我们的平台上，用户选好医院、科室、日期、医生等（这些步骤看起来，跟一般的挂号平台没什么区别）。然后我们去请求所有合作方，将号源情况展现给用户，并且会给予合作方品牌曝光。
