# Cedar Ridge Intake Reconciliation > Reconcile Cedar Ridge Intake Coordination Portal tasks and produce schema-valid JSON for patient access verification, referral readiness or activation audits, dialysis transfer packet reviews, and chronic-care enrollment panels. Use when a task references the Cedar Ridge portal, an environment_access.md base URL, intake rosters, referral batches, transfer batches, program candidates, chart artifacts, ICD metadata, documents, pharmacies, or read-only SQL reconciliation. - Skill: `prism-shadow/cedar-ridge-intake-reconciliation-3` (Agent Skill) - Install (CLI): `npx skillmds@latest add prism-shadow/cedar-ridge-intake-reconciliation-3` - Raw SKILL.md: https://api.skillmd.com/api/skills/prism-shadow/cedar-ridge-intake-reconciliation-3/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Data & Analytics - Author: prism-shadow (https://skillmd.com/u/prism-shadow) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/prism-shadow/cedar-ridge-intake-reconciliation-3 --- # Cedar Ridge Intake Reconciliation ## Core Workflow 1. Read the user's prompt and every file under `input/payloads/`, especially `answer_template.json`. 2. Read `environment_access.md` when present and use only its base URL and listed endpoints for network access. Substitute any `` placeholder with that base URL. Credentials are normally absent unless the file says otherwise. 3. Identify the target object from the prompt/template: roster, referral batch, transfer batch, program code, or explicit patient/referral/transfer IDs. 4. Query the portal for the complete target cohort before reasoning. Prefer `POST /query` for compact joins, and use detail endpoints such as `/patients/{id}`, `/referrals/{id}`, `/transfers/{id}`, `/chart/{patient_id}`, `/icd/{code}`, `/documents`, and `/pharmacies` to confirm ambiguous fields. 5. Build the JSON strictly from the template: required top-level keys, controlled values, nullability, ordering rules, and summary/count keys. Do not emit prose outside JSON when the task asks for JSON only. 6. Derive every ID, date, count, and row from the current prompt/template/environment. Never reuse literal values from examples or prior tasks. Useful portal tables exposed through read-only SQL include `patients`, `intake_rosters`, `coverage`, `pbm`, `patient_pharmacy`, `pharmacies`, `lifestyle`, `clinical_history`, `referrals`, `icd_codes`, `documents`, `transfer_requests`, `facility_capacity`, `program_candidates`, and `chart_artifacts`. ## General Validation - Treat `answer_template.json` as the output contract even when endpoint data uses different field names. - Sort each list exactly as the template specifies. Common orders are ascending `patient_id`, `referral_id`, `transfer_id`, or `group_id`; priority lists use the template's priority definition. - Treat reason-code, issue-code, and blocker-code arrays as unordered sets unless the template gives an ordering. - Recompute summary counts from the completed item rows, not from separate assumptions. - Include empty arrays and zero-valued count buckets when the template requires them. - Use `null` only where the template permits it. ## Access Verification For new-patient roster verification, join the roster to patient identity, coverage, PBM, preferred pharmacy, lifestyle, and clinical history records. - Use the roster row for `requested_service_date` and `service_line`. - Mark insurance valid only when a coverage record is active for the requested service date and includes the requested service line. Flag expired, pending, missing, or excluded-line cases with the template's matching reason codes. - Mark prescription benefits valid only when PBM data is present, active, approved, and covered. Rejected, pending, inactive, not-found, review, missing, payer/policy mismatch, or specialty-policy conflicts should map to the closest PBM reason code allowed by the template. - Use the patient's first preferred pharmacy by `preference_rank`; map its pharmacy `network_status` to in-network/out-of-network/unknown. - Score lifestyle risk from smoking, alcohol, exercise, and sleep. Current smoking, heavy alcohol, absent exercise, or very low sleep increase risk; multiple adverse factors usually become high. - Score overall risk from lifestyle risk plus clinical burden such as high medication count, recent hospitalization, risk flags, and major access blockers. - Registration status should follow blocker severity: hard coverage/service-line conflicts reject, remediable administrative or benefit issues hold or clinical-review, high clinical risk routes to clinical review, and clean low-risk rows approve. ## Referral Readiness And Activation For referral batch audits, query the target batch and reconcile each referral with ICD metadata, patient/chart information, documents, authorization fields, appointment fields, duplicate patterns, and shared insurance IDs. - Use `/icd/{code}` or `icd_codes` to compare referral `service_line` with ICD `service_family`, expected chapter, narrative, and laterality. - Clinical code discrepancies include wrong service family/chapter, mismatch between referral reason or diagnosis text and ICD meaning, and laterality conflicts. - Records and imaging blockers come from `records_received` and `imaging_received`. - Authorization blockers apply when authorization is required and the status is denied, pending, not submitted, or otherwise not cleared. - Existing scheduled appointments before clearance should be flagged with the template's appointment/hold reason. - Duplicates usually share patient, insurance, referring contact, reason, or a "duplicate" note. Keep the earliest or primary referral unless the task gives another rule. - Shared insurance anomalies are shared insurance IDs across distinct patients; shared insurance on duplicate referrals for the same patient is usually a legitimate duplicate. - Readiness precedence: no issues is ready; records/imaging/auth blockers are blocked; clinical-code, duplicate, or scheduled-before-clearance issues are under review unless combined blockers make the template call for blocked; pure administrative insurance/contact issues are administrative follow-up. - Map issues to action or correspondence codes using the template vocabulary. Urgent clinical discrepancies are highest priority, clinical/admin blockers usually follow, and pure administrative verification is lowest. ## Dialysis Transfer Packet Review For transfer batches, gather transfer requests, packet documents, patient records, and facility capacity for the requested start date and modality. - A required packet item is complete only when the document exists for the transfer/patient and is finalized/final. Draft, absent, or non-final documents count as missing. - For stale checks, compare `received_date` with the requested start date. Common freshness windows are 30 days for current dialysis labs/infectious-screening/PPD-CXR style items and 365 days for history and physical; use task/template wording if it gives a different limit. - Capacity is available when the sum of `facility_capacity.open_chairs` for the requested date and modality is greater than zero. - Feasibility combines packet readiness and capacity: ready on requested start only when the packet is complete/fresh and capacity is available; otherwise choose the template value matching packet-not-ready and/or capacity-unavailable. - Intake decision should accept only fully ready transfers with capacity. Missing or stale clinical packet items usually require clinical review; capacity-only issues route to scheduling or hold; administrative-only missing items route to intake coordination. ## Chronic-Care Program Panels For program candidate panels, load `/programs/{program_code}/candidates`, then join each candidate to patient, chart artifacts, and clinical history. - Eligibility depends on the program target condition and active clinical history. For diabetes/hypertension panels, require both active diabetes and hypertension evidence unless the task defines another target. - Consent declined usually rejects. Missing consent or inactive/missing chart data usually holds unless combined with wrong target condition, which rejects. - Missing chart artifacts come from absent or stale `chart_artifacts` rows for the artifact types required by the template. Treat `status != current` as needing refresh. - High-touch monitoring is appropriate for recent hospitalization, recent ED/risk flags, very low adherence, or other high-risk clinical markers. CKD commonly routes to biweekly monitoring. Stable eligible candidates can use monthly or standard monitoring. - Outreach should follow the candidate or patient preferred channel when usable; fall back only when the preferred channel has no usable phone/email/portal information and the template permits another channel. - Initial monitoring packages should match disposition: high-touch for high-risk enrollment, standard for stable enrollment, deferred for holds needing consent or chart updates, and not applicable for rejects. ## Output Discipline Before finalizing, parse the JSON locally if possible and check: - All required keys from the template are present. - All controlled values are from the template. - Every required target row is included exactly once. - Summary counts equal the row-level data. - No task-local answer constants or example rows have been copied from prior work.