交付可控
底座复用 + 场景拆分，过程可验收，交付物标准化；不做一次性项目堆叠。
底座负责可持续，场景负责可落地，AI 负责加速度。
底座复用 + 场景拆分，过程可验收，交付物标准化；不做一次性项目堆叠。
权限、审计、限流、可观测与国密能力内置于底座，关键操作可追溯。
多租户、多库、插件化与持续升级能力，支撑医院业务逐步扩展。
AI 辅助需求整理、沙箱实时预览与变更单提交，业务确认后快速进入研发迭代。
业务与技术解耦，换 HIS、换数据库、加院区，不用推倒重来。
对医院意味着：信息科管的是一套底座 + 多个场景，而不是一堆互不相通的系统。
多主体不是多套系统，而是同一底座上的隔离与授权。
一套系统、一个租户，部署在医院内网或私有云，数据边界清晰。
一套平台承载多个院区，统一组织树与分级授权，业务规则可按院区配置。
牵头单位统一平台，成员单位独立租户或独立库，支撑区域协同与分级管理。
医院信息科能管住、能追溯，才敢把系统交给业务部门。
用户—角色—菜单/按钮/接口，支持组织树、多机构、主管与职位，按岗位分配访问能力。
全部、本部门及以下、本部门、仅本人、自定义五种数据范围，按机构与人员自动过滤。
菜单按钮权限与后端接口白名单/黑名单联动，前端可见性与后端访问控制一致。
操作、访问、异常、数据差异、HTTP 日志，关键状态变化与第三方调用结果可追溯。
SM2/SM3/SM4 国密算法、双 Token、Token 黑名单、接口限流与敏感数据脱敏。
按等保、密评要求设计权限、审计与数据保护；具体合规结论以第三方测评结果为准。
不承诺“全面支持”，只承诺“每一项都有明确状态”。
| 适配项 | 已实机验证 | 已代码适配，待项目验证 | 依赖上游生态 |
|---|---|---|---|
| 操作系统 | Linux；麒麟 V10（终端场景） | — | — |
| CPU 架构 | x86_64 | — | ARM / 鲲鹏 / 飞腾 |
| 数据库 | PostgreSQL | 达梦、人大金仓 | OceanBase、GBase、GaussDB 等 |
| 中间件 | Nginx、Redis 等通用组件 | — | 国产中间件按项目评估 |
| 浏览器 | 主流 Chromium 浏览器 | 国产内核浏览器 | — |
| 密码算法 | SM2 / SM3 / SM4 | — | — |
真正的瓶颈是需求表达、确认与响应速度。我们把“提意见 → 看效果 → 提交研发”压缩成一个闭环。
在真实页面上用自然语言描述“想怎么改”，不需要先写需求文档。
捕获页面上下文，生成结构化改动方案，标明影响范围。
左侧沙箱即时呈现改动效果，歧义处点选确认，不满意可回滚。
确认后生成变更单，自动进入研发流程，缩短沟通与返工。
示意：业务人员在真实页面上提意见，AI 在沙箱中实时预览，确认后生成变更单提交研发；沙箱不写入真实业务数据。
不卖“全家桶”，按医院阶段选择起点。
面向患者的高频就医服务，形成院外到院内的服务闭环。
把院内的等待、用药追溯和终端服务变成可运营的数字化流程。
根据医院实际需求快速迭代：可部分替代、可与 HIS 相辅相成、补充完善，不搞推倒重来。
以多租户底座支撑医共体、多院区和区域平台的分级协同。
周期按项目评估；AI 把需求整理、预览确认与变更单流转前置，减少来回沟通。
确认场景范围、业务规则、数据边界与验收标准
底座配置、场景开发、接口联调与数据迁移
第三方联调、自动化用例、业务验收与回滚演练
上线发布、培训交接、监控告警与持续升级
底座 + 患者服务 + 排队叫号 + 追溯码 + 自助终端
医共体协同、统一主数据、区域监管驾驶舱
基层 HIS 连接、更多 AI 辅助场景与运营分析
可提供演示环境，按场景预约。覆盖管理后台、患者端、叫号大屏、追溯码与自助终端；具体演示范围以实际环境为准。