平台业务分离的前端扩展框架

熙牛医疗HBOS的核心设计理念，是将岗位职责拆解为可复用的标准业务流程单元。以门诊医生工作站为例，其聚焦于患者接诊、医嘱开具等规范流程。然而，受医疗机构使用习惯和地方政策差异的影响，系统落地时常常需嵌入子流程、新增业务活动或设置特殊限制，此类定制会对前端交互、接口参数、数据流向及控制逻辑产生系统性影响，我们将其统称为“业务定制”。

前端业务定制面临三大挑战：

• 视图复杂度控制难：界面形式多样，定制开放度难以平衡。过度开放易致系统复杂，限制过严则无法满足灵活需求，需在灵活与收敛之间取得框架级平衡。

  
  

• 逻辑层混杂：交互逻辑与业务逻辑深度耦合，扩展点难以暴露，业务定制常“无从下手”。如何清晰串联混杂的业务逻辑，成为模块化改造的关键。

  
  

• 架构耦合度高：页面与逻辑网状交织，缺乏流程化边界，扩展点定位困难，影响系统稳定与迭代效率。需实现平台与业务分层，支持并行开发。

  
  

因此，我们需要构建一个视图可灵活定制、权限可控，业务逻辑清晰且支持快速插拔的扩展框架，既能支撑平台长期演进，也能响应医院的快速迭代需求——这正是Jarvis扩展框架的设计初衷。

在实际业务中，定制能力具体体现在：

• 视图定制：如超三甲医院因操作规范严格，需适配全键盘操作、特定组件或适老化界面。

  
  

• 数据定制：因地域政策与三方合作差异，需规范处理数据，如申请单转换，以实现本地快速适配。

  
  

• 事件定制：支持大块逻辑的插拔与替换，如各地医保政策的灵活适配。

  
  

• 流程定制：支持精细化逻辑调整，如在接诊流程中插入合理用药检查，并控制流程的继续或阻断，确保灵活而不扰乱现有功能。

前端页面技术一直在不断更新换代，无论是早期的JQuery，还是现在流行的React、Vue，它们的核心任务其实始终没变——就是定义页面的布局、使用的组件、背后的业务逻辑以及数据状态。可以说，这些正是将业务功能呈现给用户的关键所在。即使未来出现更先进的技术语言，业务本身的核心逻辑是不会轻易改变的。正是基于对这种“不变性”的思考，我们设计了Jarvis框架中的Schema协议。

图1：Schema 引擎组装页面的过程

它的核心理念很简单：把“看到的”和“执行的”分开。我们用Schema来定义页面的布局结构和组件关系，而业务逻辑则通过可插拔的方式与视图建立联系。外部开发的定制模块，能够在不修改原始代码的情况下，通过Schema引擎在运行时将定制逻辑与标准页面结构融合在一起，最终完成整个页面的渲染。

在基于这套 Schema 基础协议之上组装页面的过程中，我们可以将平台代码与业务代码进行剥离，在运行时通过 Schema 串联平台与业务的视图与逻辑，达到平台与业务迭代既能边界清晰、又能相互协同的目的。

平台侧实现的主要功能包括：

数据模型：基于服务端接口自动生成调用包，使前端无需关注接口细节，同时根据业务场景定义对应数据模型，为视图驱动提供类型支持。

前端组件：提供SPI、API及标准接入规范，确保与Schema组装兼容，是构建视图的基础单元。

模版视图：框架通过语义化标签语法描述界面结构，运行时将其解析为Schema协议并完成视图组装。

运行时设计：平台在运行时根据业务身份加载定制代码，并与平台代码动态结合。支持同一扩展点挂载多份定制逻辑，可按需叠加或选择执行。

在业务侧实现主要功能如下：

研发规范：对于业务前端来说无需了解过多 Jarvis 框架实现的细节，只需要根据定制文档实现具体视图组件或者覆盖对应业务逻辑即可。

运行时设计：定制包运行时采用 umd 的方式进行加载，根据业务身份动态获取最小粒度 umd 包，代码层面完全与平台隔离。

图2：平台与业务隔离设计

得益于平台与业务侧的隔离设计，HBOS前端与业务前端在代码仓库和团队分工上均可实现完全物理隔离，使平台版本能够轻装上阵、独立迭代。

Jarvis框架的平台-业务分离策略带来以下优势：

• 团队职责清晰，并行开发：平台团队专注底层框架与通用功能，业务团队深耕各医院个性化需求，分工明确，互不阻塞。

  
  

• 技术升级自主连续：平台在保持兼容的前提下，可独立进行技术升级、性能优化与问题修复，成果持续赋能所有医院系统。

  
  

• 平台能力持续沉淀：随着交付医院数量增加，平台不断吸收各地域、各规模医院的共性需求，推动功能完善与行业经验积累，形成良性演进循环。

为满足不同医院的个性化需求，HBOS在前端层面提供了充分的扩展能力，包括视图与业务逻辑的灵活定制，各业务团队可自主实现所需功能。平台与业务侧在组织架构上相互独立，形成专门团队，使各业务团队能够更聚焦自身领域、深入挖掘业务特点，实现多个机构项目的高效并行交付。

