简介：这是一套面向医疗信息化开发者与医院系统集成人员的电子病历控件源码，用于在业务系统中嵌入电子病历文档的编辑与展示能力，适合具备C#/.NET桌面开发基础、需要快速搭建病历编辑模块的技术人员参考。压缩包共663个文件，约6.49MB，以313个bmp界面位图、163个cs源码文件、49个resx与49个resources资源文件为主，另含14个dll、6个exe及若干csproj、sln工程文件，构成可直接编译运行的完整解决方案。源码围绕病历文档的树形结构展示、图片存取、逻辑删除、SQL生成等模块展开，配套资源文件与图标素材齐全，便于二次开发时替换界面风格或扩展字段。目前已有532人学习下载，可作为理解电子病历编辑控件架构、复用文档处理逻辑与排查编译问题的实用参考。

1. 电子病历控件源码：医院文档编辑为什么不能直接用富文本编辑器

做过 HIS 或临床系统的人都遇到过这个场景：医生要在浏览器里写病程记录、手术记录、入院评估单，格式要求严格——标题层级、段落缩进、页眉页脚、打印排版一样不能少。你第一反应可能是塞一个富文本编辑器进去，但真到了三甲医院的信息科评审环节，会发现事情远没那么简单。电子病历文档编辑的核心诉求不是「能打字」，而是「结构化 + 可追溯 + 可打印 + 可归档」，这四个词决定了你必须用专门的电子病历控件，而不是通用编辑器。

所谓电子病历控件源码，通常指的是一套可嵌入 B/S 或 C/S 系统的文档编辑组件，它把类似 Word 的编辑能力封装成控件，同时暴露数据接口给上层业务系统。医院信息科关心的「源码」不是让你去改它的内核，而是要有可审计、可二次开发、可私有化部署的代码基础。热搜里频繁出现的「控件」「源码」「文档编辑」这几个词，本质上是同一批人在找：怎么在自己的系统里嵌一个能写病历、能存结构化数据、能打印的编辑器。这篇文章就按这个思路，把选型、集成、参数、踩坑讲透，适合正在做电子病历模块的后端和前端工程师，也适合需要评估技术路线的人。

2. 电子病历控件的技术选型：从 B/S 架构到数据存储格式

2.1 为什么通用富文本编辑器在病历场景会翻车

通用富文本编辑器（比如常见的开源 Web 编辑器）输出的是 HTML 片段，这对病历来说有三个致命问题。第一，HTML 是表现层格式，不是结构化的医疗数据，你没法从一段 HTML 里可靠地抽出「主诉」「现病史」「既往史」这些字段。第二，病历要求留痕，每次修改要有版本记录，通用编辑器的 undo 栈是内存级的，刷新就没了。第三，打印排版不可控，医院要求的病历打印格式有明确规范，HTML 转打印经常出现分页错乱、页眉丢失。

电子病历控件的做法不一样。它内部维护一个文档模型（通常是类 XML 的结构），编辑操作作用于模型，渲染只是模型的一种输出。这样你既能拿到结构化的数据节点，又能保证打印时按固定模板渲染。选型时第一个要确认的就是：这个控件的数据模型是不是结构化的，能不能按节点读写。

2.2 三种主流集成方式的对比

目前医院里常见的电子病历控件集成方式有三类，各有适用场景。

我一般会推荐纯前端 JS 控件 + 服务端结构化存储的组合，原因是现在医院终端环境越来越杂，依赖插件的方案在信创环境下经常装不上。热搜里有人问「pageoffice控件安装后依然提示让安装」，这类问题基本都出在插件方案上——浏览器版本、安全策略、注册表残留都可能导致控件加载失败，排查成本极高。纯前端方案虽然排版能力弱一点，但可控性强，出问题也好定位。

2.3 数据存储格式：为什么建议用结构化 XML 而不是 HTML

选定控件后，下一个决策是数据怎么存。我的经验是：编辑态可以用控件自己的格式，但落库一定要转成结构化 XML 或 JSON。具体做法是给每个病历段落打上语义标签，比如<section name="chief_complaint">，控件负责渲染，业务层负责按标签读写。

