Ca Medical Exclusions

io.github.pipeworx-iov0.1.0更新于 Oct 8, 2026

California DHCS Medi-Cal Suspended and Ineligible (S&I) Provider List

已验证Streamable HTTP可网页运行Data & AnalyticsBusiness & Commerce

概览

AI 生成的概览

按姓名、NPI 或执照号,将医疗服务提供者与加州 Medi-Cal 暂停及不合格提供者名单进行筛查比对。

功能
提供两个工具:ca_medical_check_exclusion 可按姓名、NPI 或执照号,在约 23,400 行的加州 DHCS Medi-Cal 暂停及不合格(S&I)提供者名单中筛查提供者;ca_medical_exclusion_coverage 报告名单规模、带 NPI 或执照号的行数、提供者类型多样性、暂停日期范围、全名单法定依据以及数据截止日期。NPI 和执照匹配被视为精确身份识别;姓名匹配仅标记为候选线索。名单已内置在包中并定期刷新,而非实时抓取。
适用场景
适用于针对加州州级 Medicaid 排除名单的提供者筛查、资质审核、合规与尽职调查,可作为联邦 LEIE 的州级对应工具。当你需要核查某个具体提供者或汇总名单覆盖情况时最为合适。
运行要求
使用 Pipeworx 网关上的远程 streamable HTTP 端点;首次调用无需账户、API 密钥或请求头。也提供本地 stdio 版本,作为 npm 包通过 npx 运行,需要 Node.js。需要能访问网关或 CHHS 开放数据门户来源的网络。
安装前请注意
姓名匹配仅为候选线索,因为名单不含出生日期,且许多实体行缺少名或中间名;不要将姓名命中视为已确认的排除。内置副本可能相对 DHCS/CHHS 的每月刷新而过期,请查看所报告的数据截止日期。该端点还会暴露本包工具之外的共享网关元工具,会增加上下文开销。这是独立的非官方集成,与上游提供者无关联,也未获其认可。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Ca Medical Exclusions,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Web executable,通过 Streamable HTTP。 远程服务在工作区中配置后即可从网页运行时运行。

其他 MCP 客户端

把它添加到你客户端的 mcpServers 配置中。

{
  "mcpServers": {
    "ca-medical-exclusions": {
      "type": "http",
      "url": "https://gateway.pipeworx.io/ca-medical-exclusions/mcp"
    }
  }
}

README

@pipeworx/ca-medical-exclusions

California DHCS Medi-Cal Suspended and Ineligible (S&I) Provider List screening — check a provider by name, NPI or license/provider number against the ~23,400-row list of providers barred from California's Medicaid program, the state-level counterpart to the federal HHS OIG LEIE (leie pack) and the sibling of ny-omig-exclusions for New York.

Part of Pipeworx — an MCP gateway connecting AI agents to 1721+ live data sources. This is an independent, unofficial integration — not affiliated with, endorsed by, or published by the upstream provider.

Tools

  • ca_medical_check_exclusion(name?, npi?, license?, limit?) — screens a provider against the DHCS S&I List. An NPI or license match is an identification (both are exact, provider-specific identifiers); a name match — even an exact one — is a candidate lead only, since the list carries no date of birth and many entity rows have no first/middle name to disambiguate same-named providers.
  • ca_medical_exclusion_coverage() — total exclusions held, how many carry an NPI or license number, provider-type diversity, the oldest/newest suspension date, the list-wide statutory basis, and the CHHS Open Data Portal's "last modified" date for the baked copy this pack serves.

Auth

Keyless.

Data sources

Why the CHHS datastore, not dhcs.ca.gov/files.medi-cal.ca.gov directly

DHCS's own pages (dhcs.ca.gov, files.medi-cal.ca.gov) link the S&I List only as a month-named CSV — e.g. suspended-ineligible-list-august-2026.csv — whose filename changes on every monthly refresh, so it cannot be fetched by a fixed URL without first scraping the current filename from an HTML page. The SAME dataset (same CKAN resource_id, 48630a37-b5ba-4d3d-af54-e82b30e658a0) is also published on the California Health and Human Services (CHHS) Open Data Portal, data.ca.gov and catalog.data.gov — all three mirror the identical resource. The CHHS CKAN API's datastore_search/resource_show endpoints are keyed by that stable resource id, never by a filename, and return clean JSON directly (no CSV parsing). This pack uses that API.

Why this is baked, not a live proxy

Per root CLAUDE.md's standing rule for a table this size, the full list (23,433 rows at capture time, ~7.2MB as generated TypeScript) is baked by scripts/bake-index.mjs into src/ca-dhcs-index-data.ts, registered in workers/gateway/src/pack-baked-indexes.json, uploaded to KV at deploy, and injected into every call as args._bakedIndex — never a static module-scope import (fleet #2754: six packs doing that put ~48MB of retained heap into every gateway isolate and cost about one call in four as a Cloudflare 1102). A missing or malformed injection throws loudly rather than answering "not found" — see src/index.test.ts.

