這個需求我接到的時候第一反應是又是那種表頭十幾列、業(yè)務邏輯繞三圈的改造。HIS系統(tǒng)里的檢驗報告原本只管打印現(xiàn)在要開放成XHEDITOR在線編輯而且報告里那些自動算好的公式也得跟著轉過去不能被當成死文本丟掉。聽起來是個小功能拆開才發(fā)現(xiàn)涉及檢驗報告的結構梳理、公式解析、字符轉義、編輯器集成一整條鏈路。這篇就把我在實際項目里從設計到落地的完整過程寫出來方案選型、數(shù)據(jù)結構、核心代碼、踩坑排查都在里面正在做同類改造的同行可以直接參考。1. 先把需求掰開揉碎檢驗報告里的公式到底是什么1.1 一份檢驗報告單通常包含什么處理這種需求的第一步永遠不是寫代碼而是搞清楚數(shù)據(jù)長什么樣。常規(guī)的檢驗報告單至少包含四塊內容。第一塊是患者與標本信息姓名、性別、年齡、科室、標本類型、采樣時間。第二塊是檢驗項目的明細結果每一項包含項目名稱、結果值、單位、參考區(qū)間、異常標志這部分是報告的主體。第三塊是計算項目比如陰離子間隙AG、肌酐清除率CCr、BMI之類它們不是儀器直接測出來的而是由多個檢驗結果通過公式算出來的。第四塊是審核信息包括檢驗醫(yī)師的簽字、審核備注、報告解釋性文字。從系統(tǒng)實現(xiàn)角度看前兩塊數(shù)據(jù)在報告模板里是動態(tài)填充的后兩塊是需要人工參與維護的內容。在線編輯功能要解決的核心問題就是讓第二塊和第三塊既能自動計算又能被人工調整調整之后仍然保持正確的格式和公式關系。這里有個很容易被忽略的點報告單上的公式不是一個值而是一個計算過程。比如AG Na - (Cl- HCO3-)如果只把結果值傳過去技師想改一下Na的值AG不會跟著變整個報告就失真了。所以需求拆解出來之后底線是兩條第一公式的展示形態(tài)要保留計算過程第二公式的結果值要能隨原始數(shù)據(jù)變化。1.2 檢驗公式的三種典型形態(tài)在HIS系統(tǒng)里檢驗公式大致分三類處理方式完全不同。第一類是算術運算型也是最常見的。AG、CCr、GFR、BMI、LDL-C估算都是通過加減乘除計算出來的。這類公式的特點是參數(shù)明確、算法固定適合用表達式解析器動態(tài)求值。第二類是條件判斷型比如根據(jù)某個指標是否超標來生成異常標志、決定報告提示語。報告單上常見的↑↓箭頭、加粗提示、危急值標記都算這一類。它們本質上不是算術公式而是規(guī)則判斷在HTML層面往往體現(xiàn)為樣式切換或者文案拼接。第三類是文本拼裝型比如該患者HbA1c偏高建議結合血糖結果綜合評估這類解釋性語句。以前的做法是在后端寫死在模板里現(xiàn)在要支持在線編輯這類文本就必須開放出來變成可改寫的富文本內容。搞清楚這三種類型后面做方案設計才不會走偏。算術型需要真正的公式引擎支持條件判斷型需要規(guī)則渲染文本拼裝型則需要編輯器層面的自由度。1.3 需求邊界什么必須在線編輯什么保持離線在線編輯不是把整個報告都放開那會讓HIS系統(tǒng)的嚴謹性崩掉。實際項目里需要劃清楚邊界。必須在線編輯的內容是報告描述區(qū)域、計算結果區(qū)域的格式化調整、備注信息的增刪改。這些內容與患者本次檢驗結果直接相關技師在審核時需要微調而且需要所見即所得。不能放開的內容是患者基本信息、檢驗項目名稱、單位、參考區(qū)間這些由LIS系統(tǒng)或儀器下發(fā)的數(shù)據(jù)。這些屬于質量控制范圍如果在編輯器里被改了溯源就出問題了。我的做法是把這些字段在編輯器初始化之前全部用占位符替換掉編輯器里只能看到渲染后的占位符文本不能直接編輯。另外還需要明確一點編輯器的定位是人工干預通道不是數(shù)據(jù)錄入主通道。主數(shù)據(jù)永遠來自檢驗流程編輯器的改動要記錄日志、要可追溯。沒有這條約束后面驗收的時候會被人質疑數(shù)據(jù)可信度。2. 方案選型三條路線試下來說說取舍2.1 路線一后端全部算完直接吐HTML給編輯器當展示殼這個方案最直覺后端拿到檢驗結果把公式算好整個報告渲染成一段HTML字符串丟給XHEDITOR加載。編輯器看起來是能編輯了但本質上是看一張靜態(tài)網(wǎng)頁。試過之后發(fā)現(xiàn)了明顯問題。技師在編輯器里改了某個指標的解釋文字保存拿到的是一整段HTML我又沒法從這段HTML里反推出哪些是原始數(shù)據(jù)、哪些是人工改動。下一次重打報告同樣的內容又得重新生成。更麻煩的是報告里某個結果值被人工修正過但下一次檢驗數(shù)據(jù)一刷新修正值直接被覆蓋了。這個方案適合演示不適合生產。它致命的缺陷是把數(shù)據(jù)和展示揉成了一團丟了結構化信息后面的版本管理、數(shù)據(jù)核驗全都做不了。2.2 路線二公式占位符加字典替換編輯器做兜底微調這個方案是從模板引擎的思路里借鑒過來的也是我最終的選型。核心思路是報告模板里不寫死數(shù)值而是保留占位符比如檢驗結果占位符寫成${GLU}公式計算項寫成${AG}。后端在把內容交給編輯器之前先做一輪占位符替換把${GLU}替換成真實的血糖值把${AG}替換成AG的完整計算過程和結果。這樣編輯器里看到的是一份完整的報告但底層數(shù)據(jù)結構里仍然保留了公式定義的引用關系。這個方案的好處是邊界清晰。占位符替換是單向的從數(shù)據(jù)到展示編輯器保存回來的HTML會再做一次逆向解析把人工改過的部分和原始數(shù)據(jù)部分分離。人工修改的區(qū)域記錄成覆蓋層下次刷新數(shù)據(jù)時可以選擇保留覆蓋還是重新計算。這里要注意一個細節(jié)占位符本身的設計要避開HTML轉義陷阱。我當時用的是雙大括號風格方便正則匹配也能避免和CSS里的花括號語法沖突。2.3 路線三前端引入公式引擎全部動態(tài)計算這個方案聽起來最“先進”把公式定義下發(fā)到瀏覽器XHEDITOR內部插入一段計算腳本用戶在界面上改一個數(shù)值公式結果立即聯(lián)動刷新。實話說純前端做這個完全可行有很多現(xiàn)成的表達式解析庫能用。但在HIS這種環(huán)境里我最終沒有選它原因有兩個。第一是安全邊界問題。檢驗報告的公式計算如果全部交給前端相當于把部分業(yè)務邏輯轉移到瀏覽器端執(zhí)行后端對數(shù)據(jù)正確性的控制力會變弱。萬一前端腳本被篡改或者版本不一致報告結果就會出偏差這在醫(yī)療場景里是沒法接受的。第二是兼容性成本。醫(yī)院的環(huán)境比一般企業(yè)復雜得多很多科室的瀏覽器還是老版本部分客戶端甚至是內網(wǎng)專用終端。把復雜的表達式解析邏輯放在前端等于給自己埋了一堆兼容性雷。所以路線三只被我用來做“預覽聯(lián)動”就是技師在編輯器里臨時改數(shù)值時用前端腳本做一個即時預覽效果。真正落庫、真正打印的報告結果仍然由后端統(tǒng)一下發(fā)。2.4 為什么XHEDITOR在這個場景里夠用很多同行會問為什么不用更流行的編輯器。在這個項目里選XHEDITOR不是因為它功能最全而是因為它剛好滿足場景需求輕量、可定制工具欄、有源碼模式、和舊系統(tǒng)的jQuery技術棧兼容。檢驗報告在線編輯需要的核心能力其實只有幾個段落加粗、文字換行、上下標處理、表格插入、源碼查看。前四個XHEDITOR原生支持最后一個源碼模式特別關鍵——技師可以把通過其他途徑規(guī)范的HTML直接貼進源碼區(qū)省去來回格式兼容的麻煩。另一個重要原因是環(huán)境約束。HIS系統(tǒng)往往跑在內網(wǎng)甚至專網(wǎng)環(huán)境很多外網(wǎng)資源無法加載。XHEDITOR這個體積小、無強依賴的編輯器適合放到內網(wǎng)靜態(tài)資源目錄不需要外網(wǎng)CDN也不依賴復雜的打包工具鏈。對醫(yī)療信息化場景來說有時候“剛好夠用”“容易部署”比“功能強大”更重要。3. 落地實現(xiàn)從模板結構到公式回顯的完整鏈路3.1 模板與公式的數(shù)據(jù)表設計數(shù)據(jù)表設計是要先做好的地基。我在項目里建了兩張核心表一張存報告模板一張存公式定義。報告模板表的關鍵字段如下CREATE TABLE report_template ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 模板ID, template_code VARCHAR(64) NOT NULL COMMENT 模板編碼對應檢驗類別, template_name VARCHAR(128) COMMENT 模板名稱, content_html MEDIUMTEXT COMMENT 模板正文含占位符, version_no INT DEFAULT 1 COMMENT 版本號, status TINYINT DEFAULT 1 COMMENT 狀態(tài)1啟用0停用, create_time DATETIME, update_time DATETIME ) COMMENT 檢驗報告模板表;公式定義表的設計要能支撐表達式解析和動態(tài)求值CREATE TABLE report_formula ( id BIGINT PRIMARY KEY AUTO_INCREMENT, formula_code VARCHAR(64) NOT NULL COMMENT 公式編碼如AG、CCr, formula_name VARCHAR(128) COMMENT 公式名稱, formula_expr VARCHAR(512) NOT NULL COMMENT 計算公式如Na-(ClHCO3), result_unit VARCHAR(32) COMMENT 結果單位, decimal_places INT DEFAULT 2 COMMENT 保留小數(shù)位數(shù), status TINYINT DEFAULT 1, create_time DATETIME ) COMMENT 檢驗報告公式定義表;這里有個細節(jié)想強調公式編碼要跟報告模板里的占位符約定一致。比如模板里寫${AG}公式表里的formula_code就存AG。前端渲染時按規(guī)則把所有占位符找出來到公式表里去匹配對應定義匹配不到的直接報錯避免出現(xiàn)報告上某個位置空白。至于原始檢驗結果數(shù)據(jù)一般直接存在檢驗結果明細表里結構大致是檢驗申請?zhí)?、項目編碼、結果值、單位、參考上下限。公式計算時通過申請?zhí)柲玫疆敶螜z驗的全部結果值再用項目編碼去匹配公式參數(shù)。3.2 公式表達式的存儲與解析公式表達式存的是帶項目編碼的文本比如AG Na - (Cl HCO3)其中Na、Cl、HCO3是檢驗項目的編碼。解析要解決兩個問題一是把中綴表達式轉成可計算的格式二是從檢驗結果集合里按項目編碼取到對應的值。最穩(wěn)妥的做法是把表達式拆成token用經典的中綴轉后綴算法求值。我把這個過程整理成三步。第一步詞法分析。把字符串拆成操作數(shù)、運算符、括號三類token。這里要注意項目編碼可能包含字母數(shù)字和特殊字符例如HDL-C、LDL-C中間有橫線拆token的時候容易把減號當成運算符。解決的辦法是維護一個項目編碼字典解析時優(yōu)先按字典里的最長匹配去識別操作數(shù)。第二步中綴轉后綴。用棧處理運算符優(yōu)先級把表達式轉成逆波蘭式避免括號嵌套帶來的優(yōu)先級混亂。這個算法是編譯原理里的基礎內容實現(xiàn)起來并不復雜。第三步求值。遍歷后綴表達式遇到操作數(shù)就從結果集合里取數(shù)值壓棧遇到運算符就從棧里彈出兩個數(shù)值計算計算完再入棧。最終棧里剩下的就是結果。核心的Java實現(xiàn)大致是這樣public class FormulaEvaluator { private MapString, BigDecimal resultMap; public FormulaEvaluator(MapString, BigDecimal resultMap) { this.resultMap resultMap; } public BigDecimal evaluate(String expression) { ListString tokens tokenize(expression); ListString rpn infixToRpn(tokens); DequeBigDecimal stack new ArrayDeque(); for (String token : rpn) { if (isOperator(token)) { BigDecimal b stack.pop(); BigDecimal a stack.pop(); stack.push(applyOperator(a, b, token)); } else { BigDecimal val resultMap.get(token); if (val null) { throw new FormulaException(缺少參數(shù): token); } stack.push(val); } } return stack.pop(); } }實際使用時還需要給每個公式配置小數(shù)位數(shù)和結果單位。AG默認保留1位小數(shù)CCr這種通常保留2位。小數(shù)位配置在公式表里統(tǒng)一管理避免前端展示層臨時格式化時出現(xiàn)不一致。這里有一個容易踩的坑檢驗結果里有些項目是負數(shù)有些項目可能為0。求值的時候如果某個參數(shù)結果為空直接拋出異常比靜默返回0更安全。因為檢驗報告上的公式為空會讓臨床醫(yī)生困惑寧可讓技師看到明確報錯也不能讓錯誤數(shù)據(jù)悄悄出現(xiàn)。3.3 后端計算、替換與轉義的順序模板渲染這塊順序很重要順序錯了渲染結果就會出問題。我最終采用的渲染順序是先做公式計算再做占位符替換最后做HTML轉義。公式計算要在占位符替換之前完成因為公式占位符替換時需要的是計算結果值而公式定義里嵌套的那些項目編碼占位符又是從模板里提取的。實際操作時我是先從模板HTML中用正則把所有${...}提取出來過濾出公式類型的占位符逐個調用FormulaEvaluator計算得到一個計算結果Map。然后第二次掃描模板把普通結果占位符和公式占位符統(tǒng)一替換。轉義這一步要格外小心。檢驗結果里經常出現(xiàn)單位符號、上下標、正負號直接替換進去會被瀏覽器當成HTML標簽解析。比如結果值里的大于號小于號尤其是0.1這種表示低于檢測下限的結果如果不轉義HTML結構直接就被破壞了。我的處理是把結果值替換進模板時統(tǒng)一經過一個安全封裝方法public static String safeValue(String rawValue) { return StringEscapeUtils.escapeHtml4(rawValue); }這里有一個關鍵限制只對替代進去的數(shù)值做轉義模板本身保留原樣。也就是說技術人員設計模板時可以寫合法的HTML結構而動態(tài)數(shù)據(jù)進來時統(tǒng)一做安全檢查防止值里混入非預期內容。替換完成后的這段HTML就是交給XHEDITOR加載的內容。此時編輯器里看到的報告公式結果是真實計算出來的格式是正常的數(shù)據(jù)部分也限制了可修改范圍。3.4 XHEDITOR初始化與編輯內容保存XHEDITOR的集成本身不復雜但有幾個配置項要想清楚。初始化代碼如下function initReportEditor() { var editor $(#reportContent).xhEditor({ tools: Cut,Copy,Paste,|,Bold,Italic,Underline,StrikeThrough,|,Superscript,Subscript,|,Removeformat,|,InsertTable,|,Source, skin: office2003, loadCSS: /static/css/report_print.css }); editor.loadContent(initialHtml); window.reportEditor editor; }工具欄配置需要根據(jù)檢驗報告的實際編輯場景裁剪。下標Superscript和上標Subscript必須保留檢驗報告里經常用到化學式和單位例如H?O、×10?/L。表格插入要保留因為有些報告需要臨時加兩列表格做補充說明。鏈接和圖片上傳建議去掉內網(wǎng)環(huán)境不需要而且圖片可能會破壞報告的打印排版。獲取編輯內容和保存的代碼function saveReport() { var editorHtml window.reportEditor.getSource(); var postData { applyNo: applyNo, templateCode: templateCode, editedHtml: editorHtml }; // 發(fā)送到后端保存 }這里推薦用getSource()拿源碼而不是getHtml()。因為檢驗報告里有些手工調整的格式比如特殊縮進、行內樣式只有源碼模式能精確保存下來。拿到的源碼在后端還需要做一次反向解析把人工編輯產生的覆蓋層數(shù)據(jù)和原始占位符對應的動態(tài)數(shù)據(jù)分開存儲。保存后還有一步校驗把提交回來的HTML里的動態(tài)數(shù)據(jù)區(qū)域重新檢查一遍確保沒有出現(xiàn)被篡改的檢驗數(shù)值。這一步用CSS選擇器把動態(tài)數(shù)據(jù)區(qū)標識出來白名單校驗即可。4. 實操中的典型問題與排查心得4.1 特殊符號亂碼與上下標錯位第一個讓我卡住兩天的問題是化學符號和單位上下標的顯示錯亂。報告顯示μmol/L時μ這個希臘字母在某些編輯器里會被吞成亂碼H?O的下標2在別的編輯器里又會變成普通文本。后來排查發(fā)現(xiàn)根因有兩層。第一層是字符編碼頁面整體字符集必須統(tǒng)一成UTF-8數(shù)據(jù)庫連接串里也要顯式聲明字符編碼。第二層是轉換規(guī)則檢驗結果字符串里如果出現(xiàn)了Unicode上下標字符例如U2082下標2在進入HTML前要統(tǒng)一轉換為sub標簽否則瀏覽器會顯示異常。處理方案是做一個預處理方法掃描結果字符串把上標和下標Unicode字符映射成對應的HTML標簽包裹。映射表寫清楚所有常用上標和下標字符覆蓋化學式和單位常見場景。另外乘號×、正負號±、大于等于這些符號在HTML里要保存為命名實體times;、plusmn;、ge;直接用UTF-8字符在某些瀏覽器和老打印控件下會出現(xiàn)渲染異常。這條經驗讓我把報告的字符表做了全面檢測凡是進入HTML的文本統(tǒng)一走一個字符標準化方法。4.2 空值、零值和精度問題檢驗結果不是每次都有值。有些項目沒做有些項目低于檢測下限有些項目儀器沒有報數(shù)這些空值場景在公式計算時特別容易出問題。我定的規(guī)則是公式計算時參數(shù)為空或非法值直接拋錯并在報告上顯示公式參數(shù)缺失由檢驗技師確定原因。絕不默認為0。為什么不能默認0因為0會經過運算變成一個看似合理的數(shù)字比如分母為0時計算結果無窮大還是0語義完全不同臨床醫(yī)生會誤解為真實測量結果。精度問題上我踩過一次坑。有些結果值本身是浮點型運算后出現(xiàn)0.9999999這種長尾。這個在展示上會讓人懷疑系統(tǒng)有bug。解決方案是采用BigDecimal運算在公式表里配置每類公式的舍入位數(shù)最終結果統(tǒng)一由后端格式化后在替換進HTML。前端不做任何精度處理避免兩端規(guī)則不統(tǒng)一導致不同步。4.3 報告模板版本管理與編輯日志在線編輯放開之后馬上面臨一個新問題模板改錯了怎么辦技師把某個提示語寫壞了或者格式調亂了需要能恢復到之前的狀態(tài)。模板本身要有版本號。每次內容保存如果檢測到模板結構變化生成一個新版本舊版本進入歷史列表。這個設計實現(xiàn)起來成本不高兩張表加一個復制邏輯但價值非常大。編輯日志也是必須的。誰在什么時間改了哪個報告、改了什么內容都要留痕。這里不需要記錄全量HTML只記錄diff信息或者只記錄編輯前后版本號再加上操作人、操作時間就夠用了。醫(yī)療信息系統(tǒng)對可追溯性的要求決定了這個功能不是可有可無的。4.4 外部粘貼內容導致的樣式污染技師從Word或者網(wǎng)頁里復制一段說明文字進編輯器這看起來是個普通操作但在XHEDITOR環(huán)境下會引起麻煩。Word粘貼的內容會帶大量內聯(lián)樣式和無效標簽例如span stylemso-spacerun:yes渲染出來格式混亂打印時更加失控。排查時的現(xiàn)象是整個報告多了一堆不規(guī)則的縮進、奇怪的間距部分文字字號忽大忽小。分析后確認是Word粘貼內容帶的樣式和報告模板的CSS沖突。解決方案是在保存時做一次HTML清洗把白名單之外的全部屬性過濾掉。保留的標簽只有p、br、span、b、strong、i、sub、sup、table、tr、td屬性只保留colspan、rowspan、width、height幾個必要項。清洗前在源碼模式里去掉Word粘貼那段XML頭信息效果會更好。這個清洗函數(shù)本身不復雜但字段相當考驗細心建議收集一批真實粘貼場景的HTML慢慢積累過濾規(guī)則一次做完美不太現(xiàn)實。5. 一點項目落地后的體會這套方案做完回過頭來看自己當時的第一反應其實低估了這類需求的復雜度。檢驗報告在線編輯這個事表面上是給HIS加一個富文本編輯器實際上是打破了過去報告內容由后端統(tǒng)一生成的單一路徑。只要編輯器介入就會牽出數(shù)據(jù)邊界、公式解析、版本控制、安全轉義這一整串問題。我最初的方案選了最簡單粗暴的后端整段渲染結果被反反復復的需求調整打臉最后回到占位符加替換的思路才真正跑通。我在實際項目里獲得的最大教訓是醫(yī)療信息化系統(tǒng)的改動任何功能都同時存在系統(tǒng)正確性和數(shù)據(jù)可溯源性兩個評價標準。在線編輯功能好不好用是體驗問題但動過的數(shù)據(jù)能不能追回來、算出來的結果有沒有依據(jù)是質量問題。所以那些看起來增加工作量的事情——反向解析、編輯日志、模板版本——一個都不能省。最后再分享一個小技巧在XHEDITOR初始化之前預留一個初始內容快照保存時如果編輯后的內容與快照完全一致就不用寫數(shù)據(jù)庫。這個優(yōu)化雖然很小但能過濾掉大量只打開了沒改的無效操作歷史數(shù)據(jù)干凈了后面追查改動記錄會輕松很多。