# Northstar Payer Determination

> Produce a structured Northstar Health Plan payer-operations determination by querying the shared read-only environment over the network and returning exactly one JSON object that conforms to the task's answer_template.json, including the standard basis_audit trail. Covers UM prior-authorization determinations, pharmacy appeal & manufacturer-assistance intake dispositions, payment-integrity claim repricing, peer-to-peer summaries, and UM-finance margin-queue analysis.

- Skill: `prism-shadow/northstar-payer-determination` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add prism-shadow/northstar-payer-determination`
- Raw SKILL.md: https://api.skillmd.com/api/skills/prism-shadow/northstar-payer-determination/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: prism-shadow (https://skillmd.com/u/prism-shadow)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/prism-shadow/northstar-payer-determination

---


# Northstar Payer-Operations Determination

You are handed a Northstar Health Plan payer-operations work item. Review the
relevant records in the shared **read-only** environment and return **exactly one
JSON object** that conforms to the task's `answer_template.json`, ending in the
standard `basis_audit` block.

## Inputs (under the task's `input/` directory — read all three first)

- `prompt.txt` — the narrative request: target ID, requester role, reporting
  date/period, and what the deliverable must include.
- `payloads/task_context.json` — machine-readable parameters. The **target
  business ID** key varies by archetype (`target_business_id`, `business_id`,
  `target.claim_id`, `target.case_id`, `work_item.case_id`, etc.). Also carries
  `requester_role`, `reporting_date`/`reporting_period`, the environment access
  block, and any task-specific parameters (queue row IDs, thresholds,
  total-cost definitions, appeal windows). Honor these verbatim.
- `payloads/answer_template.json` — the **authoritative output contract**:
  required top-level keys, per-field types/enums, list ordering rules, numeric
  precision, `additional_fields_allowed`, and the `basis_audit` schema. It is
  the source of truth for the shape of your answer.

## Environment access — network only

Reach the environment exactly as described in `environment_access.md` (details
in `references/environment_and_data_model.md`). **Never** open, read, grep, or
otherwise inspect environment source files, generated data files, SQLite
database files, manifests, or setup scripts — use the HTTP endpoints only.

- Base URL: from `environment_access.md`.
- `GET /api/...` business endpoints are **open** (no auth): `/portal`,
  `/api/tables`, `/api/cases`, `/api/cases/{case_id}`, `/api/policies`,
  `/api/policies/{policy_id}`, `/api/documents/{document_id}`,
  `/api/rate-schedules`, `/api/appeals`.
- `POST /sql/query` requires header `Authorization: Bearer pa-review-token-014`
  and JSON body `{"sql": "<SQL>"}` (SQLite dialect). Response shape:
  `{"columns":[...], "rows":[...], "row_count":N, "max_rows":500, "limited":bool}`.
  **Check `limited`** — if true, narrow your query (add `WHERE`/`LIMIT`) until it
  is false so no rows are silently dropped.

Use `GET /api/tables` to confirm the current schema, then use SQL for joins and
targeted retrieval and the `GET /api/...` endpoints for single-record lookups.

## Procedure

1. **Read the three inputs.** Capture the target business ID, role, reporting
   date/period, and any task parameters. Note the exact required keys, enums,
   and ordering rules from the template.
2. **Classify the archetype.** From role + service domain + requested output,
   map to one of the archetypes in `references/task_archetypes.md`. This fixes
   the `source_precedence` rule and the business logic to apply.
3. **Gather evidence (network only).** Pull the target record and every related
   record the archetype needs. Prefer the **current/effective** record and
   identify any **stale/legacy alternative** that must be rejected or excluded.
   Apply date, `plan_type`, modifier, and version filtering to pick the
   controlling record.
4. **Compute the determination** per the archetype logic and the template's
   enums. Apply task_context parameters verbatim — e.g., use only the listed
   queue row IDs; the given threshold; the given total-cost definition; the
   given appeal window.
5. **Build the `basis_audit`** per `references/basis_audit.md`: pick
   `source_precedence` for the archetype; populate `controlling_record_ids`,
   `exception_record_ids`, and `precedence_record_order` using the prescribed
   orderings.
6. **Emit one JSON object** conforming to `answer_template.json`. No markdown,
   no comments, no prose outside the JSON. Follow
   `references/output_conventions.md` (list orderings, currency to cents,
   `null` for absent modifiers, date/ratio formats, integer units).
7. **Self-check** against the template: every required top-level key present;
   every enum value in the allowed set; every list in the specified order;
   `additional_fields_allowed` respected; numeric precision correct; no extra
   keys when disallowed.

## References

- `references/environment_and_data_model.md` — endpoint behavior, SQL wire
  format, and the full table/column data model.
- `references/task_archetypes.md` — the task archetypes, what each reviews, key
  outputs, and the `source_precedence` mapping.
- `references/basis_audit.md` — the `basis_audit` structure and ordering rules
  (identical across all templates) plus the `source_precedence` decision table.
- `references/output_conventions.md` — JSON-only output, list orderings, and
  numeric/date/null conventions.