Task Priority Detail Extension

Canonical	../StructureDefinition/nexus-task-priority-detail
Status	draft · 1.26.0
Base	Extension (constraint)
Context	Task.priority (element)
Source	FSH · JSON

A priority refinement finer than R4's request-priority vocabulary allows, currently one concept: trivial, meaning below routine. Task.priority binds required to a value set whose floor is routine and is a bare code with no second coding slot, so a refinement cannot be carried in the element itself. When this extension is present Task.priority SHALL be routine, so a consumer that ignores the extension sorts the task as routine -- an understatement rather than a mis-sort.

FSH

The authored source of truth: extensions/TaskPriorityDetail.fsh (edit on GitHub). One FSH file may define several related artifacts.

// TaskPriorityDetail.fsh
// A priority BELOW routine, carried alongside `Task.priority` because it cannot be carried in it.
//
// WHY AN EXTENSION, AND WHY THERE IS NO ALTERNATIVE. Two independent blockers, either one of which
// would be enough:
//
//   * `Task.priority` binds REQUIRED to `http://hl7.org/fhir/ValueSet/request-priority`, and a
//     profile may only make a binding stronger or narrow its value set. Relaxing required to
//     extensible is not a constraint, and a derived profile cannot do it.
//   * `Task.priority` is a bare `code`, not a `CodeableConcept`. There is no repeating `coding` to
//     add a second system to and no `text` to fall back on. Even with a relaxable binding there
//     would be nowhere to put a second vocabulary.
//
// So the base element keeps saying exactly what base FHIR lets it say, and the refinement rides
// beside it. `routine` is the FLOOR of request-priority (routine | urgent | asap | stat); nothing
// in R4 expresses "less than routine", and workflows keep asking for it -- a trivial to-do that
// should sort below the day's real work without being invisible.
//
// THE SAFE-DEGRADATION RULE, which is the point of the design. When this extension is present,
// `Task.priority` SHALL be `routine` (enforced by nexus-task-priority-detail-1 on the Task
// profile). A consumer that has never heard of this extension therefore reads `routine`, which is
// the nearest TRUE statement available in the base vocabulary -- it under-states the refinement
// instead of mis-sorting the task or failing to read it. An extension whose absence changes an
// item's rank is an extension that silently reorders a worklist for half its readers; this one
// cannot.
//
// The vocabulary is a CodeSystem rather than a fixed code because "below routine" is unlikely to
// stay the only refinement anyone asks for, and growing a code system is additive while widening
// a fixed value is not.

Extension: TaskPriorityDetail
Id: nexus-task-priority-detail
Title: "Task Priority Detail"
Description: "A priority refinement finer than R4's request-priority vocabulary allows, currently one concept: `trivial`, meaning below routine. `Task.priority` binds required to a value set whose floor is `routine` and is a bare `code` with no second coding slot, so a refinement cannot be carried in the element itself. When this extension is present `Task.priority` SHALL be `routine`, so a consumer that ignores the extension sorts the task as routine -- an understatement rather than a mis-sort."
* ^url = "../StructureDefinition/nexus-task-priority-detail"
* ^status = #draft
* ^context[0].type = #element
* ^context[0].expression = "Task.priority"
* value[x] only code
* value[x] 1..1
* value[x] from NexusTaskPriorityDetailsVS (required)
* value[x] ^short = "trivial (below routine)"