简介电子数据采集EDC系统完整源代码面向临床研究信息化开发人员及临床试验数据管理者覆盖试验项目管理、实验设计、病例报告表表单定义、数据录入校验、疑问追踪、逻辑自动校验、报告导出PDF、统计报表生成等关键环节可作为定制化EDC平台的参考实现。压缩包共6个文件包含4个Java源码文件和2个Visual SourceSafe工程文件Java程序分别对应输入与手动查询两个功能模块前者处理数据采集写入逻辑后者实现自定义检索便于理解系统交互与查询扩展方式。资源包仅17KB代码精简易于快速阅读和二次开发。目前已有1722人浏览学习。通过这套源码可以快速熟悉EDC系统的分层结构与典型功能编码思路尤其适合需要搭建临床数据采集系统原型或深入理解其核心机制的开发者。 这些年陆续有人问我能不能把EDC系统的整套源代码交付给我们第一次听到这个需求时我觉得不太理解毕竟市面上一套成熟的临床研究数据采集管理系统EDC少说也要几十万授权费谁会白拿源码自己折腾直到后来亲手交付过几套完整源代码之后我才明白这个需求背后其实藏着一个很现实的问题很多团队并不缺买系统的预算缺的是对系统内部逻辑的掌控权。这篇文章我就围绕“EDC系统完整源代码”这件事把系统应该有哪些模块、源代码里的关键实现、交付前后最容易踩的坑一次性讲清楚。1. 为什么“完整源代码”是这个行业最稀缺的交付形态1.1 市面EDC的三种交付形态我在临床研究信息化这块混了多年接触过的EDC产品不下十种按交付形态基本能分成三类。第一类是SaaS订阅模式也是现在大多数CRO和小型申办方在用的方式。账号开通、浏览器录入、按月付费听起来很省心但数据全部存在服务商那边。项目做完之后想要完整数据库导出一份可以开通导出权限就行。但如果你想在库表结构里查一条质疑的处理链路或者想改一下查重逻辑基本没门。第二类是私有化部署但不开源码。客户租用一套独立环境系统装在本地服务器数据在自己手里但代码仍然属于厂商。这类方案适合药企项目中对数据安全要求很高的场景问题是每次想加一个新功能或者调整一个校验规则都得提工单等排期。第三类就是我这次要说的完整源代码交付。源码、数据库脚本、部署文档、测试用例全部打包带走系统完全部署在团队自己的环境里。数据表、接口、前端页面、后台任务每一个环节都可以修改和审计。对药物研发企业和大型医院机构来说这种交付意味着真正的自主可控。1.2 到底谁在要完整源代码完整源代码的诉求往往不是来自IT部门而是来自项目负责人和临床运营团队。我遇过几类典型客户。一类是药企的新药研发部门。他们同时跑十几个临床试验用外部EDC一年就要付掉几十万甚至上百万的订阅费。项目多、周期长、经费紧干脆内部搭一套。一类是三甲医院的机构办公室。GCP机构要承接大量注册类和非注册类临床研究很多研究者发起的临床研究IIT预算非常有限医院信息科又有开发和运维能力拿到源码后配合自身HIS系统做数据对接成本能压到很低。还有一类是接临床信息化项目的系统集成商。他们买一套源码用它的底层架构为基础再做二次开发交付给下游客户。说白了源码是他们的“半成品原料”。1.3 源码交付的真正门槛很多外行以为源码交付就是打个压缩包发过去这想法差得太远了。一个真正能落地的EDC源码包至少包含后端服务、前端工程、数据库建表脚本、初始化种子数据、容器编排配置、部署文档、二次开发说明、以及用于测试的演示项目模板。光是把这些组织整洁保持“拿到就能跑、跑起来就能建库、建完库就能录数据”就不是一件轻松的事。源码本身不等于产品。没有清晰的代码结构、没有数据库字典、没有配置说明的源码拿到手里只会变成负担。所以这篇里我会重点讲清楚一套EDC完整源代码里真正值钱的部分是哪些以及怎么判断它到底“完不完整”。2. EDC系统必须有哪些模块少一个都不叫完整2.1 核心业务模块从建库到锁库的完整链路一套能用于真实临床试验项目的EDC业务链路一定是闭环的。如果源码里只有数据录入表格和简单查询那充其量是个问卷系统不能叫EDC。按我自己的经验以下核心模块缺一不可。研究构建模块也就是俗称的建库功能。临床数据管理员DM需要在线配置病例报告表eCRF包括访视安排、表单页面、字段类型、逻辑跳转、值范围校验、必填项设置。源码层面对应的就是一个强大的表单设计器分为配置界面、JSON模型解析引擎、动态渲染引擎三部分。现在个人电脑上让你看到的是一个可视化拖拽页面背后其实是把复杂的表单结构序列化成元数据再通过后端引擎按版本发布。数据录入模块供CRC或研究者按访视录入受试者数据。它不只是简单的增删改查还包含数据保存时的实时校验、字段级别的疑问触发、重复录入提示、历史数据版本查看等功能。录入页面必须严格区分“保存草稿”和“提交数据”两个状态因为两条操作路径在稽查轨迹里记录的内容完全不同。质疑管理模块也就是query。数据录入后DM发出一条质疑比如“收缩压与上次访视差值超过30mmHg请核实”CRC收到后要么澄清、要么修改数据并回复。这个模块看似简单但状态机非常容易出bug质疑态、回复态、关闭态、重开态环环相扣。稽查轨迹模块是对临床数据合规性最关键的一块。系统里每一次新增、修改、删除、查看敏感信息、导出、打印等操作都需要自动记录操作人、操作时间、操作内容以及变更前后的值。这个模块在代码层面不能只做“应用日志”而要和业务数据存在独立的审计表中并且设计成不可篡改的追加写入模式。数据导出模块用于将临床试验数据导出成SAS数据集、Excel或者符合CDISC标准的XML文件。导出逻辑里包含数据字典对照、值域映射、缺失数据处理这块做不好后面做统计分析时会非常痛苦。2.2 合规模块20年前那部法规依然是准绳EDC的合规设计绕不开FDA 21 CFR Part 11以及国内《药物临床试验质量管理规范》GCP中对电子数据的基本要求。源码里对应的就是以下功能点电子签名每个账号绑定唯一用户名和口令签名动作与具体的数据操作绑定签名后系统记录完整签名信息权限管理系统管理员、DM、CRC、PI、监察员、统计师角色不同能看到的菜单和数据范围完全不同数据锁定当项目达到锁定条件后指定表单或整个数据库被锁定锁定后只能通过特定流程解锁并留下记录系统日志除了业务稽查轨迹还包括登录日志、权限变更日志、系统配置变更日志。这套模块单独看每一个都不复杂难的是把它们嵌入到所有业务流程中。比如电子签名并不是一个单独的按钮而是当你提交一条CRF页面数据时系统在后台自动完成签名记录。这就是源代码里需要下功夫的地方。2.3 模块协同的方式我经常拿“医院挂号流程”来类比EDC的模块协同关系。表单设计器相当于医生开的检查单模板数据录入相当于采集患者信息质疑管理相当于检验科复核复查稽查轨迹相当于病历上的每一次医嘱变更记录导出模块相当于最终归档的病案首页。没有质疑、稽查、锁定这几环的EDC就像只接诊不写病历的门诊流程根本立不住。在源代码实现层面这些模块通过统一的数据模型和状态机相互咬合。表单定义、数据实例、质疑实例、审计记录这几张核心表之间通过项目ID、受试者ID、表单实例ID串联任何一个环节的数据状态变化都要同步影响其他环节。3. 这套源代码的技术构成与落地细节3.1 总体架构选型为什么要这样配结合我实际落地过的一套源码技术栈大致为前端用Vue 3加Element Plus组件库后端用Spring Boot 3.xJava 17数据库MySQL 8.0缓存Redis后端提供RESTful API前端页面完全通过API交互整个应用打包成Docker镜像用docker-compose或Kubernetes部署。选这套组合不是因为“流行”而是因为临床数据系统最看重稳定性和团队上手成本。Java生态在医疗信息化领域沉淀最久大部分医院信息科和药企IT团队都能维护Vue做复杂的动态表单渲染足够灵活MySQL作为关系型数据库完全能支撑一个项目几千例受试者的数据量。不过我也见过一些新的实现用Python FastAPI或Node.js。不是说不可以但你要考虑团队招聘和长期维护的问题。源码给你了后续都得自己改技术栈越偏门成本越高。3.2 eCRF表单设计器的数据模型实现表单设计器是EDC系统里最有代表性的模块也是最容易在源码交付后被人翻出来看的部分。这块的核心在于如何描述一个表单页面的结构。常见的做法是把表单定义存储为JSON Schema。一个“生命体征”表单在数据库里对应一条visit_form记录其content字段存的就是类似这样的JSON结构{ fields: [ { field_name: vital_signs_sbp, field_type: number, label: 收缩压(mmHg), required: true, validation: { range: [60, 260], unit: mmHg } }, { field_name: vital_signs_weight, field_type: number, label: 体重(kg), required: false, validation: { range: [30, 200] } } ], page_id: vs_page_1, version: 1.0 }前端通过网络请求拿到这套JSON之后动态渲染表单后端在数据保存时根据同一套JSON执行校验。这样做最大的好处是“定义即文档”建库员在界面上拖拽出的每一个组件最终都被序列化为结构的JSON数据后续每一个版本变更也能用JSON差异比对的方式做版本管理。3.3 数据校验规则引擎的关键实现临床数据录入过程中的即时校验是EDC和普通信息录入系统最大的区别之一。比如“如果受试者性别为女性则不能填写前列腺特异性抗原PSA数值”“如果不良事件等级为轻度则严重程度字段不应为SAE”。这些校验逻辑在源代码里由一个规则引擎统一处理。推荐的方式是规则以JSON表达式持久化比如{ rule_id: rule_ae_grade, condition: ${ae_grade} grade_3, action: warning, message: 3级不良事件必须记录合并用药和处置措施 }后端引擎在数据保存前循环执行所有与当前表单关联的规则将命中的提示或警告返回给前端。这样设计的好处是规则和代码解耦后续DM新增规则不需要改动Java代码在界面上配置好保存即可。我踩过的一个坑是规则执行顺序。如果两条规则之间有依赖关系比如A规则要基于B字段的计算结果那么引擎必须支持按优先级排序执行。否则可能会出现“先判断A然后发现B还是空”的尴尬提示。源码中一定要有明确的rule_priority字段。3.4 稽查轨迹最容易被低估的实现成本很多团队拿到EDC源码以后最先改的就是界面和报表稽查轨迹反而容易被忽略。但要知道稽查轨迹在新药申报核查时是要被药监老师直接调阅的。核心是要有两层记录。应用层在每次业务操作时写审计日志记录操作人、IP、操作类型、数据变更前后的值同时在数据库层用触发器对核心业务表做一道兜底记录。应用层记录通俗易懂适合业务查询数据库触发器记录则防止绕过应用直接改库的情况。写审计日志的时候有一个细节很容易忽略不能只记新值不记旧值。数据修改前后对比是核查中最常看的比如某条生命体征数据从“正常”被改成“异常”一定要在稽查轨迹里看到两个状态值。CREATE TABLE audit_log ( audit_id BIGINT PRIMARY KEY AUTO_INCREMENT, project_id VARCHAR(64) NOT NULL, subject_no VARCHAR(32) NOT NULL, form_instance_id BIGINT NOT NULL, field_name VARCHAR(128) NOT NULL, action_type VARCHAR(16) NOT NULL, old_value TEXT, new_value TEXT, operator_account VARCHAR(64) NOT NULL, operator_ip VARCHAR(45), created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这张表的设计保证了一条完整的审计记录可以追溯谁在什么时间通过哪个IP把表单A的字段B从旧值改成了新值。字段类型用TEXT而不是VARCHAR是因为有些大字段如备注文本改动后内容很长VARCHAR容易截断。3.5 部署与初始化拿到源码后最容易卡住的地方交付源码时最常遇到的情况是接收方把代码仓库克隆下来启动后端黑窗口一通报错然后来问我。十有八九问题都不在代码本身而是环境准备不完整。完整的部署步骤应该是这样的准备MySQL 8.0实例执行sql/init_database.sql创建库再执行sql/init_data.sql写入基础字典和管理员账号准备Redis实例作为登录会话和权限缓存修改后端配置文件中的数据库连接和Redis地址构建前端工程并配置Nginx反向代理API地址docker-compose up -d一键启动。为了降低上手门槛源码包里最好附带一个docker-compose.yml把MySQL、Redis、后端、前端一次性编排起来。数据初始化脚本里的种子数据要包含管理员账号、角色权限字典、一份完整的示例项目定义含示例eCRF表单和受试者数据。这样接收方启动完系统后立刻能看到一个可操作的EDC环境而不是面对一个空壳。4. 权限安全和数据校验最容易在源代码里被低估的两块4.1 基于角色的访问控制与受试者数据隔离EDC系统里的角色权限设计和普通办公系统完全不同。普通OA只需区分“能不能看这个菜单”但EDC必须做到“能看菜单但不一定能看到某些site的数据”。比如CRA临床监查员可以查看自己负责中心录入的数据但不能查看其他中心的统计师可以查看全库数据但不能修改CRC只能看自己负责录入的数据。这种权限最终是由项目级角色表、中心级数据范围、字段级编辑权限三层共同控制。源码中应有一个简明的权限控制模型用户 - 角色 - 权限点加上一种“数据范围”配置权限点控制能做什么操作数据范围控制能看哪些中心、哪些项目的数据。这两者必须配合否则很容易出现一个DM账号能浏览所有项目中的受试者隐私数据。4.2 字段级校验与数据核查支持EDC中的数据错误是临床研究的大忌但指望录入员敲键盘一个字不出错也不现实。所以一个好的EDC源码实现中校验不仅要在前端提醒还要在后端重新执行一遍防止绕过前端直接调API提交脏数据。后端校验我建议做两层第一层是字段级校验值域范围、数据类型、必填项、日期先后顺序第二层是跨字段跨表单的逻辑校验也就是不良事件起始日期不得早于随机化日期这类跨模块校验要放在数据操作事务中执行一旦失败则整个保存操作回滚。还要额外考虑SDV源数据核查的支持。监察员核查时需要一个独立的核验标记表示哪些数据已和源数据核对过。源码中如果没有这个字段后期核查时只能靠线下Excel效率非常低。一般做法是DataPoint表增加sdv_status和sdv_by、sdv_at三个字段。4.3 盲态控制与揭盲流程如果项目是双盲设计EDC还需要支持盲态控制。最核心的逻辑是在随机化分配和药物编号管理中盲底数据对受试者录入端完全不可见只对少数具有揭盲权限的用户开放。这个流程在源码里是一套独立的数据出口和日常录入模块完全隔离。很多二次开发者会在这里犯错误把药物编号直接放在受试者表单里导致CRC在录入时就能看到全部盲底。正确做法是随机化数据单独表存储录入端只显示“药物编号已分配”的占位符需要揭盲时走专门接口并记录完整审计日志。4.4 关于依赖组件的安全审计源代码交付之后如果接收方有自己的安全测试团队他们通常第一件事就是对依赖组件做漏洞扫描。所以源码在交付前就要做好依赖管理前端npm包和后端Maven依赖都存在版本锁定。后端关于这部分有几个常见的坑点fastjson的版本漏洞、Log4j2的远程代码执行问题、Spring框架的越权漏洞。交付前用OWASP Dependency-Check整体扫描一遍把高危漏洞处理掉不然源码发过去第一天就会被接收方质疑专业度。5. 交付源代码之后团队最先遇到的三个现实问题5.1 代码拿到了但跑不起来这是最常见的第一个问题。症状通常是两种第一种数据库初始化脚本不完整后端启动时缺表第二种没有演示项目模板登录进去以后空白一片不知道怎么下手。源码交付不只是把代码压缩包发出去还要把“系统如何从零初始化成一个可用项目”的完整路径理清楚。所以在代码包里我会额外放一个docs/initialization.md把从环境准备到创建数据库、导入初始数据、启动配置、创建第一个项目的每一个步骤都写清楚。这一步用掉的精力远比写业务代码本身要多。5.2 二次开发从哪下手拿到代码后第一个想改的功能通常是修改某个表单字段或者增加一个自定义校验规则。这个时候如果源码模块边界不清晰会非常混乱。比如表单配置存哪里、规则引擎挂在哪个服务、导出模块怎么配置映射关系文档里都得写清楚。按模块拆分的目录结构对二次开发最友好。让我举一个合理的源码目录结构edc-source/ ├── backend/ │ ├── edc-common/ # 公共工具与常量 │ ├── edc-system/ # 系统管理用户、角色、菜单 │ ├── edc-study/ # 研究配置、eCRF元数据、版本管理 │ ├── edc-data/ # 受试者数据、录入、质疑、稽查轨迹 │ ├── edc-export/ # 数据导出、SAS/XML转换 │ └── edc-auth/ # 认证与电子签名 ├── frontend/ │ ├── src/ │ │ ├── views/ # 页面组件 │ │ ├── components/ # 动态表单渲染组件 │ │ └── api/ # API封装 ├── docs/ # 部署文档、二次开发说明、数据字典 ├── sql/ # 初始化脚本、种子数据 └── docker-compose.yml接收方第一周要做的事是先让系统完整跑通然后用示例项目模拟“建库-录入-质疑-签名-导出”全流程再考虑改代码。一上来就改代码出了问题很难判断是改出来的bug还是原有逻辑没吃透。5.3 验证与支持文档要不要一起交付临床研究系统有个特殊要求是计算机化系统验证CSV。药监核查时不管系统是买的还是自研的都需要有相应验证文档证明系统在受控状态下开发、测试和上线。所以完整源代码交付不能只交代码还需要附上需求规格说明书、概要设计文档、数据库设计文档、测试用例和执行记录、系统管理员操作手册、用户操作手册。哪怕这些文档的颗粒度没那么细也比什么都没有强。我见过一个项目因为验证文档缺失审计时被开了重大缺陷项后期补文档补到崩溃。最后补一句我的实际体会源码交付这事本质上不是把手艺卖出去而是把一套方法传递出去。真正负责任的交付是让接手的团队不仅拿到能跑的系统还知道怎么改、怎么扩展、怎么验证。我自己在写这套EDC源码时最花心思的地方不是炫技的技术框架而是表单元数据模型、稽查轨迹、规则引擎和权限控制这几个最“沉闷”的模块。这些也是后来被复用最多、反馈最值得的部分。如果你也在考虑自建或引进EDC源码建议先拿一份demo跑通全流程再用小型项目试运行别在正式项目上做首次验证。本文还有配套的精品资源点击获取