这样做的好处是，后续要做病历质控、科研检索、数据上报时，你不需要去解析 HTML。很多团队一开始图省事直接存 HTML，等到要做「提取所有高血压患者的既往史」时才发现根本没法查，只能推倒重来。结构化存储是电子病历文档编辑能不能长期用下去的分水岭。

3. 用前端控件跑通病历编辑的最小闭环：代码与参数

3.1 初始化控件与文档模型

下面这段代码演示的是在一个病历编辑页面里初始化控件、加载结构化模板、绑定保存事件的最小流程。不同控件的 API 名字会有差异，但逻辑是通用的：创建实例、加载模板、监听变更、序列化输出。

// 初始化电子病历编辑控件 const emrEditor = new EmrControl({ container: '#editor-root', // 挂载容器 mode: 'design', // design 可编辑，readonly 只读 template: '/templates/admission.xml', // 结构化模板路径 toolbar: ['bold', 'italic', 'section', 'table', 'print'], autoSaveInterval: 30000, // 30 秒自动暂存 onReady: function () { console.log('控件就绪，文档模型已加载'); }, onChange: function (dirty) { // dirty 为 true 表示有未保存修改 document.getElementById('save-btn').disabled = !dirty; } }); // 保存时取结构化数据，而不是 HTML function saveRecord() { const xmlData = emrEditor.getContent('xml'); // 关键：取 xml 格式 const plainText = emrEditor.getContent('text'); // 纯文本用于全文检索 fetch('/api/emr/save', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ recordId: currentRecordId, content: xmlData, searchText: plainText }) }); }

这段代码里几个参数值得说明。mode决定控件是否可编辑，查看历史病历时切成readonly能避免误改。template指向结构化模板，模板里预置了病历的章节骨架，医生打开就有格式，不用从空白开始。autoSaveInterval是自动暂存间隔，病历编辑时间长，没有自动保存很容易丢数据。getContent('xml')是核心，它返回的是带语义标签的结构化数据，落库用这个；getContent('text')返回纯文本，专门喂给全文检索。

3.2 结构化字段的读写与校验

病历里有些字段是必填的，比如主诉、现病史。控件如果支持按节点操作，就可以在保存前做校验。

// 按语义标签读取和校验字段 function validateRecord() { const required = ['chief_complaint', 'present_illness', 'past_history']; const missing = []; required.forEach(function (tag) { const node = emrEditor.getNode(tag); // 按标签取节点 const text = node ? node.getText().trim() : ''; if (!text) { missing.push(tag); node && node.highlight(true); // 高亮缺失字段 } }); if (missing.length > 0) { alert('以下必填项未完成：' + missing.join('、')); return false; } return true; }

getNode(tag)按语义标签定位节点，highlight(true)把缺失字段标红提示医生。这套机制的前提是模板里已经给每个章节打好了标签，所以模板设计阶段就要和临床科室确认好字段命名，不然后期改标签会牵一发动全身。

3.3 打印与导出的参数配置

病历最终要打印归档，控件的打印配置直接影响输出质量。

// 打印配置：A4、页眉页脚、分页规则 emrEditor.print({ paper: 'A4', margin: { top: '20mm', bottom: '20mm', left: '25mm', right: '20mm' }, header: 'XX医院 入院记录', footer: '第 {page} 页 / 共 {pages} 页', pageBreakBefore: ['section[name="operation_record"]'], // 手术记录另起一页 scale: 1.0 });

pageBreakBefore这个参数很实用，医院要求某些章节必须另起一页，用选择器指定即可。header和footer支持{page}占位符自动填页码。打印前建议先用scale微调，不同打印机边距有差异，1.0 不一定合适，我一般会在 0.95 到 1.0 之间试。

4. 电子病历控件集成中的避坑与排查

4.1 控件加载成功但编辑区空白

现象：页面不报错，控件容器也渲染了，但编辑区一片空白，工具栏按钮点了没反应。

