<h1 align="center">dsh-cdi-plugin</h1>
<p align="center"> <strong>Synthetic CDI auditing, packaged for DeepSeek Harness</strong><br/> Native model tools for deterministic SOP-rule evaluation over a bundled SQLite rule store — with the CDI agent skills and (fictional) gold sets shipped in the box. </p>
<p align="center"> <img src="https://img.shields.io/npm/v/dsh-cdi-plugin" alt="npm version" /> <img src="https://img.shields.io/npm/dm/dsh-cdi-plugin" alt="npm downloads" /> <img src="https://img.shields.io/badge/license-MIT-green" alt="license MIT" /> <img src="https://img.shields.io/badge/DSH-0.1.0--rc.6-8257D0" alt="DSH 0.1.0-rc.6" /> <img src="https://img.shields.io/badge/status-published-green" alt="published on npm" /> <img src="https://img.shields.io/badge/data-synthetic-orange" alt="synthetic data only" /> </p>
A DeepSeek Harness (DSH) plugin that turns a governed clinical-documentation audit pipeline into two native model tools. Install it, ask for an audit, and the model walks the pipeline end to end — with every deterministic verdict coming from the SQLite SOP store, never from the LLM's judgment.
> Every finding stays requires_human_review and routes to a qualified human reviewer. All data is synthetic and fictional — no real patient, provider, or client data; no clinical, coding, billing, or compliance decision.
---
Who is this for
- Documentation-quality & audit teams in healthcare operations who need a
governed, traceable way to review clinical documentation against SOP rules — every finding cites its source fields and routes to a qualified human reviewer.
- DSH users building vertical solutions — a working reference for packaging
a domain pipeline (skills + rules + data + tools) as a standard plugin on the stock DSH GUI.
- Researchers & students studying governed agentic workflows — everything
runs on synthetic data, so it is safe to experiment with end to end.
Use cases
- Full-pipeline audit of a synthetic ICHD record: normalization → evidence
review → rule evaluation (deterministic via SQLite, narrative via use-case skills) → 7 draft findings, all requires_human_review.
- Patient-domain checks with the multi-domain gold set (
SYN-ICHD-05/06,
requires store: "multi-domain").
- Ad-hoc rule lookups — "which treatments finished ≥ 15 min early?"
(cdi_query_rule with SYN-ICHD-01, one record at a time).
Features
- Native tools, no shelling out —
cdi_query_ruleandcdi_list_rulesare first-class model tools (cards in the conversation, not bash+python). - The LLM reports, never judges — deterministic rules evaluate against bundled SQLite SOP stores (
shared+multi-domain); the tool's result is final. - 8 CDI agent skills in the box — the governed pipeline (normalization → evidence review → rule evaluation → human review) ships with the package, and is also discoverable from any repo's
.agents/skills. - Self-contained — tools + SOP stores + gold sets + rules + skills travel inside the npm package.
- Zero UI changes (Step 1) — runs on the stock DSH GUI; Step 2 adds a domain UI (finding cards, evidence detail, review workbench).
How it works
gold set (synthetic) ──► normalize ──► evidence review ──► rule evaluation ──► draft finding ──► HUMAN REVIEW
│ │
deterministic: cdi_query_rule (SQLite) └─► confirm / reject / clarify
narrative: use-case skills (LLM) │
└─► feedback loopQuick start
# install into your web profile
dsh plugin --profile web add dsh-cdi-plugin
# restart dsh web, then in any session:> 用 cdi_list_rules 列出所有确定性规则,然后对 > data/synthetic-ichd-patient-goldset.json 跑一次完整 CDI 审计
The deterministic-rule-audit skill prefers cdi_query_rule for every deterministic check; tools/query_deterministic_rule.py remains as a fallback with the same contract.
Tools
| Tool | Purpose |
|---|---|
cdi_query_rule | Evaluate one deterministic SOP rule (SYN-ICHD-01/09/06) against one record. store: "multi-domain" selects the patient-domain store. |
cdi_list_rules | List every deterministic rule in both bundled stores with trigger descriptions. |
Development
node --test "test/*.test.mjs" # frozen smoke tests — no DSH host neededThe tests cover the failure modes that actually crash profiles at boot (schema compilation at apply() time) and at tool-call time (output-schema validation, including non-triggered results whose draft_question is null). Run them before every release.
Local dev needs one machine-specific wiring symlink so the plugin resolves @deepseek-ai/* from its real location:
mkdir -p node_modules
ln -sfn ~/.dsh/profiles/node_modules/@deepseek-ai node_modules/@deepseek-ai(node_modules/ is git-ignored.)
Publish
node --test "test/*.test.mjs" # gate
npm version patch # bump
npm publish # requires a bypass-2FA granular token or OTPpeerDependencies deliberately pin the working release train (@deepseek-ai/dsh-tools: ^0.1.0-rc.6) — the npm latest dist-tag of @deepseek-ai/dsh-tools points at a broken 0.0.1-rc.1, so never resolve from latest.
Roadmap
- [x] Step 1 — host plugin (this package): native rule tools, packaged skills/data, verified on DSH
0.1.0-rc.6 - [x] npm publish —
dsh-cdi-plugin@0.1.0live on the npm registry - [ ] Step 2 —
cdi-guiclient half: audit-finding cards in the conversation, evidence/rule detail panel, human-review workbench — enterprise domain UI inside the DSH shell - [ ] More verticals — other documentation-audit domains on the same governed-pipeline pattern
License
MIT