Re-run node mcps/ca-medical-exclusions/scripts/bake-index.mjs periodically (DHCS/CHHS update the list monthly) and recommit; data_as_of on every response says how stale the baked copy is relative to CHHS's own last_modified metadata.

What this data does NOT include — and what it does, that NY's list lacks

The task that filed this pack assumed DHCS publishes a per-record exclusion reason/authority field "which NY lacks." Checked directly against the live CHHS datastore (not assumed): that is not correct. DHCS's published fields are Last/First/Middle Name, AKA/DBA, Address, Provider Type, License Number, Provider Number(s) (NPIs and/or non-NPI codes like PHA410230), Date of Suspension, and Active Period — there is no per-row statute, reason code, or case citation. "Active Period" is "Indefinitely effective" for 23,431 of 23,433 rows and carries no reason either.

What California's list DOES carry that NY's OMIG list lacks:

  • Provider Type — hundreds of distinct values (Registered Nurse, Physician, Pharmacy, Entity/Corporation, etc.), returned on every match.
  • A published list-wide statutory basis — California Welfare & Institutions Code §§14043.6 and 14123 (felony conviction, a Medi-Cal-related misdemeanor, federal Medicare/Medicaid exclusion, loss of license, or contract breach). This applies to the WHOLE list, not per-record, and every response surfaces it as statutory_basis, clearly labelled as list-wide rather than an invented per-record reason.

Matching

provider_numbers is a comma-separated field in the source data that can mix 10-digit NPIs with non-NPI codes (pharmacy/registration numbers like PHA410230). This pack extracts the 10-digit tokens as npis at bake time; an npi query matches only against those. A license query matches the separate License Number field, digits-only, leading zeros stripped — the same comparison ny-omig-exclusions uses. Name queries match against the provider's assembled name (last, or last+first+middle) and any AKA/DBA, case/punctuation-insensitive.

Reachability

Verified live 2026-10-07 from both a laptop curl and a throwaway wrangler dev --remote Worker on the prod account: identical 200 responses from the Cloudflare edge on both datastore_search (the full ~8.68MB payload, in ~1.1s) and resource_show. Unlike oklahoma-code / utah-code / new-hampshire-code, this host needs no Supabase egress relay.

Quick Start

Add to your MCP client (Claude Desktop, Cursor, Windsurf, etc.):

json
{  "mcpServers": {    "ca-medical-exclusions": {      "url": "https://gateway.pipeworx.io/ca-medical-exclusions/mcp"    }  }}

What this endpoint actually serves

tools/list at https://gateway.pipeworx.io/ca-medical-exclusions/mcp returns the tools in the table above plus the shared Pipeworx meta-tools — ask_pipeworx, discover_tools, search_within, remember/recall and the rest of the gateway-wide set. So the tool count you see is larger than this table: a single-pack endpoint currently lists roughly 30 shared tools alongside the pack's own. The connection's initialize response states its exact scope, and is the authoritative answer for a given day.

This is deliberate, not multiplexing by accident. The meta-tools are what let a scoped connection answer a question this pack does not cover — via ask_pipeworx, which routes across the whole catalog — without you adding a second MCP server. There is currently no way to mount a pack endpoint without them; if the extra schemas cost you more context than the routing is worth, connect to the full gateway once rather than to several pack endpoints.

Or connect to the full Pipeworx gateway to get every pack's tools listed directly, instead of just this one's:

json
{  "mcpServers": {    "pipeworx": {      "url": "https://gateway.pipeworx.io/mcp"    }  }}

Both URLs reach the same gateway and the same 1721+ data sources. The only difference is which pack's tools are listed directly; ask_pipeworx reaches all of them from either one.

No MCP client? Call it over HTTP

bash
curl -X POST https://gateway.pipeworx.io/v1/tools/ca_medical_check_exclusion \  -H 'Content-Type: application/json' \  -d '{"name":"111 Pharmacy"}'

No account needed for the first calls. Inspect any tool: GET https://gateway.pipeworx.io/v1/tools/ca_medical_check_exclusion. Find one: POST https://gateway.pipeworx.io/v1/tools/search_packs with {"query":"..."}.

Standalone (no gateway account)

This package also runs as a local stdio MCP server — no Pipeworx account, no gateway round-trip:

json
{  "mcpServers": {    "ca-medical-exclusions": {      "command": "npx",      "args": ["-y", "@pipeworx/mcp-ca-medical-exclusions"]    }  }}

Or run it directly to confirm it starts:

bash
npx -y @pipeworx/mcp-ca-medical-exclusions

It speaks MCP over stdin/stdout and answers initialize/tools/list/tools/call for only this pack's tools — none of the shared meta-tools the gateway connection above adds. Same source, same tools, no ask_pipeworx routing.

Using with ask_pipeworx

Instead of calling tools directly, you can ask questions in plain English — this works on the pack endpoint above as well as on the full gateway:

ask_pipeworx({ question: "your question about Ca Medical Exclusions data" })

The gateway picks the right tool and fills the arguments automatically.

More

License

MIT

来源:README.md,提交 2166371

工具

0
工具元数据尚未被收录。

版本历史

1
  1. v0.1.0最新Oct 8, 2026