簡介面向醫(yī)療信息化開發(fā)與學(xué)習(xí)者的zebone單病種上報管理平臺完整工程包基于Java技術(shù)棧實現(xiàn)疾病數(shù)據(jù)采集、審核上報與統(tǒng)計分析的閉環(huán)流程。資源共2270個文件以Java源碼、HTML頁面、JS/CSS腳本、GIF動態(tài)截圖、SQL初始數(shù)據(jù)與XML配置為主壓縮包大小約10.57MB另含啟動、打包、初始化數(shù)據(jù)庫及清理環(huán)境的批處理命令方便本地快速部署和復(fù)現(xiàn)業(yè)務(wù)流程。項目整體呈現(xiàn)了企業(yè)級Web應(yīng)用的標(biāo)準(zhǔn)分層覆蓋MVC設(shè)計、關(guān)系型數(shù)據(jù)庫交互、RESTful接口、權(quán)限安全控制和前端可視化圖表等模塊可幫助讀者深入理解單病種場景下的數(shù)據(jù)字典設(shè)計、審核狀態(tài)流轉(zhuǎn)和上報接口對接方式。資源包內(nèi)還附帶可執(zhí)行腳本與輔助文檔適合作為Java Web醫(yī)療信息化項目的入門學(xué)習(xí)或二次開發(fā)參考。目前已有490人學(xué)習(xí)下載對希望系統(tǒng)掌握醫(yī)療上報平臺搭建思路的技術(shù)人員來說是一份結(jié)構(gòu)清晰、內(nèi)容完整的實戰(zhàn)資料。1. 單病種上報管理平臺醫(yī)生不填Excel之后上報工作才真正跑了起來每個季度末醫(yī)院病案室和信息科最怕的就是單病種數(shù)據(jù)上報——臨床科室用Excel填一堆診斷編碼、費用明細(xì)、用藥記錄再由病案室人工核對、手工清洗之后導(dǎo)進(jìn)上報系統(tǒng)。錯一個編碼整批數(shù)據(jù)被打回重填趕上截止日期前三天辦公室全是抱著電腦改表的醫(yī)生。某公司內(nèi)部孵化的這套zebone單病種上報管理平臺就是把這條手工鏈路線上化從診療環(huán)節(jié)直接抽取病例數(shù)據(jù)、按病種模板自動生成上報表單、院內(nèi)逐級審核、完成后按時段對接上級平臺。它適合兩類人看一類是醫(yī)院信息科或軟件廠商的Java開發(fā)想找一套結(jié)構(gòu)清晰的上報類業(yè)務(wù)系統(tǒng)做參照另一類是正在做醫(yī)療質(zhì)控類項目的開發(fā)者想看看填報、審核、對賬這些核心節(jié)點是怎么用Spring Boot這類主流Java技術(shù)棧落地的。2. 技術(shù)選型與工程結(jié)構(gòu)Spring Boot MyBatis-Plus 的分模塊單體架構(gòu)2.1 為什么選分模塊單體而不是微服務(wù)這類單病種上報系統(tǒng)的使用場景很明確醫(yī)院內(nèi)網(wǎng)部署用戶量是全院醫(yī)生和質(zhì)控人員高峰期集中在月底和季末并發(fā)量不像互聯(lián)網(wǎng)系統(tǒng)那么夸張但對數(shù)據(jù)一致性、事務(wù)邊界、權(quán)限控制的要求非常高。技術(shù)選型上管理端用Spring Boot 2.x作為基礎(chǔ)框架數(shù)據(jù)訪問層用MyBatis-Plus數(shù)據(jù)庫用MySQL緩存用Redis前端是Vue加Element UI報表部分接ECharts。整體沒有拆微服務(wù)而是做成分模塊單體——把業(yè)務(wù)按邊界切成report、system、patient、stat幾個模塊編譯產(chǎn)物還是同一個工程。選擇分模塊單體而不是微服務(wù)的原因很實際單病種上報平臺的核心數(shù)據(jù)是院內(nèi)病例和上報記錄模塊間調(diào)用頻繁拆成微服務(wù)后網(wǎng)絡(luò)開銷和分布式事務(wù)成本遠(yuǎn)大于收益。分模塊單體保留了業(yè)務(wù)邊界清晰、便于后期拆分的優(yōu)點同時開發(fā)調(diào)試簡單內(nèi)網(wǎng)單機(jī)部署就能支撐全院使用。工程名叫zeboneMaven坐標(biāo)大致可以分為幾個子模塊zebone-admin負(fù)責(zé)后臺接口聚合zebone-framework放通用安全、異常處理、工具類zebone-system做用戶角色和科室機(jī)構(gòu)管理zebone-patient管理患者主索引和病例數(shù)據(jù)zebone-report是核心上報模塊zebone-stat是統(tǒng)計報表模塊zebone-common放公共配置和實體類。2.2 目錄結(jié)構(gòu)與模塊職責(zé)整個工程是標(biāo)準(zhǔn)的Maven多模塊結(jié)構(gòu)啟動入口在zebone-admin模塊。你克隆代碼之后先別急著找application.yml它不在某個固定的地方而是在zebone-admin的src/main/resources下里面有數(shù)據(jù)源、Redis、文件上傳等配置。我一般拿到這類多模塊工程會先花十分鐘過一遍pom.xml的依賴關(guān)系搞清楚模塊之間的引用方向后續(xù)改代碼時才知道動一個類會影響哪些模塊。zebone ├── zebone-admin # 啟動入口Controller層聚合 ├── zebone-common # 通用工具、常量、公共實體 ├── zebone-framework # 安全框架、異常處理、配置類 ├── zebone-system # 用戶、角色、科室、菜單管理 ├── zebone-patient # 患者索引、病案首頁、診斷信息 ├── zebone-report # 單病種模板、填報、審核、上報 ├── zebone-stat # 上報統(tǒng)計、質(zhì)控指標(biāo)、圖表數(shù)據(jù)zebone-report是整個平臺的核心它內(nèi)部又按職責(zé)拆了子包template包管理病種模板定義form包處理填報數(shù)據(jù)review包處理審核流程report包負(fù)責(zé)生成上報文件和對接外部平臺。這樣拆的好處是新增一個病種時大多數(shù)情況只需要在template里加一條模板配置不用動其他包。2.3 數(shù)據(jù)模型設(shè)計的幾個關(guān)鍵表單病種上報的數(shù)據(jù)模型設(shè)計核心是搞清楚“病種模板”和“填報數(shù)據(jù)”之間的關(guān)系。平臺上每一個單病種對應(yīng)一張病種定義表disease_config存儲病種名稱、ICD-10編碼、適用科室、上報周期、上級平臺要求的必填字段標(biāo)識。而每個病人的具體填報數(shù)據(jù)存在single_disease_report表里一條記錄代表一次填報。這個設(shè)計的巧妙之處在于模板和數(shù)據(jù)分離——上級平臺調(diào)整上報字段時只需要改模板配置歷史填報數(shù)據(jù)不受影響。另一個關(guān)鍵設(shè)計是上報批次表。對接上級平臺不是一條條實時推送而是按批次批量上報批次表記錄每次上報的時間段、病種、數(shù)據(jù)量、上報結(jié)果和失敗原因。這樣設(shè)計的好處是出現(xiàn)網(wǎng)絡(luò)超時或接口返回校驗錯誤時可以精準(zhǔn)定位到某個批次的某幾條數(shù)據(jù)手動修正后重新上報而不是把整個時間段的數(shù)據(jù)重新推一遍。3. 核心模塊拆解一條上報數(shù)據(jù)從錄入到對接的完整鏈路3.1 病例數(shù)據(jù)自動匹配病種模板在單病種上報系統(tǒng)里最煩瑣的工作是判斷一個病例該填報哪個病種。傳統(tǒng)做法是醫(yī)生手工選擇但這套系統(tǒng)的做法是自動匹配患者出院后系統(tǒng)根據(jù)病案首頁的出院診斷ICD-10編碼去disease_config表里匹配適用的病種模板。比如ICD-10編碼I21開頭的是急性心肌梗死系統(tǒng)會自動為該病例掛上對應(yīng)的上報模板。匹配邏輯用MyBatis-Plus的QueryWrapper就能實現(xiàn)public DiseaseConfig matchDiseaseConfig(String icd10Code) { LambdaQueryWrapperDiseaseConfig wrapper new LambdaQueryWrapper(); wrapper.eq(DiseaseConfig::getStatus, 1) .likeRight(DiseaseConfig::getIcd10Prefix, icd10Code.substring(0, 3)); ListDiseaseConfig configs diseaseConfigMapper.selectList(wrapper); if (configs.isEmpty()) { return null; } // 取匹配度最高的模板 return configs.stream() .max(Comparator.comparingInt(c - c.getIcd10Prefix().length())) .orElse(null); }這里用了likeRight查詢目的是匹配ICD-10前綴。參數(shù)說明icd10Code是病案首頁上的完整診斷編碼比如I21.001disease_config表中的icd10_prefix字段存的是模板對應(yīng)的編碼前綴可能是I21也可能是更精確的I21.0。取匹配度最高的模板是因為一個診斷可能命中多個模板前綴越長越精確。匹配不到時返回null由人工處理避免大量漏報數(shù)據(jù)直接流入審核環(huán)節(jié)。自動匹配的邏輯能覆蓋大約80%的病例剩下一部分需要人工干預(yù)比如診斷編碼書寫不規(guī)范、復(fù)合病種等。平臺在人工核查頁面會把未匹配的病例列出來操作員手動指定病種模板。3.2 動態(tài)表單渲染與填報數(shù)據(jù)暫存匹配到模板后前端要根據(jù)模板配置動態(tài)渲染表單。模板的字段定義不寫死在頁面里而是以JSON結(jié)構(gòu)存儲在disease_config的field_define字段中。字段定義包含字段名、中文標(biāo)簽、類型input、select、date、number、是否必填、校驗規(guī)則、下拉選項數(shù)據(jù)源等。前端拿到這個JSON后用動態(tài)渲染組件生成表單頁面。后端提供接口給前端獲取模板詳情public DiseaseTemplateVO getTemplateDetail(Long diseaseId) { DiseaseConfig config diseaseConfigMapper.selectById(diseaseId); if (config null) { throw new BizException(病種模板不存在); } DiseaseTemplateVO vo new DiseaseTemplateVO(); vo.setDiseaseName(config.getDiseaseName()); vo.setIcd10(config.getIcd10Prefix()); // fieldDefine存的是JSON字符串直接透傳給前端渲染 vo.setFieldDefine(JSON.parseArray(config.getFieldDefine())); vo.setReviewFlow(config.getReviewFlow()); return vo; }這里有個容易踩坑的地方field_define直接透傳給前端時必須確保是合法JSON否則前端渲染直接白屏。常見做法是存儲時就校驗JSON格式查詢出庫時再用JSON.parseArray校驗一次解析失敗時記錄日志并返回默認(rèn)模板結(jié)構(gòu)。這樣做的意義是單病種平臺經(jīng)常要跟著上級文件調(diào)整上報字段如果字段寫死在頁面代碼里每次調(diào)整都要發(fā)版更新動態(tài)表單把調(diào)整成本降低到改一條數(shù)據(jù)庫記錄。填報數(shù)據(jù)本身也存在JSON字段里平臺對高頻查詢字段病種ID、患者ID、填報狀態(tài)、填報時間做了獨立列低頻查詢的明細(xì)字段放在form_data的JSON列中。這樣設(shè)計在查詢列表頁時只需查主表點開詳情時才解析JSON避免大字段拖慢列表查詢。3.3 審核狀態(tài)機(jī)從草稿到已上報填報完成后的數(shù)據(jù)不是直接上報要走院內(nèi)審核流程。審核流程在disease_config里配置通常是“臨床填報 → 科室質(zhì)控員審核 → 病案室終審”每個環(huán)節(jié)只有指定角色能操作。審核狀態(tài)我習(xí)慣用整數(shù)表示0草稿、1待審核、2審核退回、3審核通過、4已上報、5上報失敗。狀態(tài)流轉(zhuǎn)的核心代碼如下Transactional(rollbackFor Exception.class) public void review(Long reportId, Integer action, String opinion) { SingleDiseaseReport report reportMapper.selectById(reportId); if (report null) { throw new BizException(上報記錄不存在); } // action: 1通過 2退回 if (action 1) { if (report.getStatus() ! 1) { throw new BizException(當(dāng)前狀態(tài)不允許審核通過); } report.setStatus(3); } else if (action 2) { report.setStatus(2); } report.setReviewOpinion(opinion); report.setReviewTime(LocalDateTime.now()); reportMapper.updateById(report); }這里加Transactional是因為審核操作要同時更新主表和審核日志表任何一步失敗都要回滾避免狀態(tài)和數(shù)據(jù)對不上。代碼里的關(guān)鍵是先校驗當(dāng)前狀態(tài)再執(zhí)行流轉(zhuǎn)防止單人重復(fù)提交導(dǎo)致狀態(tài)錯亂。實際使用時要注意并發(fā)問題兩個審核員同時審核同一條數(shù)據(jù)后提交的會覆蓋先提交的意見。我一般會加一個樂觀鎖版本號字段更新的SQL里帶上version條件更新影響行數(shù)為0時說明數(shù)據(jù)被改過拋出提示。3.4 上報對接與失敗重試審核通過的數(shù)據(jù)會進(jìn)入上報隊列定時任務(wù)按批次拉取已審核數(shù)據(jù)調(diào)用上級平臺的WebService或HTTP接口推送。對接外部接口要處理幾種異常網(wǎng)絡(luò)超時、對方返回業(yè)務(wù)校驗錯誤、數(shù)據(jù)格式不正確。平臺的做法是每個批次單獨記錄狀態(tài)失敗的數(shù)據(jù)支持單條重推。public ReportBatchResult pushBatch(ListLong reportIds) { ReportBatch batch new ReportBatch(); batch.setBatchNo(generateBatchNo()); batch.setStatus(0); reportBatchMapper.insert(batch); int successCount 0; for (Long reportId : reportIds) { SingleDiseaseReport report reportMapper.selectById(reportId); try { String requestXml buildRequestXml(report); String responseXml diseaseReportClient.pushSingle(requestXml); if (parseResponseCode(responseXml) 0) { report.setStatus(4); successCount; } else { report.setStatus(5); saveFailLog(report.getId(), parseResponseMsg(responseXml)); } } catch (Exception e) { report.setStatus(5); saveFailLog(report.getId(), e.getMessage()); } reportMapper.updateById(report); } batch.setSuccessCount(successCount); batch.setFailCount(reportIds.size() - successCount); batch.setStatus(1); reportBatchMapper.updateById(batch); return buildResult(batch); }上報邏輯里最需要注意的是部分成功場景一批10條數(shù)據(jù)可能5條成功5條失敗。如果整體事務(wù)回滾成功的5條也要退回重推造成重復(fù)上報如果不回滾失敗的要支持精準(zhǔn)重試。上面這種實現(xiàn)是每條數(shù)據(jù)獨立處理失敗記錄寫到fail_log表后續(xù)按批次號和報告ID精準(zhǔn)重推。真實對接中還會遇到一個問題對方接口的冪等性不好同一條數(shù)據(jù)推兩次會生成兩條記錄。解決方案是batch_no加report_id生成唯一請求體流水號對方接口按流水號去重不過這就依賴外部平臺是否支持了。4. 本地部署與運行從克隆代碼到前后臺聯(lián)通4.1 環(huán)境準(zhǔn)備與配置修改先把工程跑起來需要準(zhǔn)備的環(huán)境是JDK 1.8以上、Maven 3.6以上、MySQL 5.7以上、Redis任意穩(wěn)定版本前端需要Node.js 14以上。代碼克隆下來后先別急著啟動把配置文件過一遍。zebone-admin模塊下的application-dev.yml是開發(fā)環(huán)境配置主要關(guān)注三個地方數(shù)據(jù)源連接信息、Redis連接信息、文件上傳路徑。spring: datasource: url: jdbc:mysql://localhost:3306/zebone?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 database: 0 mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl數(shù)據(jù)源配置里serverTimezone必須設(shè)成Asia/Shanghai否則LocalDateTime類型在JDBC驅(qū)動里會差8小時。MyBatis-Plus的map-underscore-to-camel-case開啟后數(shù)據(jù)庫的snake_case字段能自動映射到Java的駝峰屬性這個配置對于減少實體類注解非常關(guān)鍵。log-impl在開發(fā)環(huán)境打開SQL日志方便排查問題生產(chǎn)環(huán)境記得關(guān)掉。4.2 初始化數(shù)據(jù)庫與啟動后端工程里帶了數(shù)據(jù)庫初始化腳本是sql目錄下的zebone_init.sql包含建表語句和基礎(chǔ)數(shù)據(jù)。執(zhí)行腳本時要注意MySQL的sql_mode如果包含ONLY_FULL_GROUP_BY部分統(tǒng)計SQL會報錯。建議在連接串上去掉這個模式或單獨設(shè)置mysql -u root -p sql/zebone_init.sql初始化腳本執(zhí)行完畢后用IDEA打開工程根目錄等待Maven下載依賴。這里有個血淚經(jīng)驗Maven依賴下載慢或失敗先檢查鏡像配置在settings.xml里配阿里云鏡像能解決大部分問題。依賴就緒后在zebone-admin模塊找到ZeboneAdminApplication啟動類直接運行main方法。后端啟動成功的標(biāo)志是控制臺出現(xiàn)Tomcat started on port(s): 8080同時初始化腳本里內(nèi)置了一個管理員賬號用戶名admin密碼存在數(shù)據(jù)庫里首次登錄后強(qiáng)制修改。4.3 前端啟動與登錄驗證前端工程在源碼的web目錄下是標(biāo)準(zhǔn)的Vue項目。安裝依賴并啟動cd web npm install npm run dev默認(rèn)開發(fā)服務(wù)器端口是9527Vue項目通過環(huán)境變量VUE_APP_BASE_API來配置后端接口地址開發(fā)環(huán)境默認(rèn)指向http://localhost:8080。在vue.config.js里配置了代理把/api路徑轉(zhuǎn)發(fā)到8080端口所以前端頁面訪問后端接口不需要處理跨域。啟動完成后瀏覽器打開http://localhost:9527用初始賬號登錄進(jìn)入主界面后先看左側(cè)菜單填報管理、審核管理、上報管理、統(tǒng)計報表、系統(tǒng)管理能正常打開列表頁并加載出數(shù)據(jù)說明前后臺聯(lián)通成功。常見的問題是前端頁面一片空白且控制臺報404這種情況通常是接口地址配置不對或者后端還沒完全啟動。先訪問一下http://localhost:8080/api/health看后端是否存活再檢查.env.development文件里VUE_APP_BASE_API的值。5. 常見問題與避坑字段丟失、狀態(tài)卡死、SQL超時的排查5.1 前端提交時間字段比數(shù)據(jù)庫少了8小時現(xiàn)象填報頁面選擇的日期時間保存后數(shù)據(jù)庫里存的值比選擇值少8小時或者查詢時時間對不上。 原因項目時區(qū)配置不一致。前端JavaScript的Date對象默認(rèn)使用瀏覽器時區(qū)后端如果沒配置Jackson的時區(qū)序列化和反序列化時按UTC處理就會產(chǎn)生8小時偏移。 解決在application.yml里配置Jackson時區(qū)確保全局生效spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8同時數(shù)據(jù)庫連接串里保留serverTimezoneAsia/Shanghai。排查時需要檢查三個環(huán)節(jié)的時鐘一致性前端傳遞字符串而不是時間戳、后端接收時指定DateTimeFormat、數(shù)據(jù)庫字段用datetime而不是timestamp。5.2 動態(tài)表單字段值提交后部分丟失現(xiàn)象填報頁面能正常顯示所有字段但保存成功后重新打開部分字段值為空特別是下拉選擇類字段。原因排查下拉選擇類字段的值可能不在字段定義JSON中配置的option里前端復(fù)選時存儲了額外屬性而保存時只序列化value值導(dǎo)致重新渲染時找不到對應(yīng)顯示文本。另一種常見原因是提交的數(shù)據(jù)結(jié)構(gòu)與fieldDefine定義不一致比如字段key是cure_way但表單提交的是cureWay前后端命名沒對齊后端按cure_way解析取不到值。 解決約定提交的數(shù)據(jù)key必須與fieldDefine中的fieldKey完全一致在保存接口增加校驗邏輯private void validateFormData(DiseaseConfig config, MapString, Object formData) { ListFieldDefine fields JSON.parseArray(config.getFieldDefine(), FieldDefine.class); for (FieldDefine field : fields) { Object value formData.get(field.getFieldKey()); // 必填字段為空時報錯用于提示 if (field.getRequired() 1 (value null || StringUtils.isBlank(value.toString()))) { throw new BizException(字段 [ field.getLabel() ] 不能為空); } // 下拉框值校驗必須在可選范圍 if (field.getType().equals(select) value ! null !field.getOptions().contains(value.toString())) { throw new BizException(字段 [ field.getLabel() ] 存在非法選項); } } }做完校驗之后前端保存時要用JSON.stringify整個formData對象后端以String類型存入form_data字段不逐字段映射從根源上避免字段缺失。5.3 審核并發(fā)導(dǎo)致狀態(tài)覆蓋現(xiàn)象同一條上報記錄兩個審核員同時操作后提交的審核意見覆蓋了先提交的且狀態(tài)不符合預(yù)期。 原因?qū)徍烁掠胾pdateById直接覆蓋所有字段沒有做版本控制。在并發(fā)場景下兩個線程同時讀到status1處理完后各自寫回最終只有最后一次寫回生效。 解決在single_disease_report表加version字段更新SQL帶上version條件Update(UPDATE single_disease_report SET status #{status}, version version 1 WHERE id #{id} AND version #{version}) int updateStatusWithVersion(Param(id) Long id, Param(status) Integer status, Param(version) Integer version);代碼里先查version執(zhí)行更新時把查到的version傳進(jìn)去。影響行數(shù)為0時說明期間有其他人更新過數(shù)據(jù)此時應(yīng)該重新加載數(shù)據(jù)并提示操作員“該記錄已被他人處理請刷新后重試”。5.4 批量上報超時與內(nèi)存溢出現(xiàn)象月底集中上報時一次性拉取幾千條已審核數(shù)據(jù)定時任務(wù)執(zhí)行了一分鐘左右直接報超時或OOM。 原因分析上報邏輯是把所有待上報的記錄ID一次性查出來然后循環(huán)逐條推送。數(shù)據(jù)量大時MyBatis查詢?nèi)繉ο笤趦?nèi)存中堆積同時單條推送網(wǎng)絡(luò)IO耗時疊加總耗時不可控。 解決分批處理每次拉取100條處理完再拉下一批。同時對單條數(shù)據(jù)增加超時控制用HttpClient的connectTimeout和socketTimeout限制在10秒以內(nèi)防止單條數(shù)據(jù)卡住整個批次。5.5 數(shù)據(jù)權(quán)限過濾導(dǎo)致列表數(shù)據(jù)缺失現(xiàn)象質(zhì)控員登錄后列表頁只能看到自己科室的數(shù)據(jù)但切換科室查詢條件后數(shù)據(jù)條數(shù)變化不對。 原因排查系統(tǒng)做了數(shù)據(jù)權(quán)限控制MyBatis-Plus攔截器自動追加了科室過濾條件。如果科室ID在session里存儲不當(dāng)或者關(guān)聯(lián)查詢時別名不一致可能會出現(xiàn)過濾條件追加錯表的情況。 解決定位到權(quán)限攔截器DataScopeInterceptor查看SQL解析后追加的條件AND (dept_id 1001)確認(rèn)dept_id是哪張表的字段。如果去掉權(quán)限攔截器后列表數(shù)據(jù)正常說明問題出在權(quán)限SQL的拼接待上重點檢查多表關(guān)聯(lián)時是否用了正確的表別名。這類問題在審核列表多表關(guān)聯(lián)查詢中比較容易出現(xiàn)。6. 二次開發(fā)指南給平臺新增一個單病種并優(yōu)化對賬邏輯6.1 新增病種的具體操作步驟單病種上報平臺最頻繁的二次開發(fā)需求就是新增病種。因為上級機(jī)構(gòu)的病種管理范圍會不斷調(diào)整平臺維護(hù)哪些病種是動態(tài)的。以前手工方式要改表結(jié)構(gòu)、加頁面、寫接口現(xiàn)在這套設(shè)計下大部分新增病種只需要配置化完成。第一步在disease_config表插入一條記錄。disease_name填病種名稱icd10_prefix填對應(yīng)的ICD-10編碼前綴status設(shè)為1啟用。核心字段是field_define需要按平臺約定的JSON結(jié)構(gòu)定義字段以新增“急性病毒性肝炎”為例至少要包含入院時間、出院時間、乙肝五項結(jié)果、抗病毒用藥情況等字段。[ {fieldKey: admission_date, label: 入院時間, type: date, required: 1}, {fieldKey: discharge_date, label: 出院時間, type: date, required: 1}, {fieldKey: hbsag, label: 乙肝表面抗原, type: select, required: 1, options: [陽性, 陰性, 未查]}, {fieldKey: antiviral_drug, label: 抗病毒用藥, type: input, required: 0} ]第二步是配置審核流程review_flow字段填JSON數(shù)組比如[{role: dept_quality, action: audit}, {role: record_room, action: finalize}]按順序執(zhí)行。第三步在disease_config表中配置上報周期和關(guān)聯(lián)的上報接口編碼完成后前端不需要改動填報頁面、審核頁面、上報邏輯全部復(fù)用現(xiàn)有功能。我改造過這類系統(tǒng)有兩點建議新增病種上線前用病案首頁數(shù)據(jù)跑一遍自動匹配看ICD-10編碼前綴設(shè)計是否合理同時準(zhǔn)備幾份測試數(shù)據(jù)走完整流程重點驗證動態(tài)表單渲染有沒有格式錯誤。6.2 優(yōu)化定時任務(wù)的對賬邏輯上線之后遇到最麻煩的問題是對賬。上報接口推送成功后對方平臺可能在異步處理中出現(xiàn)數(shù)據(jù)丟失導(dǎo)致我方顯示已上報而對方平臺查不到記錄。剛開始的解決方式是人工比對導(dǎo)出我方上報批次和對方查詢結(jié)果費時費力且容易漏查。后來在定時任務(wù)中增加了一個對賬補償邏輯每次推送成功后把批次信息寫入一個本地對賬表每天凌晨定時查詢對方平臺的記錄接口比對后發(fā)現(xiàn)對方缺失的數(shù)據(jù)自動觸發(fā)重推。Component public class ReconciliationTask { Scheduled(cron 0 0 1 * * ?) public void reconcile() { LocalDateTime yesterday LocalDateTime.now().minusDays(1); ListReportBatch batches reportBatchMapper.selectList( new LambdaQueryWrapperReportBatch() .ge(ReportBatch::getCreateTime, yesterday) .eq(ReportBatch::getStatus, 1)); for (ReportBatch batch : batches) { ListLong reportIds batch.getReportIds(); // 查詢對方平臺是否已有對應(yīng)記錄 ListLong confirmedIds diseaseReportClient.queryConfirmed(batch.getBatchNo(), reportIds); ListLong missingIds reportIds.stream() .filter(id - !confirmedIds.contains(id)) .collect(Collectors.toList()); // 對缺失數(shù)據(jù)重新上報 if (!missingIds.isEmpty()) { pushBatch(missingIds); } } } }這里的參數(shù)說明Scheduled的cron表達(dá)式表示每天凌晨1點執(zhí)行避開業(yè)務(wù)高峰。queryConfirmed傳入批次號和本地上報ID列表返回對方平臺能查到的ID集合。missingIds就是本地認(rèn)為已上報但對方查不到的記錄觸發(fā)重推。注意重推前要判斷數(shù)據(jù)當(dāng)前狀態(tài)避免把審核中的數(shù)據(jù)誤推。做這套優(yōu)化時有兩點經(jīng)驗一是對賬窗口不能太長取前一天的數(shù)據(jù)就行太早的數(shù)據(jù)可能已經(jīng)被清理二是重推要加次數(shù)限制比如連續(xù)重推3次仍失敗就告警交給人工處理避免死循環(huán)。從那以后我每次給上報類系統(tǒng)設(shè)計對接方案時都會把對賬補償機(jī)制放在架構(gòu)圖里而不是等上線后出了問題再補。數(shù)據(jù)對接這事推送成功不代表對方真的入庫了只有閉環(huán)校驗過才真正放心。希望這篇拆解能幫你在跑通這個單病種平臺時少踩幾個坑也給你后續(xù)做同類系統(tǒng)提供一些可復(fù)用的設(shè)計思路。本文還有配套的精品資源點擊獲取