Skip to content

Attribute-context resolution

An attribute’s tag, VR, and VM are registry facts. Its requiredness comes from how PS3.3 uses it in a module, macro, functional group, or IOD.

The contextual resolver brings those layers together.

A request identifies:

  • an attribute by tag, keyword, or name;
  • a concrete edition;
  • an IOD or SOP Class context.

A SOP Class is resolved through imported PS3.4 links to one or more IODs.

attribute input
-> PS3.6 data element
-> selected IOD context
-> applicable module and macro paths
-> matching attribute-use rows
-> declared types and condition text
-> bounded effective-type analysis

Every layer retains source references.

A declared type belongs to one imported attribute-use row.

An effective type is a resolver result for the selected context after comparing all applicable uses and bounded override language.

These are not interchangeable.

When one applicable use remains, its declared type can be reported as the effective type.

The response still retains the use row and its source reference.

When multiple uses apply, the resolver evaluates the DICOM lowest-type rule and inspects matched descriptions and condition text for explicit type override phrases.

A deterministic phrase such as “shall be Type 1” can override the base comparison when it is linked to the applicable use and source reference.

The resolver leaves effective_type null when:

  • applicable rows conflict;
  • override language is ambiguous;
  • an override cannot be linked uniquely;
  • required context is missing;
  • graph resolution leaves multiple incompatible paths.

Warnings explain the boundary. The correct downstream behavior is to inspect the cited source, not to guess.

A condition can depend on:

  • values in a particular instance;
  • implementation choices;
  • acquisition or modality state;
  • relationships not represented by the current query input;
  • prose semantics too broad for a deterministic parser.

That is why contextual responses are classified as partially decidable even when an effective type is returned.

A validator can use the resolver to identify candidate requirements and source rules. It still needs instance context and implementation logic to evaluate many conditional requirements.

The project supports validation workflows; it does not provide official conformance certification.