用真心对掌心:一周搞定一个微信企业号子应用手记

本文已授权HIT专家网,未经允许请勿转载。

三年前曾写过一篇《一周搞定一个微信公众号手记》,随后由于工作忙碌,并没有继续深入微信公众号的开发。去年有缘再次接触微信服务号和企业号,发现接口能力已经今非昔比,再用一周的时间从头开发一个服务号或者企业号,感觉是天方夜谭了。

微信企业号和服务号类似,最大的特点之一是每个企业号可以建立多个独立的子应用。自认为先前有大半年做企业号的积累,所以在「手术安排查询」上面,能够用较短的时间,去完成这个子应用。

Day 1 念起

手术安排是手术医生最为关心的内容之一,以往医护人员需要在医院内部的台式电脑上查询手术安排信息。有时临床工作忙碌,离开医院才想起需要查看明日手术安排,这个时候只能打电话给在医院的同事帮忙了。

因为医院正在上微信企业号,比起原生 App,跨平台、消息可触达这些特性使得把桌面应用迁移到员工手机上面的难度降低。微信企业号还可以建立多个独立子应用。 这个时候就想,是否可以开发一个方便手术科室查看手术安排的子应用?

Day 1-3 手术信息提取

在 HIS 系统已经有了手术电子申请,并且运转良好,无需在手机中重复该业务逻辑。手术医生每天早上在手术申请时,已经确定了该次手术的大部分信息:

  • 病人身份信息,包括病人姓名、性别、床号、住院号等
  • 手术方式信息,包括拟定的手术名称及编码,以及拟定的麻醉方式
  • 手术人员信息,包括主刀及助手姓名工号等
  • 特殊检查信息,包括肝炎等传染病检查结果
  • 特殊准备信息,包括与本次手术相关的需要准备的特殊器械、或者其他注意事项

手术室在当天下午安排明日手术时,也会确定相应的手术安排信息:

  • 手术间和台次
  • 麻醉方式、麻醉医生
  • 洗手、巡回护士

从 HIS 系统中提取这部分信息,基本涵盖了手术安排的大部分信息,满足医护人员了解手术安排情况的需求。这部分信息所涉及的业务流程并不多,在HIS里面所关联的表也相对有限,而且时效性相对不强。医院并没有数据平台,所以采用每 5 分钟同步一次HIS数据的策略,总的过程还算顺利。

Day 3-6 开发

1.     应用选型

微信企业号的子应用包括消息型应用和主页型应用,消息型应用和我们平时看到的订阅号和服务号类似:

  • 底部菜单——用户可以主动拉取信息;
  • 主界面推送文字或者链接消息——向用户推送信息。

主页型应用打开后则全部是一个网页,由开发者自行定义网页的展示和交互,仅能推送短文字消息给予用户提醒。手术安排查询主要是用户拉取信息为主,达到的效果是用户打开后不用多余操作,立即可以查看手术安排情况,所以选择用主页型应用。

2.     信息简化

2.1 卡片折叠

如上所述,手术信息涵盖的内容非常多,桌面电脑屏幕大,相对来说屏幕空间不是限制。但是到了手机上面,屏幕空间有限,必须重新思考。

%e6%89%8b%e6%9c%af%e5%8d%a1%e7%89%87

使用卡片的方式,依照信息内容的特点,划分出不同大小的内容区块,由区块来组成卡片,这样卡片能够做到整齐划一,用户容易辨识和使用。但是由于手术信息的容量还是比较大,每张卡片几乎占据了手机屏幕的一半大小,手术台数一多,上下滚动的范围加大,不便于用户定位查找。

再进一步提取关键的手术信息,比如手术台次、病人信息、手术方式和医生,把这些信息显露出来,其他手术信息折叠。当用户点击卡片,展开折叠部分,进一步显示麻醉、护士以及其他备注信息。

%e6%89%8b%e6%9c%af%e5%ae%89%e6%8e%92%e6%8a%98%e5%8f%a0

通过卡片折叠的方式,在数量和内容之间取得平衡,达到在手机上面也能呈现大量信息的目的。

2.2 以「图」代言

「图」指的是图标,使用图标可以在有限的空间里面,直觉的表达信息:

screen-shot-2016-09-23-at-12-20-15-pm

通过使用图标,节约屏幕空间,使得信息表述更加直观。

3.     权限控制

本来医护人员是在医生办公室操作病人数据,位置是固定的,环境是公开的。一旦数据到了手机上面,数据查看和操作更加隐秘,在现有的条件下,尽其所能的多考虑一点。

3.1  信息界限

在既有的医院系统中,医生是能够查看整个医院的手术安排情况。但是到了手机端,划分了三层:

  • 手术室、医疗护理管理层:查看全部手术。
  • 临床手术科室(妇、外、骨科):查看本科手术 。
  • 非手术科室:不显示此子应用,无法查看手术内容。

通过这样的分层,使得信息界限的层次更加清晰。

3.2  身份与设备绑定

使用微信提供的 API 接口获取员工身份的同时,还能获取对应手机的微信设备码(DeviceID),这些设备码在员工第一次关注医院企业号时就写入数据库。当用户打开「本院手术安排」的子应用时,微信API接口获取访问手机的员工信息和DeviceID,与数据库内的DeviceID进行比对,如果相等则可以访问数据。

DeviceID 是微信提供的,当更换手机或者重新安装微信的时候,需要告知管理员重置数据库内的 DeviceID。虽然这样增加了维护的难度,一开始用户更换手机或者重装微信后也不明所以,需要向用户解释 ,但从医院信息安全的角度来说,尽可能的使用微信可用的安全机制来保护我们的数据。

Day 6 地推实施

医院电脑是由信息科安装配置的,硬件和系统的可控度较好。但是员工手机都是个人自行购置的,同一个网页在不同类型的手机上面表现有可能会千差万别。

微信在2016年4月份,静默更新了Android版微信浏览引擎X5,使得不同安卓手机的微信,均使用同一个浏览器内核,抹平了不同安卓手机的浏览器差异。而在iOS设备上面,则调用iOS内置的浏览引擎,体验基本统一。这些都大大降低了编码、测试的难度。

在推出「手术安排查询」的当天,正好是夜班巡查,使用这个机会到临床一线去看看医护人员使用手机的类型,也可以在第一时间发现并解决问题:

  • 医院员工苹果手机的iOS版本都在1 以上,浏览体验一致。当晚发现立即修正了在 iOS 8.1 下一个代码小 bug。
  • 安卓手机以华为、三星居多,遇到问题只需要升级到最新版微信,默认启用最新 X5 引擎,绝大多数问题都能解决。
  • 网络基本都是 4G,2G 网络手机几乎绝迹,网络已经不是用户使用的障碍 。

「本院手术安排」这个子应用是在 6 月上线的,3个月来,大家的反馈还都不错,从企业号的后台数据,可以发现平均每天每人都有 1-2 次的打开次数。

做的过程中,总的感觉是医院的桌面应用和掌上应用还是有较大的差别。在员工掌心上的应用,用心去做了,用的人也会感受得到,大家自然会表示感谢鼓励。

前天无意中,看到了微信之父张小龙2011年在饭否的一段文字,作为本文的结尾:

心有千千结,每种结都是一个产品。关系千万重,每种关系都是一个产品。

发表评论

电子邮件地址不会被公开。 必填项已用*标注