互联网医院上线第三周药房端反馈回一张截图处方里“按体表面积计算卡铂剂量”那段经过HIS→互联网平台→药店ERP三次转存公式里的乘号丢了单位“mg/m²”变成了“mgm”小数点后的数字也错了一位。幸好审方药师经验足电话核对了原始处方才没有让问题流向患者。做医疗信息化的朋友都知道电子处方跨平台流转最大的“隐性炸弹”往往不在药品编码、不在库存同步而在那些看起来不起眼的“公式”——剂量计算公式、输液速率公式、儿童用药的公斤体重公式。它们一旦在跨系统转存中变形就是实实在在的用药安全事件。这篇文章我想把“电子处方公式跨平台转存”这件事完整拆开谈谈我在这类项目中踩过的坑、验证过的技术路径以及一套可以直接参考的落地框架。内容主要适合三类人正在做互联网医院或处方流转平台的架构师和开发、做HIS/ERP改造的药学信息工程师以及想理解处方数据底层逻辑的产品经理。整篇内容不依赖某个特定厂商方案以通用技术思路为主。1. 电子处方跨平台转存为什么会“卡”在公式上1.1 处方流转的业务链路与三种常见平台先看清楚电子处方跨平台转存到底发生在哪些环节。现实中处方最少要经过三个平台开方端的医院HIS或互联网医院系统中间的处方共享平台或区域处方流转中心以及承接端的零售药店ERP、云药房或第三方配送系统。部分场景还会延伸到医保结算、商保理赔、审方中心、慢病管理平台。这些系统往往来自不同厂商开发语言从Java、C#到老旧的PowerBuilder都有数据库更是五花八门。处方数据在这些系统间传输通常走的是接口对接比如WebService、HTTP API、ESB消息队列或干脆是导出Excel/CSV再人工导入。药品编码不一致、单位不统一这些问题大家多少都有预案唯独“公式”这个东西绝大多数系统根本没有在数据结构里给它留位置。于是公式只能跟着备注字段走或者“扁平化”成一段纯文本转存天然就面临风险。1.2 “公式”在处方里的真实模样很多人以为处方里的公式就是教科书上那种复杂的数学表达式但实际临床处方里最常见的公式恰恰是那些“看起来简单、转存时最容易坏”的儿童用药按体重计算布洛芬混悬液单次剂量体重(kg)×5mg/kg换算成毫升数还要除以浓度100mg/5ml。输液泵速率ml/h 剂量(mg/kg/min) × 体重(kg) × 60 ÷ 浓度(mg/ml)。肿瘤化疗按体表面积BSA(m²)√(身高(cm)×体重(kg)/3600)卡铂剂量靶AUC×(GFR25)。肾功能不全时调整剂量肌酐清除率Cockcroft-Gault公式涉及年龄、体重、血肌酐值。肠外营养配比热氮比、糖脂比、钠钾离子浓度的计算。新生儿/早产儿矫正胎龄后的剂量系数修正。这些公式在原始处方里可能是这样存在的Word版病历中的公式对象、HIS处方明细里的一段描述性文字“按BSA计算”、药师备注里的简写“20kg→5ml”甚至是一张手机拍照的图片。它们没有统一的结构化表达转存时要么被降级成普通字符串要么在富文本转换中丢失格式要么被OCR识别得面目全非。所以第一步必须在认知上确认处方公式不是“排版点缀”而是剂量决策的关键数据必须当成结构化数据来管理。1.3 转存失控的三个层次我在实际排查中习惯把公式转存问题拆成三个层次方便定位故障到底出在哪一层。第一个是语义层。公式作为一种数学对象在Word里是OMMLOffice Math Markup Language在MathType/AxMath里是域代码在LaTeX里是控制序列在网页里可能是MathML。不同系统的公式“母语”不同直接拷贝转存时最常见的结果就是公式退化成图片或者干脆变成乱码。这一层丢失的是“公式的可计算性”比如乘号丢了、括号没了系统无法再对这个公式做任何数值校验。第二个是结构层。公式与文字的对齐关系、公式内部的层级结构分式、根号、上下标、矩阵在转存中经常被压平。典型表现是“mg/m²”变成“mgm”根号里的内容被放到根号外分子分母挤在同一行。这一层丢失的是“公式的排版语义”。第三个是呈现层。目标端的字体、渲染引擎、富文本控件不支持公式所需的特殊符号时就会出现豆腐块、问号、乱码。很多系统测试时在电脑端没问题一上微信小程序或App端就崩问题基本都出在这一层。弄清楚了这三个层次后面所有技术方案其实都在回答一个问题怎么让公式在语义、结构、呈现三个层面都完整地穿过系统边界。2. 先定规矩处方公式怎么建模才不散架2.1 公式在文档中的几种存在形态要做跨平台转存得先搞清楚公式在源系统里可能以什么形态存在。我列一个对比表这些形态在实际处方数据里都见过形态典型来源可编辑性可计算性跨平台兼容性转存风险Word OMMLWord/网页复制的电子病历中中低非微软生态支持差转成图片或断裂MathType/AxMath域代码老HIS里的病历编辑器高低需Word域解析极低无Word环境直接失效LaTeX源码科研系统、部分新平台高高可被符号计算高文本格式目标端缺宏包渲染失败MathML标准化学术出版、网页中高中浏览器支持参差老旧浏览器显示异常位图/图片扫描件、截图不可编辑无高只是能显示不可检索、不可校验、OCR易错这表一列就清楚了如果你只在源系统里看到一段Word公式直接拿文本接口去转存基本等于赌运气。现实中我建议的做法是对源端做一次公式形态普查统计HIS里到底有多少处方带了公式带的公式是域代码、OMML还是图片再决定解析策略。2.2 处方专用公式模型的建议跨平台传输公式最怕的就是“各说各话”。我建议在中间层定义一套统一的结构化公式模型源端解析成这个模型目标端再从模型渲染成自己的格式。下面是一份我在项目中实际用过的JSON结构核心思路是“表达式 参数 语义说明”三段式{ formulaId: fx-001-2025, formulaName: 输注速率计算, expressionType: latex, expression: \\text{速率(ml/h)} \\frac{\\text{剂量(mg/kg/min)} \\times \\text{体重(kg)} \\times 60}{\\text{浓度(mg/ml)}}, description: 按公斤体重计算静脉输注速率常用于儿科静脉用药, params: [ { key: 剂量, value: 0.5, unit: mg/kg/min }, { key: 体重, value: 20, unit: kg }, { key: 浓度, value: 2, unit: mg/ml } ], calcResult: { value: 300, unit: ml/h }, renderFallback: { type: image/png, base64: iVBORw0KGgoAAAANSUhEUgAA... }, version: 1.0 }为什么用LaTeX文本作为expression的主格式因为LaTeX是纯文本跨平台传输没有编码问题也便于存数据库、做版本对比、被符号计算库解析。MathML虽然语义更强、可以直接进浏览器DOM但文本体积大、人工阅读性差不适合做存储主格式更适合做渲染中间格式。图片base64是最差的选择但它“什么环境都能显示”所以作为兜底字段保留后面会展开讲双写策略。这里有个容易被忽略的设计细节params字段一定要保留“计算时的入参值”。很多处方审核场景需要重算验证如果公式体结构过去了但参数值丢了重算就是空谈。把参数与公式绑定在同一份JSON里转存过程中即使某个系统看不懂LaTeX也能通过params和calcResult至少理解处方意图不会让用药信息彻底丢失。2.3 用双写策略保住可读性上一节JSON里有个renderFallback字段这是我的“双写”思路结构化表达式用于计算和精确转存渲染图片用于任意环境兜底显示。实际经验是在转存链路上确保“文本与图片”同时送达能省掉大量线下沟通成本。具体做法是源端解析出LaTeX表达式后动态渲染一张PNG或SVG压缩后作为BASE64字符串一并传输。目标端如果自带的渲染器不行比如老药店的ERP只支持富文本图片就直接显示这张图如果目标端渲染能力强就优先用结构化表达式重新渲染图片退为审计存档。双写策略的代价是数据体积变大一张公式图BASE64后大概2-6KB对于动辄几万条的批处理来说要设计好压缩和缓存。不过对于用药安全场景这点体积成本完全可以接受。提示一下SVG比PNG体积小、放大不糊是更好的兜底格式但老系统普遍只认PNG/JPG具体按目标端适配来。3. 从原始处方到目标平台转换管线的搭建3.1 解析端如何把Word公式、图片和描述性文字变成结构化表达式转换管线第一公里是解析源端数据。根据处方公式的原始形态大致有三条路第一种源端是Word/RTF里的OMML或MathType域代码。这种最麻烦因为不是所有系统都导出干净的标准格式。我实践中比较稳的路径是先利用Word的docx解析库比如python-docx或开源的mammoth把document.xml提取出来找到m:oMath元素再用OMML转MathML的XSLT微软官方有提供OMML2MML.XSL转成MathML最后通过MathML转LaTeX工具如pandoc得到LaTeX。整条链路可以用pandoc一条命令完成大部分事pandoc input.docx -t markdown --webtex但这个方案对老HIS导出的RTF可能失效RTF里的公式通常是MathType域代码得先确认目标系统能不能导出docx。第二种源端是一段描述性文字比如“按体重计算”或“20kg×5mg/kg”。这种只能靠人工规则关键词解析属于弱结构化抽取。我曾经做过一个正则词典的解析器把常见的剂量表述如“mg/kg”“ml/h”“按体表面积计算”“Cockcroft-Gault公式”抽出来映射到公式模板库。这里的关键是公式模板库要先行建设——先把本院常用的几十个剂量计算公式固化成模板解析时只需要匹配模板和填参数准确性比自由文本解析高得多。第三种源端是图片/扫描件。靠公式OCR识别比如Mathpix、通义千问/腾讯云的公式识别API、开源的pix2tex。OCR公式识别现在准确率已经不低但对处方这种包含大量中文单位混排的内容容易在“÷”和“/”、“µg”和“mg”之间翻车。图片识别结果必须走人工复核关口不能让机器结果直接进数据结构。3.2 传输端标准化载体与接口设计公式一旦转成结构化JSON传输端的选择就从容多了。处方共享平台一般已经定义好了处方对象结构我们要做的只是把上面的formula JSON嵌套进处方明细的doseExpression字段并配套一个版本号。接口层面建议用POST包含签名和防篡改校验响应里要有明确的成功/失败回执。下面是一个简化的传输示例{ transmissionId: tx-20250617-001, prescriptionId: RX20250617001, sender: hospital-his-v3, receiver: pharmacy-erp-v2, items: [ { drugCode: BR-001, drugName: 布洛芬混悬液100mg/5ml, doseExpression: { formulaId: fx-ped-ibuprofen, expressionType: latex, expression: \\text{ml} \\frac{\\text{体重(kg)} \\times 5\\text{mg/kg}}{20\\text{mg/ml}}, params: [ { key: 体重, value: 20, unit: kg } ], calcResult: { value: 5, unit: ml } }, administrationRoute: 口服, frequency: tid, durationDays: 3 } ], signature: sha256:..., timestamp: 2025-06-17T10:30:0008:00 }接口设计有个容易被忽略的点字段单位一定要随值携带。处方转存的历史教训中单位丢失导致用药过量是最高频事故。“剂量5”和“剂量5mg/次”在系统语义里完全不是一回事。建议单位字段不走文本备注而是独立枚举字段在平台层做映射校验。3.3 渲染端目标平台按自己的“画布”显示公式目标端拿到结构化公式后怎么渲染取决于它的载体。这里按常见终端整理一份选型参考目标载体主选渲染方案备选方案注意事项Web管理端/药师审核端MathJax或KaTeX渲染LaTeXMathML转原生DOM中文变量名注意定义宏包字体移动端App/小程序服务端预渲染SVG/PNG原生计算引擎解析后拼接文本公式不宜单独成行需处理基线对齐药店ERP老系统直接使用BASE64图片无图片需控制分辨率避免撑爆接口体量Word/PDF导出服务端LaTeX排版生成PDF或转OMML嵌入HTML转PDF时用MathJax插件转Word时优先原生OMML避免MathType域渲染端最常踩的坑是“公式与文字不对齐”。处方里公式常常出现在一句描述中间比如“剂量按【速率公式】计算每日分3次口服”——公式的垂直基线和正文不对齐时整行文字会非常难看甚至在部分老旧浏览器里直接错位。Web端我一般用CSS设置公式容器的vertical-align为middle或让公式以inline-block包裹。小程序端则建议直接把公式连同前后文字渲染成一张整行图片省去对齐烦恼。4. 实操步骤让一个儿科剂量处方在三个系统间完整走一遍4.1 前期准备数据字典与公式库动手开发之前先做两件准备工作否则后面处处返工。第一件是统一数据字典特别是单位字典把“mg/kg”“mg/m²”“ml/h”“mmol/L”这些单位做成枚举表每个单位在平台层有统一定义源端能映射、目标端能识别。第二件是建立处方公式模板库从本院或合作方实际病历中提取高频公式给每个公式分配稳定ID如fx-ped-ibuprofen附上LaTeX模板、参数定义、剂量上下限、重算规则。这里提一个“Excel维护公式库”的小教训很多团队初期习惯用Excel维护公式模板库复制公式列时按下CtrlD经常“无效”原因是公式所在列中间有空行断档或者Excel计算选项被设为了手动。症状虽然发生在办公软件层面但它直接导致公式库版本错乱转存调试时对不上号。公式模板库建议直接用数据库表维护Excel只做展示。4.2 从HIS导出并解析原处方实操开始。假设HIS里原始处方是这么写的“患儿20kg布洛芬混悬液100mg/5ml单次5mltid*3d”。我们要把它解析成结构化公式JSON。第一步通过HIS的接口或者定时导出任务拿到处方明细文本。这条文本可能是结构化字段拼接出来的也可能是医生自由输入的备注。第二步交给解析器处理。解析器先识别药品、单位、数值再触发模板匹配逻辑import re raw 患儿20kg布洛芬混悬液100mg/5ml单次5mltid*3d weight_match re.search(r(\d(?:\.\d)?)kg, raw) dose_match re.search(r单次(\d(?:\.\d)?)ml, raw) concentration_match re.search(r(\d(?:\.\d)?)mg/(\d(?:\.\d)?)ml, raw) expr ( r\\text{{单次剂量(ml)}} r\\frac{{{weight}kg \\times 5\\text{{mg/kg}}}}{{20\\text{{mg/ml}}}} ).format(weightweight_match.group(1)) structured { format: ped-ibuprofen, expression: expr, params: [ {key: 体重, value: weight_match.group(1), unit: kg}, {key: 浓度, value: 100mg/5ml, unit: mg/ml} ], calcResult: {value: dose_match.group(1), unit: ml} }第三步关键校验解析器算一遍把calcResult的5ml和文本里的单次5ml做比对不一致就标记告警并转人工。这一步看着简单但它能在数据源头拦下80%的“公式变形错位”。4.3 通过共享平台转存到药店ERP处方明细加上剂量表达式后组装成传输JSON发给处方共享平台。平台任务有两块一是转发二是签名。转发过程中平台不要修改公式体内容只做透传签名是为了让药店ERP验证处方确实是医院发出的、内容没被篡改。药店ERP收到数据后按第3节的渲染端策略展示。如果ERP前端支持MathJax就把LaTeX直接渲染如果不支持就显示传输JSON里携带的BASE64公式图。这里再强调一点药店端审方药师看到的界面公式图旁边必须同时显示“计算公式入参和计算结果”的文字摘要。因为光有公式图药师还是没法快速判断剂量对不对有了“体重20kg单次5ml”这样的平实文字人工复核才高效。转存完成后要回执回执信息至少包含处方号、药品、展示方式图片/公式渲染、公式是否成功渲染、是否有异常告警。回执是链路监控的原始依据也能用来生成日后的对账报表。4.4 批量转存的性能与异常处理实际项目里处方从来不是一张张传往往是一批几万条。有朋友曾拿着4万条处方数据来问批处理传到一半接口超时怎么办。这个问题的核心在于公式渲染是非常消耗CPU的操作尤其是LaTeX转SVG/PNG每条处方可能要几十到几百毫秒。4万条如果全部实时渲染平台压力非常大。我的建议是分批异步处理。源端先批量上传结构化JSON不含渲染图平台收到后进入消息队列渲染任务由独立worker池消费每次100条一批处理渲染结果回传到存储后目标端再通过拉取接口获取。失败任务进入死信队列重试重试3次仍失败的直接转人工处理而不是让整批数据卡死。日志里要记录每个公式的渲染成功/失败状态方便事后定位。5. 现场排坑实录那些让公式“变形”的隐藏问题5.1 常见问题速查表这节我把真实项目里遇到的高频问题整理成一张速查表方便读者直接对照排查症状根因解决方案Word公式对象跨平台后变成一张图片或直接消失Word的OMML结构在非微软环境被降级源端优先导出LaTeX/MathML图片仅作兜底MathType与AxMath同时安装Word插入公式调出错误的编辑器两个公式插件的COM加载项冲突统一公式插件环境或在导出前检查域代码类型LaTeX公式在目标端渲染成“豆腐块”或问号目标端字体或宏包不支持中文/特殊符号引入数学字体和中文宏包或改走图片兜底mg/m²被显示成mgm或m²丢失上下标在纯文本转换中被压平单位字段独立传输不依赖公式文本公式图片OCR后“÷”变成“/”、“µg”变成“mg”OCR模型的符号歧义OCR结果强制二次规则校验超阈值转人工网页端公式行与正文垂直错位公式容器基线未对齐设置vertical-align:middle必要时整行图片化JSON传输中公式的“\”被转义丢失反斜杠未双重转义/字符串被二次解析统一序列化规则传输后做LaTeX合法性校验批处理中间断点后公式重复渲染任务没有幂等控制按transmissionId做唯一约束支持重试5.2 踩坑细节和规避办法第一个要展开的坑是“Word公式复制到目标系统后变成图片”。很多HIS导出的Word病历里公式其实是MathType嵌入的域代码普通文本复制只带走了“渲染结果”也就是对象截图。如果目标系统不做域代码解析转存就等于把可计算公式降级成了死图片。规避办法是在源端导出接口里直接用docx解析层抽取OMML别依赖医生的复制粘贴。第二个坑是LaTeX里的中文变量名。处方公式经常出现“体重”“剂量”这种中文描述而标准LaTeX推荐用英文变量。直接用xelatex配合ctex宏包可以编译中文公式但目标端如果只是Web端MathJax需要配置字体和规则。最简单稳妥的做法是公式主体用标准数学符号中文含义放到description字段和params里不要在LaTeX表达式里硬塞中文否则渲染兼容性非常差。我在上文的示例pep里有中文写法实际生产环境我建议把“体重”用W_body代替中文描述单独放。第三个坑是JSON转义导致的LaTeX破损。LaTeX代码里全是反斜杠和花括号经过一层JSON序列化时非常容易出错。比如\frac{}{}被解析后变成frac{}{}渲染直接失败。规避办法是传输后第一时间在目标端做LaTeX合法性校验校验失败的不入库直接返回重发请求。这个校验是必须的不需要等渲染环节才暴露问题。5.3 建立转存验证闭环最后说验证闭环我认为这是整套方案最不能省的一步。处方公式转存不是“显示出来就算成功”必须验证三个点表达式文本完整、参数值正确、计算结果一致。我在项目里落地的是“三查三对”一查公式体是否与原处方一致文本对比二查参数是否被篡改或丢失字段级diff三查重算结果是否落在合理剂量区间配合审方规则。任何一个异常都触发告警并且异常数据不允许进入最终展示环节。处方审核端要能一键调出原始处方和转存后处方的并排对比方便药师人工判断。这个验证闭环在测试阶段就能发现大量问题建议不要等到上线后靠线下反馈。个人实际操作中的体会是公式跨平台转存做了将近一年最深的感受是“这不是渲染问题是数据建模问题”。公式在源系统里没有被当成结构化数据转存再怎么做都是亡羊补牢。真正稳妥的路径是先把医院常用处方公式整理成模板库让HIS开方端就按模板录入参数后续所有转存、审方、统计都基于结构化公式展开。即使短期内无法改动HIS也要在平台层建立公式解析映射中心把“公式转存”从一次性开发做成持续运营的能力。最后分享一个小技巧所有公式字段统一用“LaTeX文本存储 MathML/图片双轨渲染”的方案实测下来兼容性和可维护性都很稳遇到再老的终端也能拿出一个能看的兜底方案。这套方法后续还可以延伸到药品说明书结构化、CDSS规则审核、AI辅助审方等领域原理都是相通的。