案例 · 临床研究

40 家研究中心,患者数据只录一次,每次修改都有记录。

业务
临床研究机构,海得拉巴
规模
在 6 个城市的 40 家医院研究中心开展试验
此前依靠
纸质表格、电子邮件和共享盘
团队
两位创始人

一家在 40 家医院研究中心开展试验的研究机构。数据通过纸张和电子邮件传来,核对一条记录要追着三个人跑。

原来哪里出了问题

维杰亚瓦达一家医院的研究协调员,在病床边填写一张纸质表格。表格被扫描后通过邮件发出,有时干脆由人送过去。海得拉巴有人把它录入电子表格。后来,监查员发现一个不可能正确的数值,给研究中心发邮件,等待,最终在一份新的扫描件上拿到更正。于是这位患者的记录有了两个版本,而修改的原因埋在一串邮件往来里。

把这个情形乘以 6 个城市的 40 家研究中心。数据以人能想到的各种形式传来。核对一条记录要追着三个人跑,而追人本身成了工作:协调员整天忙着处理邮件,而不是照顾患者。任何时候,都没人能确切说出一个试验有多少个问题还没解决。

最让这家机构担心的不是速度,而是关于改了什么、谁改的、为什么改的记录,散落在扫描件、电子表格和收件箱里。一次稽查,就意味着要手工把这些重新拼凑起来,还只能祈祷没有遗漏。

我们做了什么

一个让研究中心只录入一次数据的平台:就在研究中心,在协调员本来就开着的屏幕上录入。表单就是记录。核查在录入的那一刻进行,而不是事后:超出预期范围的数值,不可能晚于另一个日期的日期,方案要求却空着的字段,都会在协调员还看着患者病历、能够作答的时候被提出来。

每一次修改都有记录。谁改的,什么时候改的,改之前是什么,以及他们给出的理由,都和记录保存在一起,而不是放在收件箱里。任何内容都不会被覆盖,也不会被删除,所以一个数值的历史,本身就是这个数值的一部分。

研究中心录入的生命体征表单,数值一填入就触发核查:一个超出预期范围的血压值,一个不可能晚于访视日期的日期,一个空着的必填项;旁边是未关闭的质疑数,以及记录谁在何时改了什么的稽查轨迹。
根据文中描述绘制的界面示意图,并非截图。

质疑不再靠邮件。监查员提出的问题,会直接出现在它所针对的那个字段上,分配给研究中心的一位指定人员,双方都能看到,直到得到答复。任何人都能看到一个试验有多少条未关闭的质疑、分布在哪些研究中心、已经等了多久,一场旷日持久的争论就这样变成了屏幕上的一个数字。

访问权限按角色和研究中心划分,所以协调员只能看到自己所在的研究中心,看不到其他任何内容;每一次登录、每一次导出都有记录。

老板最后得到了什么

每条记录只采集一次,并附带每次修改的完整历史。质疑和稽查都从平台上作答,而不是靠三个人的记忆。协调员拿回了自己的时间,这是各研究中心最先注意到的变化。

平台运行在这家机构自己的云账户里,备份是当着他们的面恢复过的,而不是想当然,因为试验数据绝不能是靠祈祷的东西。研究中心的员工逐个中心接受了培训,书面指南留在机构手里。

交接复盘坦白写明了哪些仍靠手工:少数化验结果仍以文件形式,从一些与任何系统都对不上话的仪器传来,这些仍由人来核对。这是我们下一步会着手的部分,复盘说明了怎么做。

这属于业务系统工作,而托管和恢复被当作这项工作的一部分,而不是别人的问题。

改变了什么,改变了多少。

  1. 消除差错

    每录入 100 个字段发出的数据质疑数

    12 变为 2

    监查员退回研究中心要求更正的字段

  2. 节省时间

    从发出质疑到关闭质疑

    11 天 变为 2 天

    从监查员发出质疑,到研究中心解决为止

  3. 堵住流失

    稽查轨迹有缺口的记录

    每 9 条有 1 条 变为 无

    修改没有记录修改人、修改原因或原值

每项指标都在开发前书面约定,起始数字也在开工前测得。从“12”到“2”,是同一项指标在完工后按同样方法统计的结果。

业务系统:完整介绍

全部案例

开始

写一段话。创始人会在 1 个工作日内回复。

随后是与两位创始人的 30 分钟通话。不放幻灯片,也不套方案模板,只是先初步判断:我们是否适合解决这个问题。

也可以通过邮件、电话或 WhatsApp 联系: hello@netogrit.com · +91 94330 54299 · WhatsApp(在新标签页中打开)