基于Java与大数据分析的远程糖尿病随访系统设计与实现

简介：这套源码基于Java与大数据分析，构建了一个面向糖尿病患者的远程医疗随访系统，适合医疗信息化开发者、Java后端工程师以及慢病管理研究者学习和二次开发。系统将大数据分析融入日常随访流程，帮助医护人员远程掌握血糖、用药与生活习惯等指标，提升慢性病管理效率。压缩包共包含201个文件，大小51.43MB，核心为136个Java源文件，覆盖WebSocket通信、医疗档案、认证鉴权、日志处理等功能模块；另有36个XML配置，以及若干properties、YAML和PNG图标资源，便于部署调优。包内还附带5篇PDF研究文献和xmind等文档，参考了智慧家医、人工智能语音随访等方向的实践。该资源目前已有347人学习下载，既能作为毕业设计或课程项目的完整参考，也能帮助开发者掌握从数据采集到智能随访的完整技术链路。

1. 基于 Java 与大数据分析的远程糖尿病医疗随访系统设计源码：先说清它解决什么，再看值不值得做

糖尿病管理真正难的不是开药，而是出院后到下次复诊之间的“随访真空期”：血糖数据散在血糖仪、手机 App 和病历里，医生看不到趋势，也无法在血糖连续偏高时及时干预。这套基于 Java 与大数据分析的远程糖尿病医疗随访系统设计源码，把这条流程搬上线：血糖自动上报、后端存储、分析程序做趋势与风险分层，最后按规则生成随访任务触达医患两端。

技术形态很清晰：Spring Boot 负责患者档案、血糖接收、随访计划，大数据分析模块负责血糖趋势、指标统计和风险评分，再把分析结果反向喂给随访规则。适合有 Java 基础的毕设或课程设计学生，也适合医疗信息化公司里想快速补一个慢病随访模块的初级工程师。它的价值不在算法多深，而在于把“数据采集到随访闭环”完整跑通。

2. 端到端架构怎么搭：血糖从上报接口到分析模块的完整链路

随访系统最容易做死的地方，是把所有代码堆在一个 Controller 里：上报、落库、发通知全同步做。血糖数据量不大时没问题，一旦接入几百个患者、每天几千条测量，同步链路就会拖慢接口、丢数据，还把后续分析任务堵死在业务进程里。下面按数据来源、选型、最小接口三层展开。

2.1 数据从哪来：血糖仪、手机 App、医院 HIS 三路来源怎么统一

三路采集的接入方式差别很大，但落到业务侧必须归一成同一套结构。

• 智能血糖仪：现在主流血糖仪基本都带蓝牙或 GPRS 模块，测量完自动上传厂商云，厂商通过 HTTP 回调把结果推给医院系统；也有设备网关走 MQTT 上报，由服务端订阅。
• 手机 App：患者手动录入，或者 App 通过蓝牙读血糖仪后调后端接口，一般是 JSON over HTTP。
• 医院 HIS：糖化血红蛋白、空腹血糖这类检验结果在院内系统里，通常不做实时推送，而是每天定时增量同步，数据格式也更杂。

统一后的结构我一般固定这几个字段，后面所有分析和随访逻辑只依赖这一套结构：

三路数据里，血糖仪回调实时性最好，HIS 最稳定但最慢。统一结构的意义在于，不必为每个数据源写一套分析分支，分析模块只认 patientId、血糖值、测量时间和测量类型这四个核心字段。

2.2 技术选型：为什么是 Spring Boot + MySQL + Redis + Kafka，而不是微服务全家桶

我见过不少团队，项目初期就照着网上的架构文章上一套 Spring Cloud 全家桶，服务拆了七八个，最后查一个血糖列表要跨三个服务。这套系统覆盖的是一个地区医院或一个科室的随访场景，患者几千人、每日血糖数据几万条，这个量级下的务实选择是 Spring Boot 单体应用加中间件，而不是微服务。

