| name | harborview-clinic-protocol-answers |
| description | Use for protocol-bound clinical decision-support tasks against the Harborview synthetic-clinic runtime API. Each task names a target case id and provides an answer_template.json contract; the job is to retrieve the case from the clinic runtime, apply the case's machine-readable clinic protocol, filter out seeded distractor records, and emit exactly one JSON object that conforms to the template. Covers the recurring families: adult respiratory / CAP assessment, pediatric head-injury triage, potassium repletion & escalation, care-management routing, and observation-window / protocol-gate retrieval. |
Harborview synthetic-clinic protocol answers
A task in this family gives you: (1) a prompt.txt naming a target case id and
what to decide, and (2) input/payloads/answer_template.json — the exact output
contract. Network access (base URL + allowed endpoints) is in a separate
environment_access.md. Your deliverable is one JSON object matching the
template, with no prose around it.
The answer is never a matter of general clinical judgment. Every scored field is
determined by the case's data in the runtime plus the case's protocol (also
in the runtime). Retrieve both, apply the protocol literally, and format to the
template.
Golden rules
- The template is the contract. Read
answer_template.json end to end first.
Match required_top_level_keys exactly, add no extra top-level keys, and for
every field honor its type, allowed_values (enums), precision/unit,
nullability, and ordering. Emit an enum value only if it appears in that
field's allowed_values.
- The protocol is the source of truth — not your medical knowledge. Fetch the
governing protocol and apply its stated thresholds, codes, triggers, and rules
verbatim. Do not invent cutoffs or substitute textbook defaults.
- The environment is full of distractors. Decoy cases (
CASE-D30xx),
patients (PAT-D20xx), and observations tagged "source": "generated distractor feed" exist to trap you, alongside wrong-code / wrong-status / out-of-window
rows. Scope strictly to the target case_id/patient_id, the correct code,
status == "final", and the correct time window.
- Never claim what the record does not show. Only assert positive findings the
retrieved evidence supports. Anything not in the record is absent/negative.
Safety-check booleans encode this (see step 7).
- Output is machine-graded. Return exactly one JSON object — no markdown,
comments, or explanatory text; ISO-8601 UTC timestamps with trailing
Z;
numbers rounded to the stated precision; null only where the spec permits.
Procedure
1. Establish identifiers
case_id: from the prompt (and any required_value/expected_constant in the
template — they must agree).task_id: if the template pins it via expected_constant/required_value, use
that; otherwise use this run's task identifier (the task/folder name).patient_id: do not guess — read it from the retrieved case record
(step 2). It is a stable clinic id like PAT-####.
2. Retrieve the case bundle
GET {BASE}/api/cases/{case_id} returns an aggregated bundle and is the backbone
of every task. It contains:
case — patient_id, case_type, service_date, status, summary.findings — non-lab facts as {finding_key, finding_value, source_id},
including current_time (the clinical review time; source like
TASK-CLOCK-*), symptoms, exam/ECG, and contraindication notes. Use
current_time from here — not the wall clock.allergies, medications, observations, imaging, care_registry (and, via
the collection endpoints, sdoh / problems).
Supplement with collection endpoints when you need to confirm scoping or list
distractors, e.g. GET /api/observations?case_id=... or ?patient_id=...,
/api/medications, /api/allergies, /api/problems, /api/imaging,
/api/care-registry, /api/sdoh. (POST /api/query needs a clinic token that is
usually not provided — rely on the GET endpoints.)
3. Retrieve and parse the governing protocol
GET {BASE}/api/protocols lists protocols; pick the one whose title matches the
case type, then GET {BASE}/api/protocols/{protocol_id} for its machine-readable
body. The body carries the decision logic: target values, controlled_codes
(LOINC / NDC / local codes), urgent / red-flag triggers, authoritative_statuses
(final), excluded_statuses, ordering, follow-up hours, and dosing rules.
Treat the live body as authoritative — thresholds are versioned and may differ from
any example in this skill.
See references/task-families.md for how each case type maps its protocol body onto
its template fields.
4. Filter to the truth set
Before computing anything, reduce the retrieved rows to what actually qualifies:
- Ownership:
patient_id / case_id equals the target.
- Code: matches the protocol's controlled code for the quantity in question
(e.g. serum potassium
K vs. a distractor LOINC).
- Status:
final only for protocol gates; route preliminary,
entered-in-error, canceled (and other non-final) to the excluded set.
- Window (when a window applies):
from inclusive, to exclusive —
[from, to).
- Latest: the qualifying
final row with the greatest effective_time; break
ties per the protocol ordering (effective_time asc, then observation_id asc).
Keep track of the excluded ids and why (wrong owner / code / status / date) — some
templates ask you to list them.
5. Apply the protocol to fill scored fields
Compute assessment / risk / disposition / plan / gate strictly from the filtered
evidence and the protocol rules. When a contraindication or urgent trigger fires,
the protocol's safe branch wins (escalate or hold rather than treat). Select each
enum from the template's allowed_values; leave lists empty (not null) when nothing
applies, unless the field is explicitly nullable.
6. Assemble evidence_ids
Cite the actual identifiers you relied on — observation_ids, source_ids from
findings, the case_id, the protocol_id, medication/imaging ids — following that
template's ordering rule (e.g. "case id first, then clinical sources", or
"descending relevance", or a specified sort). Do not include ids you did not use.
7. Set safety-check / provenance booleans honestly
Safety-check keys are compliance assertions. A key like no_false_loc,
no_false_vomiting, no_normal_cxr_claim, or no_clear_lungs_claim is true
when you did NOT make that unsupported claim — i.e. you complied. Make your output
actually comply (avoid contraindicated drugs, don't assert unshown findings), then
set the booleans to reflect the truth of what you emitted. For care-management-style
provenance splits, separate facts present in the chart from facts that would require
the member to disclose them.
8. Validate and emit
Run the checklist in references/output-contract.md, then print exactly one JSON
object. No leading/trailing prose, no code fences.
References
references/data-model.md — endpoints, response shapes, distractor patterns.references/task-families.md — the five recurring case types and how each
protocol body maps to its template.references/output-contract.md — pre-submit validation checklist.
