TEDY.10 — Defined Properties

State: Built — list + create/edit form (standard ResourceList + ResourceForm). Template: tool-feature. Prefix: TEDY.

Overview

A Defined Property is a globally-registered property/designation definition that code systems reference by name — the shared vocabulary behind concept property values and designations. Served off /ts/defined-properties; numeric id. used is server-computed (true when at least one code system references the definition).

Data model (libs/tedy/src/lib/types/definedProperty.ts)

DefinedProperty { id?:number, name?, kind?, type?, uri?, description?:LocalizedName, rule?:PropertyRule, used?:boolean }.

• kind — property | designation.
• type — FHIR concept-property type (code, Coding, string, integer, boolean, dateTime, decimal).
• rule — PropertyRule { codeSystems?, valueSet?, filters? }; carried through unchanged, not edited in this slice (the reference edit form doesn’t edit it either).
• used — read-only; flagged with an info marker in the list.

DefinedPropertySearchParams extends QueryParams { textContains? }.

REST API (base /ts/defined-properties)

• GET /ts/defined-properties — paged search (textContains).
• GET /ts/defined-properties/{id} — load one.
• POST /ts/defined-properties (create) / PUT /ts/defined-properties/{id} (update) — saveDefinedProperty upserts by presence of id.
• POST /ts/defined-properties/{id}/update-related — re-propagate the definition to the code systems that use it (the list’s row action).

Client: libs/tedy/src/lib/client/definedPropertyClient.ts; hook: useDefinedProperties / useDefinedProperty / definedPropertyKeys.

Business rules / constraints

• A used defined property locks its identity (referenced by ≥1 code system): in the reference edit form, when used the name / URI / kind / type become read-only while the description stays editable — and there is no delete for defined properties at all. TEDY mirrors this exactly — those four fields get modeOverride:'view' when used (Save still applies the description change; subtitle: “In use by a code system — only the description can be changed.”), and the list has no delete action. used is server-computed, so the constraint is also enforced backend-side.
• Editing/adding requires *.DefinedProperty.write.

Screens

• List (pages/DefinedPropertyList.tsx, resource-list) — a standard ResourceList: Name (link, with a used info marker) · Description · URI · Kind (tag) · Type. textContains search; Add (gated *.DefinedProperty.write) → the form; per-row Update related properties action. No delete.
• Form (pages/defined-property/DefinedPropertyForm.tsx, resource-create/resource-management) — a standard ResourceForm with declarative sections: Name (required), URI, Kind (select), Type (select of the concept-property types), Description (localized). Create + edit; POST/PUT then return to the list.
  • When the property is used, name/URI/kind/type are locked (view) and only Description is editable; the whole form is view when the user lacks *.DefinedProperty.write.
  • The form mount is gated until the record loads into the dataController — ResourceForm seeds its antd form from dataController.current once at mount, so an async dc.load must complete before it first renders (a ready flag set in the load effect).

Routes & nav

/defined-properties (list), /defined-properties/new, /defined-properties/:id/edit. Nav: Terminology → Defined Properties (tedyMenu.ts).

Privileges

*.DefinedProperty.write gates Add / edit / update-related. Read is open (list/view).

i18n

tedy.definedProperty.* (fields.*, kind.*, list.*, validation.*, notifications.*, updateRelated, usedHint).