• Spring Boot 3.x 单体应用：所有随访业务在一个工程里，部署就是一个 fat jar，运维成本低。先把业务闭环跑通，再谈拆分。
• MySQL 8.x：主库存患者、血糖、随访计划、随访记录。血糖数据按年百万级，配合索引完全扛得住。
• Redis：存登录态、接口幂等键、随访计划短期缓存。
• Kafka（或 RocketMQ）：血糖上报和落库分析之间的解耦通道。选 Kafka 是因为后续数据分析也要消费同一份实时数据，多个消费组天然支持。
• 定时任务：用 Spring 自带的 @Scheduled 或 XXL-Job，每天凌晨做离线聚合，生成前一天的血糖统计。

ORM 这层用 MyBatis-Plus 而不是 JPA，理由很实际：医疗统计 SQL 长且复杂，MyBatis 方便写自定义 SQL；MyBatis-Plus 能从实体类直接配出建表语句，演示项目里能省不少活。很多人纠结要不要读 MyBatis 源码，我的看法是先把 SQL 写对、映射配明白，源码是后话。这套选型逻辑其实也是 Java 面试题里系统设计题的标准答法：先讲业务量级，再讲组件角色，最后讲为什么不上微服务。

2.3 最小可跑通的血糖上报接口：同步接口加异步队列

上报接口的设计原则是：只负责接收和校验，不做重活。Controller 收下数据，Service 做幂等判断后投递消息队列，落库和分析都在消费端做。

