CGA 系统演示与验收要验证什么？

本页使用顺序

本清单用于准备和记录核对工作，不代表当前产品已通过所有项目。演示结果仅对应当次环境与版本；正式验收条件由机构结合确认范围另行约定。

演示前发给双方的准备清单

• 范围：写明本次要验证的业务环节、必须现场操作的事项和暂不具备联调条件的接口。未能演示的项目单列为待验证。
• 人员：确定主持人与记录人，安排评估者、审核者及信息部门代表参加；权限验证使用各自角色账号，另备无权访问的测试账号。
• 环境：记录演示地址、版本、部署方式和数据初始化状态。异常模拟、权限与恢复验证应在双方授权的隔离测试环境开展，明确操作范围与停止条件。
• 样例：准备正常流程、补充评估、报告退回和随访复评的合成案例。每个案例有固定编号、相同输入和预期状态，不使用真实姓名、身份证号、手机号或病历。
• 规则：需要核对计分时，事先确认工具版本、使用授权、测试输入和由正式材料确定的预期结果；无法确认的计分项保持待验证。
• 留存：约定记录表、截图或日志的保存位置、访问人员和脱敏方式。演示中的报告与消息保留在测试环境，不发送给真实服务对象。

业务范围尚未明确时，可先填写机构需求准备清单；需要了解模块边界时，可查看CGA 老年综合评估产品介绍。

演示前先统一案例和判断口径

由机构准备一组不含真实患者信息的合成案例，至少覆盖正常流程、需要补充评估、报告退回和随访复评。所有候选产品使用同一输入，才能比较流程深度而不是供应商熟练程度。

为每个步骤写清角色、前置条件、操作、预期结果和证据形式。记录通过、部分通过、不通过或依赖第三方，不把口头说明自动记为完成，也不要求演示人员接触生产数据。

核对对象、路径与评分证据

演示对象建档、身份核对、场景选择、筛查、路径推荐、进一步评估和中断恢复。观察系统能否区分未评、不适用、拒绝和缺失，而不是用默认值把表单强制变完整。

选择一个可公开验证的测试规则，核对原始答案、计算、边界值、人工确认和规则版本。完整受授权工具不在公开演示中转载；验收以合法取得的正式材料和项目配置为准。

核对报告、审核与闭环任务

从评估结果生成报告草稿，检查工具名称、结果、综合说明、干预计划、版本和审核状态。让审核者退回一次，再查看修改差异、原因和重新提交记录是否保留。

发布报告后查看行动如何分配、接受、反馈和关闭，随访如何触发复评并比较历史。系统建议不能直接替代医嘱或处方，统计也应区分已建议与已执行。

核对权限、审计和异常路径

使用不同机构、科室和角色账号验证可见范围，并直接测试未授权链接或接口，而不只看菜单是否隐藏。检查查看、修改、审核、下载、导出和管理员操作能否进入审计。

模拟重复建档、输入越界、接口超时、身份不一致、消息重复和目标系统不可用。系统应呈现明确状态和授权补救入口，不能要求运维人员直接修改数据库完成业务恢复。

把演示结果转成正式验收

演示证明的是当前环境和版本表现，正式项目仍需把产品已有、配置、定制和第三方依赖分开。每项写入范围、责任、样例、通过条件和未通过处置，避免宣传材料代替合同。

上线验收还包括环境、培训、接口、安全、备份恢复和回滚演练。签字前复核遗留问题及风险接受人，重大权限、数据完整性或评分问题未关闭时不宜扩大使用范围。

保留可复验的验收证据

验收记录应包含版本、环境、账号角色、样例编号、操作步骤、实际结果和证据位置。截图只能证明可见页面，评分、权限、审计、接口和恢复还需日志、导出或恢复结果等适当证据，并对敏感内容脱敏。

失败项写清影响与复验条件，修复后重新执行原步骤，而不是用文字说明直接关闭。最终报告列明通过范围、遗留问题、责任人和回滚材料，便于后续升级时重复同一组关键用例。

性能体验也要放在真实范围中观察，包括约定并发、典型报告生成、列表查询和批量任务，而不是脱离硬件与数据规模给出绝对结论。测试数据量、环境资源和结果口径写入报告，后续扩容另行评估，并保留复验基线和归档记录。

可复制的演示记录格式

以下字段适用于单个步骤；涉及多个角色或状态变化时分别记录，并用案例编号串联。

• 记录信息：案例编号：____；日期、版本及环境：____；操作者角色：____；记录人：____。
• 执行条件：前置状态：____；合成输入或样例文件：____；操作步骤：____；预期结果及依据：____。
• 现场结果：实际结果：____；证据文件及具体位置：____；结论：通过 / 部分通过 / 不通过 / 待验证。
• 依赖与复验：第三方或配置依赖：____；遗留问题和影响：____；责任人：____；复验条件与时点：____。

合成示例 DEMO-01：报告退回、修改与重新提交

下面演示如何写记录，案例和结果均为合成示意，不是客户病例、真实验收记录或产品能力声明。若当前演示版本没有相应流程，应如实记录差异，不套用示例结论。

1. 前置条件：合成对象 DEMO-001 已有一份待审核的报告草稿；评估者和审核者使用两个独立测试账号。版本与环境由现场填写，不预设已通过。
2. 操作步骤：审核者填写测试退回原因“补充流程说明”并退回；评估者查看原因、补充一段测试说明，再次提交；审核者查看此次提交及历史记录。
3. 预期核对：对象关联保持正确，草稿状态按约定变化；退回原因、操作角色与时间可追溯；前后内容或版本的查询方式清楚。是否允许导出及导出状态按机构要求另行验证。
4. 记录示意：假设现场已看到退回原因与重新提交，但未找到版本证据，应记录“部分通过：退回与重提已观察，历史版本追溯待验证”，附已观察步骤的证据；未展示部分不填写为已具备。
5. 复验安排：由供应商说明版本查询方式及配置条件，机构确认通过口径后重跑同一案例。责任人、日期及实际复验结果保留空白，待双方填写。

演示结束后，先完成四项确认

1. 核对结论：逐项确认已验证范围、部分通过项、失败项和待验证项；第三方依赖单独记录，不能作为通过结论。
2. 安排补验：为每个遗留问题填写负责人、所需条件和复验时点；修复或配置变更后重复原步骤并保留新旧证据。
3. 明确下一阶段：将拟纳入项目的能力分别标明已有、配置、开发或第三方依赖，确认交付边界。演示记录不能直接替代正式项目验收。
4. 归档材料：保存范围清单、案例、环境版本、结果和证据索引；按约定回收临时账号并处理测试数据，保留后续复验所需的合成样例。

带着需求清单和希望核对的案例预约产品演示，可帮助双方提前确认演示条件；暂不能展示的项目应在记录中明确说明。