简介C#医院HIS系统是一套基于C#与.NET框架开发的医疗信息系统源码包面向医院信息化建设者、HIS二次开发人员及.NET学习者覆盖患者管理、挂号收费、处方检验、物资库存、报表统计与权限控制等核心业务模块可用于快速部署演示或作为企业级医疗项目开发参考。包内包含186个文件以C#源码30个cs、可执行程序23个exe、界面资源22个resx及resources、数据库脚本sql/mdf/bak和DLL组件为主压缩包仅2.8MB整体轻量但结构完整适合直接还原运行或对照学习。资源附带数据库备份文件能够帮助理解HIS系统的表结构与数据流同时提供大量窗体与操作位图便于梳理界面交互逻辑。目前已有640人学习下载对于希望掌握C#桌面应用分层开发、医疗业务流程建模及SQL Server数据库设计的读者是一份不错的实践素材。1. C#医院HIS系统为什么说难点不在C#而在医院现场早上八点门诊大厅挂号窗口排到电梯口收费员连点两下收费系统弹出订单号已存在药房那边又喊某张处方打印了三遍。这类现场我见过不止一次C#做医院HIS系统是行业里走了十几年的老路线WinForm/WPF客户端、Web API、SQL Server或MySQL语法层面没什么门槛真正的难点在窗口并发、账务一致性和一堆非标准设备对接。HIS对很多刚入行的人来说是个黑匣子但拆开看无非是架构选型、号源与流水设计、幂等与状态机、以及实施现场那些让你翻车的边角坑。这篇按这个顺序往下讲新手能照着把最小可运行的HIS骨架搭起来熟手也能对上号源预扣、医保接口幂等这些边界问题。2. HIS架构与技术选型C/S还是B/S数据访问层用什么HIS系统的技术栈选型医院信息科和实施方的分歧往往最大。有人上来就推B/S架构说免维护有人坚持C/S说设备好接。我的结论很直接主业务用C/S管理端用B/S接口层独立成服务。这一章把客户端形态、数据访问层和更新策略一次说清。2.1 C/S还是B/S先想清楚收费窗口的容错半径挂号、收费、药房发药、护士站执行医嘱这些每天几千次操作的主业务我建议C/S。理由不是B/S做不了而是三个现实约束。第一医院窗口工作站是Windows工控机带着医保读卡器、打印机、扫码枪C/S客户端直连串口和USB设备最省事浏览器方案得绕ActiveX或WebSocket兼容性拼人品。第二院内网络半径就一栋楼客户端更新用本地更新器可控出问题时定位链路短。第三收费员操作节奏极快C/S响应快卡一下窗口就有人喊系统卡了。B/S放在院长查询、管理端报表、移动查房这类低频轻设备场景更合适——浏览器里看个统计图不需要读卡器。对比项C/SWinForms/WPFB/SWeb设备对接串口/USB/读卡器直接控制要绕ActiveX或WebSocket兼容性差断网容忍客户端可做短暂本地操作断网即白屏部署更新更新器或ClickOnce刷新即升级报表打印本地模板直出依赖浏览器打印方案小诊所的单机版HIS常见做法是C#加Access一台电脑一个读卡器一套打印模板C/S最省事——这也是很多老诊所系统至今不换B/S的原因。记住技术选型不是赶时髦是看现场条件。2.2 客户端技术栈WinForms、WPF还是ASP.NET Core老HIS大量是WinForms加.NET Framework 4.x不少三甲医院到现在还在跑。新项目我会按场景分收费、挂号、药房这种数据录入密集、界面朴素、机器配置低的窗口端继续用WinForms维护成本最低老工程师接手快住院护士站、手术室大屏这类交互密度高、界面不能土的用WPF绑MVVM护理人员日常使用体验好很多。ASP.NET Core不做客户端而是做Web API层给自助机、App和管理端喂数据。HIS实施工程师需要掌握的其实不只是C#语法是把现场操作翻译成事务和状态机的建模能力。一个窗口端经常遇到的情况是后台轮询待办加前台刷卡千万别在UI线程里做串口读卡——界面直接假死。用BackgroundWorker或Task.Run读串口拿到数据后用Control.BeginInvokeWinForms或DispatcherWPF切回UI线程更新界面。还有个常见需求是生成病案或出院小结的Word文档C#用OpenXML操作书签变量填充模板比在界面上拼文本可靠得多。2.3 数据访问层为什么我在HIS里偏用DapperHIS的查询SQL基本都长跨表join、分组统计、报表聚合、行转列一个报表SQL几十行是常态。EF Core写增删改查方便但复杂统计SQL要么手写SqlQuery要么写一堆Include绕来绕去。Dapper把SQL握在手里执行计划可控性能好定位。实践中我一般再加一层仓储把Dapper的Connection管理收口避免每个业务方法都new一个SqlConnection。// 收费明细汇总按收费员汇总当日现金/扫码/医保金额 const string sql SELECT operator_id, SUM(CASE WHEN pay_type 1 THEN amount ELSE 0 END) AS cash_amount, SUM(CASE WHEN pay_type 2 THEN amount ELSE 0 END) AS card_amount, SUM(CASE WHEN pay_type 3 THEN amount ELSE 0 END) AS insurance_amount, COUNT(*) AS bill_count FROM account_flow WHERE create_time StartDate AND create_time EndDate GROUP BY operator_id;; using var conn new SqlConnection(_connString); var rows conn.QueryOperatorSummary(sql, new { StartDate today, EndDate today.AddDays(1) }).ToList();逻辑说明这段按操作员聚合当日各支付方式金额是财务科每天必跑的口径。关键点在于WHERE条件用半开区间 StartDate AND EndDate——如果写成 EndDate第二天零点零分零秒的流水就会被算进前一天日切报表对不上就查这种边界。参数说明pay_type对应收付款字典OperatorSummary是列名对齐的DTO_connString从配置中心读别在代码里写死连接串。2.4 客户端更新ClickOnce与自更新器哪个更省心门诊窗口系统最怕更新时出岔子。ClickOnce的好处是发布到IIS或文件共享后自动升级权限干净但每次启动都要做版本检查网络慢时打开系统明显卡顿而且版本回滚麻烦。发版保护还可以绑定终端设备指纹比如读硬盘序列号做授权防止客户端被拷走乱装——这一套在自更新器里都好做。我一般写个自更新器启动时先比对服务端manifestJSON格式含版本号和包名有新版就下载zip、杀旧进程、解压替换、再拉起主程序。// AppUpdater 核心逻辑比对版本 - 下载 - 替换 var manifest await _http.GetStringAsync(_manifestUrl); // JSON: {version:1.2.3,package:his_1.2.3.zip} var remoteVer Version.Parse(ParseVersionFromJson(manifest)); var localVer Version.Parse(File.ReadAllText(_localVerFile).Trim()); if (remoteVer localVer) { await _http.DownloadFileAsync(_packageUrl, _tempZip); // 下载新包 Process.GetProcessesByName(HisApp) .ToList().ForEach(p p.Kill()); // 杀旧进程 ZipFile.ExtractToDirectory(_tempZip, _appDir, true); // 覆盖解压 File.WriteAllText(_localVerFile, remoteVer.ToString()); Process.Start(Path.Combine(_appDir, HisApp.exe)); // 拉起新版本 }逻辑说明manifest是服务端维护的JSON下载完必须先杀进程再解压否则exe被占用会解压失败替换期间用户看到的是更新进度条更新器界面不能弹文件被占用的报错。参数说明_packageUrl和_manifestUrl放同一路径运维只需改JSON里的版本号就能发版_tempZip建议放临时目录更新成功后清理避免残留旧包占用磁盘。3. 数据库设计与事务从患者主索引到号源预扣HIS的地基是数据不是窗体。我们见过太多系统界面花哨但数据一塌糊涂——同一个病人建三个档、号源超卖、退费改原流水。数据库层设计决定了系统上线后能撑几年。3.1 患者主索引一人多卡问题必须在地基阶段解决HIS上线第一周最容易出现的脏数据就是同一个病人建档三遍。原因很简单挂号员搜病人只按姓名查结果王芳1985年生的和1990年生的都被当成新病人建档。患者主索引EMPI的核心是唯一识别规则先按身份证号精确匹配匹配不到再按姓名出生日期出候选列表由挂号员确认是否复用档案。先看建表DDL-- 以下按 SQL Server 方言MySQL 去掉筛选索引语法即可 CREATE TABLE patient ( patient_id BIGINT IDENTITY(1,1) PRIMARY KEY, id_card_no VARCHAR(18) NULL, name NVARCHAR(64) NOT NULL, birth_date DATE NULL, gender TINYINT NULL, phone VARCHAR(20) NULL, merge_to BIGINT NULL, -- 合并后指向的主档案ID UNIQUE (id_card_no) WHERE id_card_no IS NOT NULL );逻辑说明merge_to是一人多档的后悔药。发现重复档案时不DELETE而是把被合并档案的merge_to指向保留档案历史挂号记录仍然可追溯业务报表不会因为合并而丢数。唯一索引用筛选索引只在身份证号非空时约束避免多条空值记录互相冲突报重复键。参数说明身份证号里的X统一存大写应用层toUpper后再入库否则同一个人的x和X会被当成两个人姓名列用NVARCHAR生僻字存不进去的坑第5章专门讲。3.2 号源表用预扣确认替代插入即占用初学HIS的人做预约挂号第一反应是INSERT一条挂号记录号源就没了。这在单机演示没问题门诊一开就出事两个窗口同时INSERT都读到还有号插完发现超卖。正确做法是把号源库存和挂号流水分开——号源是计数器挂号是流水扣减必须是一个原子SQL。号源拆到时段粒度CREATE TABLE register_schedule ( schedule_id BIGINT PRIMARY KEY, dept_id INT NOT NULL, doctor_id INT NOT NULL, visit_date DATE NOT NULL, period TINYINT NOT NULL, -- 1上午 2下午 3晚间 total INT NOT NULL, remaining INT NOT NULL, version_no INT NOT NULL DEFAULT 0 );逻辑说明remaining不是画出来的每次更新都做算术扣减。version_no用于CAS乐观锁更新时同时校验版本号能避免两个事务都读到remaining5都写成4但实际只该扣一次的丢失更新。预扣的意思窗口点了号源先扣减并生成待支付流水支付成功转为正式记录支付超时未确认后台任务把remaining加回来同时把待支付流水置为已过期。3.3 事务边界与隔离级别收费开单别拖长事务HIS里事务要短越短越好。一个真实的反例是收费事务里直接调医保接口接口15秒没返回整个事务挂15秒后面窗口全部排队。外部调用一律挪到事务外事务里只做三件事写账户流水、更新订单状态、写操作日志。隔离级别上账务用读已提交Read Committed足够SQL Server默认就是它MySQL默认的Repeatable Read也能用串行化隔离能解决幻读但并发直接掉一半别为了绝对安全牺牲窗口吞吐。using var scope new TransactionScope(TransactionScopeOption.Required, new TransactionOptions { IsolationLevel IsolationLevel.ReadCommitted }); // 1. 生成订单并置为已收费 // 2. 写入账户流水 // 3. 写入操作日志 scope.Complete();逻辑说明三个写操作同事务提交任何一个失败全部回滚避免订单已收费但流水没记这种对不平的账。参数说明IsolationLevel.ReadCommitted只保证不读脏数据不回滚已提交的数据对HIS账务够用注意async方法里别直接用旧的TransactionScope它和异步上下文不兼容要么用同步写法要么换支持异步的作用域实现打印小票、调医保接口必须放到scope.Complete()之后。3.4 退费与冲正流水只追加不允许改原记录退费是最容易做脏的场景。正确模型是退费不UPDATE原流水而是INSERT一条金额为负数的冲正流水通过related_flow_id指向原流水。这样账务天然平衡审计沿着流水链就能还原完整业务。-- 查某个患者的净发生额收费与退费正负抵消 SELECT SUM(amount) AS net_amount, COUNT(*) AS flow_count FROM account_flow WHERE patient_id PatientId;逻辑说明一条SQL就能同时覆盖收费与退费net_amount为0说明收支平衡。审计时通过related_flow_id把收费-退费串成一条链财务科问为什么今天退这么多时从流水表按时间、按操作员、按原流水逐级钻取。参数说明amount按分存BIGINT避免浮点误差所有流水不做物理删除作废只做状态标记这是HIS账务的铁律。4. 并发窗口场景挂号扣号与缴费防重复的落地写法门诊高峰本质上就是并发问题多个窗口抢号源、重复点击、接口超时重试。这一章给的是可以直接抄的写法。4.1 并发扣号一条原子SQL比锁实在扣号不能先查再扣要一条UPDATE完成判断和扣减靠数据库行锁保证不超卖const string sql UPDATE register_schedule SET remaining remaining - 1, version_no version_no 1 WHERE schedule_id scheduleId AND remaining 0;; using var conn new SqlConnection(_connString); conn.Open(); using var tx conn.BeginTransaction(); var affected conn.Execute(sql, new { scheduleId 10086 }, tx); if (affected 0) { tx.Rollback(); throw new BizException(该时段号源已满); } // 同一事务内插入挂号流水状态置为待支付 conn.Execute(insertFlowSql, new { ... }, tx); tx.Commit();逻辑说明数据库在UPDATE时对目标行加锁两个事务同时执行时后一个会等前一个提交后再执行此时remaining已经被扣过WHERE remaining 0不成立受影响行数为0业务直接抛已满。不需要应用层分布式锁也不存在超卖窗口。参数说明affected 0有三种可能——号源已满、schedule_id不存在、时段被停诊关闭建议分别查一次再抛不同提示避免收费员一头雾水version_no 1让每次扣减可追溯排查数据问题时能对比版本号变化。4.2 幂等键双击、重试和网络回执的后悔药收费场景的重复来源有三个收费员双击按钮、客户端请求超时自动重试、医保或支付平台回调重复投递。光靠前端禁用按钮不可靠后端必须做幂等。做法是业务表加request_id列建唯一索引处理请求前先插入幂等记录// SQL Server 唯一键冲突2627/2601MySQL 重复键1062 const string insertIdempotentSql INSERT INTO idempotent_flow (request_id, order_id, status, create_time) VALUES (requestId, orderId, 1, GETDATE());; try { conn.Execute(insertIdempotentSql, new { requestId, orderId }); } catch (SqlException ex) when (ex.Number 2627 || ex.Number 2601) { return GetExistingResult(orderId); // 重复请求返回已处理订单 }逻辑说明唯一索引冲突是幂等兜底——两个并发请求同时到只有一个能INSERT成功另一个吃索引冲突后去查既有结果返回。双击、重试在这里被统一拦住。参数说明request_id建议用操作员ID时间戳随机数拼接别裸传GUID否则排查时看不出请求来源如果业务涉及多表写把幂等INSERT和业务写包在同一个事务里保证请求记录和业务数据同生共死——事务回滚时幂等记录也消失不残留脏的幂等键。4.3 订单状态机待支付、已收费、已退费只走合法迁移订单状态散落成if-else是HIS后期维护的灾难。有人问这个单子能退吗你得翻三个地方查状态判断。我一般用一张迁移表把状态规则钉死private static readonly DictionaryOrderStatus, OrderStatus[] Allowed new() { [OrderStatus.Pending] new[] { OrderStatus.Paid, OrderStatus.Cancelled }, [OrderStatus.Paid] new[] { OrderStatus.Refunded }, [OrderStatus.Refunded] Array.EmptyOrderStatus(), [OrderStatus.Cancelled] Array.EmptyOrderStatus(), }; public void TransitionTo(OrderStatus target) { if (!Allowed[_current].Contains(target)) throw new BizException($订单不允许从 {_current} 迁移到 {target}); _current target; }逻辑说明状态机让非法迁移在入口被拦住已退费再转已收费这种操作不可能发生。新增状态比如部分退费只改这一处不用满项目找if。参数说明C#里用Dictionary加枚举做小状态机够用不必引状态机框架业务量大时建议再加一张order_status_log表每次迁移写一行审计时能查谁在几点把订单改成了退费——这是医院审计的硬要求。4.4 死锁排查缴费流水为什么偶发超时现象高峰期偶发事务与另一个进程死锁请重试。多窗口同时缴费时事务A先锁账户1再锁账户2事务B先锁账户2再锁账户1两边互相等数据库选一个牺牲者回滚。解决三板斧统一锁顺序、缩短事务、索引对齐。-- SQL Server 查看当前阻塞链 SELECT request_session_id, resource_type, resource_description, request_mode, request_status FROM sys.dm_tran_locks WHERE request_status WAIT;逻辑说明发现死锁先把事务里做的事砍到最少再检查所有UPDATE是否按同一字段顺序执行比如统一按patient_id升序处理最后看关联条件的列有没有索引——没索引时行锁升级成表锁死锁概率会大很多。MySQL环境用SHOW ENGINE INNODB STATUS看LATEST DETECTED DEADLOCK定位到最后一条互相等待的SQL。这种偶发问题最气人一定要把死锁日志捞出来留着分析别只加个重试机制就完事。5. HIS实施避坑医保接口、设备对接与数据修正的5个现场教训这一章是血泪经验五个坑都是真实项目里踩过的每条按现象、原因、解决写清楚。实施阶段把这五条排掉能少熬一半的夜。5.1 医保接口双写导致金额不一致现象收费成功后医保侧金额对不上同一笔结算在医保系统出现两遍月底对账差出几千块。原因本地账务先提交成功再调医保接口时网络超时收费员重试——本地判断已成功跳过写入但医保侧已经落了一笔结算两边就差了。解决把本地账务和医保结算设计成主从关系。本地先落pending单把request_id上送医保收到医保明确回执后再把本地单置为成功接口超时后只做查询确认不做重复提交。医保结算接口常是WebServiceC#里动态调用wsdl不把客户端绑定死在某个版本的服务上省去每次升级都要重新引用的麻烦。另外每天必须跑对账任务把医保汇总金额和本地流水SUM比对差一分钱都要查链。5.2 读卡器与打印机抢占串口现象新装两台扫码枪后挂号的医保读卡器间歇性失灵拔插一下又好过半小时又犯。原因多个USB转串口设备共用一个HUB驱动把同一个COM号分给了不同设备扫码枪默认是键盘仿真模式焦点落在任意输入框时扫描内容直接打进表单看起来就像乱输字符。解决给每台设备固定COM口在设备管理器端口设置-高级-COM端口号里手动指定不要用无源HUB扫码枪设成USB-HID模式或设置前缀后缀在程序里识别到扫描内容后自动回车提交。对接读卡器、体温枪这些外用设备时C#用SerialPort或厂家动态库对接逻辑和做上位机一致——记住串口用完必须释放SerialPort被占用时第二次Open会直接抛异常这是设备被别人占着最常见的报错来源。设备参数别写死在代码里存注册表或JSON配置都行。5.3 生僻字姓名存不进数据库现象病人姓名含生僻字挂号员敲完保存报错或者存进去变成问号少数民族姓名带·间隔符查询时对不上。原因数据库字符集不支持补充字符或客户端连接串没指定UTF-8服务端把UTF-16转成GBK时截断。SQL Server的普通排序规则装不下Unicode扩展区MySQL的utf8旧版utf8mb3也存不了emoji和部分生僻字。解决MySQL建库用utf8mb4连接串加charsetutf8参数SQL Server选支持补充字符的排序规则比如Chinese_PRC_90_CI_AS_SC普通_CI_AS不行。应用层禁止对姓名做trim之外的改写身份证号里的X统一大写姓名里的·符号不要在UI层拦掉——你以为在防脏数据实际是把合法姓名挡在门外。5.4 直接改库修数据引发审计事故现象某天收费员录错单价工程师嫌界面操作麻烦连上生产库直接UPDATE订单金额几周后财务审计发现流水与业务单据对不上又没有操作日志只能翻数据库日志还原。原因绕过应用层改数据跳过了操作员、操作时间、业务日志这三样审计要素。改的时候数据没问题但审计追问谁改的、为什么改时系统回答不了。解决规范只有两条——数据修正必须走应用功能作废重开、红冲重录界面没有的修正场景先开发再上线别拿生产库当测试环境。特殊情况确实需要直改库必须先SELECT备份原记录再UPDATE再写一条审计记录包含工单号、操作人、改动前后值。不要抱用完就删的侥幸审计系统读的就是这张表。5.5 操作员电脑时间不准导致HIS与LIS对不上现象检验科报申请单时间和实际不符医保对账报时间漂移查下来是某台收费机系统时间慢了8分钟。原因Windows默认时间同步没开有人手动改过系统时间客户端代码取了DateTime.Now本地时间于是每条业务记录的时间都跟着歪。解决客户端发起的所有业务时间一律以服务端时间为准代码里不信任客户端DateTime.Now接口入参不允许客户端传时间字段工作站加入域后统一用NTP同步或用开机脚本对时。服务端也别取应用服务器本地时间统一用数据库时间函数比如SQL Server的GETDATE()当业务时间避免应用服务器和数据库服务器时间不一致导致报表对不上。6. 上线前自测手法用压力脚本验证挂号并发与数据一致性HIS上线最怕的不是功能缺是并发场景在开诊那天才暴露。我的习惯是上线前跑一轮并发压测专门验证号源扣减和流水写入的一致性// 并发抢号验证50个任务抢同一时段号源 var tasks Enumerable.Range(1, 50) .Select(i Task.Run(() TryRegister(_connString, i))) .ToArray(); await Task.WhenAll(tasks); // TryRegister 内部执行 4.1 的原子UPDATE 插入挂号流水 // 结束后执行两条验证SQL // SELECT total - remaining FROM register_schedule WHERE schedule_id 10086; // SELECT COUNT(*) FROM register_flow WHERE schedule_id 10086 AND status 0; // 两者必须相等且都等于成功扣号的次数。逻辑说明这个测试重点不是TPS多高而是扣销量与流水量是否严格相等。跑完如果两者不等说明事务边界或幂等逻辑有问题直接看4.4的死锁SQL查阻塞链。参数说明压测前先把号源remaining重置到50跑完再重置回5做小号量回归确保已满分支也被走到——很多系统只在有号路径测过没号时的提示语反而漏了。上线清单里我习惯再加三步第一导完数据跑一次历史流水SUM等于账户余额的校验第二写一个定时对账任务每天凌晨把挂号流水、收费流水、退费流水三张表按业务口径汇总比对第三新版本先在住院部找一台机器跑一个工作日别直接推到门诊高峰。当年急诊挂号上线那次没有脚本撑腰谁也不敢在早高峰动号源表结构后来每次改号源逻辑都先压一遍才敢发版。这套自测做完C#做HIS这个方向就值得投入——至少不会被并发扣号这种基础问题在开诊那天打脸。希望帮到你。本文还有配套的精品资源点击获取