@RestController @RequestMapping("/api/glucose") public class GlucoseReportController { private final GlucoseReportService reportService; public GlucoseReportController(GlucoseReportService reportService) { this.reportService = reportService; } @PostMapping("/report") public Result<Void> report(@RequestBody @Valid GlucoseReportRequest request) { // 上报接口只负责两件事：参数校验、提交给业务层 reportService.submit(request); return Result.success(); } }

Controller 不做业务判断，直接交给 Service。血糖上报的并发量不高，但胜在持续，接口响应时间必须稳定。

@Service public class GlucoseReportService { private final StringRedisTemplate redisTemplate; private final KafkaTemplate<String, String> kafkaTemplate; public GlucoseReportService(StringRedisTemplate redisTemplate, KafkaTemplate<String, String> kafkaTemplate) { this.redisTemplate = redisTemplate; this.kafkaTemplate = kafkaTemplate; } public void submit(GlucoseReportRequest request) { // 幂等：同一患者同一测量时间只处理一次，防设备重传和接口重试 String idempotentKey = "glucose:report:" + request.getPatientId() + ":" + request.getMeasureTime(); Boolean first = redisTemplate.opsForValue().setIfAbsent(idempotentKey, "1", Duration.ofMinutes(5)); if (Boolean.FALSE.equals(first)) { throw new BusinessException("重复上报，请勿重复提交"); } // 转成统一结构投递到消息队列，落库和分析在消费端做 GlucoseMessage message = GlucoseMessage.of(request); kafkaTemplate.send("glucose-report-topic", message.getPatientId().toString(), JSON.toJSONString(message)); } }

这个接口故意把落库和分析全部放到消费端。原因有三个：一是上报接口响应时间不受数据库写盘拖累；二是血糖是典型的写多读少数据，消费端批量写入比逐条插入性能好；三是数据分析模块直接消费同一份消息流，业务系统不用给分析模块单独开接口。

参数说明：幂等键过期时间设 5 分钟而不是永久。设备重传通常集中在同一分钟内，5 分钟足够拦截；设永久的话，患者同一天同一时间点真的补测两次会被误拦。measureTime 必须带时区，无时区的 “yyyy-MM-dd HH:mm:ss” 在跨服务器部署时一定会出问题。kafkaTemplate.send 的第二个参数传 patientId 作为 key，是为了让同一个患者的消息落进同一分区，消费端处理时顺序有保障。

消费端做的事就是插 glucose_record 表，再做一次实时阈值判断触发异常预警。Kafka 消费端挂了，消息会保留在 topic 里，恢复后补跑，这比同步落库稳妥得多。

3. 用 Spring Boot 把随访闭环做出来：模板、计划、提醒与回填

数据能进来只是第一步。糖尿病随访系统的核心价值在于，把“医生凭记忆随访”变成“系统按规则提醒医生和患者”。这个闭环由四个环节组成：随访模板配置、核心表结构、规则引擎、定时任务触达。

3.1 随访模板先行：把医生的习惯转成可配置规则

随访不能拍脑袋。血糖控制差的患者应该三天一次电话，控制好的患者两周一次推送，刚出院的患者第 3 天必须首次随访。这些规则如果硬编码在业务代码里，医生每次改方案都要发版，根本不可维护。

常见做法是设计一张随访模板表，把“什么条件、什么频率、用什么方式触达”参数化。模板核心字段包括：

• template_name：模板名，比如“血糖控制差高优随访”
• 触发条件：近 7 天平均血糖大于 11.1 且波动系数大于 0.3
• 随访频率：每 3 天 / 每周 / 每 2 周
• 触达方式：电话、App 推送、短信
• 模板状态：启用 / 停用

模板和患者是多对多关系，一个患者可能同时命中多个模板，所以需要一张患者随访方案表记录当前生效的模板组合，而不是在患者表上挂一个字段。这个设计决定了后期医生调整随访策略时，只需要改模板配置，不需要动代码。

3.2 核心表结构：患者、血糖记录、随访计划、随访记录四张表

建表是整套系统最值得花时间的部分。下面这四张表覆盖随访闭环的主链路：

-- 患者表：只保留随访关心的关键字段 CREATE TABLE patient ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, gender TINYINT COMMENT '1男 2女', birth_date DATE, phone VARCHAR(20), doctor_id BIGINT NOT NULL COMMENT '主治医生', diagnosis_type TINYINT COMMENT '1型/2型/妊娠期/其他', status TINYINT DEFAULT 1 COMMENT '1在组 0已退出', created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL ); -- 血糖记录表：只增不改 CREATE TABLE glucose_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, patient_id BIGINT NOT NULL, glucose_value DECIMAL(5,2) NOT NULL COMMENT 'mmol/L', measure_type TINYINT NOT NULL COMMENT '1空腹 2餐后2h 3睡前 4随机', measure_time DATETIME NOT NULL COMMENT '统一东八区', source TINYINT COMMENT '1血糖仪 2App 3HIS', device_id VARCHAR(64), created_at DATETIME NOT NULL, KEY idx_patient_time (patient_id, measure_time) ); -- 随访计划表：每次随访任务一行 CREATE TABLE followup_plan ( id BIGINT PRIMARY KEY AUTO_INCREMENT, patient_id BIGINT NOT NULL, template_id BIGINT NOT NULL COMMENT '来自随访模板', plan_date DATE NOT NULL COMMENT '计划执行日期', status TINYINT DEFAULT 0 COMMENT '0待执行 1已完成 2已逾期 3已取消', remark VARCHAR(255), created_at DATETIME NOT NULL, KEY idx_plan_date_status (plan_date, status) ); -- 随访记录表：医生实际执行后的回填 CREATE TABLE followup_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, plan_id BIGINT NOT NULL, patient_id BIGINT NOT NULL, doctor_id BIGINT NOT NULL, contact_way TINYINT COMMENT '1电话 2App推送 3短信 4门诊', result TINYINT COMMENT '0未接通 1已沟通 2需转诊 3已住院', summary VARCHAR(1000) COMMENT '随访小结', created_at DATETIME NOT NULL, KEY idx_patient (patient_id) );

建表说明：glucose_record 不设 update_time，业务上也不提供修改接口。血糖是客观测量数据，一旦被改，后续统计和随访判断全部失真。真发现录错了，做法是作废原记录、新增一条正确记录，而不是原地 update。idx_patient_time 联合索引是这四张表里最重要的索引，按患者、按时间段的查询全靠它。followup_plan 的 idx_plan_date_status 专门服务定时任务：每天早上扫“今天到期且待执行”的计划，条件就是 plan_date 加 status。

临床上还有一个行级权限需求：医生只能看自己名下患者的血糖和随访记录。实现上所有核心查询强制带 doctor_id 条件，或者做一个数据权限拦截器统一加条件，这个在源码实现里最容易漏，漏掉就是数据越权事故。

3.3 策略模式写随访规则引擎：把 if-else 拆成可插拔规则

如果随访判断写成 20 行 if-else，前三个月还能改，半年后没人敢动。我习惯把规则拆成策略模式：每个规则一个类，满足条件就返回建议动作，不满足就 pass，调度器统一收集结果，取最高优先级执行。

public interface FollowupRule { // 每个规则根据患者的统计画像决定是否需要发起随访 FollowupAction evaluate(PatientProfile profile, GlucoseStat stat); } // 高风险规则示例：近7天平均血糖过高且波动大 @Component public class PoorControlRule implements FollowupRule { private static final double AVG_THRESHOLD = 11.1; @Override public FollowupAction evaluate(PatientProfile profile, GlucoseStat stat) { if (stat.getAvg7d() > AVG_THRESHOLD && stat.getCoeffVar7d() > 0.3) { return FollowupAction.of(Frequency.THREE_DAYS, Channel.PHONE, RiskLevel.HIGH, "近7天血糖均值偏高且波动大，建议3天内电话随访"); } return FollowupAction.pass(); } }

调度器负责汇总所有规则结果：

@Service public class FollowupRuleDispatcher { private final List<FollowupRule> rules; public FollowupRuleDispatcher(List<FollowupRule> rules) { this.rules = rules; } public FollowupAction dispatch(PatientProfile profile, GlucoseStat stat) { return rules.stream() .map(rule -> rule.evaluate(profile, stat)) .filter(FollowupAction::isActive) .max(Comparator.comparingInt(a -> a.getRiskLevel().getCode())) .orElse(FollowupAction.pass()); } }

Spring 会把所有实现 FollowupRule 的 Bean 自动注入到 List 里，新增一条规则只需要新写一个实现类，调度器不用改。这是策略模式在业务规则里的典型用法。

参数说明：AVG_THRESHOLD 设 11.1 mmol/L，对应空腹血糖诊断阈值上方；波动系数用标准差除以均值，大于 0.3 认为波动显著。调度器取最高风险等级动作而不是全部执行，避免同一个患者被多个模板重复触达。

3.4 定时任务把计划变成触达：扫描到期计划并通知

规则引擎生成的是未来的随访计划，定时任务负责把计划变成实际的人与人的联系。

@Component public class FollowupRemindJob { private final FollowupPlanMapper planMapper; private final PushService pushService; @Scheduled(cron = "0 30 9 * * ?") public void scanTodayPlans() { // 每天早上9点扫一次当天待执行的随访计划，生成提醒 List<FollowupPlan> plans = planMapper.selectTodayPending(); for (FollowupPlan plan : plans) { pushService.notifyDoctor(plan.getDoctorId(), plan.getPatientId()); pushService.notifyPatient(plan.getPatientId(), "今日随访"); } } }

逻辑说明：cron 表达式0 30 9 * * ?表示每天 09:30:00 执行，放在上午而不是凌晨，是不想在休息时间打扰患者。通知医生端“今天要电话随访了”，患者端“请留意医生来电或消息”。医生完成随访后回填 followup_record，再把 followup_plan 的状态改成已完成，并依据规则生成下一次计划，这才算闭环。

参数说明：cron 六个位置分别是秒、分、时、日、月、周。很多新手会写0 0 9 * * *，把周几位置漏掉导致计划不执行。上线前用在线 cron 工具验证一下，别凭记忆写。

4. 大数据分析在系统里真正落地的三件事：趋势、分层与预警

标题里的大数据分析最容易被做成摆设：建几个宽表、跑几条 SQL 就算分析了。先明确一点，这个量级的随访系统不会上 Hadoop 和 Spark 集群，它的大数据分析指的是对血糖时序数据的批量聚合、风险分层与实时预警，核心是数据处理方法，不是分布式框架表演。

4.1 离线分析与实时分析怎么分工：定时任务算历史，消息队列算实时

两种分析边界必须分开，否则会互相干扰。

离线分析也就是 T+1 统计，每天凌晨跑定时任务，算每个患者前一天、前 7 天、前 30 天的血糖统计指标，写入 patient_glucose_stat 表。这些指标是随访规则引擎做风险判断的输入。

实时预警在 Kafka 消费血糖消息时进行，对单条测量值做阈值判断。血糖低于 2.8 mmol/L 或高于 16.7 mmol/L 属于危险值，立即推送医生和家属，不等到第二天统计。

为什么不全部实时算？因为“趋势”这个概念必须基于一段时间的区间聚合，实时算既浪费资源，跨天边界也难处理。T+1 统计加实时阈值，是成本最低、效果最稳的组合。

4.2 用 SQL 直接算出血糖管理核心指标：均值、TIR、波动系数

这一节给出每日定时任务里最核心的一段 SQL。TIR 即 Time in Range，指血糖处于 3.9 到 10.0 mmol/L 范围内的时间占比，是近两年糖尿病管理指南里最被强调的指标。

-- 患者近30天血糖统计，由每日定时任务写入 patient_glucose_stat SELECT patient_id, COUNT(*) AS measure_count, ROUND(AVG(glucose_value), 2) AS avg_glucose, ROUND(STDDEV(glucose_value), 2) AS sd_glucose, ROUND(SUM(CASE WHEN glucose_value BETWEEN 3.9 AND 10.0 THEN 1 ELSE 0 END) / COUNT(*) * 100, 2) AS tir_30d, ROUND(SUM(CASE WHEN glucose_value > 13.9 THEN 1 ELSE 0 END) / COUNT(*) * 100, 2) AS high_ratio_30d, ROUND(SUM(CASE WHEN glucose_value < 3.9 THEN 1 ELSE 0 END) / COUNT(*) * 100, 2) AS low_ratio_30d FROM glucose_record WHERE measure_time >= DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY patient_id;

逻辑说明：STDDEV 表示标准差，反映血糖波动幅度。糖尿病管理里，血糖均值控制好只完成了一半目标，波动大同样增加并发症风险，所以波动系数要作为风险特征单列。TIR 越高越好，高血糖占比和低血糖占比越低越好。

参数说明：3.9 到 10.0 是 TIR 的标准目标区间，有些指南用更严苛的 3.9 到 7.8。这个区间应该做成配置项，不要写死在 SQL 里。CURDATE() 取的是数据库时区当天，这正是下面第五章要详细展开的时区坑的根源之一。

4.3 风险分层：先跑线性加权评分，暂时别上机器学习

统计指标算出来后，需要转成每个患者的风险等级。这里用一个线性加权评分，不引入机器学习。

public class RiskScoreCalculator { // 三个维度加权，总分 0~100，越高越危险 public int calc(GlucoseStat stat) { int score = 0; // TIR 越低分越高，占 40 分 double tirScore = 40 * (1 - stat.getTir30d()); // 高血糖占比占 30 分 double highScore = Math.min(30, stat.getHighRatio30d() * 1.5); // 低血糖占比占 30 分，低血糖更危险，权重略微放大 double lowScore = Math.min(30, stat.getLowRatio30d() * 2.0); score = (int) Math.round(tirScore + highScore + lowScore); return Math.min(100, score); } }

为什么先不上机器学习？三个现实原因：一是数据量不够，单中心几百上千个患者撑不起像样的训练集；二是医疗场景需要可解释性，医生说得出“为什么给这个患者高优先级”，比模型 AUC 高 0.02 重要得多；三是合规要求。医疗场景最忌讳把风险判断交给黑匣子，线性加权模型已经能把高风险患者优先捞出来，机器学习是数据积累到一定程度以后的事。

参数说明：tirScore 用 1 - tir 做正向映射，tir 是 0 到 1 的小数，TIR 越低风险分越高。低血糖占比权重 2.0 高于高血糖占比的 1.5，因为严重低血糖会直接危及生命，优先干预的优先级更高。

分层结果写入 risk_level 字段，供随访规则引擎读取决定计划周期：0 到 30 分低风险，每两周随访；31 到 60 分中风险，每周随访；61 到 100 分高风险，三天随访。

注意：风险分层的阈值直接决定随访频次，上线前必须和临床医生确认一遍，不要拿网上的参数直接照抄。阈值对医疗资源占用和患者体验影响很大。

5. 部署与上线最容易踩的 5 个坑：从时间错乱到慢 SQL 的血泪实录

这一章的每一条都是医疗项目里反复出现的真实问题。血糖、体温这类时序数据系统，最怕的就是时间错、数据被改、查询越来越慢。下面 5 个坑按优先级排，基本覆盖这套系统上线头一个月容易翻车的点。

5.1 时间戳全错位：跨天指标为什么一夜之间全翻车

现象：患者早上 8 点测的空腹血糖，页面显示下午 4 点才入库，TIR 的分天统计全部错乱，医生开始质疑系统准确性。

原因：三处时区不一致叠加。前端传的是无时区的yyyy-MM-dd HH:mm:ss；服务器是 UTC 时区；MySQL 连接串没配 serverTimezone，JDBC 又按本地时区解析了一次，数据就被平移了好几个小时。

解决：统一时区链，缺一环都不行。

# JVM 启动参数固定时区 java -Duser.timezone=Asia/Shanghai -jar followup-server.jar # MySQL 连接串显式声明时区 jdbc:mysql://127.0.0.1:3306/diabetes?serverTimezone=Asia/Shanghai&useSSL=false

同时接口层统一接收 ISO8601 带时区字符串。我的习惯是后端全部按东八区解释，前端传什么格式，后端先解析出时区信息再转成规范格式落库。这套系统不涉及跨时区患者，统一东八区足够，但一定要显式配置，不能依赖服务器默认值。时区翻车通常是上线几天后跨天统计跑出来才暴露，排查成本远高于配置成本。

5.2 随访列表越查越慢：三个缺索引的场景

现象：系统上线一个月后，患者详情页打开要 3 到 5 秒，随访逾期列表翻页越来越卡。

原因：glucose_record 有数万条记录后，按 patient_id 加时间段查询走全表扫描；followup_plan 按 plan_date 扫描也没索引；分页还用了LIMIT 100000, 10这种大 offset，越往后翻越慢。

解决：glucose_record 建联合索引idx_patient_time (patient_id, measure_time)；followup_plan 建idx_plan_date_status (plan_date, status)；分页改成游标式，记录上一页最后一条 id，下一页用WHERE id > ? ORDER BY id LIMIT 10。

排查方法是在大 SQL 前面加 EXPLAIN，重点看 type 和 rows：type 为 ALL 说明全表扫，rows 上万就必须处理。这种慢 SQL 在测试阶段数据量小发现不了，属于典型的“数据量上来才暴露”，所以建表时就要把索引一次建对。

5.3 凌晨分析任务把业务库打满：任务隔离与读写分离

现象：每天凌晨 1 点大数据分析任务跑完，第二天上午业务页面卡得不行。

原因：分析 SQL 直接在主库上跑大聚合，几十万行血糖记录 GROUP BY，把数据库 CPU 和 IO 打满，业务高峰正好撞上。

解决：分析任务连从库跑，配置读写分离，分析查询走只读实例；定时任务分批处理，每批 500 个患者，批间加小延迟，不要一把梭；聚合结果写入独立分析结果表，业务查询读结果表而不是直接跑聚合。

这个问题的根源是分析任务和业务查询共用数据库资源。分析任务应该是一个独立的应用模块，有自己的配置和数据库连接池，不要和线上业务代码混在一起。如果是单机部署，至少要把定时任务的执行时间错开业务高峰，优先级最低。

5.4 半夜批量推送把患者手机推炸了：消息积压与重复消费

现象：某天凌晨 4 点，几百个患者同时收到随访短信，同一患者收到 3 条重复推送。

原因：定时任务扫描“待执行”计划后把提醒消息投到 MQ，消费端处理超时触发 Kafka 重试，导致同一消息重复消费；定时任务本身也没有幂等控制，下一个批次又把同一批计划扫了一遍。

解决：提醒投递前先检查同一 plan 当天是否已经产生过提醒，用 followup_remind_log 表加唯一约束；定时任务扫描状态加乐观锁，处理中的计划先更新状态再发提醒；推送时间窗口限制在白天，cron 表达式里不要写凌晨时段。

消费者侧必须做幂等：同一个 plan_id 同一天的提醒记录，数据库唯一索引一插就报错，捕获后跳过。不做幂等，MQ 每重试一次，患者就多收一条消息，这在医疗场景里会直接损害信任。

5.5 血糖记录被误改：为什么这条要单独拿出来说

现象：护士在后台把一条血糖记录改成正常值，后续所有统计和风险分层全部出现偏差，最后靠查 binlog 才定位到修改记录。

原因：后台管理页面提供了血糖记录的编辑功能，update 权限没有收紧。血糖是客观测量数据，一旦可以被随意修改，统计结果、随访判断、诊断参考全部失真，还涉及数据审计合规。

解决：血糖记录表只提供 insert，不提供 update 和 delete 接口；录错的场景走“作废 + 新增”流程，把原记录状态置为作废，再写入一条正确记录；所有变更写审计日志，记录操作人、操作时间、变更前后内容。

这一点在医疗信息化项目里不是可选项，是底线。实现成本很低，但很多团队会忽略，直到数据出了偏差才回来补。

6. 上线前必须做的一次全链路演练：用模拟血糖数据把系统跑透

这套系统链路长，最容易出问题的不是单点功能，而是数据进来后到底有没有按预期流动。我上线的习惯是：先用模拟数据灌一个月的量，把实时预警、T+1 统计、风险分层到随访计划生成整条链路跑一遍，确认无误再连真实数据。这一步能省掉上线后大量返工时间。

模拟数据不要随机到底。里面要有不同风险分布：70% 平稳患者、20% 偏高患者、10% 含危险值患者，这样才能测出风险分层和预警有没有起作用。

import random from datetime import datetime, timedelta start = datetime(2025, 1, 1, 8, 0) with open("sim_glucose.csv", "w", encoding="utf-8") as f: f.write("patient_id,glucose_value,measure_type,measure_time,source\n") for day in range(60): for pid in range(1, 51): t = start + timedelta(days=day) roll = random.random() if roll < 0.7: # 平稳：大多数在 4.5~8.5 之间波动 value = round(random.uniform(4.5, 8.5), 1) elif roll < 0.9: # 偏高：9.0~13.5，用来触发高风险规则 value = round(random.uniform(9.0, 13.5), 1) elif roll < 0.95: # 危险低血糖 value = round(random.uniform(1.5, 2.8), 1) else: # 危险高血糖 value = round(random.uniform(16.5, 22.0), 1) f.write(f"{pid},{value},1,{t.isoformat()}+08:00,1\n")

生成 60 天乘 50 个患者共 3000 条记录，导入后验证四个点。

第一，实时预警。脚本里 5% 的危险值记录应该在上报后几秒内出现在预警列表。没出现就先查 Kafka 消费端有没有把预警逻辑执行到。第二，T+1 统计。核对 patient_glucose_stat 表里每个患者的 tir_30d 是否和手工计算一致，重点核对跨月边界和时区偏移。第三，风险分层。运行随访规则引擎，预期偏高组分配到三天或一周随访，平稳组是两周。分层结果和输入数据对不上，优先查规则阈值。第四，随访计划生成。高风险患者应自动生成对应频次的 followup_plan，再检查提醒任务有没有重复生成计划。

我习惯把这套模拟数据生成和校验脚本放进项目 tools 目录，每次改完随访规则或分析逻辑就跑一遍，比上线后翻车再回滚省得多。这套系统源码的正确读法也类似，不是从头读到尾，而是先跑起来、灌入模拟数据、打断点跟着一条血糖记录从上报走到随访计划生成，整条链路理解了，项目才算真正拿下了。医疗随访系统最忌讳带着没验证过的逻辑上线，希望帮到你。

本文还有配套的精品资源，点击获取