CGA 与 HIS、EMR 如何做接口协作？

先画数据流而不是先谈协议

明确哪个系统创建评估对象、何时发起任务、谁维护患者和就诊主索引、结果在哪里审核、报告最终进入何处。只有业务流明确后，接口协议才有可执行含义。

字段口径需要逐项确认

姓名等基本信息只是少数部分，还要核对机构科室、人员、就诊、评估状态、报告版本、时间和编码字典。敏感字段遵循最小必要原则传输和展示。

异常路径必须能够追踪

接口超时、重复消息、身份不一致、目标系统不可用和回写失败都需要可追踪状态与人工补救入口。不能用“自动同步”替代异常处理设计。

公开介绍的承诺边界

颐晖智能可围绕部署与接口条件开展技术协作；具体接口是否现成、开发范围、联调周期、第三方配合和费用，以项目确认文件为准。

用接口契约管理跨系统责任

接口契约应把业务事件写清楚：患者何时成为评估对象，住院、门诊或健康档案标识如何关联，撤销或合并身份时如何处理，报告审核完成后何时回写。每个事件需要唯一关联标识、发送方、接收方、必填字段、状态码和重试策略。仅有字段表而没有触发规则，往往会导致双方都能发送数据，却无法保证业务状态一致。

身份映射是最容易被低估的风险。患者主索引、就诊号、住院次数、机构科室和人员编码可能来自不同系统，不能只用姓名或手机号匹配。联调时要覆盖同名、证件缺失、跨院区、转科、重复消息和档案合并等情况；对无法自动确定的记录，应进入人工核对队列并限制后续操作，避免把评估结果错误写入另一位患者档案。

接口安全不仅是使用 HTTPS。还要核对网络边界、双向身份认证或授权方式、密钥保管、最小字段、传输与存储日志脱敏、访问审计和调用频率限制。错误响应中不要返回完整患者信息，排查问题时使用关联标识定位。测试环境和生产环境使用不同凭据，人员离岗或合作结束后及时撤销访问，并对异常批量调用设置告警。

验收时应模拟目标系统不可用、网络超时、重复提交、字段缺失和回写被拒绝等情况，检查是否会丢失、重复或覆盖报告。系统应展示待处理状态，允许授权人员重试或关闭，并保留操作原因。颐晖智能可以参与接口方案、开发和联调协作，但每个项目的现有接口、第三方费用、网络审批与工期均需单独确认。

接口文档还需要明确数据保存边界和主数据归属。患者基本信息由哪个系统维护、CGA 报告哪一版本有效、目标系统是否允许撤回或修订、双方日志保留多久，都要形成一致规则。发生争议时以关联标识、时间戳、报文摘要和业务审核记录定位，而不是在多个系统之间手工猜测。生产变更前先在隔离环境完成回归，准备旧版本配置与切换方案；发布后用少量受控业务验证，再逐步恢复正常流量，避免一次性批量回写造成难以恢复的数据问题。