# Self Attempt 01 > Cedar Ridge Intake Coordination - Skill: `prism-shadow/self-attempt-01-17` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add prism-shadow/self-attempt-01-17` - Raw SKILL.md: https://api.skillmd.com/api/skills/prism-shadow/self-attempt-01-17/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: prism-shadow (https://skillmd.com/u/prism-shadow) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/prism-shadow/self-attempt-01-17 --- # Cedar Ridge Intake Coordination The Cedar Ridge Intake Coordination Portal is a shared, read-only store of intake, referral, transfer, chart, and program data. A task in this family gives you a **prompt** (`prompt.txt`) and an **answer template** (`input/payloads/answer_template.json`), and asks for one JSON object built from portal evidence. The work is always the same shape: **scope → gather → map → summarize → emit JSON**. The rules below are reusable across every batch, roster, and program. Do not hardcode any task-specific final values (statuses, reason codes, counts, dates) — derive every value from the portal and the template. ## 1. Read the contract first Before touching the network, read `prompt.txt` and `answer_template.json` end to end. The template is the contract. From it, extract: - **Scope identifier and entity list** — the `roster_id` / `batch_id` / `program_code` named in the prompt, plus which entities (patient_ids, referrals, transfers, candidates) must be covered. The prompt always supplies the identifier; the entity list comes from the portal (or from a roster payload, if one is staged). - **Required top-level keys** and any **constant values** the template pins (`task_id`, `batch_id`, `roster_id`, `program_code`). Emit those constants verbatim. - **Per-item keys** and the **controlled vocabulary** (`allowed_values` / `allowed`) for every enum, reason code, and blocker code. You may only emit values from these lists. - **List ordering** per field — ascending by id, alphabetical by code, or "unordered set". - **Summary count keys** — which buckets the cohort summary must contain (include zero counts). ## 2. Connect through the documented access only Resolve the base URL from `environment_access.md` (it points at the running portal). Use **only** the endpoints listed there — the REST `GET` collection plus `POST /query` (read-only SQL). No authentication. Never call `/health` or any reset/reseed endpoint. See `references/endpoint_catalog.md` for params and response shapes. ## 3. Scope, then gather evidence per entity Filter by the prompt's scope identifier and ignore everything else. The portal contains **distractor rows** (rows whose `notes`/`status_note` literally say "distractor") and rows belonging to **other batches/rosters/programs**. Filter strictly on the scope identifier; an out-of-scope row is noise even if it looks relevant. Evidence-gathering pattern (pick REST or SQL per need — they expose the same tables): - **List + filter**: `GET /referrals?batch_id=…`, `GET /transfers?batch_id=…`, `GET /programs/{code}/candidates`, `GET /patients?q=…`. List responses are paginated (`limit`, default low) — raise `limit` or page until you have the full scoped set. - **Patient detail is the hub**: `GET /patients/{id}` aggregates coverage, pbm, pharmacies, lifestyle, clinical_history, rosters, referrals, transfers, documents, chart_artifacts, and program_candidates for that patient. Use it as the primary source for patient-scoped tasks instead of re-joining by hand. - **Detail lookups**: `GET /chart/{id}` (active problems, meds/allergies, recent vitals/labs, chart artifacts), `GET /icd/{code}` (chapter, description, laterality, service_family), `GET /pharmacies` (network_status by pharmacy_id). - **Reconcile with SQL**: `POST /query` with a JSON body `{"sql": "SELECT …"}`. Use it for cross-entity grouping (duplicates, shared insurance), counts, and joins across the full table set — see `references/data_model.md` for tables/columns. Response is `{columns, row_count, rows, truncated}`; check `truncated` and raise limits if set. ## 4. Map evidence → controlled values with deterministic rules Apply the **same** rule to every entity so results are consistent and auditable. The field-to-enum mappings are fixed per task family and live in `references/decision_rules.md` (e.g. coverage → `insurance_status`; ICD `service_family` vs referral `service_line` → `icd_chapter_mismatch`; `records_received`/`imaging_received` → missing-records/imaging blockers; `auth_status` → auth blocker; `facility_capacity.open_chairs` → feasibility; `existing_chart` + chart artifacts → `chart_action`). Never infer a status you cannot trace to a field; when evidence is genuinely absent, use the template's "missing/unknown" enum rather than guessing. ## 5. Detect cross-entity anomalies Group across the scoped set, not per row: - **Duplicate referrals**: same `patient_id` + same `service_line` + overlapping ICD/reason within the batch → one `duplicate_group`, pick a `primary_referral_id`, recommend `consolidate_to_primary` or `keep_separate`. - **Shared insurance**: group referrals by `insurance_id`; an id shared across **different** `patient_id`s is an anomaly (`verify_distinct_patient_policy_id`), across the **same** patient is `legitimate_duplicate_same_patient`. - SQL `GROUP BY … HAVING COUNT(*) > 1` is the reliable way to find both. ## 6. Ordering, IDs, and counts - Order every list exactly as the template specifies. For "unordered set" arrays (reason codes, blocker codes, issue codes), emit a stable sorted order anyway so output is deterministic. - Use **uppercase IDs exactly as the portal returns them** (`REF0035`, `P001`, `TR0026`). Do not reformat or lowercase. - **Cohort summary must reconcile**: every count is an integer, every required bucket is present (zero where applicable), and totals add up (e.g. `total_patients` == sum of `counts_by_registration_status`). See `references/output_contract.md`. ## 7. Emit one JSON object, JSON only The final answer is a **single JSON object** conforming to the template. No prose, no markdown fences, no trailing commentary, no keys outside the template. Re-validate before finalizing: every required key present, every enum value in `allowed_values`, every list correctly ordered, every count correct, no pinned constant changed. ## References - `references/endpoint_catalog.md` — portal endpoints, query params, response shapes. - `references/data_model.md` — SQL tables/columns and the field → concept map. - `references/decision_rules.md` — per-task-family evidence → enum/code mappings. - `references/output_contract.md` — JSON discipline and the pre-submit self-check.