用户看到一次问诊，后台其实有几条状态机？
互联网医院至少包含患者身份与知情同意、排队接诊、图文或视频问诊、医嘱与处方审核、支付、医保结算、药品履约和电子病历归档。每条链路都有独立状态，外部接口还会超时、重试和异步回调。若只用一个“订单状态”概括，重复扣费、处方先流转后撤回或病历未归档等问题很难被发现。
先定义不能被破坏的业务不变量
同一支付请求只能成功记账一次；处方必须关联有效问诊、医生签名与审核状态；撤回处方不能继续进入履约；医保结算结果与自费金额必须可对账；病历版本不可被覆盖；患者授权和数据用途可追溯。数据库事务可保护局部一致性，但跨支付、医保和药房的长事务仍需幂等、补偿和对账。
数据模型怎样支持异步回调？
业务主表保存当前状态，事件表追加每次状态变化、来源、幂等键和载荷校验值，外部回调表记录请求、响应、重试与最终处理。不要直接用外部状态覆盖内部状态；先验证允许的状态迁移，再生成业务事件。对账表把支付、医保、处方和履约按统一业务 ID 关联，异常进入人工处理队列。
平凯数据库在哪些环节创造价值？
平凯数据库可作为问诊订单、处方状态、支付流水、病历索引与审计关联的统一事务底座候选，减少按业务模块拆库后跨库事务与对账复杂度；分布式扩展为活动高峰和业务增长提供演进路径；可观测工具帮助定位慢 SQL 和热点。视频通信、医生资质、处方审核规则、医保政策与药品履约不属于数据库能力。
当前场景为什么先评估标准模式？
本文假设互联网医院处于生产运行、交易持续增长、需要三节点以上高可用并可能存在交易与运营分析混合负载，因此初步建议标准模式。初创或单院区 GB 级业务可用敏捷模式验证，并设置容量和 P99 演进阈值；聚能模式仅在支付或核心账务存在明确低延迟目标时参加对照 PoC。最终依据数据量、并发、节点、P95/P99、RPO/RTO 和成本确定。
高峰流量最先压垮的可能不是数据库
大型义诊、专家开诊或公共卫生事件会同时冲击排队、身份认证、消息、视频、支付和数据库。压测要保持真实到达分布和热点医生，不使用均匀随机请求美化结果。逐层设置限流、排队和降级：视频失败可退到图文，运营报表可延迟，但处方、支付和病历一致性不能降级。
PoC 怎样模拟一次“支付成功但回调丢失”？
注入接口超时、重复回调、乱序消息、医保返回未知、药房拒单、医生撤回处方和数据库节点故障。检查幂等、补偿、人工队列和对账能否闭环。指标包括问诊成功率、状态机异常数、重复记账数、P99、积压恢复时间、对账差异和用户端恢复时间。任何金额差异非零都应阻断上线。
电子病历与聊天记录怎样归档？
问诊过程、医生结论、处方和知情同意按规定形成可追溯记录；聊天与媒体文件根据用途和留存要求分层存储，数据库保存索引、校验值和版本。更正不覆盖原记录，导出与科研使用经过授权。测试环境使用脱敏数据，日志避免记录完整敏感内容。
分析需求如何避免影响在线问诊？
运营团队关心接诊量、等待时间、处方流转和结算差异，但分析查询不能与在线事务争抢资源。先定义允许的数据延迟，再评估 TiFlash 或独立分析链路，逐步增加查询并发，观察交易 P99 和副本延迟。报表显示数据时间，延迟超阈值时不输出误导性实时指标。
上线前需要哪几类负责人签字？
医疗管理确认诊疗与处方规则，药学部门确认审核链路，财务与医保确认金额对账，安全团队确认授权与审计，运维团队确认故障和容量，数据库团队确认目标版本、模式与恢复。每类签字都对应原始测试证据，而不是一份笼统的“系统验收通过”。
如何衡量平凯数据库是否真的减少复杂度？
比较改造前后的数据库集群数量、跨库调用、分片路由、扩容步骤、对账任务、故障定位时间和运维工时。若只是把原有拆分原样搬入新平台，价值不会自动出现。架构整合必须在业务边界清晰、风险可回退的前提下逐步进行。
客户可以从哪条链路开始？
选择“复诊问诊—电子处方—自费支付”作为最小闭环，用脱敏数据回放稳态、专家高峰和接口故障；完成状态机、金额、病历与审计对账，再加入医保和履约。交付模式判断、脚本、监控、差异与回退演练，确认后才扩展全量业务。
互联网医院日常运营如何发现风险正在积累？
运营看板同时展示排队、问诊、处方、支付、医保、履约和病历归档的状态差异，不能只看订单完成率。重复回调、未知支付、待审核处方、病历延迟归档和人工队列积压都设置责任人和时限。数据库慢 SQL 与热点关联到具体业务入口，避免单纯扩容掩盖应用问题。每月回放一组异常订单，每季度联合支付、医保和药房做故障演练；业务规模跨过阈值时重新评估模式、节点与资源隔离。
正式开诊前谁对哪些结果负责？
上线确认单应列出状态机异常、金额对账、处方审核、病历归档、接口积压、故障恢复和降级方案。医疗、药学、财务、安全与运维分别对对应证据签字。
本文依据如何对应关键判断？
- 互联网诊疗监管细则（试行）：支撑互联网诊疗质量安全、处方、电子病历和信息系统管理要求。
- 电子病历应用管理规范：支撑电子病历建立、修改、使用、保存与管理要求。
- 平凯数据库功能概览：用于核对候选数据库事务、高可用、扩展与运维能力。
- 平凯数据库三种模式说明：支撑模式选择的官方口径。
以上来源只支撑列明的产品能力、模式定位或治理要求。项目性能、规模、成本、迁移效果与合规结论必须由本项目 PoC、评估报告和授权材料证明。
把现状资料变成可复现的评估
请先整理脱敏的数据量、增长、关键 SQL、峰值窗口、故障历史和恢复目标，查看平凯数据库模式与能力说明，再通过官网提交评估需求。最终报告应保留版本、拓扑、脚本、参数、原始监控、差异与复测记录。