多机构并行交付的优势如下：

• 业务隔离，互不干扰：高度定制化的需求可在各自业务工程内闭环实现，避免不同医院逻辑相互影响。

  
  

• 扩展灵活，平台稳定：新增机构交付不会对平台架构产生冲击，新医院迭代更加自主灵活。

  
  

• 共性沉淀，能力复用：各医院交付中形成的共性需求可反哺至平台，或沉淀为标准化能力供后续复用。

  
  

• 并行交付，节奏可控：不同医院由对应业务团队独立负责，避免交付环节相互阻塞。

  
  

• 规范统一，降低门槛：业务团队遵循统一的定制开发规范并使用配套工具，无需深入理解平台底层设计，有效降低学习成本。

随着业务范围的扩大和交付医院数量的增加，医疗行业特有的组件、操作习惯和业务流程也在不断积累。依托Jarvis扩展框架的设计机制，通用能力可逐步沉淀至平台层，个性化功能则由各业务定制工程实现。交付的医院越多，HBOS前端的功能设计与实现就越趋成熟和稳健。借助数字化能力，这些经验积累将成为企业可传承、可复用的重要资产。

• 持续优化的技术底座：平台代码的积累推动性能、体验和效率持续提升。通过数字化分析与客户端及框架层优化，系统加载与渲染效率不断改善，性能保持稳定。针对医院提出的操作流畅度、全键盘支持、快捷键设置、适老化界面等体验问题，平台持续优化并固化解决方案，转化为平台通用能力。Jarvis研发体系还提供一系列效率工具，助力研发流程提速。

  
  

• 业务知识的沉淀桥梁：Jarvis框架作为连接载体，将中医医嘱、电子病历操作、打印功能等医疗行业知识逐步沉淀到HBOS，形成可复用的共性业务能力。

  
  

• 能力市场的关键纽带：随着合作机构的增多，熙牛医疗前端团队将定制需求中的通用实现抽象为标准能力，构建能力市场。新机构上线时可快速复用这些能力，大幅缩短交付周期。

在多团队协作与多客户并行的背景下，提升研发与迭代效率成为关键任务。为此，熙牛医疗前端团队构建了一整套开发调试工具链，涵盖本地命令行工具、静态代码数字化文档和运行时调试工具，全面降低开发与调试成本。

完善的开发调试发布能力

通过本地命令行工具，可快速创建和调试页面，并依托自动化构建与发布流程，有效减少重复劳动。

静态页面数字化分析

面对 HBOS 交付工作中高昂的业务理解与技术学习成本，Jarvis结合前端数字化能力，实现了业务知识的有效传承与技术体系的直观呈现。

图3：前端页面静态数据的数字化

页面运行时数字化调试

借助Chrome调试插件，可实时查看页面结构树、组件数据、扩展执行状态及接口情况，大幅提升调试效率。

图4：运行时数字化与运行时调试

业务定制数据指导平台扩展灵活度建设

页面定制诉求的集中点、功能扩展的最佳位置、流程逻辑所需的定制能力，传统上依赖产品与开发人员的主观经验判断。然而，个人经验存在局限。随着业务发展，各医院的真实定制数据已成为指导框架扩展能力建设的最佳依据。通过分析医院需求的共性与特性，我们能够构建更精准、灵活的扩展机制。

性能数据指导页面加载与交互优化

功能增加往往伴随页面体积增大，进而引发性能问题。在庞大的 HBOS 中，人工全面监控每个页面和功能并不现实。依托院内性能监控数据，可及时发现问题并实现预警，将主观使用感受转化为客观可验证的指标，并通过数字化研发体系精准推送至维护人员。

体验度量数据优化核心功能交互路径

核心功能操作有其规范路径。在医生高频使用的场景中，简化一次点击或优化键盘操作，虽看似微小，却能显著提升工作效率。因此，在框架与定制层面探索最短操作路径，成为精细而有价值的课题。Jarvis框架以业务数据与体验度量数据为依据，持续优化交互设计，推动系统向更稳健、实用的方向演进。

异常数据助力框架问题发现与修复

尽管软件迭代经过严格测试，仍难免出现异常。框架层问题影响范围广，现场操作中若出现异常，将严重影响使用体验。通过线上监控实时捕捉异常，并借助前端数字化能力定向推送至开发人员，可做到早发现、早修复，有效控制影响范围。

机构数量的增长并不意味着需要复制更多系统版本，也不代表业务代码的简单堆砌。在业务拓展的同时，我们更注重建立可持续的迭代机制，使日益丰富的业务场景成为滋养 HBOS 持续成长的土壤。

面对不同医院、科室乃至医生对系统功能的个性化需求，始终是医疗信息化系统交付过程中的核心挑战。Jarvis前端扩展定制框架的实施，在保障各医院高效交付的同时，也逐步形成了一套推动平台持续完善与自我演进的发展模式。在数字化与AI技术融合的浪潮中，Jarvis框架正在探索更多创新可能，致力于让业务交付更加智能、高效。

往期精彩推荐：

复杂系统研发认知升维之路：前端数字化研发

基于多Agent架构的新一代智能助理：重塑医疗信息化的“超级大脑”