[开源] 医联体结算博弈结构可视化系统：用纳什均衡定位多记账与少付出的策略失衡点，面向联盟办和医保结算岗的决策支持工具
本项目是一个专为医联体结算机制分析设计的开源决策支持系统，将医院间结算行为建模为非合作博弈，以纳什均衡为数学锚点，识别「多记账」与「少付出」两类典型策略在真实资金流中的共谋结构与稳定状态。我们不替代财务系统，也不生成会计凭证，而是把结算过程里那些说不清道不明的“账面偏差”还原成可计算、可对比、可交互的博弈图谱。面向医联体管理办公室、区域医保经办机构、卫生行政部门结算岗人员，提供 CLI 命令行驱动的场景生成、均衡求解与 HTML 报告输出能力；核心引擎用 Python 实现纳什均衡求解（纯策略+混合策略），前端可视化由 Plotly 驱动博弈树与 Sankey 资金流向图，整体通过 TypeScript/Node.js 封装为跨平台命令行工具。所有分析均基于本地数据运行，不联网、不上传、不依赖云服务。
定位与能力范围
我们不做全量结算系统，也不做医院 HRP 插件。本项目聚焦一个具体而尖锐的问题：当多家医院组成医联体后，为什么结算报表总存在“总额对得上、明细对不上”的黑洞？为什么反复强调规范记账，仍有机构倾向性地多记转诊收入或少计成本分摊？这不是操作疏漏，而是策略理性，每个主体都在自身约束下追求局部最优，最终导致系统级失衡。本系统把这种结构性张力显性化：把每家医院设为博弈参与者，把「实记账」「适度多记账」「激进多记账」「适度少记账」「激进少记账」设为可选策略，用标准博弈论框架建模其收益函数，并自动求解纳什均衡点。结果不是给出“谁错了”，而是指出“在当前规则下，哪些策略组合会自然收敛并长期维持”。这对联盟办理解结算顽疾根源、对医保部门设计激励相容的支付规则、对牵头医院评估成员单位行为边界，都提供了可验证的结构依据。
核心功能
系统围绕“建模—求解—呈现—对比”四步闭环展开，全部能力均可通过命令行触发，无需启动 Web 服务或数据库。
博弈建模：支持按需配置医院数量（如3家、5家）、交易条数（如100条、500条），自动生成符合医联体常见协作关系的初始场景；策略空间严格对应业务语义，例如「激进多记账」指将本院收治但实际由下级医院完成的检查项目全额计入自身收入，「激进少记账」指对向上转诊患者的后续费用分摊主动压低至显著低于成本水平。
纳什均衡求解：内置双路径求解器。对小规模博弈（≤4家医院+≤20策略组合）启用穷举法求纯策略均衡；对中等规模启用线性规划（LP）求解混合策略均衡；自动判别并切换，不需用户干预。所有均衡结果附带收敛验证标记与收益矩阵快照。
交互式可视化：生成三类 HTML 报告。博弈树图标注每个决策节点的医院名称、所选策略、对应收益值（单位：万元），支持鼠标悬停查看策略含义；Sankey 图以宽度映射资金量、颜色映射流向类型（如绿色=上级医院向下拨付、橙色=下级医院向上返还），直观暴露“钱从哪来、往哪去、被谁截留”；综合报告整合上述两图，并叠加均衡稳定性分析（如是否存在多个均衡点、各点收益差异幅度）。
场景对比机制：强制区分
normal（各方诚实记账）与gaming（存在策略性记账）两类基线场景。对比时不仅展示均衡点变化，更突出显示：同一医院在两种场景下策略选择的偏移方向（如从「实记账」滑向「适度多记账」）、资金净流入/流出额的绝对值变化、以及整个联盟的资金循环效率下降比例（示例：Sankey 图中回流环路占比从82%降至63%，提示内耗加剧）。可复现分析流程：所有生成动作支持
--seed参数固定随机种子，确保相同参数下输出完全一致；支持--verbose输出建模细节（如每家医院初始成本结构、策略收益计算逻辑），便于审计与教学复盘。
功能模块 | 输入控制方式 | 输出形态 | 典型使用目的 |
|---|---|---|---|
场景生成 | --hospitals, | JSON 场景文件 + 日志 | 构建符合本地医联体规模的仿真起点 |
均衡求解 | 内置自动判别，无需手动指定 | HTML 报告中嵌入均衡结果表格 | 判断当前结算规则是否诱发稳定失衡 |
博弈树可视化 | 自动生成，无额外参数 | game_tree_*.html | 理解单次决策中各医院收益权衡逻辑 |
Sankey 资金图 | 自动生成，无额外参数 | sankey_*.html | 追踪资金在多级机构间的实际滞留与损耗路径 |
场景对比 | compare命令 + 相同参数 | 对比报告含双图并列+差异高亮 | 量化博弈行为对结算健康度的影响程度 |
使用与配置
安装只需两步：先配 Python 环境跑通博弈引擎，再装 Node.js 编译 CLI。二者完全解耦，Python 部分可单独调用，Node.js 部分也可仅作格式封装器。
cd interlocking-accounting-game-tree python -m venv venv source venv/bin/activate pip install -r requirements.txtnpm install npm run build日常使用以igt（interlocking game tree 缩写，CLI 中已设为别名）为主入口。以下是最常用组合：
快速启动分析：
igt generate --hospitals 3 --records 100 --scenario gaming
生成3家医院、100条交易的博弈场景，自动求解并输出完整 HTML 报告到output/reports/对比基线差异：
igt compare --hospitals 3 --records 100
同时生成normal与gaming两套场景，输出对比报告，直接呈现策略漂移与资金漏损量化值查看最新报告：
igt view
自动定位output/reports/下时间最新的report_*.html并用默认浏览器打开指定输出位置：
igt generate --hospitals 4 --output my_analysis
所有输出（JSON、HTML、log）均落于my_analysis/目录，便于项目隔离
所有子命令均支持--help，例如igt generate --help会列出全部参数及业务含义，如--strategy-distribution控制各策略在初始场景中的出现概率分布，供高级用户调节博弈烈度。
工程结构
项目采用清晰的分层架构，Python 侧专注“算得准”，Node.js 侧专注“用得顺”。
python/src/是核心算法层：models/定义Hospital（含等级、床位数、成本系数）、Strategy（含策略名、适用条件、收益影响权重）、TransactionRecord（含来源医院、目标医院、项目类型、金额、是否被策略修饰）等实体；solver/实现两种均衡求解器，接口统一返回NashEquilibrium对象（含策略组合列表、各参与方收益、稳定性标识）；simulator/提供可插拔的数据生成器，如HospitalGenerator按三级/二级/社区医院比例生成异构机构集；visualizer/封装 Plotly 调用，将博弈结果转化为 JSON 可序列化的图表配置。src/是交互层：cli.ts为命令主干，解析参数后调用python/子进程（通过spawn启动并传参）；commands/下generate.ts、view.ts、compare.ts分别封装对应逻辑；formatter/统一处理终端输出样式与 HTML 路径拼接。output/为纯产物目录，不参与构建。所有中间数据与最终交付物均落于此，结构固定，便于脚本批量处理或集成进现有 BI 流程。
这种分离设计意味着：若你已有 Python 数据栈，可直接 importpython/src/solver模块嵌入自有系统；若你习惯 Node.js 生态，也可跳过 Python 安装，仅用igt view打开他人共享的output/reports/下的 HTML 文件，报告本身是自包含的，含全部 JS 与数据。
数据与扩展
输入数据全部由模拟器生成，不依赖外部数据库或 Excel 表格。但模拟逻辑高度可配置，适配真实业务映射：
医院属性：
Hospital模型含level（三级/二级/社区）、beds（床位数）、cost_ratio（单位服务成本系数），这些字段直接影响策略收益计算。例如「多记账」收益 = 记账金额 × (1 +cost_ratio)，体现高成本机构更有动机虚增收入。交易记录：
TransactionRecord的type字段预设consultation（会诊）、referral（转诊）、exam（检查）、treatment（治疗）四类，每类对应不同分摊规则。用户可在simulator/中新增类型并定义其收益公式。策略扩展：新增策略只需在
models/Strategy.py中添加枚举项，并在solver/中补充其对收益矩阵的修改逻辑。例如要加入「选择性少记账」（仅对特定类型交易少记），只需定义新策略并重载apply_to_transaction()方法。
所有扩展均不破坏原有 CLI 接口。新增策略后，--scenario gaming仍可正常运行，系统自动将新策略纳入均衡搜索空间。
限制与说明
本项目明确限定于研究与教育场景，有三项关键边界：
不处理真实财务数据：所有输入均为模拟生成，不读取医院 HIS、EMR 或医保结算库。若需接入真实数据，须由用户自行开发适配器，将原始交易流水映射为
TransactionRecord对象，并确保策略标签可业务归因。不替代政策制定：均衡结果揭示“在给定规则下会发生什么”，但不回答“应该制定什么规则”。例如发现
gaming_B（激进少记账）成为主导均衡，只说明当前分摊公式存在漏洞，具体如何修订需结合卫生经济学评估。不覆盖全部博弈形态：当前模型假设医院完全理性且信息对称，未引入学习机制、声誉惩罚或动态重复博弈。对需要建模“今年少记、明年被约谈”这类预期约束的场景，需用户在
simulator/中增强状态机逻辑。
项目文档中已明确标注：所有分析结论需结合本地医联体章程、结算办法与历史纠纷案例交叉验证。我们提供的是结构显影剂，不是诊断书，更不是处方签。
项目地址：
https://github.com/nexorin9/interlocking-accounting-game-tree