本文目录
先把预约资源与变更通知管理清楚
医疗预约平台首版应以已确认的机构服务范围为边界，处理科室、人员排班、号源、预约、取消和到诊记录。本文讨论预约软件流程，不涉及诊断建议；在线问诊、处方或其他医疗业务需要另外确认业务条件。
先明确预约服务与到诊状态
例如用户为家人预约某时段服务，需要区分操作账号、就诊人和预约记录。预约成功表示占用了号源，不表示已经提供医疗服务。
- 首版先选择门诊预约或体检预约一种明确业务。
- 验收示例：停诊后受影响预约进入改约处理，而不是继续显示可按时到诊。
与机构现有系统对接需先验证
HIS、排班、支付或患者主索引接口的可用性与授权会影响集成。不能因为对方有系统就默认有可直接调用的接口。
- 报价列明测试环境、字段映射、联调协调和数据更新频率。
- 用一次停诊事件验证新平台与机构系统谁负责最终号源状态。
预约数据与医疗记录分清范围
预约平台可能只保存时间、服务项目和状态，不必复制全部病历。具体记录以机构确认的数据范围为准。
- 交接预约字段、接口映射、同步日志和身份关联方式。
- 抽一笔改约记录，核对原预约、变更原因和最终到诊状态可追踪。
代预约不等于拥有全部记录权限
账号代家人预约时，需要按机构规则核验关系和身份。客服、前台和医务人员查看的字段应与职责一致。
- 对查询、导出和修改身份信息限制授权。
- 测试同一账号管理两名就诊人，不能把其中一人的记录混到另一人名下。
号源状态与收费结果分别确认
如果业务允许在线收费，要明确未付款占号时间、取消退费和原系统对账方式。费用是否收取、收取什么由机构确定。
- 支付超时但结果稍后成功时，由服务端核对真实结果再安排处理。
- 重复接收支付或取消事件，号源只释放一次，收费记录不重复。
停诊和改约需要明确处理结果
通知应提供日期、地点和下一步方式，避免在短信或推送中暴露不必要的就诊细节。机构仍需看到未完成改约的预约。
- 发送失败时转入工作人员跟进队列。
- 模拟停诊通知未送达，前台仍能逐笔处理受影响人员。
预约量和实际到诊量分开统计
取消、爽约、改约与到诊是不同状态。跨时段变更不应把一次服务重复计为多个到诊。
- 汇总尽量使用业务所需字段，个人信息按权限查看。
- 同一预约改两次日期，核对最终到诊量仍为一次。
先在测试号源中演练关键流程
使用合成就诊人资料验证预约、取消、号源耗尽、代预约和停诊，不以真实患者数据做公开演示。
- 机构负责人确认服务范围、账号权限及上线材料，提交前核对当期平台要求。
- 模拟最后一个号源被并发预约，最终只确认一个有效占用。
排班变更不能悄悄覆盖预约
人员调整或停诊应生成明确变更事件，并处理已有预约。接口中断时停止不可靠的可预约承诺，显示可执行的人工办理方式。
- 监测号源同步延迟、失败取消和身份匹配异常。
- 恢复同步后核对未结预约，不重复通知或释放已占用号源。
按职责限制敏感信息和日志
预约也可能包含个人敏感信息，日志、导出和备份要与正式访问权限一起设计。测试和演示使用脱敏或合成数据。
- 从读取、存储到备份明确责任人与允许范围。
- 使用无关科室或停用账号验证无法查询不属于其职责的数据。
需求讨论中的问题
可以把预约平台直接升级成在线问诊吗？
应另行评估服务主体、实际业务范围、平台要求与医疗系统责任。预约软件的技术能力不能代替开展医疗服务所需的条件。
号源被取消后应该立即放回吗？
要以机构确认的取消结果和号源规则为准。外部系统尚未确认取消时，不能先在本地重复放号。
带着这些资料讨论方案
可逐项勾选，辅助本次阅读；刷新页面后不保留。
准备规划医疗预约平台？
可以先提供一条脱敏业务记录和一个异常处理过程，帮助我们把你的实际规则落实到页面、接口与验收条件。