早上七点四十检验科的门刚开生化室的老师已经坐在工作站前双击桌面上的客户端图标输入工号和口令屏幕上刷出当天已经签收的标本列表——这一刻整套系统的响应速度、列表排序方式、异常标本的标红逻辑全都要在几秒钟内接受真实工作节奏的检验。我接触过不少基于 C/S 架构的医学检验实验室信息管理系统也就是大家常说的 LIS 源码很多人拿到手的第一反应是这年头怎么还有客户端但真正在科室里蹲过几个早上就会明白工作台前的操作效率、条码枪的即时响应、仪器串口的稳定收数这些东西决定了 C/S 在检验场景里依然有很强的生命力。这篇内容我打算把这类源码拆开讲它到底由哪些模块拼起来一条标本从申请到报告发布在代码里是怎么流转的仪器双向通讯这个最容易翻车的部分该怎么看室内质控的数学逻辑怎么落到表结构里以及把源码真正部署到科室之前必须先想清楚的几件事。适合正在评估这类系统源码的开发者、需要二次开发的技术人员也适合检验科里负责对接信息系统的老师用来判断一套系统到底靠不靠谱。1. C/S 架构在检验科工作台前为什么依然站得住1.1 科室里的物理环境决定了客户端的形态检验科不是办公室。生化、免疫、血球、凝血、尿沉渣、微生物每个专业组都有自己的仪器区工作台旁边就是分析仪中间常常只隔一道矮挡板。技师的手是戴着手套的很多时候还要一边盯着仪器屏幕一边敲键盘鼠标点错一个按钮就可能把标本号录到别人头上。这种环境下C/S 客户端的优势非常实在本地渲染、按键即时反馈、可以深度绑定本地设备资源比如条码枪、标签打印机、串口通讯端口、本地缓存的结果草稿。浏览器方案要用到串口就得中间件要用到标签打印就得装打印控件绕一圈反而更脆弱。源码层面这类系统通常由三块组成WinForm 或 WPF 写的客户端、中间的业务服务层、SQL Server 或 Oracle 的数据库。也有不少直接做成胖客户端 直连数据库的两层结构早期项目尤其多。两层结构的优点是开发和部署都简单客户端直接开连接串增删改查一目了然缺点是任何一个客户端出问题都可能拖垮数据库连接池而且业务逻辑散落在各个窗体里改一条规则要满项目找。我的建议是如果拿到的源码是两层结构不要急着重构先确认连接管理有没有做连接池上限、有没有统一的数据库访问封装类。如果没有改造优先级最高的是把所有窗体的直连 SQL 收敛到一个数据访问层这件事的工作量远小于彻底改三层但对稳定性的提升立竿见影。1.2 三层结构在 LIS 源码里通常怎么落地比较规范的三层项目目录结构一般长这样Lis.Client所有 WinForm 窗体按专业组划分文件夹比如Biochem、Hematology、MicrobiologyLis.Business业务规则标本状态机、报告审核、危急值判定、质控判定都在这一层Lis.DataAccess数据访问通常配一个DbHelper或使用轻量 ORMLis.Instrument仪器通讯串口/网口监听、报文解析、结果回写Lis.Common公共类日志、加密、配置读取、打印Lis.Service常驻服务负责抓取仪器原始数据、定时任务、与外部系统交换数据关键是Lis.Instrument这一层。很多项目把它做成客户端的一部分结果就是某台工作站关机了那台仪器就收不到数据。正确的做法是仪器通讯跑在独立的 Windows 服务里客户端只负责展示和人工干预。这一点在源码评审时很容易看出来如果串口打开的动作写在某个窗体里那基本可以判定这套代码是在单机环境下长出来的上多客户端就会出问题。1.3 什么时候真的该考虑客户端之外的方案不是所有场景都适合 C/S。如果使用方是社区检验点、体检车、外送采样点客户端部署和维护成本会变得不可接受如果主要使用者是临床医生只需要查看报告那完全没必要装客户端浏览器或者移动端更合适。我见过的比较务实的架构是客户端负责检验科内部高强度录入Web 端负责临床查询和报告浏览两边共用同一个业务服务层。这种混合方案在源码里如果已经预留了服务接口哪怕是 WebAPI 或者简单的 Socket 服务二次开发的成本会低很多。判断标准其实很简单看源码里有没有把业务逻辑和界面事件彻底分开。如果审核报告这个动作在窗体按钮的 Click 事件里写了三十行 SQL那基本没有扩展余地如果它调用的是ReportService.Audit(reportId, userId, password)那不管以后套什么前端都能复用。2. 一条标本从申请到报告发布在数据表里是怎么走完的2.1 样本主表与状态机是整个系统的骨架LIS 的核心不是界面是那张标本主表和它上面挂的状态字段。我见过的设计里比较合理的是单独设一个状态字段然后用一个枚举去约束取值而不是用一堆布尔字段IsSigned、IsTested、IsAudited来表达进度。原因很直接布尔字段无法表达顺序也没法防止未签收就直接审核这种非法流转。典型的枚举值大致是这样一串状态码状态名触发动作责任人10已申请医生站开单或手工登记申请医生20已采样护士采样并打印条码采样护士30已签收检验科扫码接收标本接收岗40已上机仪器开始检测仪器自动50结果已回传仪器或手工录入完成仪器/技师60已初审技师复核结果检验技师70已终审审核医师签发审核医师80已发布报告可被临床查看系统自动90已打印报告打印完成打印岗状态机的实现在业务层里应该是一个显式的字典比如Dictionaryint, int[]表示当前状态允许迁移到哪些状态每次更新前先校验。这种写法看起来笨但它能把跳过初审直接终审这类问题挡在代码层面而不是靠操作规范。private static readonly Dictionaryint, int[] AllowedTransitions new() { { 10, new[] { 20, 99 } }, // 已申请 - 已采样 / 已作废 { 20, new[] { 30, 99 } }, // 已采样 - 已签收 / 已作废 { 30, new[] { 40, 99 } }, { 40, new[] { 50 } }, { 50, new[] { 60, 30 } }, // 结果回传后可初审也可退回重测 { 60, new[] { 70, 50 } }, // 初审后可终审也可退回 { 70, new[] { 80 } }, { 80, new[] { 90 } } }; public void ChangeStatus(string sampleId, int targetStatus, string operatorId) { var current _sampleRepo.GetStatus(sampleId); if (!AllowedTransitions.TryGetValue(current, out var allowed) || !allowed.Contains(targetStatus)) { throw new BusinessException($标本 {sampleId} 不允许从状态 {current} 迁移到 {targetStatus}); } _sampleRepo.UpdateStatus(sampleId, targetStatus, operatorId, DateTime.Now); _logRepo.Write(sampleId, current, targetStatus, operatorId); }这段代码没什么技术含量但它是整套系统的防呆底线。实际做二开时我见过有人为了方便直接在 SQL 里改状态结果历史报告对不上追溯的时候完全抓瞎。状态变更必须走统一入口并且写日志这一条是硬要求。2.2 条码规则与申请单的绑定关系条码是整个流程的物理载体条码规则的设计会直接影响后续的排错效率。常见的规则是日期 专业组代码 流水号比如240618 SH 0001长度控制在 10 到 14 位之间因为很多老式条码枪和标签打印机对这个长度最友好。源码里需要重点关注两处第一处是条码唯一性校验的时机。有些实现是在生成时查一次数据库看着没问题但在并发下会重号稳妥做法是用数据库唯一索引兜底插入失败再重试生成而不是只靠应用层判断。第二处是一个条码对应多个检验项目的处理。实际业务里一管血可能同时做肝功能和肾功能这两组项目可能落在不同专业组。源码里如果设计成一条标本记录 多条明细记录那签收、上机、结果回传都要按明细走如果设计成一条标本一条记录、项目用逗号拼接那后期按项目查询、按项目质控都会变成灾难。看到后者基本可以直接判定这套源码不适合规模化使用。CREATE TABLE Lis_Sample ( SampleId VARCHAR(24) NOT NULL PRIMARY KEY, Barcode VARCHAR(32) NOT NULL, PatientId VARCHAR(32) NOT NULL, PatientName NVARCHAR(50) NOT NULL, Gender CHAR(1) NULL, Age INT NULL, AgeUnit CHAR(1) NULL, DeptCode VARCHAR(20) NULL, BedNo VARCHAR(20) NULL, SampleType VARCHAR(20) NULL, Status INT NOT NULL DEFAULT 10, CollectTime DATETIME NULL, ReceiveTime DATETIME NULL, ReportTime DATETIME NULL, IsUrgent BIT NOT NULL DEFAULT 0, Remark NVARCHAR(200) NULL ); CREATE UNIQUE INDEX UX_Lis_Sample_Barcode ON Lis_Sample(Barcode); CREATE INDEX IX_Lis_Sample_Status ON Lis_Sample(Status, ReceiveTime);注意IsUrgent这个字段。急诊标本的优先级处理在真实科室里极其关键源码里如果只是打个红色标记而没有在查询排序、仪器上机队列、结果审核队列里做优先级提升那这个字段等于没做。2.3 报告审核环节里那些容易被忽略的拦截审核是 LIS 里业务规则最密集的一步。除了常规的结果是否为空结果是否超出线性范围还有几个必须做的拦截危急值拦截结果触发危急值阈值时必须弹出提醒并强制记录通知过程通知时间、被通知人、复述确认人。这个记录在源码里应该是一张独立的表而不是塞在备注字段里。结果与历史值偏离过大同一个人上次结果和这次相差数倍系统应该提示复核防止标本搞错或者仪器漂移。未做质控或质控失控时禁止发布这条规则实现起来需要质控模块和审核模块联动很多源码里是断开的。审核人资质校验初级职称不能终审某些项目这需要权限表里带上资质字段。危急值提醒的实现要特别注意一点不能做成点一下就关的提示框。必须是一个阻塞式窗口用户要么填写通知记录要么明确选择暂不处理并留下原因否则就是一个形同虚设的功能。3. 仪器双向通讯整套源码里最考验功力的部分3.1 ASTM 与 HL7 在实现上的实际差异医学检验仪器通讯主流就两大协议族。ASTM E1394 更老但更常见尤其在生化、血球、尿液分析这类设备上HL7 v2.x 在免疫、分子、微生物和部分新设备上用得多。两者在代码实现上的差别不小。ASTM 是典型的帧结构每帧以ENQ0x05开头仪器发STX加数据末尾ETX加校验和接收方回ACK0x06。数据部分按记录类型分行H是消息头P是患者信息O是申请信息R是结果L是结束。解析的时候要按|和^两级分隔符拆。HL7 则是纯文本消息MSH开头定义编码字符后面PID患者、OBR申请、OBX结果字段之间同样用|但复合字段用^~\这四个字符定义。相比 ASTMHL7 的字段位置更严格差一个位置就可能解析全错。实际操作里我倾向于把协议解析抽成一个接口public interface IInstrumentProtocol { string ProtocolName { get; } InstrumentMessage Parse(byte[] raw); byte[] BuildQuery(string sampleBarcode); byte[] BuildAck(); }然后 ASTM 和 HL7 各写一个实现类仪器配置表里存一个协议名运行时反射创建。这样后期加新仪器只需要加一个类不用改主流程。3.2 串口和网口的连接参数该怎么配串口通讯是最容易出问题的地方。常见参数是波特率 9600 或 192008 数据位、1 停止位、无校验但不同厂家差别很大必须以仪器说明书为准。源码里的配置表至少要包含配置项说明常见取值通讯方式串口或 TCPCOM / TCP端口号串口号或 IP:PortCOM3 / 192.168.1.50:5100波特率仅串口有效9600 / 19200 / 38400数据位仅串口有效8停止位仅串口有效1校验位仅串口有效None / Even协议类型ASTM / HL7ASTM双向开关是否支持查询true / false结果回传超时秒30现场调试时我的习惯是先开一个串口抓包工具让仪器做一次测试把原始字节流存下来再对照解析代码逐字段核对。这一步省不得因为协议文档和实际报文对不上的情况太常见了——有的仪器说明书写的字段顺序和实际发出来的就是反的还有的仪器在结果为空时不是留空而是发一个空格解析的时候不做 Trim 就会出错。TCP 方式相对稳定但要处理断线重连。源码里如果写的是TcpClient.Connect()然后一个 while 循环读一旦网络抖动就会抛异常退出。正确的做法是包一层重连机制加心跳检测并且把接收缓冲区的处理做成按帧边界拆分而不是简单地Read一次就当一条消息。3.3 结果匹配不上的四类原因双向通讯上线后最常见的抱怨就是结果回不来。排查下来基本集中在四类条码格式不一致。仪器读到的条码带校验位LIS 里存的不带或者反过来。解决办法是在配置里加一个条码截取规则比如去掉前两位、去掉最后一位。标本号与申请单号混用。有的仪器回传的是仪器内部的样本序号不是条码。这种情况下必须开双向查询先根据条码把申请信息发给仪器仪器再用这个序号回传才能对应上。项目代码映射缺失。仪器的项目代码往往是ALT、GLU这种缩写LIS 里项目编码可能是自定义的中间必须有一张映射表Lis_InstrumentItemMap缺一条就少一个结果。同一标本多次检测未区分。复查、稀释复测会回来多组结果源码如果没有检测次数字段后到的结果会覆盖先到的。这个坑很隐蔽等到发现的时候历史数据已经乱了。4. 室内质控怎么从纸面规则变成可执行的判定代码4.1 质控数据模型的字段设计质控是检验科质量管理的核心也是 LIS 里最容易被做成只记录不判定的模块。一个能用的质控模块数据表至少要有这些字段质控品编号、批号、有效期靶值和标准差可以是固定值也可以由累积数据计算检测日期、检测结果、检测人所属仪器、所属项目、质控水平低值/中值/高值判定结果在控/警告/失控违反的规则编号关键在于违反的规则编号这个字段。很多实现只存一个是否失控事后想追查是哪条规则触发都查不到。存规则编号哪怕只存一个逗号分隔的字符串后期做统计分析时价值完全不一样。质控靶值的来源有两种源码里要能区分一种是厂家提供的固定靶值一种是实验室自己累积 20 次以上结果算出来的均值。后者需要一个累积计算的过程界面上通常要做成前 20 次数据入库后自动计算并允许人工确认。4.2 Westgard 规则的判定顺序多规则质控的核心是 Westgard 规则常见的是 1-2s 作为警告1-3s、2-2s、R-4s、4-1s、10x 作为失控。判定顺序很重要因为同一组数据可能同时违反多条规则系统应该按严重程度优先输出。我给一个可落地的判定骨架假设当前结果集合是按时间倒序的public QcJudgeResult Judge(ListQcPoint points, double mean, double sd) { var result new QcJudgeResult(); var current points[0]; // 1-3s单点超出 ±3SD if (Math.Abs(current.Value - mean) 3 * sd) { result.IsOutOfControl true; result.Rules.Add(1-3s); return result; } // 2-2s连续两点同侧超出 ±2SD if (points.Count 2) { var p1 points[0]; var p2 points[1]; var d1 p1.Value - mean; var d2 p2.Value - mean; if (Math.Abs(d1) 2 * sd Math.Abs(d2) 2 * sd Math.Sign(d1) Math.Sign(d2)) { result.IsOutOfControl true; result.Rules.Add(2-2s); } } // R-4s连续两点极差超过 4SD if (points.Count 2) { if (Math.Abs(points[0].Value - points[1].Value) 4 * sd) { result.IsOutOfControl true; result.Rules.Add(R-4s); } } // 4-1s连续四点同侧超出 ±1SD if (points.Count 4) { var side Math.Sign(points[0].Value - mean); if (side ! 0 points.Take(4).All(p Math.Abs(p.Value - mean) sd Math.Sign(p.Value - mean) side)) { result.IsOutOfControl true; result.Rules.Add(4-1s); } } // 10x连续十点落在均值同侧 if (points.Count 10) { var side Math.Sign(points[0].Value - mean); if (side ! 0 points.Take(10).All(p Math.Sign(p.Value - mean) side)) { result.IsOutOfControl true; result.Rules.Add(10x); } } // 1-2s单点超 2SD 仅警告 if (!result.IsOutOfControl Math.Abs(current.Value - mean) 2 * sd) { result.IsWarning true; result.Rules.Add(1-2s); } return result; }几个实操上的注意点不要用当前结果去更新靶值。一旦失控数据混入累积计算靶值会被带偏后面全乱。累积计算必须只用在控数据。质控水平要分开判定。低值、中值、高值三个水平各自有各自的靶值和 SD不能混算2-2s 规则也是在同一个水平内部判定的。失控后的处理记录要做。规则判定只是第一步后面必须有原因分析纠正措施是否放行的填写入口并且和审核模块联动。这一块在源码里经常缺失导致质控模块成了摆设。4.3 质控与报告发布的联动设计真正把质控做好用的系统会在报告审核时做一次隐性检查当天对应的仪器和项目如果质控失控且未登记处理措施就禁止审核通过。实现方式是在审核前的校验链里加一环查Lis_QcRecord表当天记录。这个联动有个分寸问题不能一律锁死否则遇到紧急标本会耽误事。我的做法是给一个授权放行的口子由科室负责人输入口令强制放行同时生成一条特殊标记在报告备注里事后可追溯。这种默认严格、例外留痕的设计思路在医疗信息系统里几乎是通行做法。5. 源码拿到手之后部署前必须确认的几件工程问题5.1 数据库版本、字符集与连接串这类源码大多面向 SQL Server早期版本可能是 2008 甚至 2005 兼容级别。部署前先确认服务器上的 SQL Server 版本用SELECT VERSION看一眼然后检查源码里有没有用到新版本才有的语法比如STRING_AGG、OFFSET FETCH、窗口函数。反过来也成立有的老项目里用了WITH (NOLOCK)到处飞读脏数据在结果查询场景里是会造成误判的。字符集方面姓名字段、备注字段必须用NVARCHAR不能用VARCHAR。这一点在核对旧代码时一定要查见过不少项目因为字段类型问题生僻字存进去变成问号报告打印出来是乱码最后只能通过改表结构和补数据来解决。连接串里几个参数值得单独提一下Max Pool Size要设上限默认 100工作站多的科室容易打满Connect Timeout不要太短检验科早上集中签收的时候压力很大加密连接串不要把明文密码写在app.config里5.2 报告打印这件事比想象中复杂报告打印是 C/S 系统里唯一一块几乎没有替代方案的领域。标签打印要调本地驱动报告单要精确控制页边距和对齐A5 和 A4 两种纸张经常同时存在还得支持套打。源码里如果用的是Crystal Reports那部署时每台机器都要装运行库版本对不上就是一片报错如果用FastReport或自绘的PrintDocument部署会轻松一些。我的经验是报告模板一定要做成可配置的至少要做到字段位置、字体、字号、是否打印、打印顺序能在界面上调整而不是硬编码。检验科的报告格式一年改好几次每次都要改代码重新编译那是折磨。还有一点容易被忽略打印失败的处理。网络打印机卡纸、脱机、墨粉不足这些在科室里天天发生。源码里如果有打印队列和重打机制会省很多事如果没有至少要保证打印失败时状态不会被误改成已打印。5.3 权限分级与操作留痕LIS 的权限模型至少要分三层功能权限能看到哪些菜单、数据权限能看哪些专业组、哪些科室的标本、操作权限能不能审核、能不能修改已发布结果、能不能强制放行质控。后两个权限是重点。修改已发布结果是医疗数据管理里的敏感操作必须做到修改前留原始值、修改必须填写理由、修改后生成新版本报告并标注更正。源码里如果只做了一个UPDATE那这套系统在合规性上是不合格的。操作留痕的实现不要太依赖客户端。日志写在客户端本地文件里毫无意义必须写数据库并且至少记录操作人、操作时间、操作类型、涉及主键、变更前后的关键字段。表结构可以很简单CREATE TABLE Lis_OperationLog ( LogId BIGINT IDENTITY(1,1) PRIMARY KEY, OperatorId VARCHAR(32) NOT NULL, OperatorName NVARCHAR(50) NOT NULL, Workstation VARCHAR(64) NULL, ActionType VARCHAR(32) NOT NULL, TargetKey VARCHAR(64) NOT NULL, BeforeValue NVARCHAR(MAX) NULL, AfterValue NVARCHAR(MAX) NULL, Remark NVARCHAR(200) NULL, CreateTime DATETIME NOT NULL DEFAULT GETDATE() );Workstation这个字段别省出问题的时候能定位到具体哪台机器排查效率差好几倍。5.4 历史数据迁移与新旧系统并行如果这套源码是要替换现有的老系统数据迁移是绕不过去的坎。标本主表、结果表、患者信息表这三张必须迁质控数据看情况迁不迁。迁移的时候要注意主键冲突和历史报告的可追溯性——旧报告号和新报告号要有对应关系至少要留一张映射表否则临床回头查历史结果会查不到。并行期建议至少留两周。这两周里新旧系统同时接收数据每天比对一次结果数量、异常标本数量、危急值数量。比对不上就当天查清楚别拖。我见过并行了三个月还没切换的最后原因是历史报告号对不上临床科室不认。这种问题越早暴露越好。6. 读这类源码时我习惯先看哪几个文件拿到一套陌生的 LIS 源码我不会从 UI 开始看顺序一般是这样的。先看数据库脚本。找.sql文件或者.bak备份把表结构导出来重点看标本主表、结果表、质控表、日志表的字段设计。字段命名是否统一、有没有主外键、索引建得合不合理这几眼下去基本能判断这套代码的成熟度。再看配置读取的入口。找App.config或者自定义的配置文件读取类看连接串、仪器配置、打印模板路径是怎么组织的。配置管理混乱的项目后期维护成本会非常高。然后直接跳到仪器通讯模块。看有没有独立的服务进程看协议解析是不是抽了接口看串口异常怎么处理。这一块是分水岭做得好的项目通常整体质量也不差。最后才看业务窗体而且只看两三个标本签收、结果录入、报告审核。这三个窗体覆盖了绝大部分核心业务逻辑看完基本就知道二次开发的工作量大概在什么量级。按这个顺序看一般半天到一天就能对一套源码形成比较靠谱的判断比从头到尾翻代码效率高得多。还有一种情况是只给了编译好的程序没给源码那就只能从界面反推先看菜单结构再看各窗体的操作流程最后用数据库工具看表结构反推出来的结论准确度会打折但大致方向还是能判断。 
长河君 · 2026/10/26 21:46:34 · 阅读 1.2k C/S架构LIS源码拆解：标本流转、仪器双向通讯与室内质控
早上七点四十检验科的门刚开生化室的老师已经坐在工作站前双击桌面上的客户端图标输入工号和口令屏幕上刷出当天已经签收的标本列表——这一刻整套系统的响应速度、列表排序方式、异常标本的标红逻辑全都要在几秒钟内接受真实工作节奏的检验。我接触过不少基于 C/S 架构的医学检验实验室信息管理系统也就是大家常说的 LIS 源码很多人拿到手的第一反应是这年头怎么还有客户端但真正在科室里蹲过几个早上就会明白工作台前的操作效率、条码枪的即时响应、仪器串口的稳定收数这些东西决定了 C/S 在检验场景里依然有很强的生命力。这篇内容我打算把这类源码拆开讲它到底由哪些模块拼起来一条标本从申请到报告发布在代码里是怎么流转的仪器双向通讯这个最容易翻车的部分该怎么看室内质控的数学逻辑怎么落到表结构里以及把源码真正部署到科室之前必须先想清楚的几件事。适合正在评估这类系统源码的开发者、需要二次开发的技术人员也适合检验科里负责对接信息系统的老师用来判断一套系统到底靠不靠谱。1. C/S 架构在检验科工作台前为什么依然站得住1.1 科室里的物理环境决定了客户端的形态检验科不是办公室。生化、免疫、血球、凝血、尿沉渣、微生物每个专业组都有自己的仪器区工作台旁边就是分析仪中间常常只隔一道矮挡板。技师的手是戴着手套的很多时候还要一边盯着仪器屏幕一边敲键盘鼠标点错一个按钮就可能把标本号录到别人头上。这种环境下C/S 客户端的优势非常实在本地渲染、按键即时反馈、可以深度绑定本地设备资源比如条码枪、标签打印机、串口通讯端口、本地缓存的结果草稿。浏览器方案要用到串口就得中间件要用到标签打印就得装打印控件绕一圈反而更脆弱。源码层面这类系统通常由三块组成WinForm 或 WPF 写的客户端、中间的业务服务层、SQL Server 或 Oracle 的数据库。也有不少直接做成胖客户端 直连数据库的两层结构早期项目尤其多。两层结构的优点是开发和部署都简单客户端直接开连接串增删改查一目了然缺点是任何一个客户端出问题都可能拖垮数据库连接池而且业务逻辑散落在各个窗体里改一条规则要满项目找。我的建议是如果拿到的源码是两层结构不要急着重构先确认连接管理有没有做连接池上限、有没有统一的数据库访问封装类。如果没有改造优先级最高的是把所有窗体的直连 SQL 收敛到一个数据访问层这件事的工作量远小于彻底改三层但对稳定性的提升立竿见影。1.2 三层结构在 LIS 源码里通常怎么落地比较规范的三层项目目录结构一般长这样Lis.Client所有 WinForm 窗体按专业组划分文件夹比如Biochem、Hematology、MicrobiologyLis.Business业务规则标本状态机、报告审核、危急值判定、质控判定都在这一层Lis.DataAccess数据访问通常配一个DbHelper或使用轻量 ORMLis.Instrument仪器通讯串口/网口监听、报文解析、结果回写Lis.Common公共类日志、加密、配置读取、打印Lis.Service常驻服务负责抓取仪器原始数据、定时任务、与外部系统交换数据关键是Lis.Instrument这一层。很多项目把它做成客户端的一部分结果就是某台工作站关机了那台仪器就收不到数据。正确的做法是仪器通讯跑在独立的 Windows 服务里客户端只负责展示和人工干预。这一点在源码评审时很容易看出来如果串口打开的动作写在某个窗体里那基本可以判定这套代码是在单机环境下长出来的上多客户端就会出问题。1.3 什么时候真的该考虑客户端之外的方案不是所有场景都适合 C/S。如果使用方是社区检验点、体检车、外送采样点客户端部署和维护成本会变得不可接受如果主要使用者是临床医生只需要查看报告那完全没必要装客户端浏览器或者移动端更合适。我见过的比较务实的架构是客户端负责检验科内部高强度录入Web 端负责临床查询和报告浏览两边共用同一个业务服务层。这种混合方案在源码里如果已经预留了服务接口哪怕是 WebAPI 或者简单的 Socket 服务二次开发的成本会低很多。判断标准其实很简单看源码里有没有把业务逻辑和界面事件彻底分开。如果审核报告这个动作在窗体按钮的 Click 事件里写了三十行 SQL那基本没有扩展余地如果它调用的是ReportService.Audit(reportId, userId, password)那不管以后套什么前端都能复用。2. 一条标本从申请到报告发布在数据表里是怎么走完的2.1 样本主表与状态机是整个系统的骨架LIS 的核心不是界面是那张标本主表和它上面挂的状态字段。我见过的设计里比较合理的是单独设一个状态字段然后用一个枚举去约束取值而不是用一堆布尔字段IsSigned、IsTested、IsAudited来表达进度。原因很直接布尔字段无法表达顺序也没法防止未签收就直接审核这种非法流转。典型的枚举值大致是这样一串状态码状态名触发动作责任人10已申请医生站开单或手工登记申请医生20已采样护士采样并打印条码采样护士30已签收检验科扫码接收标本接收岗40已上机仪器开始检测仪器自动50结果已回传仪器或手工录入完成仪器/技师60已初审技师复核结果检验技师70已终审审核医师签发审核医师80已发布报告可被临床查看系统自动90已打印报告打印完成打印岗状态机的实现在业务层里应该是一个显式的字典比如Dictionaryint, int[]表示当前状态允许迁移到哪些状态每次更新前先校验。这种写法看起来笨但它能把跳过初审直接终审这类问题挡在代码层面而不是靠操作规范。private static readonly Dictionaryint, int[] AllowedTransitions new() { { 10, new[] { 20, 99 } }, // 已申请 - 已采样 / 已作废 { 20, new[] { 30, 99 } }, // 已采样 - 已签收 / 已作废 { 30, new[] { 40, 99 } }, { 40, new[] { 50 } }, { 50, new[] { 60, 30 } }, // 结果回传后可初审也可退回重测 { 60, new[] { 70, 50 } }, // 初审后可终审也可退回 { 70, new[] { 80 } }, { 80, new[] { 90 } } }; public void ChangeStatus(string sampleId, int targetStatus, string operatorId) { var current _sampleRepo.GetStatus(sampleId); if (!AllowedTransitions.TryGetValue(current, out var allowed) || !allowed.Contains(targetStatus)) { throw new BusinessException($标本 {sampleId} 不允许从状态 {current} 迁移到 {targetStatus}); } _sampleRepo.UpdateStatus(sampleId, targetStatus, operatorId, DateTime.Now); _logRepo.Write(sampleId, current, targetStatus, operatorId); }这段代码没什么技术含量但它是整套系统的防呆底线。实际做二开时我见过有人为了方便直接在 SQL 里改状态结果历史报告对不上追溯的时候完全抓瞎。状态变更必须走统一入口并且写日志这一条是硬要求。2.2 条码规则与申请单的绑定关系条码是整个流程的物理载体条码规则的设计会直接影响后续的排错效率。常见的规则是日期 专业组代码 流水号比如240618 SH 0001长度控制在 10 到 14 位之间因为很多老式条码枪和标签打印机对这个长度最友好。源码里需要重点关注两处第一处是条码唯一性校验的时机。有些实现是在生成时查一次数据库看着没问题但在并发下会重号稳妥做法是用数据库唯一索引兜底插入失败再重试生成而不是只靠应用层判断。第二处是一个条码对应多个检验项目的处理。实际业务里一管血可能同时做肝功能和肾功能这两组项目可能落在不同专业组。源码里如果设计成一条标本记录 多条明细记录那签收、上机、结果回传都要按明细走如果设计成一条标本一条记录、项目用逗号拼接那后期按项目查询、按项目质控都会变成灾难。看到后者基本可以直接判定这套源码不适合规模化使用。CREATE TABLE Lis_Sample ( SampleId VARCHAR(24) NOT NULL PRIMARY KEY, Barcode VARCHAR(32) NOT NULL, PatientId VARCHAR(32) NOT NULL, PatientName NVARCHAR(50) NOT NULL, Gender CHAR(1) NULL, Age INT NULL, AgeUnit CHAR(1) NULL, DeptCode VARCHAR(20) NULL, BedNo VARCHAR(20) NULL, SampleType VARCHAR(20) NULL, Status INT NOT NULL DEFAULT 10, CollectTime DATETIME NULL, ReceiveTime DATETIME NULL, ReportTime DATETIME NULL, IsUrgent BIT NOT NULL DEFAULT 0, Remark NVARCHAR(200) NULL ); CREATE UNIQUE INDEX UX_Lis_Sample_Barcode ON Lis_Sample(Barcode); CREATE INDEX IX_Lis_Sample_Status ON Lis_Sample(Status, ReceiveTime);注意IsUrgent这个字段。急诊标本的优先级处理在真实科室里极其关键源码里如果只是打个红色标记而没有在查询排序、仪器上机队列、结果审核队列里做优先级提升那这个字段等于没做。2.3 报告审核环节里那些容易被忽略的拦截审核是 LIS 里业务规则最密集的一步。除了常规的结果是否为空结果是否超出线性范围还有几个必须做的拦截危急值拦截结果触发危急值阈值时必须弹出提醒并强制记录通知过程通知时间、被通知人、复述确认人。这个记录在源码里应该是一张独立的表而不是塞在备注字段里。结果与历史值偏离过大同一个人上次结果和这次相差数倍系统应该提示复核防止标本搞错或者仪器漂移。未做质控或质控失控时禁止发布这条规则实现起来需要质控模块和审核模块联动很多源码里是断开的。审核人资质校验初级职称不能终审某些项目这需要权限表里带上资质字段。危急值提醒的实现要特别注意一点不能做成点一下就关的提示框。必须是一个阻塞式窗口用户要么填写通知记录要么明确选择暂不处理并留下原因否则就是一个形同虚设的功能。3. 仪器双向通讯整套源码里最考验功力的部分3.1 ASTM 与 HL7 在实现上的实际差异医学检验仪器通讯主流就两大协议族。ASTM E1394 更老但更常见尤其在生化、血球、尿液分析这类设备上HL7 v2.x 在免疫、分子、微生物和部分新设备上用得多。两者在代码实现上的差别不小。ASTM 是典型的帧结构每帧以ENQ0x05开头仪器发STX加数据末尾ETX加校验和接收方回ACK0x06。数据部分按记录类型分行H是消息头P是患者信息O是申请信息R是结果L是结束。解析的时候要按|和^两级分隔符拆。HL7 则是纯文本消息MSH开头定义编码字符后面PID患者、OBR申请、OBX结果字段之间同样用|但复合字段用^~\这四个字符定义。相比 ASTMHL7 的字段位置更严格差一个位置就可能解析全错。实际操作里我倾向于把协议解析抽成一个接口public interface IInstrumentProtocol { string ProtocolName { get; } InstrumentMessage Parse(byte[] raw); byte[] BuildQuery(string sampleBarcode); byte[] BuildAck(); }然后 ASTM 和 HL7 各写一个实现类仪器配置表里存一个协议名运行时反射创建。这样后期加新仪器只需要加一个类不用改主流程。3.2 串口和网口的连接参数该怎么配串口通讯是最容易出问题的地方。常见参数是波特率 9600 或 192008 数据位、1 停止位、无校验但不同厂家差别很大必须以仪器说明书为准。源码里的配置表至少要包含配置项说明常见取值通讯方式串口或 TCPCOM / TCP端口号串口号或 IP:PortCOM3 / 192.168.1.50:5100波特率仅串口有效9600 / 19200 / 38400数据位仅串口有效8停止位仅串口有效1校验位仅串口有效None / Even协议类型ASTM / HL7ASTM双向开关是否支持查询true / false结果回传超时秒30现场调试时我的习惯是先开一个串口抓包工具让仪器做一次测试把原始字节流存下来再对照解析代码逐字段核对。这一步省不得因为协议文档和实际报文对不上的情况太常见了——有的仪器说明书写的字段顺序和实际发出来的就是反的还有的仪器在结果为空时不是留空而是发一个空格解析的时候不做 Trim 就会出错。TCP 方式相对稳定但要处理断线重连。源码里如果写的是TcpClient.Connect()然后一个 while 循环读一旦网络抖动就会抛异常退出。正确的做法是包一层重连机制加心跳检测并且把接收缓冲区的处理做成按帧边界拆分而不是简单地Read一次就当一条消息。3.3 结果匹配不上的四类原因双向通讯上线后最常见的抱怨就是结果回不来。排查下来基本集中在四类条码格式不一致。仪器读到的条码带校验位LIS 里存的不带或者反过来。解决办法是在配置里加一个条码截取规则比如去掉前两位、去掉最后一位。标本号与申请单号混用。有的仪器回传的是仪器内部的样本序号不是条码。这种情况下必须开双向查询先根据条码把申请信息发给仪器仪器再用这个序号回传才能对应上。项目代码映射缺失。仪器的项目代码往往是ALT、GLU这种缩写LIS 里项目编码可能是自定义的中间必须有一张映射表Lis_InstrumentItemMap缺一条就少一个结果。同一标本多次检测未区分。复查、稀释复测会回来多组结果源码如果没有检测次数字段后到的结果会覆盖先到的。这个坑很隐蔽等到发现的时候历史数据已经乱了。4. 室内质控怎么从纸面规则变成可执行的判定代码4.1 质控数据模型的字段设计质控是检验科质量管理的核心也是 LIS 里最容易被做成只记录不判定的模块。一个能用的质控模块数据表至少要有这些字段质控品编号、批号、有效期靶值和标准差可以是固定值也可以由累积数据计算检测日期、检测结果、检测人所属仪器、所属项目、质控水平低值/中值/高值判定结果在控/警告/失控违反的规则编号关键在于违反的规则编号这个字段。很多实现只存一个是否失控事后想追查是哪条规则触发都查不到。存规则编号哪怕只存一个逗号分隔的字符串后期做统计分析时价值完全不一样。质控靶值的来源有两种源码里要能区分一种是厂家提供的固定靶值一种是实验室自己累积 20 次以上结果算出来的均值。后者需要一个累积计算的过程界面上通常要做成前 20 次数据入库后自动计算并允许人工确认。4.2 Westgard 规则的判定顺序多规则质控的核心是 Westgard 规则常见的是 1-2s 作为警告1-3s、2-2s、R-4s、4-1s、10x 作为失控。判定顺序很重要因为同一组数据可能同时违反多条规则系统应该按严重程度优先输出。我给一个可落地的判定骨架假设当前结果集合是按时间倒序的public QcJudgeResult Judge(ListQcPoint points, double mean, double sd) { var result new QcJudgeResult(); var current points[0]; // 1-3s单点超出 ±3SD if (Math.Abs(current.Value - mean) 3 * sd) { result.IsOutOfControl true; result.Rules.Add(1-3s); return result; } // 2-2s连续两点同侧超出 ±2SD if (points.Count 2) { var p1 points[0]; var p2 points[1]; var d1 p1.Value - mean; var d2 p2.Value - mean; if (Math.Abs(d1) 2 * sd Math.Abs(d2) 2 * sd Math.Sign(d1) Math.Sign(d2)) { result.IsOutOfControl true; result.Rules.Add(2-2s); } } // R-4s连续两点极差超过 4SD if (points.Count 2) { if (Math.Abs(points[0].Value - points[1].Value) 4 * sd) { result.IsOutOfControl true; result.Rules.Add(R-4s); } } // 4-1s连续四点同侧超出 ±1SD if (points.Count 4) { var side Math.Sign(points[0].Value - mean); if (side ! 0 points.Take(4).All(p Math.Abs(p.Value - mean) sd Math.Sign(p.Value - mean) side)) { result.IsOutOfControl true; result.Rules.Add(4-1s); } } // 10x连续十点落在均值同侧 if (points.Count 10) { var side Math.Sign(points[0].Value - mean); if (side ! 0 points.Take(10).All(p Math.Sign(p.Value - mean) side)) { result.IsOutOfControl true; result.Rules.Add(10x); } } // 1-2s单点超 2SD 仅警告 if (!result.IsOutOfControl Math.Abs(current.Value - mean) 2 * sd) { result.IsWarning true; result.Rules.Add(1-2s); } return result; }几个实操上的注意点不要用当前结果去更新靶值。一旦失控数据混入累积计算靶值会被带偏后面全乱。累积计算必须只用在控数据。质控水平要分开判定。低值、中值、高值三个水平各自有各自的靶值和 SD不能混算2-2s 规则也是在同一个水平内部判定的。失控后的处理记录要做。规则判定只是第一步后面必须有原因分析纠正措施是否放行的填写入口并且和审核模块联动。这一块在源码里经常缺失导致质控模块成了摆设。4.3 质控与报告发布的联动设计真正把质控做好用的系统会在报告审核时做一次隐性检查当天对应的仪器和项目如果质控失控且未登记处理措施就禁止审核通过。实现方式是在审核前的校验链里加一环查Lis_QcRecord表当天记录。这个联动有个分寸问题不能一律锁死否则遇到紧急标本会耽误事。我的做法是给一个授权放行的口子由科室负责人输入口令强制放行同时生成一条特殊标记在报告备注里事后可追溯。这种默认严格、例外留痕的设计思路在医疗信息系统里几乎是通行做法。5. 源码拿到手之后部署前必须确认的几件工程问题5.1 数据库版本、字符集与连接串这类源码大多面向 SQL Server早期版本可能是 2008 甚至 2005 兼容级别。部署前先确认服务器上的 SQL Server 版本用SELECT VERSION看一眼然后检查源码里有没有用到新版本才有的语法比如STRING_AGG、OFFSET FETCH、窗口函数。反过来也成立有的老项目里用了WITH (NOLOCK)到处飞读脏数据在结果查询场景里是会造成误判的。字符集方面姓名字段、备注字段必须用NVARCHAR不能用VARCHAR。这一点在核对旧代码时一定要查见过不少项目因为字段类型问题生僻字存进去变成问号报告打印出来是乱码最后只能通过改表结构和补数据来解决。连接串里几个参数值得单独提一下Max Pool Size要设上限默认 100工作站多的科室容易打满Connect Timeout不要太短检验科早上集中签收的时候压力很大加密连接串不要把明文密码写在app.config里5.2 报告打印这件事比想象中复杂报告打印是 C/S 系统里唯一一块几乎没有替代方案的领域。标签打印要调本地驱动报告单要精确控制页边距和对齐A5 和 A4 两种纸张经常同时存在还得支持套打。源码里如果用的是Crystal Reports那部署时每台机器都要装运行库版本对不上就是一片报错如果用FastReport或自绘的PrintDocument部署会轻松一些。我的经验是报告模板一定要做成可配置的至少要做到字段位置、字体、字号、是否打印、打印顺序能在界面上调整而不是硬编码。检验科的报告格式一年改好几次每次都要改代码重新编译那是折磨。还有一点容易被忽略打印失败的处理。网络打印机卡纸、脱机、墨粉不足这些在科室里天天发生。源码里如果有打印队列和重打机制会省很多事如果没有至少要保证打印失败时状态不会被误改成已打印。5.3 权限分级与操作留痕LIS 的权限模型至少要分三层功能权限能看到哪些菜单、数据权限能看哪些专业组、哪些科室的标本、操作权限能不能审核、能不能修改已发布结果、能不能强制放行质控。后两个权限是重点。修改已发布结果是医疗数据管理里的敏感操作必须做到修改前留原始值、修改必须填写理由、修改后生成新版本报告并标注更正。源码里如果只做了一个UPDATE那这套系统在合规性上是不合格的。操作留痕的实现不要太依赖客户端。日志写在客户端本地文件里毫无意义必须写数据库并且至少记录操作人、操作时间、操作类型、涉及主键、变更前后的关键字段。表结构可以很简单CREATE TABLE Lis_OperationLog ( LogId BIGINT IDENTITY(1,1) PRIMARY KEY, OperatorId VARCHAR(32) NOT NULL, OperatorName NVARCHAR(50) NOT NULL, Workstation VARCHAR(64) NULL, ActionType VARCHAR(32) NOT NULL, TargetKey VARCHAR(64) NOT NULL, BeforeValue NVARCHAR(MAX) NULL, AfterValue NVARCHAR(MAX) NULL, Remark NVARCHAR(200) NULL, CreateTime DATETIME NOT NULL DEFAULT GETDATE() );Workstation这个字段别省出问题的时候能定位到具体哪台机器排查效率差好几倍。5.4 历史数据迁移与新旧系统并行如果这套源码是要替换现有的老系统数据迁移是绕不过去的坎。标本主表、结果表、患者信息表这三张必须迁质控数据看情况迁不迁。迁移的时候要注意主键冲突和历史报告的可追溯性——旧报告号和新报告号要有对应关系至少要留一张映射表否则临床回头查历史结果会查不到。并行期建议至少留两周。这两周里新旧系统同时接收数据每天比对一次结果数量、异常标本数量、危急值数量。比对不上就当天查清楚别拖。我见过并行了三个月还没切换的最后原因是历史报告号对不上临床科室不认。这种问题越早暴露越好。6. 读这类源码时我习惯先看哪几个文件拿到一套陌生的 LIS 源码我不会从 UI 开始看顺序一般是这样的。先看数据库脚本。找.sql文件或者.bak备份把表结构导出来重点看标本主表、结果表、质控表、日志表的字段设计。字段命名是否统一、有没有主外键、索引建得合不合理这几眼下去基本能判断这套代码的成熟度。再看配置读取的入口。找App.config或者自定义的配置文件读取类看连接串、仪器配置、打印模板路径是怎么组织的。配置管理混乱的项目后期维护成本会非常高。然后直接跳到仪器通讯模块。看有没有独立的服务进程看协议解析是不是抽了接口看串口异常怎么处理。这一块是分水岭做得好的项目通常整体质量也不差。最后才看业务窗体而且只看两三个标本签收、结果录入、报告审核。这三个窗体覆盖了绝大部分核心业务逻辑看完基本就知道二次开发的工作量大概在什么量级。按这个顺序看一般半天到一天就能对一套源码形成比较靠谱的判断比从头到尾翻代码效率高得多。还有一种情况是只给了编译好的程序没给源码那就只能从界面反推先看菜单结构再看各窗体的操作流程最后用数据库工具看表结构反推出来的结论准确度会打折但大致方向还是能判断。