Self Attempt 01

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_ids 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.