| name | ehr-governance-packet |
| description | Build the normalized JSON deliverable for an EHR quality-governance task — duplicate-merge readiness packet, referral coordination packet, care-transition packet, ServiceRequest/duplicate quality review, or referral-batch audit — by reading the case from input/prompt.txt, treating input/payloads/answer_template.json as the exact output contract, and pulling every value from the read-only EHR API described in environment_access.md. Use whenever a task references that API, an answer_template.json, patients/referrals/duplicates/service-requests, ICD-10 or provider directories, and asks for normalized JSON only. |
EHR quality-governance packet & audit builder
You produce one normalized JSON object for an EHR quality-governance case. Every
answer value comes from a live, read-only EHR API. The task ships an
answer_template.json that is the exact schema contract for your output.
Two rules that override everything else
- The environment is the only source of truth. Never invent, guess, or carry
over a value from an example, a previous case, or these instructions. If a field
is not derivable from the API, it does not go in the answer. Re-fetch rather than
assume.
- The template is the contract, not a suggestion. Match its top-level keys,
nesting, field names, value types, and
enum: vocabularies exactly. Emit JSON
only — no prose, no comments, no markdown fences around it. Do not add keys the
template does not define.
Workflow
- Read the case. Read
input/prompt.txt. Extract every case object ID it names
(patient IDs, duplicate-candidate ID, referral/batch ID, ServiceRequest ID,
provider ID, service line). Read all files under input/payloads/ — the
answer_template.json is the schema; any other payload (e.g. a
*_request.json) lists the requested outputs and confirms the case IDs.
- Read the template as a checklist. List its required top-level keys and, for
each field, its type and any
enum: / required_value / ordering note. If a
field declares a fixed literal (e.g. task_id → required value train_00X),
emit that literal verbatim.
- Connect. Read
environment_access.md for GDPEVO_ENV_BASE_URL and the
allow-listed endpoints. It is HTTP, no auth. Only GET the listed paths. Example:
curl -sS "$BASE/api/patients/{id}/conditions" | jq .
- Gather evidence. For each case object, GET its detail plus every related
endpoint the template needs (see
references/data-model.md). Fetch both
patients for a duplicate case; fetch active clinical lists, encounters,
documents, immunizations, disclosures, audit logs, referrals, ICD-10 codes,
service codes, and providers as the template demands. Prefer the authoritative
per-record endpoints over any embedded "preview" summary.
- Normalize & decide. Apply the cross-cutting rules in
references/normalization-and-decision-rules.md and the archetype logic in
references/task-archetypes.md: active-only filtering, normalized_key unions,
ICD-10 / service-code validation, evidence selection, distractor exclusion,
readiness/tiering, and enum selection driven by the evidence.
- Assemble & self-check. Fill the template. Run the QA checklist below. Output
the JSON object and nothing else.
Universal normalization & output rules
- Active-only clinical data. Condition/medication/allergy
*_key arrays and
"active list" outputs include only records with status == "active". Records with
status of inactive, entered-in-error, resolved, etc. are distractors —
exclude them (and list them in any excluded_* field the template provides).
- Normalized keys vs. display fields. For
*_keys / *_key fields use the
record's normalized_key. For human-readable blocks use the descriptive fields
(description, code, medication, allergen, display, provider name, …).
Deduplicate keys across records.
- Sets are sorted. Any array the template calls a set / says to sort: sort
ascending (alphabetical for strings, by
referral_id/code/normalized_key/id as
stated). Sort each nested id array too. Only keep insertion/relevance order where
the template explicitly says so (e.g. "referral-relevant first", "newest→oldest").
- Literals & enums. Never emit an enum value that is not in the template's list
for that field. Choose the value the evidence supports; see the archetype rules.
- Dates are
YYYY-MM-DD. IDs are copied verbatim from the records.
- Evidence, not narrative. Emit IDs and codes, not explanations, unless a field
is explicitly a free-text reason. Keep controlled reason-code strings as concise
lowercase
snake_case slugs derived from the evidence, sorted.
Archetype routing
Match the prompt to one archetype; full logic in references/task-archetypes.md.
| Signal in prompt / template | Archetype |
|---|
| duplicate candidate + two patients + "merge readiness / packet" | Duplicate-merge readiness packet |
| referral ID + patient + "coordination packet / letter fields" | Referral coordination packet |
| patient + recipient provider + "care transition / handoff" | Care-transition packet |
| duplicate candidate + ServiceRequest + "review outcome / quality signals" | Duplicate + ServiceRequest quality review |
| referral batch ID + "audit / tiers / follow-up queues / counts" | Referral-batch audit |
Final QA checklist (run before emitting)
References
references/data-model.md — endpoint catalog and record field shapes.references/task-archetypes.md — per-archetype gather + decision logic.references/normalization-and-decision-rules.md — cross-cutting derivation rules.
