宠物医疗是宠物赛道里专业壁垒最高的一类：它既受行业规范约束（处方、诊疗记录），又有医疗行业特有的流程（接诊、检查、处置、复诊）。本文讨论宠物医院小程序的服务端设计，聚焦病历结构化、处方合规与疫苗提醒三个点，示例基于 MySQL 8 + Java。
一、病历为什么必须结构化
很多宠物医院的第一版系统把病历做成一个大文本框，医生随手记。短期看省事，问题在后面浮现：复诊时上次的用药剂量查不清、多医生接诊时交接靠问、运营想统计"犬细小治愈率"时无从下手。
结构化的思路是拆层：就诊单（visit）+ 处置项（treatment）+ 医嘱（advice），自由文本只保留"病史描述"一个字段，其余全部结构化：
CREATE TABLE visit ( id BIGINT PRIMARY KEY AUTO_INCREMENT, hospital_id BIGINT NOT NULL, pet_id BIGINT NOT NULL, owner_id BIGINT NOT NULL, doctor_id BIGINT NOT NULL, visit_type TINYINT NOT NULL COMMENT '1初诊 2复诊 3体检 4免疫', chief_complaint VARCHAR(500) COMMENT '主诉', history_text VARCHAR(1000) COMMENT '病史（自由文本）', weight_kg DECIMAL(5,2) COMMENT '体重', temperature DECIMAL(4,1) COMMENT '体温', status TINYINT NOT NULL DEFAULT 1 COMMENT '1就诊中 2已完成', visited_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_pet (pet_id, visited_at), KEY idx_doctor (doctor_id, visited_at) ); CREATE TABLE treatment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, visit_id BIGINT NOT NULL, item_type TINYINT NOT NULL COMMENT '1检查 2用药 3手术 4处置', item_id BIGINT NOT NULL COMMENT '对应项目/药品/检查单id', item_name VARCHAR(100) NOT NULL, dosage VARCHAR(60) NULL COMMENT '用量用法', qty DECIMAL(10,2) NOT NULL, price INT NOT NULL COMMENT '单价，分', KEY idx_visit (visit_id) );
设计要点：treatment 冗余了 item_name 和 price，因为项目价格会调、名称会改，病历必须定格在就诊那一刻的事实。这一点和电商订单冗余商品快照是同一个道理。
体重字段单独强调：宠物用药剂量按体重计算，weight_kg 是病历里的安全数据，每次就诊必录，给药模块校验"剂量是否在体重对应的安全区间"时依赖它。
二、处方合规：谁开、开了什么、能不能改
宠物诊疗行业对处方的要求在趋严：处方应由执业兽医师开具、留存备查。系统层面要做的不是复杂功能，而是三个硬约束：
开方人必须是医生角色，且操作留痕（谁、什么时间、开了什么）。这要求处方单和 visit 关联且记录 doctor_id，与操作人是同一人校验——前台代开处方是审计里最常见的问题。
处方内容不可直接修改，只能退方重开。修改历史处方等于篡改医疗记录，正确做法是已有处方置为"已撤销"（记录撤销原因），新建一张处方单关联原就诊。撤销不是删除，数据永远在。
药品发药扣库存与处方绑定，发药记录独立于处方单：
CREATE TABLE prescription ( id BIGINT PRIMARY KEY AUTO_INCREMENT, visit_id BIGINT NOT NULL, doctor_id BIGINT NOT NULL, rx_no VARCHAR(32) NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT '1已开 2已发药 3已撤销', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_rx (rx_no) ); CREATE TABLE dispense ( id BIGINT PRIMARY KEY AUTO_INCREMENT, rx_id BIGINT NOT NULL, drug_id BIGINT NOT NULL, batch_no VARCHAR(40) NULL COMMENT '批次，追溯用', qty DECIMAL(10,2) NOT NULL, dispensed_by BIGINT NOT NULL, dispensed_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_rx (rx_id) );
batch_no 记录发药批次是行业特有的要求：兽药召回按批次进行，没有批次记录，召回通知来了只能全库人工排查。
三、疫苗提醒：不是发消息那么简单
疫苗驱虫提醒是这个系统里使用频率最高的功能，实现上有三个容易忽略的点。
提醒基准是"接种记录"而不是"订单"。免疫就诊可能有体检、挂号等附加项目，提醒周期要挂在疫苗制品的免疫周期上（狂犬一年、四联/八联按制品说明），不同制品周期不同，提醒规则关联制品档案而不是就诊单。
提醒要幂等且可取消。同一只宠物同一针疫苗，提醒发一次就够；主人已在别处补种，要在提醒上提供"已完成/不再提醒"操作，点过之后这条周期不再触发。没有取消入口的提醒，用户屏蔽的是整个小程序的订阅消息授权——配额就废了。
订阅消息配额管理。微信订阅消息一次授权只发一条，疫苗提醒是按年触发的低频场景，配额天然紧张。策略是在免疫就诊完成页请求授权（此刻用户意愿最强），同时把"即将到期"的名单同步给前台，前台电话回访兜底。把提醒完全押在消息推送上，覆盖率达不到预期。
检验与影像的关联也值得一提。血常规、生化、DR 片子是宠物医疗的高频检查，检验结果最好是独立建模为 report 表并挂到 visit 上：数值型结果（白细胞计数等）结构化存储并可划参考区间、超限标红；影像结果存对象存储地址加结论文本。复诊时医生调上次血检对比，是临床里最常用的动作，结构化数值才能做趋势对比（体重曲线、某指标三次变化），纯图片做不到。
费用透明是客户端的另一个重点。宠物医疗的客诉里"收费看不懂"占很大比例：检查费、药费、处置费混在一张小票上，主人分不清哪笔是哪笔。小程序里把就诊费用按 treatment 明细逐项展示，用药的单价、数量、用法并列，主人看完明细再支付。费用透明不能降低收入，但能显著降低"感觉被宰"的疑虑——疑虑才是流失的真正原因。
四、多医生协同与"转诊"语义
连锁宠物医院常遇到：初诊医生休班，复诊换了医生。结构化病历的价值在这里兑现——接诊医生打开就诊单，体重曲线、用药史、检验报告一屏可见。系统里再加一个轻量的"交接备注"字段挂在 visit 上，由前一位医生填写注意事项（如"该犬对某药物过敏，慎用"），这比让新医生翻全部历史记录可靠。
五、小结
宠物医疗系统的三条主线：病历结构化（处置项可统计、快照不可改）、处方合规（开方留痕、只撤不改、批次追溯）、提醒体系（挂制品周期、幂等可取消、订阅配额省着用）。医疗属性决定了这个系统"慢即是快"：宁可功能少一点，医疗记录的严谨性不能让步。青海青帝科技在本地宠物医疗类项目里，把"处方只撤不改"和"发药批次记录"列为验收硬指标，这两项在行业检查和纠纷处理中都是关键凭据。
