看似简单，实则不易！什么才是临床试验电子数据采集系统（EDC）的核心技术？

临床试验的信息化建设是临床试验发展的一个必然趋势。现如今，EDC（Electronic Data Capture System, 临床试验电子数据采集系统/数据管理系统）也逐渐得到广泛应用，国内的EDC厂商因此扎堆出现，全然不顾前面到底是遍地黄金还是尸山血海。 

笔者仔细思考了出现这种现象的原因，认为大致有二：

“动态”是EDC的护城河之一

EDC的前端录入页面不同于taobao或者yahoo之类的网站，其每一个页面都是动态生成的，每一个Label和控件都是在后端设置模块里面进行的。这样才能无需修改程序就可以应对绝大多数临床试验的页面要求。如果你玩过discuz建站，应该很熟悉这一点。

Edit check就是需要动态的实现对不同datapoint之间的各种逻辑核查。这些datapoint可以位于不同的datapage，不同的instance。需要实现一对一、一对多的比较。优秀的EDC产品甚至要实现逻辑关系的数据点之间的比较，如log页面某一列最大值和最小值之间的比较等。

Custom function是edit check的延伸，需要实现一些基础的check做不到的功能。早期的Custom function需要程序员编写一段代码然后打包到source里面再发布，这样非常麻烦。现如今大部分EDC都能够做到终端用户自己编写这段代码，发布到crfversion里面即可。

EDC里面的角色以及权限，权限组都是动态配置和组合的。如CRC能够做什么事情，是否可以查看数据、编辑数据、发质疑、回答质疑、查看回答过的质疑等等，都是需要动态配置和组合来实现这些功能。

流程的动态配置是最难以处理的一个环节。如做review之前必须要做SDV，或者反过来另外一个项目需要做SDV之前precondition是review。

因为数据点的状态非常之多，有时候甚至会有二三十个状态，这些状态的查询更新等如果不用一个好的算法或者好的架构来处理，终端用户看到的就是“转圈圈”，因此我们也会经常看到微信朋友圈有朋友吐槽又看到某些厂商的EDC在“转圈圈”。这是一个至关重要，直接影响到用户体验的问题，所以笔者想简单铺开一下。

在早期的设计里面，会把datapoint的各种状态作为表的一列来设计，如datapointid, roleid,isEmpty, isTouched等。这样的做法会导致程序的扩展性比较差，每增加一个状态的属性时，就要修改这个表结构增加新的一列。一个好的EDC系统往往会有将近30种的数据点的状态，初期的时候也不可能面面俱到，那么有没有办法能够让程序可以扩展且不用修改表结构呢？答案是有的，那就是利用位运算中的按位与。

首先定义各个状态的值（以下出现的数字皆为2进制），譬如IsEmpty为1，IsTouched为10，IsSigned为100，IsLocked为1000，接下来要理解的就是status的存储，假如这四个状态分别为”0,0,0,0”，那么status列就应该存储0+0+0+0=0，即存0。假如这四个状态分别为”1,1,1,1”，那么status列就应该存储1+10+100+1000=1111，即存1111。

接下来就是怎么解析这个状态，假设状态列里面存储的是1101，这个时候让1101跟IsSigned按位或得到的值为100，cast为bit的话就是1，跟IsTouched按位或得到的值就是0。那么就很简单的解析出来这个位的状态了。

 数据导出

现在市面上绝大多数EDC都自带了很多inhouse的报表，可以满足一部分功能。但是很多时候并不能满足数据管理和项目管理人员的一些特殊要求。

所以，就导出这一块可以使用一些成熟的中间件技术，把数据库里面的内容包装成一个个的类，每个类都有相应的属性和字段，这样终端用户可以通过拖拉等简单的操作来自由自在的生成自己所需数据格式的报表，甚至可以生成饼图、柱状图等。

升级是非常重要的一个功能，甚至可以说这个功能的易用性和“健壮性”是决定一个EDC产品成败的关键。

易用性指的是客户可以很容易选择source version以及target version，并能够清楚的知道两个版本之间的变化，以及需要有地方让客户能够进行dry run来确保正式的migration是否会出现问题。“健壮性”指的是升级过程中如果出错，需要提供一个回滚的功能，以及出错的报告，错误在什么地方。另外需要保证升级过程中没有任何原始数据的丢失。