“应检尽检”是北京市6月中旬出现疫情反复后采取的应急措施,即对重点人群、高风险人群全面开展核酸检测,务求做到“应检尽检”,要求各医疗机构外派医疗采集队,到社区或企事业单位,采集咽拭子标本,并送回自己的医院进行检测,并提供报告。
“应检尽检”的主要特点是:面向大批量人群,非医院现场采集,要求快速、高效、准确。
为减少手工记录的种种弊端,北京市开发了一套区域标本采集和检验程序,包括检验系统、采样点系统、“京心相助”小程序,前两者是供医疗机构采样使用的PC端程序,“京心相助”小程序是供被采样人使用的互联网应用。
通常,上级下发的应用软件,又不与医院信息系统衔接的,一般无需信息中心提供技术支持,但鉴于此次“应检尽检”的系统复杂性和使用场景的特殊性,院领导要求医院信息中心支持、指导相关工作,并与“京心相助”小程序的技术团队对接。医院信息中心按要求担任了这个应用系统的实施工作。
我们测试了系统的主要功能:(1)检验系统与医院的检验系统相近,功能相对更为简单;(2)采样点系统的主要功能是录入采样点信息、生成采样点二维码、标本转运;(3)“京心相助”小程序的主要功能是让被检测人群自主录入个人基本信息、到采样点注册、扫描样本条码、查询核酸检测结果等。
在测试小程序的过程中,我们发现:由于医院的采集管上没有条码,无法达到小程序使用的要求,因此紧急开发了预制条码程序,可以按照采集的要求,打印出贴在采集管上的条形码。
信息中心的测试,和普通用户的使用不同。除功能测试外,我们还和公司多次沟通系统逻辑性、数据严谨性、易用性等方面的问题。但从实际使用的结果看,我们测试得并不理想,有些明显的问题,不到真正使用时是发现不了的。
出于慎重起见,在上级最初临时安排的几次“应检尽检”任务中,我们没有使用“京心相助”小程序,直到为我院提供医辅工作的几家公司人员开始“应检尽检”时,我们决定尝试一下这个互联网应用。
这次核酸检测地点分别位于友谊医院的西城院区和通州院区,只有一天的准备时间,我们为参加采样的护士进行了采样点系统和小程序的使用培训,护理部安排提前打印了采样点二维码和准备贴在采集管上的预制条码,并分别为西城院区和通州院区准备了详细的小程序操作文档,提前下发,让被采样人填写好注册信息,以免耽误现场时间。
西城院区采样地点位于教学楼三层,护理部对采样点布局的安排已经很有经验。下午3:30开始,有很多人在院区里排队。在教学楼一层,有护士现场讲解注意事项,并让大家都拿出手机,检查小程序是否注册好了,然后上楼梯,排队进入三层。
教学楼一层有一台笔记本电脑,这是整个采集区域的唯一一台电脑,安装了采样点系统,没有智能手机的人员,可以提供身份证,护士将信息录入系统,另外可以随时查看后台数据,解决出现的问题。
采集工作在三层完成。狭窄的楼道里有三个分诊台,主要工作是将被采样人分为五人一组,每组扫同一个预制条码,然后其中一人拿着贴好条码的采集管,五人依次进入同一个诊室采集标本。这就是“应检尽检”采取的“五混一”方式,即五个标本放同一个采集管里,检验时只出一份报告。如果报告显示为阳性,这五个人再重新做一次检测,以判定具体哪个人是阳性。
在这次“应检尽检”中,三层的工作看上去不多,但很多被采样人在应用小程序时出现了问题,当时只有一个机动护士在处理,已经忙不过来。由此,也看出互联网应用还面临不少实际问题的约束。
1.对年纪较大的人员而言,互联网应用是个挑战。这次参与“应检尽检”的几个医辅公司,包括餐厅、保洁、护工、保安、配送等,人员组成非常复杂,既有年轻的,也有年纪较大的。安排被采样人提前填写个人信息是非常必要的,即便只有三项:姓名、身份证、手机号,有不少人仍需要其他人帮助完成。在扫条码时,如果出现问题需要重新注册,年纪较大人员遇到的困难非常多:有看不清屏幕的,有不记得身份证号的,也有不知道自己手机号的,更多的是带着对小程序应用的“恐惧”,茫然地把手机递给护士请其帮助填写。
2.互联网应用对个人设备具有依赖性。标本采集时,按传统的实现方式,需要有电脑、条码打印机,现在只能用个人手机实现注册信息和绑定条码的功能。据我观察,各种各样的智能手机均可以调出小程序,但有时会出现问题,一时不好判断是程序bug,还是手机的兼容性问题。另外,在采样的1500多人中,大约有20人没有智能手机,是护士手工录入的信息。
3.网络是互联网应用的基础条件。采样前一天,我本想加强这个区域的Wi-Fi信号,但考虑到医辅公司的人员应该没有医院的Wi-Fi(医院的无线网是有登录名和密码限制的),于是作罢。从现场情况看,他们都有办法得到。医院的Wi-Fi被大量人员同时访问,导致网速极慢,小程序无法运行,一层的护士只能不断地提醒:“关闭Wi-Fi,使用自己的流量”。但到三层时,仍有不少人开着Wi-Fi,造成小程序调不出来,原因之一是不舍得用自己的流量,另一个原因可能是他们都不知道流量是什么。另外,有些人的4G信号也不好,更有个别手机关闭Wi-Fi后,还是2G信号。
4.扫码是现场的主要操作之一,条码设计有讲究。现场需用手机扫描采集管的预制条码,让个人信息和条码信息关联上。我们打印的是一维条码,用手机扫描时需要调整手机与条码之间的位置,快的要2-3秒,慢的要4-5秒;还有实在扫不上的,也可以直接录入条码下面的条码号,但这就耽误时间了。此前我们也测试过二维码,虽然手机扫描比较容易,但贴到采集管(有弧度)上后,到检验科就识别不出来了。
5.混管采集是不太好把控的流程。“应检尽检”基本上都是混管采集的,有三混、四混、五混,甚至六混。三混的时候,我们曾经尝试压缩条码,以便在采集管上贴上三个条码,但再多就真的贴不下了。因此在实际操作中,都是一个条码代表着几个人,从条码上是看不出任何标识的。但在采集现场,从扫完条码到诊室采咽拭子这段时间,这一组人要在狭窄的楼道上保持固定的队形,谈何容易?稍有交叉,人员信息就乱了。因此,互联网应用无法现场打印,确实是一个难以解决的问题。
6.地点二维码一定要现场扫描。互联网应用经常需要通过二维码记录地点,“应检尽检”的采样点二维码也记录了采样地点。如前文所述,为了让大家提前填好信息,当时我们把两个操作文档(因为二维码不同,特意分别准备的文档)提前下发了。我看到文档时,觉得不妥,犹豫了一下,但想着如果能提前把个人信息填好了,省得耽误现场时间,也是必要的,就提醒了一下:“到哪个院区采样就用哪个文档,里面的二维码是不同的,别扫错了。”即便如此,在整理数据时发现,有些人在通州院区采集,却扫了西城院区的二维码,而系统里多了不少到了现场却未采集的数据。这个教训就是:地点二维码,必须要在到了地点的时候才能扫!放在文档里扫描,就失去了记录地点的意义。
7.区域标本采集小程序还需优化完善。“应检尽检”小程序是应急开发出来的,时间紧,任务重。我和技术团队几次沟通,他们都很认真,也很辛苦,对于“应检尽检”这个场景,我相信开发前大家都不清楚,每个采样点的布局也不尽相同,我们使用的版本也是经过几次快速迭代后的成果。但对于这种大规模、多人群、要求高效的应用场景,至少要保证:(1)易用性,适于不同年龄、不同背景人员的使用;(2)严谨性,保证最终数据的准确性;(3)灵活性,适合不同采样点的个性化需求。采集结束后,我们整理了在现场发现的问题,提交给了技术团队,希望后续他们能更好地完善。
总的来讲,这次互联网应用还比较顺利,在2-3个小时的时间里,通州院区采集近700人,西城院区采集了1500多人,与手工登记完成的时间相近,但节省了一些人力,后续检验科省去了手工录入,出报告肯定会快不少,被检测人员也可以更快捷及时地查询到检验结果。
此次核酸检测应急任务中大规模使用互联网应用,对于医院信息中心来讲,也是一次新尝试。因此,和大家分享一点经验和教训,希望以后如果再有类似的情形和应用,可以少走弯路,更加顺利。