| name | cedar-ridge-intake-coordination |
| description | Produce the strict-JSON deliverable for any Cedar Ridge Intake Coordination Portal task — primary-care access verification, referral readiness/activation audits, dialysis transfer packet review, and chronic-care program enrollment panels. Use whenever a prompt points at the Cedar Ridge Intake Coordination Portal (a base URL) plus an input/payloads/answer_template.json and asks for a single JSON object keyed by a roster_id, batch_id, or program_code. Covers how to reach the read-only REST + SQL endpoints, the shared data model, per-item classification rules, cohort/summary rollups, and the output contract. |
Cedar Ridge Intake Coordination — reusable operating guide
Every task in this family has the same shape:
- A short prompt names one work unit — a roster (
NPI-…), a referral
batch (ORTHO-…, PULM-…, CARD-…, …), a transfer batch (DIAL-…), or a
program (DMHTN-…, RENAL-…, COPD-…, CAD-…) — and points at the Cedar
Ridge Intake Coordination Portal at <TASK_ENV_BASE_URL>.
input/payloads/answer_template.json defines the exact output shape and
the controlled vocabulary (allowed enum values, required keys, ordering).- You must read portal data, classify each item, roll up cohort counts, and
return one JSON object, JSON only, no prose, that conforms to the template.
The template is the contract. The portal is the source of truth. Your job is to
join the right tables, apply the classification rules, and reconcile the counts.
1. Golden rules (do these every time)
- Re-read the task's
answer_template.json first. Treat its
required_*_keys, allowed_values/allowed, required_value/constant,
and ordering as authoritative. Never emit a key or enum value not listed
there. The controlled vocabulary is self-describing — a code named
coverage_expired, missing_imaging, or consent_missing tells you exactly
the condition it represents.
- Parameterize by the id in the prompt/template. The work-unit id
(
roster_id/batch_id/program_code) and any constant task_id come from
the prompt and the template's required_value/constant/expected_value
fields — copy those verbatim. Do not hardcode ids or dates from prior runs;
a held-out task will use a different id (e.g. NPI-JUL-02, ORTHO-JUL-04,
DIAL-FALL-03, RENAL-DM-2026B).
- Cover exactly the roster's members. Include a row for every member the
portal returns for that work unit, and no others. For rosters, the member
list and the
requested_service_date + service_line come from the
intake_rosters rows for that roster_id (not from the prompt text).
- Ordering matters. Sort every list exactly as the template says (usually
ascending by
patient_id / referral_id / transfer_id / group_id).
Where the template says "unordered set" for a code array, order is not graded
but stay consistent; where it says alphabetical (e.g. dialysis
missing_required_documents, activation artifacts_to_create), sort the
strings.
- Reconcile counts. Every summary/cohort count must equal what you can
recompute from the item list (per status, per risk, per urgency, totals). A
mismatch between the detail rows and the summary is the most common failure.
Cross-tab lists (e.g.
counts_by_urgency_and_status) should enumerate the
template's key order and may include explicit zero rows if the template's
key set is fixed.
- Emit JSON only. No markdown, no commentary, no trailing text. IDs keep the
portal's exact casing (uppercase
REF0001, P001, etc.).
- Dates are
YYYY-MM-DD strings. Compare dates as calendar dates. Use the
work unit's own reference date (roster requested_service_date, transfer
requested_start_date, program candidate_date/as-of) — see each playbook.
2. Reaching the portal
Base URL is provided per task (environment_access.md →
GDPEVO_ENV_BASE_URL, shown in prompts as <TASK_ENV_BASE_URL>).
Credentials: none. Everything is read-only.
Two equivalent ways to read; prefer whichever makes the join cleanest. The SQL
endpoint is usually fastest for batch joins and exact reconciliation.
- REST (GET):
/patients, /patients/{id}, /referrals (filter
?batch_id=&service_line=&limit=), /referrals/{id}, /transfers
(?batch_id=), /transfers/{id}, /documents, /chart/{patient_id}
(bundles patient + chart_artifacts + clinical_history), /icd/{code},
/pharmacies, /programs/{program_code}/candidates. GET /health returns
table row counts — a useful sanity check.
- Read-only SQL:
POST /query with body {"sql": "SELECT …"}. Only
SELECT / read-only PRAGMA are allowed (writes are rejected). Returns
{columns, rows, row_count, truncated}. Use LIMIT and paginate if
truncated is true.
Example:
curl -s -X POST "$BASE/query" -H 'Content-Type: application/json' \
-d '{"sql":"SELECT * FROM referrals WHERE batch_id = ?BATCH? ORDER BY referral_id"}'
The full table schemas, column enums, and per-archetype join recipes are in
references/data_model.md. The step-by-step classification logic for each
of the four archetypes is in references/task_playbooks.md. Read both
before writing output.
3. Identify the archetype, then follow its playbook
Match the prompt/template to one of four archetypes and apply the matching
section of references/task_playbooks.md:
| Signal in prompt / template top keys | Archetype | Key tables |
|---|
roster_id, service_line, patient_results, insurance/prescription/pharmacy/risk | A. Primary-care access verification | intake_rosters, coverage, pbm, patient_pharmacy+pharmacies, lifestyle, patients |
batch_id, referral_reviews/readiness_by_referral, icd/duplicate/auth/imaging | B. Referral readiness / chart activation | referrals, icd_codes, (documents) |
batch_id DIAL-…, packet_completeness, stale_documents, requested_start, chairs | C. Dialysis transfer packet review | transfer_requests, documents, facility_capacity |
program_code, patients[].enrollment_status, reason_codes, monitoring package | D. Chronic-care program enrollment | program_candidates, chart_artifacts, clinical_history, patients |
Archetype B has two closely related variants — a batch audit (duplicate
groups, shared-insurance anomalies, action plan, urgency×status summary) and a
referral-to-chart activation file (readiness, chart needs, correspondence
queue, priority order). Both read the same referrals/icd_codes data; let the
template's top-level keys tell you which outputs to produce.
4. General decision scaffolding (applies across archetypes)
These structural patterns recur; the playbook gives the field-level specifics.
- Readiness / registration / decision status is the worst-severity outcome
across that item's blockers. Something with a hard blocker is
blocked/rejected/hold; something clean is ready/approved/accept;
items needing human judgement are under_review/clinical_review; purely
clerical items are admin_followup. Map to the exact enum the template lists.
- A code array is the set of every condition that is true for that item,
drawn only from the template's allowed list. Empty list when nothing applies.
- Priority tiers: clinical/urgent + blocked →
tier_1_immediate; substantive
but non-urgent follow-up → tier_2_short_term; clerical/administrative →
tier_3_administrative. Some templates allow null tier for already-ready
items — check enum_or_null.
- Missing vs. invalid vs. stale: missing = the row/record does not exist;
invalid = it exists but fails its rule; stale = it exists and is otherwise
valid but older than its freshness window relative to the reference date.
- Contact routing / outreach channel follows the member's stated preference
(
patients.preferred_contact or program_candidates.preferred_outreach), and
falls back / becomes none when the preferred channel's contact value is
absent.
Always finish by recomputing the summary from your own item rows and confirming
every template-required count key is present (including zeros).
5. Self-check before returning
