简介这份资源是面向医保信息化实施人员、医疗机构HIS对接开发者及医保结算业务学习者的昌吉州医保结算系统实施版资料聚焦参保信息管理、费用审核报销、智能审核规则、跨区域结算与数据安全等核心业务场景帮助读者理解地方医保政策落地与系统接入的实际流程。压缩包共3个文件以htm说明文档、txt下载说明和pbl程序文件为主分别承载系统使用指南、安装操作提示与业务程序本体整体约929KB体积轻便便于快速查阅。目前已有1835人学习下载具备一定的实践参考基础。读者可从中获取昌吉州特定医保政策、报销标准与操作流程的说明借助说明文档了解系统如何与医疗机构信息系统交换费用数据、处理日常结算事务并据此梳理实施要点与排错思路适合作为区域医保结算项目入门与对接参考。1. 医保结算系统从一笔门诊费用说起上周帮一个做医疗信息化的朋友看代码他扔过来一个压缩包说“你帮我看看这个医保结算系统到底能不能跑”。我打开一看目录里躺着参保人管理、待遇计算、结算单生成、对账导出几个模块典型的医保结算业务骨架。这类系统解决的核心问题很具体一笔门诊或住院费用产生后怎么按参保类型、报销比例、起付线、封顶线算出自付和统筹支付再生成一张能对得上的结算单。适合谁一是医疗信息化方向想练手的开发者二是需要给小型机构做结算原型的团队。它不涉及真实医保平台对接但业务逻辑的骨架是完整的拿来理解“医保结算”这条链路怎么落地比看十篇概念文章管用。2. 技术栈与目录结构先看清这套骨架怎么搭的2.1 技术选型为什么是这套组合从工程结构看这套系统走的是“后端算账、前端录单”的经典分层。后端用 Python Flask 提供 REST 接口数据库用 SQLite 做本地存储前端是原生 HTML JavaScript 加一层轻量模板渲染。这个组合不是随便选的医保结算的核心是待遇计算规则多、变动频繁用 Python 写计算逻辑改起来快不用编译SQLite 免安装拷过去就能跑适合演示和二次开发起步前端不引框架是为了让读代码的人一眼看到“录单—算账—出单”的数据怎么流动。常见做法是生产环境换成 PostgreSQL 或 MySQL把计算规则抽成配置表而不是硬编码。这套源码里比例和起付线是写在配置字典里的我一般会建议二次开发时先把它挪到数据库后面加参保类型就不用改代码。依赖清单很薄requirements.txt里主要就是 Flask 和它的依赖没有 ORM、没有迁移工具。这意味着表结构是手写 SQL 建的读的时候要顺着schema.sql看字段含义。对新手来说这是好事少一层抽象对熟手来说要加索引、加事务得自己补。2.2 目录结构每个文件负责什么把压缩包解开主干目录大致是这样insurance-settlement/ ├── app.py # Flask 入口注册路由 ├── config.py # 报销比例、起付线、封顶线配置 ├── schema.sql # 建表语句 ├── seed.sql # 演示数据 ├── requirements.txt ├── modules/ │ ├── insured.py # 参保人增删改查 │ ├── settlement.py # 结算核心待遇计算 │ └── report.py # 结算单与对账导出 ├── static/ │ ├── app.js # 前端录单与结果展示 │ └── style.css └── templates/ ├── index.html # 录单页 └── detail.html # 结算单详情页modules/settlement.py是整个项目的心脏待遇计算、起付线判断、封顶线截断都在这里。config.py是规则入口改比例先看它。report.py负责把结算结果落成可导出的结构对账时用。前端两个页面一个录单一个看单没有多余页面读起来不费劲。2.3 数据模型三张表撑起结算链路schema.sql里核心是三张表参保人表、就诊记录表、结算单表。参保人表存证件号、参保类型、参保状态就诊记录表存就诊时间、费用明细、总金额结算单表存这次结算的统筹支付、个人自付、起付线扣除额。三张表通过参保人 ID 和就诊记录 ID 关联。这里有个设计取舍值得说结算单表没有把费用明细再拆一张表而是把明细以 JSON 文本存在一个字段里。好处是出单快、查询简单坏处是后面要按项目维度统计就得解析 JSON。我一般会建议二次开发时把明细拆成独立表尤其是要做费用结构分析的时候。这套源码先跑通为主这个简化可以接受。3. 核心模块拆解一笔费用怎么算成结算单3.1 待遇计算起付线、比例、封顶线三段式结算的核心逻辑在modules/settlement.py的calculate()函数里。它按“先扣起付线、再乘报销比例、最后封顶截断”的顺序算这是医保结算里最常见的三段式。看代码# modules/settlement.py from config import RULES def calculate(insured_type, total_amount, items): insured_type: 参保类型如 employee / resident total_amount: 本次费用总额 items: 费用明细列表每项含 category 和 amount rule RULES.get(insured_type) if not rule: raise ValueError(f未知参保类型: {insured_type}) # 第一步扣除起付线低于起付线不进入报销 deductible rule[deductible] base max(total_amount - deductible, 0) # 第二步按比例计算统筹支付 ratio rule[ratio] fund_pay base * ratio # 第三步封顶线截断超出部分转个人自付 cap rule[cap] if fund_pay cap: fund_pay cap # 个人自付 总额 - 统筹支付 self_pay total_amount - fund_pay return { total: round(total_amount, 2), deductible: round(deductible, 2), fund_pay: round(fund_pay, 2), self_pay: round(self_pay, 2), }逻辑说明base是扣掉起付线后的可报销基数用max(..., 0)防止费用低于起付线时出现负数。fund_pay是统筹支付额先乘比例再和封顶线比较。参数上RULES从config.py读结构是{参保类型: {deductible, ratio, cap}}。改规则只动配置不动函数这是这套代码最值得保留的习惯。注意一个细节这里封顶线截断的是统筹支付额不是费用总额。有些实现会截总额算出来的自付会偏大。二次开发时如果发现对账对不上先查这里截的是哪个量。3.2 结算接口一次请求的完整链路app.py里暴露的结算接口是POST /api/settlement接收参保人 ID 和费用明细调calculate()后写结算单表。看路由# app.py app.route(/api/settlement, methods[POST]) def create_settlement(): data request.get_json() insured_id data[insured_id] items data[items] total sum(i[amount] for i in items) # 查参保人拿参保类型 insured query_insured(insured_id) if not insured or insured[status] ! active: return jsonify({error: 参保状态异常}), 400 result calculate(insured[type], total, items) # 落库结算单 明细 JSON settlement_id save_settlement(insured_id, result, items) return jsonify({settlement_id: settlement_id, **result})这段链路的关键点在两个校验参保人存在、参保状态为 active。很多演示项目会漏掉状态校验导致停保的人也能算出报销对账时就是一笔坏账。save_settlement()把明细序列化成 JSON 存进结算单表和前面说的表设计对应。参数上items每项至少要有amountcategory目前只存不参与计算留给二次开发做分类报销。3.3 结算单生成与对账导出modules/report.py负责把结算结果转成可读的结算单结构并支持导出 CSV 做对账。核心是一个build_statement()函数把参保人信息、费用明细、计算结果拼成一个字典前端详情页直接渲染。导出部分用标准库csv写文件不引第三方库。对账场景下常见做法是按日期区间拉结算单列表汇总统筹支付总额和财务流水比对。这套源码里export_daily()就是干这个的传日期查当天所有结算单输出一行行记录加一个合计行。二次开发时如果要接真实财务系统把 CSV 换成接口推送即可结构不用大改。4. 跑起来从零到看到第一张结算单4.1 环境准备与依赖安装先确认 Python 版本这套代码用的是 Flask 2.x 的写法Python 3.8 以上都能跑。建虚拟环境是血泪经验别直接往系统环境装python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install -r requirements.txt装完确认 Flask 能导入python -c import flask; print(flask.__version__)。如果报错多半是虚拟环境没激活或者 pip 指向了系统 Python。这一步翻车的人不少先把这个排除掉再往下走。4.2 初始化数据库与演示数据建表和灌数据分两步先跑schema.sql再跑seed.sqlsqlite3 insurance.db schema.sql sqlite3 insurance.db seed.sqlschema.sql建三张表seed.sql插几个参保人和几条就诊记录方便一启动就有数据可算。如果本机没装 sqlite3 命令行用 Python 跑也行import sqlite3 conn sqlite3.connect(insurance.db) with open(schema.sql, encodingutf-8) as f: conn.executescript(f.read()) with open(seed.sql, encodingutf-8) as f: conn.executescript(f.read()) conn.commit()注意executescript会一次性执行整个文件文件里有多条语句时用它别用execute。数据库文件名要和config.py里的连接串一致不一致就是“表不存在”的经典报错。4.3 启动服务与验证一笔结算启动就是python app.py默认跑在 5000 端口。打开浏览器访问录单页选一个演示参保人填两三条费用明细提交后应该能看到结算单详情总额、起付线、统筹支付、个人自付四个数。验证算得对不对拿演示数据手算一遍假设总额 500起付线 100比例 70%封顶 300。可报销基数 400统筹支付 280没超封顶个人自付 220。页面上四个数对得上链路就通了。对不上先看config.py里该参保类型的规则再看calculate()里封顶截的是不是统筹支付额。提示演示数据里的参保类型要和config.py的RULES键名一致大小写都算不一致会直接抛“未知参保类型”。5. 避坑与排查这几处最容易翻车5.1 起付线算成负数或重复扣现象费用低于起付线时个人自付比总额还大。原因扣起付线时没做下限保护total - deductible出了负数再乘比例就乱了。解决base max(total - deductible, 0)这套源码里已经这么写了二次开发改计算逻辑时别把这层保护删掉。另外注意起付线是按次扣还是按年累计扣演示项目按次真实业务常见按年累计改的时候要加累计字段。5.2 封顶线截错对象导致对账差现象结算单统筹支付和财务流水对不上差一个固定值。原因封顶线截的是费用总额而不是统筹支付额或者截断后没重算个人自付。解决先确认截的是fund_pay截完用total - fund_pay重算自付。对账差固定值时优先怀疑这里而不是数据库写错。5.3 参保状态没校验停保人也能报销现象演示时随便选个参保人都能出结算单包括状态是停保的。原因接口只查了参保人存在没查status active。解决在create_settlement()里加状态判断异常直接返回 400。这个坑在演示阶段不明显一接真实数据就是坏账二次开发第一步就该补上。5.4 SQLite 并发写锁导致接口偶发 500现象多人同时提交结算偶尔报database is locked。原因SQLite 默认写锁粒度粗并发写会排队超时。解决演示场景加个重试或串行化写入要真并发就换 PostgreSQL。这套源码定位是单机演示别拿它直接扛生产流量这是选型时就该认清的边界。5.5 明细 JSON 字段解析失败现象结算单详情页明细显示为空或报解析错。原因写库时json.dumps了读的时候忘了json.loads或者历史数据里存了非 JSON 文本。解决读的地方统一包一层解析解析失败给空列表并记日志别让一个坏字段把整张单子打挂。6. 二次开发把演示骨架改成能用的结算模块这套代码最值得动手改的地方是把硬编码规则挪成配置表。现在config.py里RULES是字典加一个参保类型要改代码重启。我一般会建一张rules表字段是参保类型、起付线、比例、封顶线、生效日期计算前按类型和日期查最新一条。这样运营改规则不用碰代码也留了历史版本可追溯。第二个改造点是费用明细拆表。现在明细塞在结算单的 JSON 字段里做费用结构分析很别扭。拆成settlement_items表字段是结算单 ID、项目类别、金额统计时直接 group by 类别。拆的时候注意老数据迁移写个脚本把 JSON 解析出来插新表跑完比对条数。第三个是加结算单状态机。演示项目出单即终态真实业务有“待审核、已确认、已冲销”。加一个status字段和几个状态流转接口冲销时生成反向结算单而不是删记录这是对账的后悔药。验证改造是否成功我习惯用一组固定用例跑回归低于起付线、正常比例、超封顶、停保人、未知类型五个场景各跑一遍结果和手算对得上才算过。改造前先把这组用例写成脚本改完一键跑比肉眼对页面靠谱。注意改规则表时保留生效日期别直接覆盖旧记录否则历史结算单重算会对不上。从那以后我每次接这类结算项目都先把“起付线、比例、封顶线”三个参数和它们的截断顺序写成用例跑一遍再动别的。规则算错后面全白搭。希望帮到你。本文还有配套的精品资源点击获取