原因：多数是模板路径 404 或者模板 XML 格式不合法。控件加载模板失败时不一定抛异常，可能静默失败。另一个常见原因是容器高度为 0，控件初始化时算不出编辑区尺寸。

解决：打开浏览器网络面板确认模板请求是否 200；用 XML 校验工具检查模板格式；给容器显式设置min-height，比如#editor-root { min-height: 600px; }。这三点按顺序排查，基本能覆盖九成空白问题。

4.2 保存后重新打开格式错乱

现象：医生编辑时排版正常，保存后重新打开，段落缩进、表格边框全乱了。

原因：保存时取了 HTML 而不是结构化数据，重新加载时控件按自己的模型解析 HTML，两边对不上。或者模板版本更新了，旧数据里的标签在新模板里找不到对应节点。

解决：统一用getContent('xml')保存，加载时用setContent(xml)。模板升级要做版本兼容，旧标签保留映射关系，别直接删。这个坑我踩过，当时一批历史病历打开全乱，最后写了个标签映射脚本才救回来。

4.3 自动保存导致版本冲突

现象：两个医生同时打开同一份病历，后保存的覆盖了先保存的，先保存的内容丢失。

原因：自动保存没有做乐观锁，或者锁的粒度太粗。

解决：保存请求带上版本号，服务端比对版本号，不一致就拒绝并提示「病历已被他人修改，请刷新后重试」。控件层面可以在onChange里记录本地修改时间戳，和服务端版本做比对。病历场景不建议做自动合并，冲突时让人工介入更安全。

4.4 打印分页把表格切断

现象：打印预览里表格跨页被拦腰截断，表头没重复。

原因：控件的打印引擎默认按内容流分页，没有识别表格的keep-together属性。

解决：给表格节点设置page-break-inside: avoid，或者在打印配置里指定表格的重复表头规则。如果控件不支持，退而求其次，在表格前后插入分页符，让表格整体落到下一页。这个需要和临床确认，有时候表格太长确实没法不跨页，那就保证表头重复。

4.5 信创环境下控件字体缺失

现象：在国产操作系统和浏览器上，病历里的特殊符号显示成方框。

原因：控件依赖的字体在信创环境里没有预装。

解决：把病历用到的字体打包成 Web Font，随控件一起加载，在 CSS 里用@font-face声明。别依赖系统字体，医院终端环境不可控。这个坑在项目上线前一定要在目标环境实测，别等验收才发现。

5. 让电子病历控件真正落地的三个进阶技巧

5.1 用模板继承减少重复配置

医院科室多，每个科室的病历模板有差异但骨架相同。我的做法是做一个基础模板，科室模板继承它，只覆盖差异部分。控件加载时先加载基础模板，再合并科室覆盖层。这样新增科室只需要写差异配置，不用复制整份模板。实现上可以用 XML 的 include 机制，或者在服务端做模板合并后再传给控件。

5.2 编辑态与归档态分离

病历在编辑阶段允许控件用自己的格式，但归档时必须转成符合规范的归档格式（通常是 PDF/A 或结构化 XML 加签名）。我的习惯是在保存接口里做一次转换，编辑数据存一份，归档数据另存一份，两者通过 recordId 关联。归档后的数据只读，任何修改走修订流程生成新版本。这样既保证了编辑体验，又满足了归档合规要求。

5.3 用埋点数据反推控件性能瓶颈

控件在长病历（比如超过 50 页）下会变卡，但你不一定知道卡在哪。我会在控件的关键操作上埋点：加载耗时、输入响应延迟、保存序列化耗时、打印渲染耗时。这些数据攒一周就能看出瓶颈。常见结论是序列化耗时随文档长度线性增长，那就考虑增量保存，只序列化变更节点。另一个常见瓶颈是撤销栈内存占用，可以限制栈深度，比如只保留最近 50 步。

这些技巧不是一开始就要全上，但项目进入二期、病历数据量上来之后，提前有准备会省很多事。我自己最深的教训是：别等到医生投诉卡顿才去查性能，控件集成第一天就把埋点加上，后面所有优化都有数据支撑。希望帮到你。

本文还有配套的精品资源，点击获取