简介这套源码定位为临床研究领域的EDC电子数据采集系统完整实现面向临床信息化开发人员、临床试验数据管理者以及希望深入了解EDC内部机制的研发者。系统覆盖临床试验项目管理、CRF表单设计、疑问处理、数据录入、逻辑自动校验、CRF/DCF报表导出PDF及统计报表等核心环节可帮助开发者快速理解从数据采集到分析处理的全流程。压缩包共6个文件含4个Java源码文件Input、handquery两个模块的模型与动作类和2个scc辅助文件整体仅17KB体积小巧但模块结构清晰便于学习与二次开发目前已有1722人学习/下载。对于想要构建定制化EDC平台或改进现有系统的开发者这套源码提供了扎实的代码参考和模块划分思路可在此基础上扩展业务逻辑快速搭建符合自身需求的临床试验数据采集管理工具。 做临床研究的都懂数据采集这块儿有多磨人。十年前我入行的时候国内大多数项目还停留在纸质CRF病例报告表时代研究者手写、监查员逐页核对、数据录入员二次录入一套流程走下来光数据清理Data Cleaning就能拖两三个月。后来开始接触EDCElectronic Data Capture电子数据采集系统才真正感受到什么叫生产力解放。这几年陆续带团队做过几套EDC系统的选型、定制和二次开发也完整落地过一套可交付源代码的EDC系统今天就把这套系统的设计思路、核心模块拆解和落地经验一次性讲清楚。这篇博文适合两类人看一类是临床研究行业里想搞清楚EDC到底怎么运作、如何做系统选型的CRA、DM和项目经理另一类是医疗信息化方向的研发人员想了解一套合规、可扩展的EDC系统从数据模型到核查引擎应该怎么设计。两边的视角我都会照顾到研发偏重点技术实现行业侧偏重业务逻辑和合规约束。1. EDC系统全景拆解1.1 EDC到底在解决什么问题EDC系统的本质是把临床研究中的数据采集从纸质记录、人工转录、事后核查变成结构化的电子化录入、实时校验、在线质疑和全流程留痕。核心解决三个问题一是数据质量源数据在录入那一刻就被规则约束异常值、缺失值、逻辑矛盾当场拦截二是效率数据从研究中心到数据管理团队不再需要邮寄、扫描和重复录入清洗周期大幅缩短三是合规稽查轨迹Audit Trail、电子签名、权限管控满足GCP和21 CFR Part 11的监管要求。我见过不少团队在EDC选型上纠结觉得“功能越多越好”。实际上EDC的核心价值不在功能堆砌而在“数据流是否闭环、规则是否灵活、留痕是否完整”。一套真正好用的EDC录入界面要像电子表格一样顺手核查规则要能配置化下发质疑处理要像工单系统一样有状态流转导出数据要能直接对接统计软件。下面这套系统的设计基本就是照着这个标准来的。1.2 从纸质CRF到EDC的核心流程对比在讲系统设计之前先花点篇幅把业务流程理清楚。EDC的系统架构和功能设计本质上是为业务流程服务的不理解业务的人写不出好用的EDC。环节传统纸质模式EDC系统模式表单设计打印CRF纸质版修订需重新印刷可视化建库修改即时生效数据录入研究者手写之后再转录在线填报支持下拉、日期控件、单位自动换算数据核查监查员人工核对原始资料内置Edit Check自动触发质疑质疑管理邮件、电话、纸质通知单系统在线发起、回复、关闭全流程留痕数据导出人工整理成Excel或SAS格式按CDISC标准自动映射导出稽查记录手工签字、归档电子签名、时间戳、修改留痕这个对比也决定了系统的功能模块边界。拆解下来一套可复用的EDC系统至少要包含以下核心模块用户与权限管理、研究中心与受试者管理、访视计划配置、动态表单引擎、逻辑核查引擎、质疑管理、电子签名、稽查轨迹、数据导出与接口、盲态管理针对双盲试验。每个模块拆开都不算特别复杂难的是模块之间的数据关联和状态一致性。2. 核心功能模块与数据模型设计2.1 元数据驱动建库不写代码EDC系统最核心的设计思想是“元数据驱动”。说得直白一点EDC的CRF表单不是写死在页面里的而是通过配置元数据在系统里动态生成。建库人员通过后台配置页面拖拽或填写表单控件定义字段名、类型、是否必填、取值范围系统在前端动态渲染录入界面在后端动态校验数据全程不需要写一行业务代码。为了把“建库不写代码”落到位我们设计了一套精简的配置化建库方案用结构化的字段元数据field meta来描述每个录入项。一套表单Form包含多个字段Field每个字段是谁的类型文本、数值、日期、下拉、复选、单位等是否有range check取值区间校验、required标记全部记录在配置表里。前端拿到这份配置生成可填写的录入表单后端拿到同一份配置生成对应的校验逻辑。我第一次做这套设计时踩过一个大坑一开始把校验规则写死在表单渲染代码里结果研究者反馈某个字段的取值范围要按肿瘤分期动态调整每次都要发版本。后来改成“表单结构校验规则分离存储”取值范围、必填条件这些全部配置化改规则不用动代码直接在后台改配置并记录版本。这个改动让建库周期从以周为单位缩短到以天为单位。2.2 四层数据模型Subject、Visit、Form、Field这套EDC系统的数据模型设计核心是四层结构受试者Subject在最上层往下是访视Visit再往下是表单Form最底层是字段Field。这个结构几乎映射了临床研究的标准流程一位受试者按计划在多个访视节点做检查每个访视节点需要填写多张CRF表单每张表单又包含若干数据字段。受试者表和访视计划表是骨架字段数据表是血肉。字段数据表不要设计成一张宽表每个字段一列而要设计成“一行一个字段值”的长表结构这样CRF版本升级、增删字段时不需要改表结构加一个配置即可。表设计大概长这样-- 受试者主表 CREATE TABLE subject ( subject_id BIGINT PRIMARY KEY, study_id BIGINT NOT NULL, subject_no VARCHAR(50) UNIQUE, status VARCHAR(20), -- screening / enrolled / completed / withdrawn randomization_no VARCHAR(50), created_time TIMESTAMP ); -- 字段数据表 CREATE TABLE form_data ( data_id BIGINT PRIMARY KEY, subject_id BIGINT NOT NULL, visit_id BIGINT NOT NULL, form_id BIGINT NOT NULL, field_id BIGINT NOT NULL, field_value TEXT, -- 统一以文本存储展示时按元数据转类型 is_blank_reason INTEGER, -- 空值原因标记ND/NP/NA updated_by BIGINT, updated_time TIMESTAMP, UNIQUE (subject_id, visit_id, form_id, field_id) );为什么要用长表而不是宽表举一个实际例子一个研究方案筛选期表单可能包含120个字段治疗期表单包含240个字段把每个方案的表单字段全部落成一个宽表数据库列会膨胀到几千列而且方案调整一个字段就要ALTER TABLE一次线上系统根本扛不住。长表结构配合字段元数据表加字段就是加一行配置记录数据表完全不用动这才是EDC系统能灵活适配多方案的关键。2.3 权限体系与稽查轨迹临床数据系统的权限管控和普通业务系统不太一样它要满足ALCOA原则可归属、易读、同步、原始、准确、完整、一致、持久、可获得。用户权限至少分为四类角色数据录入员通常由研究中心的研究者或CRC担任、数据管理员DM、监查员CRA、系统管理员。CRA的账号权限特别敏感要能查看和质疑数据但绝不能直接编辑数据这在设计上属于硬性约束。稽查轨迹设计上不要只记录“谁在什么时候改了数据”还要记录修改前后的值、修改原因、审批状态。换句话说EDC里的数据不搞“物理删除”所有版本的变更都沉淀在Audit Table里。这样监听查员顺着时间线能还原出任何一个字段的完整演变过程。3. 技术架构与核查、质疑模块实现3.1 技术选型为什么选这套组合技术栈方面考虑到EDC系统属于典型的企业级Web应用对稳定性、可维护性和跨平台兼容性要求高我建议采用成熟稳定、社区生态好的主流组合后端用Java Spring Boot或Python FastAPI均可前端用Vue 3 Element Plus数据库用PostgreSQL缓存用Redis文件存储用MinIO或阿里云OSS。这套组合的好处是招人容易、踩坑资料多、部署成本可控临床研究机构通常不是互联网大厂没必要引入太冷门的框架增加运维负担。以我自己实际落地的一套代码为例后端是Spring Boot 3.x前端是Vue 3 TypeScript。后端按模块分包每个业务模块有Controller、Service、Mapper三层接口风格统一RESTful权限统一走JWT RBAC。这套结构不花哨但胜在清晰团队里任何一个开发接手都能快速找到代码位置。数据库选PostgreSQL而不是MySQL的一个原因是EDC系统有大量“范围查询时间戳排序”操作PostgreSQL对复杂查询的优化和JSON类型支持更成熟。长表结构里一个Subject的所有字段值跨上千行查询在PostgreSQL上配合索引可以做到毫秒级这个性能体验至关重要——研究者在医院里录入数据等三秒才出结果体验基本算是不可用。3.2 逻辑核查引擎系统好用的灵魂逻辑核查Edit Check是EDC系统里“含金量”最高的模块也是最能体现研发经验的地方。它的目的是在数据录入或保存时自动执行预设的核查规则发现可疑数据后立即给录入人员提示或发起质疑从源头卡住数据质量问题。核查规则怎么设计建议参考规则配置器模式规则配成“条件表达式触发动作”的结构系统内置一个规则解释器能解析“字段A大于180”或“字段B等于空且字段C等于1”这类逻辑表达式命中规则后自动生成一条质疑Query。表达式引擎内部可以用JEXL或QLExpress这类轻量级表达式框架前端用JSON传递规则配置后端解析执行。举个例子假设某肿瘤项目的生命体征表有一个规则收缩压SBP超过180或低于80时系统要自动发起质疑。这个规则在后端配置成类似这样的JSON{ ruleCode: VS_SBP_001, name: 收缩压异常值提醒, condition: OR(GT({{SBP}},180), LT({{SBP}},80)), action: CREATE_QUERY, message: 收缩压超出正常范围请复核确认, level: WARNING }这套引擎的好处有两点一是规则和代码完全解耦数据管理员在后台改动阈值不用研发介入二是同一套表达式规则可以用在多个场景保存时校验、提交时批量跑批、双录对比时自动核对一套引擎全覆盖。我实际测下来300条复杂规则跑一次全库扫描在10万行字段数据量下大约3~5秒完成完全可接受。3.3 质疑管理全流程状态流转质疑管理模块是EDC系统的“工单系统”。数据核查引擎发现问题、监查员或DM人工发现问题都会生成一条质疑研究中心的研究者/CRC收到质疑后需要在系统里回复说明必要时修改数据质疑处理完发起人确认关闭整个流程才算结束。质疑表至少要包含这些字段质疑编号、关联的受试者/访视/表单/字段、质疑类型系统自动/人工发起、优先级、质疑内容、发起人、接收人、回复内容、状态开放/已回复/已关闭、时间戳。状态流转要清晰我建议用状态机来控制未关闭的质疑在数据导出时应作为“待处理记录”一并导出方便数据管理层评估数据质量。这块最容易踩的坑是“质疑关闭后数据又被修改”导致问题复现但质疑链断了。我们的做法是质疑关联的字段一旦被修改系统自动把已关闭的质疑恢复到“待确认”状态并追加一条修改记录强制发起人重新审查。这个细节一开始没做数据清理时被DM追着反馈了好几次后来加上之后整个数据审查流程才闭环。4. 实操过程与核心环节实现4.1 一个最小可运行系统的落地路径如果你要从头搭建一套EDC系统最忌一上来就铺大摊子。我们第二次重构系统的时候定了一个“最小可用闭环”的落地原则两周时间搭出第一版跑通全流程。具体路径分四步第一步先搭基础框架。后端初始化Spring Boot项目集成PostgreSQL和Redis前端用Vue脚手架创建工程配置路由和登录页。这一周时间能把用户注册、登录、JWT鉴权跑通就行。第二步建立基础数据模型。落地Subject、Visit、Form、Field四张核心表和对应的CRUD接口。这一阶段重点吃透“长表结构”的增删改查逻辑尤其是按SubjectVisitForm维度聚合字段值返回给前端渲染表单。第三步实现配置化表单渲染。配置端提供Field元数据管理页面录入端根据元数据动态渲染表单。前端拿到字段元数据数组按类型映射成Input、Select、DatePicker等组件同时根据必填、范围等规则做前端即时校验。第四步接入核查引擎和质疑闭环。基于表达式引擎落核查规则触发规则后生成质疑研发一个最简单的质疑列表和回复页面跑通“数据异常→质疑生成→研究者回复→数据修正→质疑关闭”的完整链路。4.2 核查规则配置与批量跑批实现核查规则不建议只在前端做校验。前端校验解决的是录入体验问题真正能保证数据质量的是后端和批量跑批机制。实际业务里研究者不会一次把所有数据填完往往是分多次录入每一次保存都需要做即时核查数据管理层在固定时间节点比如每周也会对存量数据做一次全量跑批看看有没有漏网之鱼或新方案规则下被标记的历史数据。批量跑批的实现比即时校验复杂一些因为要考虑“跑批生成的质疑不能对同一条数据重复创建”。我们的做法是给质疑表加一个规则快照标识字段rule_version跑批时记录本次使用的规则版本已存在同版本同字段同规则编号的开放质疑时不再新建质疑。这个幂等机制虽然简单但能有效避免重复质疑。跑批任务用Spring的定时任务框架Scheduled或Quartz触发批量拉取需要核查的字段数据逐条塞进规则引擎执行。这里有一个性能优化点批量跑批时不要每查一条数据就发一次SQL应该一次性按Subject维度批量加载某个访视的所有字段数据在内存里组装成一个Map再执行表达式规则这样能大幅减少数据库交互。4.3 源代码交付、代码审计与软著申请如果你拿到的是“提供完整源代码”这类交付需求代码质量评估和知识产权保护是绕不开的两件事。代码交付前至少要做一轮完整的代码审计。PHP项目可以先用seay源代码审计系统做一轮自动化扫描重点排查危险函数、SQL注入、文件上传漏洞、越权访问等常见问题Java项目可以用Fortify或SpotBugs再配合人工Code Review。我以前接过一个外包交付的EDC源码一开始只做了功能测试就收下了后来漏洞扫描发现了一个文件上传接口没做类型校验黑客可以直接上传Webshell这个如果上线了就是安全事故。源代码版本管理、变更记录和瞬时快照也很重要。做软件著作权登记的时候需要提交60页源代码前后各30页现在很多团队的做法是从Git仓库自动生成源代码PDF避免手工复制粘贴出错。Git标签打版时建议用一个固定脚本生成对应版本的源码快照保证软著材料里的代码和实际交付的代码版本一致。这套流程看似繁琐但在医疗信息化项目里是要走正规招投标和监管备案的代码不清白后面会有很多麻烦。5. 常见问题与排查技巧实录5.1 高频问题与避坑速查问题现象可能原因解决方案录入保存时提示“数据已被修改”长表结构并发写入了同一字段数据乐观锁版本号冲突给字段数据表加version字段UPDATE时带版本号判断某些访视表单加载特别慢大表单字段数量多且一次性关联查询了全量字段历史版本分页加载字段值历史版本延迟加载自动质疑重复生成跑批任务和保存时校验同时执行缺少幂等控制按“规则版本字段质疑状态”加唯一性校验导出数据里中文乱码CSV/Excel导出时未设置UTF-8 BOM头部导出时写入BOM或统一用XLSX格式导出数据被修改后质疑链断裂质疑关闭后字段又变更但系统未重新激活质疑字段变更钩子里检测到关联质疑重置为待确认状态5.2 两个最值得分享的实操心得第一个心得是数据空白原因Blank Reason一定要单独设计不能简单用Null表示缺失。临床数据里“没做这个检查”和“做了但结果没出来”和“正常但没记录下来”在临床意义上是完全不同的FDA核查时也要求明确区分。我们系统里每个字段值旁边都带一个空白原因标记ND/NP/NA这个细节让数据审核阶段省了不知道多少来回沟通。第二个心得是SDTMStudy Data Tabulation Model导出映射要提前规划不要等数据采完再想。SDTM是向FDA提交临床数据的标准格式EDC系统导出的数据最终要转换成SDTM数据集。很多项目在这步全靠手工Mapping费时费力还容易错。我们开发了一套简单的Mapping配置工具运营人员可视化配置“EDC字段→SDTM变量”的映射关系保存后自动生成SAS或CSV文件。提前做好Mapping配置数据锁库后导出SDTM基本可以做到一键生成光这个功能就能让数据管理团队加班量减半。再分享一点数据双录Double Data Entry的经验。现在国内很多项目已经不再强制双录但有部分申办方出于数据质量考虑仍然会要求。系统实现双录不要做成两个完全独立的录入界面这样第二遍录入的工作量翻倍。更好的方案是“独立录入自动比对”两个人各自录入一次系统在后台比对两个版本不一致的字段高亮显示并生成质疑由Senior Data Manager仲裁。这样做既保留了双录的质量优势又不会让人重复劳动到崩溃。最后再提一句EDC系统这类临床研究软件本质上是“医疗数据合规”三件事的交叉。源代码再完整如果不懂临床业务的合规约束做出来也只是个“看起来像EDC的管理系统”。把这套代码真正用好建议先从一两个中小型项目试点跑起来把建库规范、核查规则配置、质疑流转流程在真实项目中磨一遍再逐步扩展到更多方案。技术问题都好解决真正需要积累的是对临床数据质量的敬畏心。本文还有配套的精品资源点击获取