CIS 系统接入
CIS 系统通常包含患者工作台、医嘱、病历、检查检验、护理、质控、审签、归档、消息和审计。DirectSurface UI 不定义这些业务域，但可以作为复杂桌面式 Web 应用的 UI 承载层。
适合承载的能力
DirectSurface UI 适合承载：
- 多 tab 工作台和浮动窗口。
- 查询表格、主从页面和维护页面。
- 大数据树、树表和对象查看。
- 病历编辑器、大文本编辑器和 Markdown 文档中心。
- 命令、权限、上下文和运行时诊断。
- 弹窗、下拉、上下文菜单和通知。
这些能力可以组成复杂业务系统，但业务流程仍由业务应用控制。
接入顺序
建议按下面顺序接入：
- 建立应用外壳和工作台。
- 注入登录用户、租户、权限服务和基础服务。
- 接入菜单和页面打开机制。
- 为页面建立独立上下文和命令范围。
- 接入查询页、维护页和表单页。
- 接入病历编辑、留痕、批注和打印。
- 接入运行时诊断、对象查看和性能浮层。
- 建立内存泄露和大数据测试基线。
不要一开始就把所有业务塞进一个全局状态。先把应用生命周期、页面生命周期和服务边界固定下来。
病历编辑本身建议按 病历编辑器接入 单独验收，包括模板加载、本地文档、工具栏、数据元、表格、批注留痕、打印和关闭释放。
医疗场景注意事项
医疗信息系统对上下文和审计要求很高。至少要明确：
- 当前操作者是谁。
- 当前患者或就诊是谁。
- 当前页面打开的是哪个业务对象。
- 当前文档是否只读。
- 当前操作是否需要留痕。
- 当前操作是否需要服务端审计。
这些规则不应散落在按钮回调里。推荐通过页面上下文、命令系统和业务服务统一表达。
与现有前端框架集成
如果 DirectSurface UI 嵌入 Vue、React 或其他宿主应用，宿主负责创建和销毁应用实例。DirectSurface UI 内部对象也必须在宿主 unmount 时释放。
接入时要确认：
- canvas 是否由宿主创建。
- 销毁时是否保留宿主 DOM。
- 所有弹层和定时器是否释放。
- 页面上下文中的可释放对象是否释放。
- 全局缓存是否属于应用级还是文档级。
框架可以帮助释放自己创建的对象，但宿主传入的外部资源需要约定归属。
长期维护
长期维护靠约束：
- demo 只作为示例，不作为业务基类。
- 所有框架能力从公共入口导入。
- 页面只组合能力，不改内部实现。
- 业务模型写在业务层，不写进框架层。
- 性能和内存问题用诊断工具验证，不靠感觉修改。