openai-agents-python 医疗支持示例中的商业资格核验清单（Commercial Eligibility Checklist）深度解析

openai-agents-python 医疗支持示例中的商业资格核验清单Commercial Eligibility Checklist深度解析【免费下载链接】openai-agents-pythonA lightweight, powerful framework for multi-agent workflows项目地址: https://gitcode.com/GitHub_Trending/op/openai-agents-python导读本文围绕 examples/sandbox/healthcare_support/policies/commercial_eligibility_checklist.md 这份政策清单文档展开剖析它在 openai-agents-python 的 healthcare_support 沙箱示例中扮演的角色它既是挂载进沙箱工作区的政策库文档之一也是资格核验 Agent 与沙箱策略 Agent 执行商业保险资格核验时必须遵循的核对要点。读完本文你将掌握这份清单逐条对应的数据字段与匹配逻辑、资格核验与预授权审查的边界划分、以及如何运行示例场景验证整条链路。一、清单文档在示例中的定位在examples/sandbox/healthcare_support这个演示项目中policies/目录共 13 份 Markdown 政策文档构成一个只读政策库commercial_eligibility_checklist.md是其中专门面向商业保险Commercial Payer资格核验这一任务的操作清单。它在整个工作流中出现于两处关键位置沙箱工作区挂载workflow.py中_build_manifest()通过Manifest将policies/以LocalDir形式挂载进沙箱策略 Agent 可以读取并搜索这些文档见 workflow.py。策略 Agent 的搜索范围沙箱策略 Agent 的提示词要求用rg/grep在policies/中检索prior authorization|prior-auth|imaging|referral|billing|PPO|Blue Cross等关键词本清单即属于可命中的政策文件之一见 support_agents.py。因此这份清单不是孤立文本而是资格核验子 Agent 的工具调用 沙箱政策搜索两条路径共同遵守的核对基准。二、清单原文与逐条语义解读清单原文共四条逐条展开如下1. 核验四要素payer name、member ID、DOB、plan statusVerify payer name, member ID, date of birth, and plan status.这是资格核验的第一组硬性要素payer name保险支付方如 Blue Cross、UnitedHealthcare、Aetna、Cignamember ID会员号保单下唯一标识如BCX-4439201date of birth出生日期用于身份比对避免同名误配plan status保单状态在数据中以eligibility_status字段体现取值如active。在数据层这四项分别对应 insurance_eligibility.json 记录中的payer、member_id、dob、eligibility_status字段。2. 核验保障细节生效/终止日期、共付额、免赔额、共保Confirm effective date, termination date, copay, deductible, and coinsurance.第二组要素聚焦成本分摊结构effective date / termination date生效/终止日期确认保障区间覆盖服务日期copay共付额单次就诊固定自付额数据中分copay_primary_care与copay_specialist两档如 $35/$60deductible免赔额年度先自付额度数据中以deductible_remaining表示剩余额如$1,200coinsurance共保比例超出免赔额后按比例分担的费用。配套文档 blue_cross_benefits_reference.md 进一步强调Benefit verification should capture specialist copay, deductible remaining, and coinsurance即核验时必须显式捕获上述三项同时指出 PPO 骨科专科共付额通常在 $40–$75 之间、成像与门诊手术仍需扣除免赔额与共保——这为 Agent 判断返回数据是否合理提供了领域基准。3. 歧义消解规则payer 不明时用 member ID DOB 定位If payer name is ambiguous, use member ID and DOB to identify the most likely eligibility match.这条规则在源码中有精确对应data.py的lookup_eligibility()实现了一个payer 可选、member_id 与 dob 优先的匹配策略若提供了member_id先按member_id过滤记录若提供了dob再用归一化后的日期normalize_date支持%Y-%m-%d、%m/%d/%Y、%Y/%m/%d、%m-%d-%Y四种格式继续过滤当payer也能精确匹配时直接返回该记录若 payer 无法精确匹配则退而返回第一个同时满足 member_id 与 dob 的记录作为fallback_match——这正是用 member ID 和 DOB 识别最可能匹配项的实现细节见 data.py。4. 边界声明资格核验不替代预授权审查Eligibility verification does not replace prior authorization review.最后一条划定职责边界有保障不等于无需授权。即使eligibility_status为active成像、择期手术等服务仍可能要求预授权。数据字段prior_auth_required_services正是为此设计例如 Blue Cross 的 MRI、CT angiogram、择期手术且每条记录带有notes说明如 MRI requires prior authorization except emergency use。该边界在 Agent 提示词中也被固化benefits 子 Agent 的规则第 4 条明确仅当案例涉及成像、手术、待处理转诊或政策特定授权语言时才建议预授权审查且recommended_queue只能取care-team-intake-queue、auth-review-queue、billing-review-queue三者之一见 support_agents.py。三、清单如何被 Agent 执行工具链与提示词约束资格核验的落地依赖benefits_agentHealthcareBenefitsAgent与其绑定的三个本地查询工具定义见 tools.py工具名输入参数作用patient_info_lookuppatient_id / phone / name定位患者档案insurance_eligibility_lookuppayer / member_id / dob执行资格核验清单第 1、2、3 条appointment_referral_status_lookupreferral_id / patient_id查询转诊状态BENEFITS_PROMPT中的调用顺序约束直接对应清单的执行路径见 support_agents.py先调patient_info_lookup有 patient ID / phone / name 时再调insurance_eligibility_lookup有 payer / member ID / DOB 时——即清单前两条的核验动作再调appointment_referral_status_lookup有 referral ID 时判断是否需要预授权审查——即清单第 4 条的边界执行输出结构化BenefitReview。BenefitReview输出模型models.py的字段与清单逐条对应payer、member_id、eligibility_status、plan_summary覆盖清单第 1 条、prior_auth_recommended、recommended_queue覆盖清单第 4 条、referral_status与summary。四、数据字段全景清单核对内容的存储形态清单要求核验的每一项在 insurance_eligibility.json 中都有对应字段汇总如下清单要求数据字段示例值payer namepayerBlue Crossmember IDmember_idBCX-4439201date of birthdob1985-02-14plan statuseligibility_statusactiveplan 名称plan_nameBlue Cross PPO Silver 4500copaycopay_primary_care/copay_specialist$35/$60deductibledeductible_remaining$1,200预授权要求清单第 4 条prior_auth_required_services[mri, ct angiogram, elective surgery]备注/边界说明notesMRI requires prior authorization except emergency use.值得注意的是该数据集的default_response与lookup_eligibility()的not_found分支都返回eligibility_status: unknown并提示确认 payer、member ID 与 DOB——与清单第 1、3 条形成闭环信息不全时Agent 应继续追问而不是臆断。五、端到端验证运行基础资格核验场景内置场景eligibility_verification_basic直接演示了清单的完整执行场景文件见 eligibility_verification_basic.json场景输入患者自称 Maya Thompson下周做 MRI提供 payerBlue Cross、member IDBCX-4439201与 DOB02/14/1985——满足清单第 1 条所需要素预期行为intent 为eligibility_verificationrequired_tool_calls为insurance_eligibility_lookuprequired_entities为payerBlue Cross与member_idBCX-4439201黄金结论Confirm prior auth requirement for MRI and proceed with scheduling.——先核验资格清单 1、2 条再确认 MRI 的预授权要求清单第 4 条最后给出排程建议。运行方式在仓库根目录执行uv run python examples/sandbox/healthcare_support/main.py --list-scenarios uv run python examples/sandbox/healthcare_support/main.py --scenario eligibility_verification_basic其中--list-scenarios会列出全部 6 个内置场景如需清空共享的 SQLite 会话记忆可加--reset-memory无人值守可设置EXAMPLES_INTERACTIVE_MODEauto详见 README.md。更复杂的messy_ambiguous_knee_case场景则模拟了 payer 信息混乱的情况——此时正对应清单第 3 条的歧义消解规则最终触发route_to_human_queue的人工审批流程该工具通过needs_approval钩子强制人工确认见 tools.py。六、清单在整个工作流中的执行链路小结从源码结构看完整链路如下各环节实现位置见 workflow.pymain.py加载场景并构建HealthcareSupportContextrun_healthcare_support_workflow()创建UnixLocalSandboxClient与沙箱通过Manifest挂载case/场景 JSON 与转写、policies/含本清单的只读政策库与output/编排 Agent 依次调用benefits_review子 Agent 按清单执行资格核验→sandbox_policy_packet沙箱策略 Agent 搜索policies/并生成policy_findings.md与human_review_checklist.md需要时经route_to_human_queue转人工队列最后沙箱产出物被复制到.cache/healthcare_support/output/scenario_id/并用memory_recap_agent结合 SQLite 会话记忆输出案件回顾。其中策略 Agent 的finalize_policy_packet工具会强制校验policy_findings.md必须包含## Case summary、## Matched policy files、## Prior authorization、## Referral、## Missing information五个标题且每个匹配到的政策文件都必须在制品中被引用——这意味着像commercial_eligibility_checklist.md这样的清单文档一旦被命中其内容会被要求如实落到结构化产出中而不是被模型凭空发挥。七、总结commercial_eligibility_checklist.md虽短却是 healthcare_support 示例中政策驱动 Agent 行为的典型代表它以四行清单定义了商业保险资格核验的核对要素payer/member ID/DOB/plan status、保障细节copay/deductible/coinsurance/日期、歧义消解member ID DOB 兜底与职责边界不替代预授权审查。其在仓库中的价值体现在三层数据层insurance_eligibility.json字段一一对应、逻辑层lookup_eligibility()的匹配与回退实现、以及 Agent 层提示词规则与结构化输出约束。理解这份清单也就理解了如何用政策文档 沙箱 结构化输出构建一个可控、可审计、可人工介入的医疗支持 Agent 工作流。【免费下载链接】openai-agents-pythonA lightweight, powerful framework for multi-agent workflows项目地址: https://gitcode.com/GitHub_Trending/op/openai-agents-python创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考